a review of requirements engineering processes ...

Lachana Ramingwong et al. / International Journal of Engineering Science and Technology (IJEST)

A REVIEW OF REQUIREMENTS ENGINEERING PROCESSES, PROBLEMS AND MODELS LACHANA RAMINGWONG Department of Computer Engineering, Faculty of Engineering, Chiang Mai University, Muang, Chiang Mai 50200, Thailand [email protected] Abstract : Precisely defined requirements are essential for a successful software development. Although dozens of requirements engineering methods and techniques are available for practitioners, some techniques are proven successful to certain systems but not for others. In fact, selection appropriate of requirements engineering methods and techniques can be difficult and, in worse case scenarios, may ultimately lead to a failure. Recent changes in business environments and emerging technologies also affect requirements processes. This makes selection of an appropriate requirements engineering model even more sophisticate. This article discusses requirements engineering processes and their problems, requirements engineering models, as well as essential characteristics of requirements engineering models. Keywords: Requirements Engineering Process; Requirements Engineering Model; Requirements Elicitation; Software Engineering. 1. Introduction Requirements engineering, widely recognized as the first phase of software engineering process, is considered the key task of software development (Wahono 2003; Asghar & Umar 2010). Ambiguous requirement is reported as one of the top reasons for software project failure (Hoffman & Lehner 2001) and product defects (Young 2001). Indeed, an effective requirements engineering is essential to the rest of software development process. Requirements engineering is also a crucial factor which influences productivity and product quality (Fernandez et al 2011). These established facts highlight requirements engineering as a critical phase for software development. Nowadays, dozens of requirements methodologies and techniques are available for practitioners. However, some techniques which are proven successful to one system may not work well for another. This shows that selection of methods and techniques can be difficult and may even lead to failure of a software system. Recent changes in business environments also affect requirements engineering process. Additionally, when time to market becomes more critical to software release than quality of software itself, requirements engineering models must provide appropriate guidelines to practitioners to provide a good basis for a quality software system in a timely manner, and ultimately, lead a software project to success. In order to develop high quality software in a timely manner while trying to avoid traditional requirement engineering problems, an effective requirements engineering process along with appropriate guidelines is inevitably required. Section 2 of this paper provides an overview for requirements elicitation process. Then, major problems in requirements elicitation are described in section 3. Section 4 discusses requirements engineering models and their characteristics. Finally, section 5 concludes the challenges to requirements engineering models and its application to real world software development. 2. Requirements Engineering Process According to Sommerville (2009), a requirements engineering phase consists of four activities; discovery (gather, elicit), analysis and negotiation, documentation, and validation. “Discover” is a more suitable term to describe the nature of requirements as they cannot be founded or gathered. The outcomes of this phase can be

ISSN : 0975-5462

Vol. 4 No.06 June 2012

2997

Lachana Ramingwong et al. / International Journal of Engineering Science and Technology (IJEST)

classified into two main types; business specification and requirements specification (Fernandez et al 2011). A business specification is an objective-oriented document that describes critical business processes required to accomplish business goals. Unlike business specification, requirements specification documents essential characteristics of a system and conditions related to the development process. A specification may include notes, lists, diagrams, scenarios, trees, forms, plans and others (Mead et al 2005; Winkler 2007). Figure 1 shows a requirement engineering process (Sommerville 2009).

Requirements elicitation

Requirements analysis and negotiation

Requirements documentation

Requirements validation

Fig. 1. A requirements engineering process

Requirements are discovered by means of gathering and eliciting. While the two words “gather” and “elicit” are used interchangeably in requirements engineering (Christel & Sang 1992; Nuseibeh & Eaterbrook 2000; Young 2001; Powell 2007), others put a line between them. Gonzales and Leroy (2011) address elicitation as the first step in requirements gathering. The BABOK Guide Version 2.0 emphasizes the use of ‘elicit’ word rather than ‘gather’ (IIBA 2009). BABOK highlights that elicitation is identification of the actual needs of stakeholders rather than gathering from their statements. Since this article mainly emphasizes on elicitation techniques, the word ‘elicit’ is used throughout this article. Requirements engineering processes kick off with elicitation activities which aim to discover the purpose of the system under development. The specification produced from this stage is an essential element that determines what to be built (Herlea 1996), why build it, when, where, and how to build (4W+1H). Rather than a question and answer session for collecting software and system requirements, requirements elicitation is more complicated that what it appears to be. The reason behind that is requirements cannot always be collected or captured, but rather elicited (Zowghi & Coulin 2005). Requirements elicitation is, therefore, considered as a critical activity to requirements engineering processes and the rest of software development. In requirements elicitation, requirements are discovered by means of elicitation techniques. There are dozen techniques available. However, unfortunately, only a few of them are found to be effective (Young 2002). In order to minimize potential challenges, a software engineer can follow guidelines for selection of elicitation techniques proposed by Kausar and colleges (2010). There are also a number of review articles that provides brief introduction and insights to these elicitation techniques (Goguen & Linde 1993; Kausar 2010; David 2006; Young 2002; Chu 2010; Rahman & Sahibuddin 2011). These details of elicitation techniques and selection guidelines are not discussed in this paper. Elicitation techniques can be grouped into six classes according to Nuseibeh and Easterbrook (2000) as follows:      

