Table of Contents
Methodology for Requirements Engineering Techniques Selection (MRETS)
The requirements engineering process is part of the overall software lifecycle and plays an important role in ensuring the overall quality of a software product . Because of the complexity of software projects, as well as the multidisciplinary nature of requirements, requirements engineering (RE) imposes developers to carefully select RE techniques and practices during software development. However, these techniques are usually selected on the basis of personal preference or existing company practices, rather than on characteristics of the project at hand, and there is also a lack of guidance on which techniques are suitable for a certain project context. So, the selection of suitable RE techniques in the context of an application domain and in the context of a specific software project is a challenging issue faced by RE practitioners (Jiang, Eberlein, Far & Mousavi, 2008).
The use of the best combination of RE techniques will facilitate the RE process and contribute to the overall quality of the requirement specification. According to Jiang et al. (2008) improving the RE process leads in most cases to improvements in the productivity of large and medium-sized software organizations.
In Jiang et al. (2008) a set of 46 RE techniques were indentified in detail, these techniques cover all phases of the RE process and are used in MRETS. MRETS helps requirements engineers, to find a set of RE techniques that is suitable for a specific project based on the project’s attributes. MRETS has three advantages:
- 1. It aids requirements engineers in establishing a link between the attributes of the project and the attributes of RE techniques. Knowledge of and experiences with the RE techniques described in literature as well as from experts were elicited, documented and used during the research.
- 2. It is based on the detailed analysis and comparison of RE techniques using an evaluation schema and a clustering method that is widely used in other domains. The evaluation and clustering of techniques provide valuable information related to the similarity of techniques based on a given set of attributes.
- 3. The objective function used in the approach provides an effective decision support mechanism for the selection of RE techniques.
One of the fundamental assumptions behind MRETS is that appropriate use of RE techniques leads to high quality requirements specifications, which in turn results in high quality software products (Jiang et al., 2008). MRETS is based on previous research (Jiang., 2005)
MRETS exists out of the following process steps:
MRETS is supported by a RE process model that is proposed by Kotonya and Sommerville (Jiang et al., 2008), In order to provide a unified framework in the research for RE techniques selection products.
The method is developed by Dr. L.Jiang, Dr. A Eberlein, Dr. B.H. Far, & Dr. M. Mousavi. The developers have all an academic background. Dr. L. Jiang was during the development of the method supervised by Dr. A . Eberlein, and Dr. B. Far was a co-supervisor of Dr. L. Jiang. Dr. A. Eberlein and Dr. B. Far are both researchers in the department of Electrical and Computer Engineering of the American University of Sharja, United Arab Emirates. Dr. L. Jiang has the title of doctor of philosophy, and graduated also at the department of Electrical and Computer Engineering. Dr. M.Mousavi was a colleague of Dr. L. Jiang in the requirement engineering team at the university of Calgary, Canada (Jiang et al., 2005).
The following example describes one case study that shows the application of the MRETS approach to an industrial project in Company Trial.
Company Trail is a medium-sized software organization that worked on a Port Scheduling System. The PSS project took about one and a half year and had many non-functional requirements. With the approval of the organization’s management , the requirement engineers agreed to apply the MRETS approach to help select a set of suitable RE techniques for the PSS project (Jiang et al., 2008).
Process steps and Deliverables:
- 1. In this step, the requirements engineers score the attributes of the given PSS project. The scores can be an initial estimate based on the experience of the requirements engineers if detailed information about the project is not yet available. The most important attributes are described in Table 1.
| || Project attributes |
| Project size |
| Project complexity |
| Requirement volatility |
| Organization and customer relationship |
| Team size |
| Degree of knowledge of requirements |
- 2. In the second step, an initially recommended set of techniques (T_IR) (Table 2) is derived based on scored attributes (Table 3) and the rules in the requirement engineering process knowledge base (REPKB) using a case-based reasoning mechanism. The project attributes are compared with the project attributes of a previous project case that is almost similar.
| || Initially recommended set of techniques |
| Interview |
| JAD |
| Viewpoint-based analysis |
| Goal-based analysis |
| Scenario-based analysis |
| OO analysis |
| AHP |
| Viewpoint definition |
| Structured natural language specification |
| Viewpoint validation |
| Formal requirement inspection |
| || Selected technique attributes || Weight of the attributes |
| Ability to help get domain knowledge || 4 |
| Ability to help identify stakeholders || 4 |
| Ability to help identify non-functional requirements || 4 |
| Ability to help model and understand requirements || 5 |
| Ability to help analyze non-functional requirements || 5 |
| Ability to help model interface requirements || 5 |
| Ability to help requirements verification || 5 |
| Ability to help get implicit knowledge || 4 |
| Ability to help write unambiguous and precise requirements by using the notations || 4 |
| Ability to help write complete requirements || 5 |
| Ability to help with requirements management || 4 |
| Ability to help identify interactions (ambiguous, inconsistency, conflict) || 3 |
| Maturity of supporting tools || 5 |
- 3. Analysis of RE techniques using the clustering method. The major task in this step is to analyze all the techniques in REPKB using the clustering mechanism (Table 4).
| || Selected technique attributes |
| Cluster 1 || Cluster 2 || Cluster 3 |
| Interview || Evolutionary prototypes || Viewpoint-based documentation |
| Contextual inquiry || Exploratory prototypes (throw-away prototypes) || Structured natural language specification |
| Brain-storming || eXtreme programming (XP) || eXtreme programming (XP) |
| Viewpoints-based elicitation || || |
- 4. Analysis of the techniques and construction of the recommendation space (T_RS)(Table 5). In this step, the requirement engineers construct the technique recommendation space including potentially suitable techniques for the project.
| || Technique recommendation space |
| Initially recommendation techniques |
| Functionally complementary techniques |
| Prospective techniques |
| Functionally comparable techniques |
- 5. Calculations based on the objective function. In this step, the requirement engineers select the most promising combinations (Table 6) of RE techniques from T_RS based on the calculation of the objective function. The combination with the highest score will the final recommendation.
| || Technique combination |
| No. || Technique combination || Elicitation technique || Analysis & Negotiation Technique || Documentation Technique || Verification & validation Technique || Sum of ability scores |
| 1. || T_1 || Interview, Focus Group, Ethnography || Viewpoint-based analysis, AHP || Structured natural language specification || Viewpoint validation || 12,6 |
| 2. || T_2 || Interview, Focus Group, Ethnography || OO Analysis, AHP || Viewpoint-based definition || Formal requirements specification || 14,6 |
| 3. || T_3 || Interview, Focus Group, Ethnography || Scenario-based analysis, AHP || Structured natural language specification || Formal requirements inspections || 13,6 |
| 4. || T_4 || Interview, Focus Group, Ethnography || Viewpoint-based analysis, AHP || Viewpoint-based definition || Formal requirements inspections || 15,6 |
Template Final Decision
- 6. Refinement of the recommended techniques selection. In this step, the final recommendation T_C (Table 7) is adjusted according to the experience of the requirements engineers. Checking the consistency ensures that the recommended techniques are not mutually exclusive. This results in a final decision see Attachment Final_Decision.
| || Final recommendation space |
| Categories || Initial recommendation || Final recommendation || Final decision |
| Elicitation Technique || Interview, JAD || Focus Group, Interview, Ethnography || Focus Group, Interview, Ethnography |
| Analysis & Negotiation technique || Viewpoint-based analysis, Scenario- based analysis, AHP || Viewpoint-based analysis, AHP || Viewpoint-based analysis |
| Documentation technique || Viewpoint-based definition, Structured natural language specification || Viewpoint-based definition || Viewpoint-based definition |
| Verification & Validation technique || Viewpoint validation, Formal requirements inspection || Formal requirements inspection || Formal requirements inspection |
Process- Deliverable Diagram
In Weerd & Brinkkemper (2009) a technique is described that can be used for modeling
activities and artifacts of a certain process. The type of modeling that is described is called meta-modeling, because it models methods and not the artifacts of an information system, The meta-models of a method can be expressed in a Process-Deliverable Diagram (PDD). It consists of two integrated diagrams, on the left side the process view and on the right side the deliverable view. The process view is based on a UML activity diagram and shows all activities that are executed in a certain order. The deliverable view is based on a UML class diagram and shows which products should derive from the activities. The PDD is illustrated in Figure 1. There is also an Activity table and a Concept table in Table 8 and 9.
MRETS Activity diagram
| || Activity || Sub activity || Description |
| Scoring project attributes || || The requirements engineers score the PROJECT ATTRIBUTES. The scores can be an initial estimate based on the experience of the requirements engineers if detailed information about the project is not available yet (Jiang et al., 2008). |
| Derivation of initially recommended techniques || || An initially recommended set of techniques is derived from the scored PROJECT ATTRIBUTEs and the rules in the requirements engineering process knowledge base (REPKB). This base is composed in prepatory steps, so is not illustrated in the deliverable-side. The INITIAL RECOMMENDED TECHNIQUEs provides only general guidance as to what techniques might be suitable candidates for the new project. Further analysis, refinement and modification of the initial recommendation is likely needed (Jiang et al., 2008). |
| Analyze all techniques || Selection of a set of techniques attributes || Selection of a set of TECHNIQUES ATTRIBUTEs which are considered important for the given project. This mechanism allows the comparison of RE techniques to focus on those TECHNIQUE ATTRIBUTEs that are of major interest and highly relevant to the characteristics of the given software project (Jiang et al., 2008). |
| Technique clustering || TECHNIQUE CLUSTERing based on technique attributes. The TECHNIQUES CLUSTERing will be based only on the set of TECHNIQUE ATTRIBUTEs selected in the previous step. MRETS uses the Fuzzy Clustering Method, to analyze the similarity between requirements engineering techniques (Jiang et al., 2008). |
| Construct the technique recommendation space || Analysis of the initially recommended techniques || Analysis of the INITIALLY RECOMMENDED TECHNIQUES, to ensure that all the techniques are compatible with the new project. Incompatible techniques are removed from the INITIALLY RECOMMENDED TECHNIQUES (Jiang et al., 2008). |
| Selection of prospective techniques || Selection is made of a set of PROSPECTIVE TECHNIQUES from the requirements engineers perspective. This makes sure that the requirements engineers’ expertise is included in the decision making process(Jiang, 2005). |
| Indentify functional comparable and complementary techniques || Identification of all techniques, which are functionally comparable and functionally complementary to all the techniques by using the TECHNIQUE LIST of the TECHNIQUE CLUSTERing in the last step(Jiang et al., 2008).The functionally comparable and functionally complementary techniques help the requirements engineers to identify those techniques that have the maximum ability and least cost (Jiang, 2005). |
| Combine suitable techniques || Combination of the techniques identified in previous steps to construct the TECHNIQUE RECOMMENDATION SPACE (Jiang et al., 2008). |
| Select combinations of RE techniques || Select combinations of RE techniques || Selection of the various combinations of techniques within the TECHNIQUE RECOMMENDATION SPACE using the objective function. The objective function focuses on the quality of requirements specification, the complexity and cost of RE techniques (Jiang et al., 2008). |
| Calculation of the technique combination || Calculation of the overall ability of the TECHNIQUE COMBINATION selected by requirements engineers based on the values of their TECHNIQUE ATTRIBUTES using the objective function (Jiang et al., 2008). |
| Refine the recommended technique selection || || The FINAL RECOMMENDED TECHNIQUE is adjusted according to the consistency rules and experience of the requirements engineers (Jiang et al., 2008). Some techniques might also be removed based on further evaluation of their complexity and characteristics of the given project (Jiang, 2005). |
MRETS Concept table
| || Concept || Description |
| PROJECT ATTRIBUTE || The PROJECT ATTRIBUTEs play a key role when it comes to project characterization and selection of requirements engineering techniques. They also provide a way to characterize software projects. The PROJECT ATTRIBUTE has the following properties: Project size, Project complexity, Requirements volatility, Organsation and customer relationship, Project category etc. (Jiang et al., 2008). |
| TECHNIQUE ATTRIBUTE || There is little research into the identification of TECHNIQUE ATTRIBUTEs. TECHNIQUE ATTRIBUTEs are essential for the comparison of techniques (Jiang et al., 2008). |
| TECHNIQUE CLUSTER || The different TECHNIQUE CLUSTERs of requirements engineering techniques in a table. The clustering methods allow objects with similar attributes to be organized into groups(Jiang et al., 2008). |
| INITIAL RECOMMENDED TECHNIQUE || The INITIALLY RECOMMENDED TECHNIQUEs given to the requirements engineers in the overall technique selection process (Jiang et al., 2008). |
| PROSPECTIVE TECHNIQUE || The recommended requirements engineering technique that is recommended bij requirements engineers and could be used in the future as a part of the FINAL RECOMMENDED TECHNIQUEs. |
| TECHINIQUE LIST || List of identificated techniques, which are functionally comparable and functionally complementary to all the INNITIALLY RECOMMENDED TECHNIQUES and the PROSPECTIVE TECHNIQUEs (Jiang et al., 2008). |
| TECHNIQUES RECOMMENDATION SPACE || A set of techniques from which the FINAL RECOMMENDED TECHNIQUEs can be derived (Jiang et al., 2008). |
| TECHNIQUE COMBINATION || A combination of the INNITIALLY RECOMMENDED TECHNIQUEs to construct the TECHNIQUE RECOMMENDATION SPACE (Jiang et al., 2008). |
| FINAL RECOMMENDED TECHNIQUE || The FINAL RECOMMENDED TECHNIQUE for the given project. Combination of techniques that has the maximum overall ability and minimal cost for a given project (Jiang et al., 2008). |
There are many RE techniques to support the work in requirements activities of software development processes. Still, a high frequency of errors occur in requirements activities (Ambrióso et al., 2009). This suggests that the misunderstanding of relationships among key decisions is the probable reason. In the article by Ambrióso et al. (2010) a dynamics system model is constructed that makes it possible for requirement engineers to better understand the relations among key decision variables in requirements activities. This model is complementary to the MRETS approach, requirement engineers could use the model next to REPKB, where is decided which technique is most suitable. There are a lot of things that could go wrong during a RE process. The article of Macaulay (1996) presents three arguments that represent the objectives of the RE process, the failures that can occur, and the possible causes of the failure. The author shows that it should be able to identify what techniques are needed to avoid failure. This requirements could also be complementary to the total MRETS approach because failures could occur in the whole process. In Jiang et al. (2008b) they explore factors that influence requirements process improvement (RPI) with the aim to explain how the attributes of the underpinning process affect both the quality and associated costs of the requirements specification delivered to the customer.
In Zawedde et al. (2011), a Knowledge-based Approach for the Selection of Requirements Engineering Techniques (KASRET) is proposed that helps during RE techniques selection. This approach has three major features. First, a library of requirements techniques was developed which includes detailed knowledge about RE techniques. Second, KASRET integrates advantages of different knowledge representation schemata and reasoning mechanisms. Thus, KASRET provides mechanisms for the management of knowledge about requirements techniques and support for RE process development. Third, as a major decision support mechanism, an objective function evaluates the overall ability and cost of RE techniques, which is helpful for the selection of RE techniques. This approach is comparable to MRETS, because MRETS is also an approach for selecting requirements engineering techniques.
In Kausar et al. (2010) and Seyff et al. (2010) there is a link with the requirement elicitation technique and how important end-user involvement is in software development processes. This article describes the difference between different elicitation techniques and the article provides guidelines in choosing one. The end-users and the stakeholders will not always be in near-by, for this reason it is a good idea take global requirements techniques into account. In Ahmad et al. (2011) the limitations of requirements prioritization techniques are discussed with respect to geographical distribution of stakeholders.
In Berkovich et al. (2011) there is an analysis on the requirement engineering techniques for IT-enabled Product Service Systems. This is linked with my example.
In Callele and Wnuk (2011) there is argued that significant similarities between policy and requirements documents suggest that requirements engineering techniques could be used to generate policy. This article reports how requirements engineering methodologies were applied to generate corporate intellectual property policy. Because MRETS is a requirement engineering methodology, this could also be an option for MRETS.
In Veerappa and Letier (2011)the Multi-objective decisions problems are discussed in requirements engineering. A common approach to solve them is to apply search-based techniques to generate a set of non-dominated solutions, formally known as the Pareto front, that characterizes all solutions for which no other solution performs better on all objectives simultaneously. The goal of Veerappa and Letier (2011) is to help decision makers identify groups of strongly related solutions in a Pareto front so that they can understand more easily the range of design choices, identify areas where strongly different solutions achieve similar levels of objectives, and decide first between major groups of solutions before deciding for a particular variant within the chosen group. This is useful when the final recommendation technique is refined, because then the most suitable requirements technique is chosen.
Ahmad, A., Shahzad, A., Padmanabhuni, V.K., Mansoor, A., Joseph, S., & Arshad, Z. (2011). Requirements Priorization with Respect to Geographically Distributed Stakeholders. International Conference on Computer Science and Automation Engineering (CSAE)
, Shanghai, China, 290-294.
Ambrióso, B.G., Braga, J.L., & Resende-Filho, M.A. (2010). Modeling and scenario simulation for decision support in management of requirements activities in software projects. Journal of softwaremaintenance and evolution: research and practice
, 23, 35-50.
Berkovich, M., Hoffmann, A., Leimeister J.M., & Krcmar, H. (2011). Analysis of Requirements Engineering Techniques for IT-enables Product Service Systems. Workshop on Requirements Engineering for Systems, Services and Systems of-Systems(RES 4)
, Trento, Italy, 50-58.
Callele, D., & Wnuk, K. (2011). More than Requirements: Applying Requirements Engineering Techniques to the Challenge of Setting Corporate Intellectual Policy, An Experience Report. 4th International Workshop on Requirements Engineering and Law
, Trento, Italy, 35-42.
Jiang, L. (2005). A Framework for the Requirements Engineering Process Development. 19th Australian Software Engineering Conference
, Calgary, Alberta, 507-516.
Jiang, L., Eberlein, A., & Far, B.H. (2008). A methodology for the selection of requirements engineering techniques. Software System Model, 7
Jiang L., Eberlein, A., & Far, B.H. (2008b). A case study validation of a knowledge-based approach for the selection of requirements engineering techniques. Requirement Engineering, 13
Kausar, S., Tariq, S., Riaz, S., & Khanum, A. (2010). Guidelines for the Selection of Elicitation Techniques. 6th International Conference on Emerging Technologies (ICET)
, Islamabad, Pakistan, 265-269.
Macaulay, A. (1996). Requirements for Requirements Engineering Techniques. Proceedings of ICRE '96
Seyff, N., Graf, F., & Maiden, N. (2010). Using mobile RE Tools to Give End-Users their Own Voice. 18th IEEE International Requirements Engineering Conference
, London, UK, 37-46.
Veerappa, V., & Letier, E. (2011). Understanding Clusters of Optimal Solutions in Multi-Objective Decision Problems. 19th International Requirements Engineering Conference
, Trento, Italy, 89-98.
Zawedde, A.S., Klabbers, M.D., Williams, D., & Brand, M.G.J. (2011). Understanding the Dynamics of Requirements Process Improvements: A New Approach. Lecture Notes in Computer Science, 6759