6.2 Specification Exemplar and Application Guidelines
6.2.3 Demonstrative Example
A short demonstrative example of the R-TEA application includes the analysis of the specification exemplar for the RE-tool selection. Let’s say, it is important that an RE- tool would maintain the object oriented and structural modelling perspectives.
Figure 6.2 Specification Example of the Functional Features FEF1.2. The RE-tool should specify requirements using semi- formal language(s).
Description: The feature and its activities define the way how an RE-tool should specify requirements model using semiformal languages.
Children: FEF1.2.1 and FEF1.2.2 Traces to: NF2.1
Priority:___________________
FEF1.2.1. The RE-tool should provide tools for semiformal language description.
Description: Semiformal languages are used to create requirements model. The examples of these languages are ER-diagrams, OMT, UML, DFD, and others. The exact languages should be specified using non-functional process requirements.
Parent: FEF1.1
Priority:___________________
FEF1.2.2. The RE-tool should provide forward/ backward traceability between semiformal, and informal, formal descriptions.
Description: While having requirements definition in different representation languages, it is important to keep requirements uniqueness and maintain traceable relationships between different representation forms.
Parent: FEF1.1
RE-TOOL EVALUATION APPROACH
The evaluation process requirements include specification exemplar, two evaluation frameworks defined in Chapter 5, and the R-TEA method. The specification exemplar is also used as evaluation technique to test the RE-tool candidates. The first step is to prepare a requirements specification for the tool acquisition. It means analysing the frameworks and selecting the relevant framework features, activities and relationships (1a). Figures 6.2, 6.3, and 6.4 present a sample of specification exemplar. Figure 6.2 shows functional feature FEF1.2 and its activities. Figure 6.3 presents non-functional process feature NF1.2 and its activities. Figure 6.4 expands the relationship R1. Next step is the RE-tool requirements and relationship prioritisation (1b).
Figure 6.3 Specification Example of the Non-functional Features NF1.2. The RE-tool should support the selected modelling perspectives.
Description: Perspectives separate modelling language according to the core phenomena classes that are represented in the language.
Children: NF1.2.1, NF1.2.2, NF1.2.3, NF1.2.4, NF1.2.5, NF1.2.6, and NF1.2.7. Traced from: FEF1.1
Priority:___________________
NF1.2.1. The RE-tool should support structural modelling perspectives.
Description: The modelling languages, which support this paradigm are entity-relationship (ER) diagrams, and reference modelling language (RML).
Parent: NF1.2
Priority:___________________
NF1.2.2. The RE-tool should support functional modelling perspectives.
Description: The modelling language with a functional perspective is data flow diagrams (DFD). Parent: NF1.2
Priority:___________________
NF1.2.3. The RE-tool should support rule-based modelling perspectives.
Description: Example of the rule perspective language is goal-based approach to consider non-functional requirements and the external rule language (ERL).
Parent: NF1.2
Priority:___________________
NF1.2.4. The RE-tool should support behavioural modelling perspectives.
Description: There are two language-types commonly used: State transition diagrams (STD) and state transition matrices (STM), and Petri-Net.
Parent: NF1.2
Priority:___________________
NF1.2.5. The RE-tool should support communicational modelling perspectives.
Description: Persons cooperate within work processes through conversations and mutual commitments. Parent: NF1.2
Priority:___________________
NF1.2.6. The RE-tool should support object modelling perspectives.
Description: Examples of the object perspective are the object modelling techniques OMT and UML Parent: NF1.2
Priority:___________________
NF1.2.7. The RE-tool should support actor and role modelling perspectives.
Description: Examples of this paradigm are agent-oriented language (ALBERT) and (OORASS). Parent: NF1.2
Figure 6.4 Specification Example of the Relationships between Features In this example the simple importance priority scale of 0-to-10 is used, where 0 means unimportant and 10 means very important features. The outcome of the first phase is a requirements specification for the RE-tool evaluation (1c). Figure 6.5 shows that an object perspective is very important (priority set to 10) and UML should be maintained as modelling language. A structural perspective (and the ER diagrams) is less important to the user (priority 5). All other modelling perspectives are excluded from the further consideration. The RE-tool requirements priorities mean their importance to the RE-tool user. Later on priorities are used to calculate the overall evaluation score for the RE-tool.
The second phase involves the analysis of the RE-tool market and selecting the RE-tools for evaluation. For the purpose of this example two RE-tools are selected: − RE-tool_A (Figure 6.6) is a prototype described in Chapter 8.
− RE-tool_B (Figure 6.7) is an RE-tool described in (Kaindl, 2004).
In order to evaluate the RE-tool, the requirements specification is adapted to the evaluation form (Table 6.2) where the user is able to provide the evaluation score to the tools features and the comments on any evaluation issue. The evaluation form is used in all the phases of the RE-tool investigation.
The third and fourth evaluation phases involve testing of the RE-tools. The requirements specification (Figure 6.5) used here as testing techniques, is entered to both tools. RE-tool_A provides functionality to specify requirements informally. RE- tool_B uses hypertext as a means to represent requirements semiformally7 as discussed in (Snaprud and Kaindl, 1994). Both tools allow importing of files, which could maintain different information (including any requirements representations) about the requirements model. In addition RE-tool_B maintains export functionality of the requirements model to Rational Rose UML diagram.
The fifth phase is evaluation of the non-functional product requirements of the RE-tools. It is easy to notice that both RE-tool_A and RE-tool_B are quite complex to
R1.
Functional requirement Non-functional requirements Importance Languages
NF1.2.1 _________ NF1.2.2 _________ NF1.2.3 _________ NF1.2.4 _________ NF1.2.5 _________ NF1.2.6 _________ FEF1.2 NF1.2.7 _________
RE-TOOL EVALUATION APPROACH
tool reliability and efficiency of this functionality. The tool maintainability also remains questionable, because users should plug in the additional tools or they have to contact tool vendors for functionality extension which might be costly.
Figure 6.5 Requirements Specification constructed from the Example FEF1.2. The RE-tool should specify requirements using semi- formal language(s).
Description: The feature and its activities define the way how an RE-tool should specify requirements model using semiformal languages.
Children: FEF1.2.1 and FEF1.2.2 Traces to: NF2.1
Priority: 6
FEF1.2.1. The RE-tool should provide tools for semiformal language description.
Description: Semiformal languages are used to create requirements model. The examples of these languages are ER-diagrams, OMT, UML, DFD, and others. The exact languages should be specified using non-functional process requirements.
Parent: FEF1.1 Priority: 7
FEF1.2.2. The RE-tool should provide forward/ backward traceability between semiformal, and informal, formal descriptions.
Description: While having requirements definition in different representation languages, it is important to keep requirements uniqueness and maintain traceable relationships between different representation forms.
Parent: FEF1.1 Priority: 5 R1.
Functional requirement Non-functional requirements Importance Languages
NF1.2.1 5 ER diagrams
FEF1.2
NF1.2.6 10 UML
NF1.2. The RE-tool should support the selected modelling perspectives.
Description: Perspectives separate modelling language according to the core phenomena classes that are represented in the language.
Children: NF1.2.1 and NF1.2.6 Traced from: FEF1.2 Priority: 8
NF1.2.1. The RE-tool should support structural modelling perspectives.
Description: The modelling languages, which support this paradigm are entity-relationship (ER) diagrams, and reference modelling language (RML).
Parent: NF1.2 Priority: 5
NF1.2.6. The RE-tool should support object modelling perspectives.
Description: Examples of the object perspective are the object modelling techniques OMT and UML Parent: NF1.2
RE-TOOL EVALUATION APPROACH
Table 6.2 Example of Specification Exemplar (Evaluation results)
RE-tool_A RE-tools_B
Require- ments
Prio-
rity Evaluation Evaluation comments Evaluation Evaluation comments
Functional requirements FEF1.2 6 2 3 FEF1.2.1 7 2 4 FEF1.2.2 5 1 No functionality to create semi-formal representation. No maintenance of traceability, but the information of the same requirement is stored as one element.
3
Functionality to create semi- formal representation using hypertext. Tool maintains association and aggregation relationships, but they are defined only between informal representations. Process requirements
NF1.2 8 2 3 NF1.2.1 5 2 1 NF1.2.6 10 2
Imported files could maintain any requirements
representation using any
modelling perspective. 5
Requirements can be exported to Rational Rose UML format. No support for structural perspective.
Overall: 77 170
The sixth phase involves analysis of evaluation results from phases 3, 4 and 5. Table 6.2 shows results of tool evaluation. The tool evaluation is very subjective and it is based only on the user opinion. The overall evaluation is calculated as sum of multiplications between feature priority and tool feature evaluation. The result analysis should also take in account notices from non-functional product requirements evaluation. In this example, most probably, none of RE-tool_A and RE-tool_B would be acquired, and the user would have to reconsider the requirements specification (limit to the informal requirements representation), or to start with investigating the business parties and selecting new RE-tools for evaluation.