Traditional techniques are long-established and well-known techniques such as document analysis, questionnaires, interviews, meetings (James 2002). Group elicitation techniques encourage stakeholders to communicate requirements more willingly. The most used techniques include focus groups and brainstorming sessions. Prototyping is one of the most used techniques to elicit hidden requirements and to draw some feedbacks. It is often used in combination with other techniques. Contextual techniques involve studying users in the context and environments to system implementation such as observation or conversation analysis. Model-driven techniques include a specific model and specific type of information to guide the elicitation process. Cognitive techniques are used to attain knowledge by means of various techniques.

Elicited requirements are examined for their incompleteness, ambiguity or inconsistency. If conflicts or discrepancies are detected, further negotiation is required to resolve conflicts between stakeholders without

ISSN : 0975-5462

Vol. 4 No.06 June 2012

2998

Lachana Ramingwong et al. / International Journal of Engineering Science and Technology (IJEST)

compromising their goals (Nuseibeh & Easterbrook 2000). The negotiation models help practitioners to define stakeholders’ goals and establish required mechanism to ensure the goals are satisfied. The requirements are then carefully recorded in appropriate forms which could be textual, graphical, symbolic or mixture of them. The specification of requirements are created and evolved when changes occur. Specifications may be deleted or added in response to changing needs or business environments. The last step in requirements engineering involves validation of requirements with customers to ensure that requirements are good enough to proceed to the next phase of software development. Complexity in requirements engineering processes presents a number of challenges. More complex or rigid processes tend to introduce more problems. On the other hand, simpler processes may not represent sufficient information and might need additional support in order to yield quality results. Undeniably, selecting appropriate combination of methods, practices and requirements engineering model is critical. The practitioners need to identify appropriate combinations of these methods and selection guidelines before the production begins. Then, they need to understand the details of the processes, methods and techniques that should work for such scenarios and adapt accordingly. This is similar to a classic philosophy, “Know your enemy and know yourself”. 3. Requirements Engineering Problems Many of problems associated with requirements engineering process are related to elicitation and analysis of requirements (Wahono 2003). One major reason of these problems is the essential involvement of stakeholders in both activities. This article, therefore, discusses common problems found during requirements elicitation, and requirements analysis and negotiation activities. 3.1. Elicitation Problems A requirements elicitation process is appeared to be straightforward. However, in fact, it is complex, highly interactive and time consuming (John & Door 2003). This is due to the number of stakeholders and communications required and, more importantly, requirement changes. Problems occur during requirements engineering process add major complexity to the process. The most used techniques for requirements elicitation includes meeting and prototyping (Liu & Li 2010). Despite the fact that these methods offer advantages over other methods, there are tradeoffs. A requirements elicitation technique accepted as an effective method for one software project may not work well for the others. Many other techniques need additional guidelines (Nuseibeh & Easterbrook 2000) and more flexibility for practitioners (Coulin et al 2005). Poor understanding also contributes inappropriate selection of elicitation technique (Kausar et al 2010). Time consuming nature of requirements elicitation tops the list of elicitation problems (Chua 2010). Besides these aforementioned problems, requirements elicitations are vulnerable to other challenges such as incorrect requirements and misinterpret requirements (Apshvalka et. al 2009). Furthermore, rapid changes in business environments and information technology force products to have a shorter time-to-market. This shortens development life cycle and causes even more problems on requirement processes. Soft issues (sometimes referred as people issues) involve non-technical aspects such as policy and morale (Thew & Sutcliffe 2008). Few studies are conducted to identify problems occur during requirements engineering processes (Apshvalka et al 2009; Rahman & Sahibuddin 2011). Other common challenges from requirements elicitation include scope, understanding and volatility (Wahono 2003). Interestingly, although these challenges are common to every software project, their effective solutions are not yet discovered.

