Table of Contents

Methodology for Requirements Engineering Techniques Selection (MRETS)

Introduction

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).

Example

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

Table 1.

• 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

Table 2.

	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

Table 3.

Table 3

• 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

Table 4.

• 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

Table 5.

• 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

Table 6.

• 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.

Template 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

Table 7.

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.

Process Description

Figure 1

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).

Table 8.

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).

Table 9.

Related literature

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.

References

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, 303-328.

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, 117-146.

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, 157-164.

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, 276-290.