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
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.
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 Jacksons problem frame
approach (Ct 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. Youngs 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 organizations 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.; Tubo, . 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.
Ct, 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

Copyright of International Journal of Engineering Science & Technology is the property of Engg Journals
Publications and its content may not be copied or emailed to multiple sites or posted to a listserv without the
copyright holder's express written permission. However, users may print, download, or email articles for
individual use.