3.2. Analysis and Negotiation Problems Elicited requirements are often incorrect, incomplete, inconsistent and ambiguous (Palmer et al 1990). Manual detection of these flaws can be time-consuming. Automatic detection and correction, though cannot be entirely automated, is possible if requirements are systematically formalized. The same solution is applied to automatic detection of conflicts (Giorgini et al 2006).

ISSN : 0975-5462

Vol. 4 No.06 June 2012

2999

Lachana Ramingwong et al. / International Journal of Engineering Science and Technology (IJEST)

Stakeholders are one of the main sources of problems. As an individual, stakeholders generally have different perspectives, perceptions, concerns, priorities and responsibilities (Ahmad 2008). An appropriate negotiation process is necessary for gaining quality requirements. Another solution to requirements analysis problems is association of requirements and computer systems to particular concepts. This is done in order to effectively guide requirements elicitation and analysis activities. Examples include the viewpoint-oriented approach (Finkelstein et al 1989), the win-win approach (Boehm et al 1995) and the Jackson’s problem frame approach (Côté 2011). The problems described in this section confirm criticality and difficulty of requirements engineering processes. Although many software projects cope with major problems, the degree of complexity and resolution depends on a number of contextual issues surrounding projects. 4. Requirements Engineering Models Requirements engineering models should clearly describe not only activities which identify software and system requirements, but also the development environment (i.e., goals, viewpoints, stakeholder concerns, etc.) The following subsections briefly describe selected requirement models proposed by others, along with lessons learnt from the models. 4.1. PREview Approach PREview associates requirement engineering processes to stakeholder concerns based on Viewpoint model (Sommerville et al 1998). PREview comes with generic requirements engineering process model adapted from the Spiral model and the Inquiry cycle. The strength of PREview is claimed to be its emphasis on stakeholders’ concerns and the ease of integration to existing requirement approaches. The Viewpoint model provides a good starting point for users to identify viewpoints. Key lessons learnt from PREview are listed as follows.     

A requirements engineering model should define activities that aim for identifying requirements, as well as providing supporting activities that contributes to the success and quality of requirements. The flexibility in implementation and integration to existing methods influences the success of approach adoption. The absence of association to particular notations and methods is surprisingly a key factor in acceptance of the approach. Introduction of new concepts may cause problems initially. An introductory session for users to be familiar with the concepts can contribute to the success of concept implementation. An iterative approach to requirements engineering is needed to allow requirements to evolve. However, the guideline to when elicitation should be commenced or ended is required. Requirements engineers should actively search for requirements, rather than emphasizing on elicitation from known sources. Elicitation can occur when the source can be identified.

4.2. Young’s Recommended Requirements Practices Young (2002) recommended a set of 16 practices for requirements elicitation. Recommended practices which are built upon experiences of practitioners provide value added insights to implementation of elicitation processes. Often, selection and application of practices are in charge of practitioners. In such situation, selection and application guidelines are more useful. Young (2002) provides a good example to others that some guidance is needed in order to allow practitioners to follow the practices. The following list summarizes the practices: (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)

Create an initial scope document. Identify, prioritize and document actual requirements with stakeholders via group elicitation technique(s). Set up requirements change control policy and mechanism. Perform change control as needed. Determine requirements for the first and subsequent releases. Peer review and inspect requirement artifacts. Use automated requirement tools to document, trace and maintain requirements. Use elicitation techniques proven to be previously successful in the organization. Include domain experts as members of the project team. Evolve approaches successfully used in project or organization. Share information among projects. Continue to improve professionalisms (ethic, teamwork approaches and culture). Engage main stakeholders (customers and users) throughout the development. Verify and validate requirements to ensure testable requirements.

ISSN : 0975-5462

Vol. 4 No.06 June 2012

3000

Lachana Ramingwong et al. / International Journal of Engineering Science and Technology (IJEST)

4.3. An Extended Requirement Elicitation Model As discussed earlier, requirements models should aim at providing supporting activities along with elicitation, analysis, specification and validation activities. An extended requirements elicitation model needs to be defined. Table 1 proposes a model extended from previous literatures as well as recommend practices and presents additional information; such as elicitation techniques, supporting practices and participants, to provide requirements elicitation guidelines for practitioners. Similar to software development, two types of activities are identified. Firstly, primary tasks involve core activities which lead to accurate requirements. Secondly, supporting tasks include monitoring, controlling, validating and assuring the success of the primary tasks. Some elicitation practices are considered as the main activities which are required to perform elicitation while others are regarded as supporting practices. A supporting practice plays an important role in the success and quality of a main process, just like a software quality assurance does to a software development process. Primary Tasks 1. Create an initial scope document.

