Professional Documents
Culture Documents
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
lachana@chiangmai.ac.th
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.
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.
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
Requirements Requirements Requirements
analysis and
elicitation documentation validation
negotiation
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
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”.
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.
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.
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.
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.
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] Wahono, R. S. (2003): Analyzing Requirements Engineering Problems, IJW-2003, pp. 55-58.
[2] 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)
[3] Hofmann, H. F.; Lehner, F. (2001): Requirements Engineering as a Success Factor in Software Projects. IEEE Software, 18(4), pp. 58-
66.
[4] Young, R. R. (2001): Effective Requirements Practices. Addison-Wesley.
[5] 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.
[6] Sommerville, I. (2010). Software Engineering, 9th edn., Addison-Wesley.
[7] Mead, N.R.; Hough, E.D.; Stehney II, T.R. (2005). Security Quality Requirements (SQUARE) Methodology” CMU/SEI-2005-TR-
009, Software Engineering Institute, Carnegie Mellon University.
[8] 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.
[9] Christel, M.; Kang, K. (1992): Issues in Requirements Elicitation. Software Engineering Institute Technical Report CMU/SEI-92-TR-
12. Pittsburgh, PA: Carnegie Mellon University.
[10] Nuseibeh, B.; Easterbrook, B. (2000): Requirements engineering: a roadmap. ICSE '00, pp. 35-46, ACM, New York, NY, USA.
[11] Powell, S.; Keenan, F.; McDaid, K. (2007): Enhancing Agile Requirements Elicitation With Personas”, IADIS 2007, 2(1), pp. 82-95.
[12] Gonzales, C. K.; Leroy, G. (2011): Eliciting user requirements using Appreciative inquiry, Empirical Software Engineering, 16(6), pp.
733-772.
[13] IIBA. (2009). Guide to the Business Analysis Body of Knowledge (BABOK Guide). Toronto.
[14] Herlea, D.(1996). Users Involvement in Requirements Engineering Process, KAW96, Banff, Canada.
[15] Zowghi, D.; Coulin, C. (2005): Engineering and Managing Software Requirements. Aurum, Aybuke and Claes Wohlin (eds).
Springer-Verlag.
[16] Young, R. R.(2002): Recommended Requirements Gathering Practices, CrossTalk, 15(4), April 2002, pp. 9-12.
[17] Kausar, S.; Tariq, S.; Riaz, S; Khanum, A. (2010): Guidelines for the selection of Elicitation Techniques. ICET 2010, 18 -19 October.
[18] Goguen, J. A.; Linde, C. (1993): Technique for requirements elicitation”, RE 1993, pp 152-164.
[19] 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.
[20] Chua, B. B.; Bernardo, V.; Verner, J. M. (2010): Understanding the Use of Elicitation Approaches for Effective Requirements
Gathering. ICSEA 2010, pp. 325-330.
[21] Rahman N. A.; Sahibuddin, S. (2011): Requirements Elicitation for Handling Soft Issues: An Overview , ICCET 2011, Malaysia.
[22] John, I.; Dorr, J. (2003): Elicitation of requirements from user documentation. REFSQ 03, pp.16-17.
[23] Liu, L.; Li , T.; Peng F. (2010), Why Requirements Engineering Fails: A Survey Report from China. RE 2010, pp. 317-322, IEEE
Computer Society.
[24] 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.
[25] Apshvalka, D.; Donina, D.; Kirikova, M. (2009): Understanding the Problems of Requirements Elicitation Process: A Human
Perspective, Information Systems Development, Springer, pp 211-223
[26] Thew, S.; Sutcliffe, A. G. (2008): Investigating the Role of 'Soft Issues' in the RE Process. RE 2008, pp. 63-66.
[27] 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.
[28] Giorgini, P.; Massacci, F.; Mylopoulos, J.; Zannone, N. (2006): Detecting Conflicts of Interest. RE 2006, pp. 308-311.
[29] Ahmad, S. (2008): Negotiation in the Requirements Elicitation and Analysis Process. ASEC 2008, pp. 683-689.
[30] 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.
[31] 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.
[32] Côté, I.; Heisel, M.; Schmidt, H.; Hatebur, D. (2011): UML4PF - A tool for problem-oriented requirements analysis. RE 2011,pp.
349-350.
[33] Sommerville, I.; Sawyer, P.; Viller, S. (1998): Viewpoints for Requirements Elicitation: A Practical Approach. ICRE 1998, pp.74-81.
[34] 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.