Elicitation Technique Ethnographic, Interview

2. Identify actual requirements.

Document/user analysis, Prototyping, Group elicitation, Cognitive, Contextual, Model-driven Prototyping, Group elicitation, Cognitive Prototyping, Document/user analysis, Cognitive

3. Prioritize and determine releases. 4. Review and inspect artifacts.

Supporting Tasks Set up change control, Use proven techniques, Engage stakeholders, Domain experts, Documentation Automated tools, Peer review and inspect, Verify and validate, Continuous improvement, Share information

Participant Team, Stakeholders, Experts

5. Iterate requirements development if required. Table 1. An extended requirements elicitation model.

Additional recommended practices from Table 1 are proposed as follows: 





There should be discussion and training sessions to develop appropriate requirements engineering approach for a particular project. These sessions facilitate setting up common methods and techniques, and also serve as introductory sessions to the approach. If new concepts, methods or techniques should be used in the requirements engineering process, this should be a good time to introduce them. Requirement methods and techniques that are successfully employed on organization’s previous projects should be systematically stored, analyzed and subsequently evolved. Knowledge from people who previously participated in these successful projects should play an important role in future projects. An investment put into requirements engineering process is invaluable, and is very likely to reduce problems occurred later during the development. Additional guidelines or sample implementation scenarios to requirements engineering models help practitioners to adopt the recommended practices in a reasonable amount of time.

5. Conclusions and Recommendations IEEE 830 claims that good requirements should be unambiguous, understandable, correct, complete, modifiable, verifiable and consistent (Bahill & Dean 2009). These characteristics critically affect quality and success of subsequent software development phases. While requirements engineering processes aim at producing quality software and system requirements, traditional and emerging requirement issues and problems drive the requirement engineering processes further to include extra elements to processes and implementation. Whereas particular practices, techniques or models place distinct concerns to different characteristics of requirements, the main aim of requirements engineering models should aim at guiding the requirements discovery, as well as identifying system boundaries and environments, and also providing additional support for environments; users and stakeholders of the processes. Moreover, the models should support dynamic, adaptive and iterative activities in order to evolve and cope with rapidly changing environment. The integration to other

ISSN : 0975-5462

Vol. 4 No.06 June 2012

3001

Lachana Ramingwong et al. / International Journal of Engineering Science and Technology (IJEST)

phases of software development should be seamless, as new requirements and changes in rapidly changing environments can surface during any of the development phases. Additional support should include facilitating communication among stakeholders, managing and enhancing the process and its core outputs. Furthermore, the requirements engineering models should also provide sufficient mechanisms to tackle problems occurred during requirement engineering process, as well as guiding and supporting the elicitation of requirements. Future model must learn from the previous lessons and propose adequately flexible mechanisms to undertake those issues discussed in this article. References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27]

[28] [29] [30] [31] [32] [33] [34]

Wahono, R. S. (2003): Analyzing Requirements Engineering Problems, IJW-2003, pp. 55-58. Asghar, S.; Umar, M. (2010): Requirement Engineering Challenges in Development of Software Applications and Selection of Customer-off-the-Shelf (COTS) Components, IJSE, 1(1) Hofmann, H. F.; Lehner, F. (2001): Requirements Engineering as a Success Factor in Software Projects. IEEE Software, 18(4), pp. 5866. Young, R. R. (2001): Effective Requirements Practices. Addison-Wesley. Fernandez D. M.; Lochmann, K.; Penzenstadler, B.; Wagner, S. (2011): A case study on the application of an artefact-based requirements engineering approach. EASE'11, IET. Sommerville, I. (2010). Software Engineering, 9th edn., Addison-Wesley. Mead, N.R.; Hough, E.D.; Stehney II, T.R. (2005). Security Quality Requirements (SQUARE) Methodology” CMU/SEI-2005-TR009, Software Engineering Institute, Carnegie Mellon University. Winkler, S. (2007): Information Flow Between Requirement Artifacts -- Results of an Empirical Study In: Sawyer, P. ; Paech, B.; Heymans, P. (Hrsg.). REFSQ 2007. LNCS 4542, S. 232-246, Springer Berlin-Heidelberg. Christel, M.; Kang, K. (1992): Issues in Requirements Elicitation. Software Engineering Institute Technical Report CMU/SEI-92-TR12. Pittsburgh, PA: Carnegie Mellon University. Nuseibeh, B.; Easterbrook, B. (2000): Requirements engineering: a roadmap. ICSE '00, pp. 35-46, ACM, New York, NY, USA. Powell, S.; Keenan, F.; McDaid, K. (2007): Enhancing Agile Requirements Elicitation With Personas”, IADIS 2007, 2(1), pp. 82-95. Gonzales, C. K.; Leroy, G. (2011): Eliciting user requirements using Appreciative inquiry, Empirical Software Engineering, 16(6), pp. 733-772. IIBA. (2009). Guide to the Business Analysis Body of Knowledge (BABOK Guide). Toronto. Herlea, D.(1996). Users Involvement in Requirements Engineering Process, KAW96, Banff, Canada. Zowghi, D.; Coulin, C. (2005): Engineering and Managing Software Requirements. Aurum, Aybuke and Claes Wohlin (eds). Springer-Verlag. Young, R. R.(2002): Recommended Requirements Gathering Practices, CrossTalk, 15(4), April 2002, pp. 9-12. Kausar, S.; Tariq, S.; Riaz, S; Khanum, A. (2010): Guidelines for the selection of Elicitation Techniques. ICET 2010, 18 -19 October. Goguen, J. A.; Linde, C. (1993): Technique for requirements elicitation”, RE 1993, pp 152-164. Davis, A. M.; Tubío, Ó. D.; Hickey, A. M.; Juzgado, N. J.; Moreno, A. M. (2006): Effectiveness of Requirements Elicitation Techniques: Empirical Results Derived from a Systematic Review. RE 2006, pp. 176-185. Chua, B. B.; Bernardo, V.; Verner, J. M. (2010): Understanding the Use of Elicitation Approaches for Effective Requirements Gathering. ICSEA 2010, pp. 325-330. Rahman N. A.; Sahibuddin, S. (2011): Requirements Elicitation for Handling Soft Issues: An Overview , ICCET 2011, Malaysia. John, I.; Dorr, J. (2003): Elicitation of requirements from user documentation. REFSQ 03, pp.16-17. Liu, L.; Li , T.; Peng F. (2010), Why Requirements Engineering Fails: A Survey Report from China. RE 2010, pp. 317-322, IEEE Computer Society. Coulin, C.; Zowghi, D; Sahraoui, A. (2005): A Lightweight Workshop-Centric Situational Approach for the Early Stages of Requirements Elicitation in Software Development. SREP ’05, Paris, France. Apshvalka, D.; Donina, D.; Kirikova, M. (2009): Understanding the Problems of Requirements Elicitation Process: A Human Perspective, Information Systems Development, Springer, pp 211-223 Thew, S.; Sutcliffe, A. G. (2008): Investigating the Role of 'Soft Issues' in the RE Process. RE 2008, pp. 63-66. Palmer, J.D.; Liang ,Y.; Wang, L. (1990): Classification as an Approach to Requirements Analysis," Advances in Classification Research and Application: Proc. 1st ASIS SIG/CR Classification Research Workshop, S.M. Humphrey and B.H. Kwasnik, eds., Learned Information, Medford, N.J. Giorgini, P.; Massacci, F.; Mylopoulos, J.; Zannone, N. (2006): Detecting Conflicts of Interest. RE 2006, pp. 308-311. Ahmad, S. (2008): Negotiation in the Requirements Elicitation and Analysis Process. ASEC 2008, pp. 683-689. Finkelstein, A.; Goedicke, M.; Kramer J.; Niskier, C. (1989): Viewpoint Oriented Software Development: Mehtods and Viewpoints in Requirements Engineering. Algebraic Methods 1989, pp. 29-54. Boehm, B.; Bose, P.; Horowitz, E.; Lee, M. J. (1995); Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach. ICSE-17, Seattle, USA, pp. 243-254. Côté, I.; Heisel, M.; Schmidt, H.; Hatebur, D. (2011): UML4PF - A tool for problem-oriented requirements analysis. RE 2011,pp. 349-350. Sommerville, I.; Sawyer, P.; Viller, S. (1998): Viewpoints for Requirements Elicitation: A Practical Approach. ICRE 1998, pp.74-81. BAHILL, A. T.; DEAN, F. F. (2009): Discovering System Requirements, Chapter 4 in Handbook of Systems Engineering and Management, A.P.Sage and W.B. Rouse (Eds.), 2nd edn. John Wiley & Sons, pp.205-266.

ISSN : 0975-5462

Vol. 4 No.06 June 2012

3002