A Requirement Engineering Process Model for Software Development and Requirements Management

Content

1. Introduction
2. Example
3. Process description
4. Related literature
5. References

1. Introduction

The most important phase in the software development lifecycle is considered to be the requirement engineering process (Juristo, Moreno, & Silva, 2002; Pandey & Ramani, 2009a). This process consists of activities that deal with the gathering, analysis, validation, documentation and maintenance of the set of requirements for a system and implements them into the software development process (Pandey, Suman, & Ramani, 2010; Siddiqi, 1996). Requirements are the properties, i.e. features or qualities, that must be possessed by the system or system component that is to be delivered, in order to satisfy customer needs (Jalote, 1997). Therefore, requirements engineering has a major impact on the capabilities of the product resulting from this software development process. In addition, requirements engineering concerns rather diverse product demands from a vast amount of different stakeholders (e.g., viewpoints, roles, responsibilities, and objectives). These reasons cause requirement engineering to be both a critical and complex process (Pandey et al., 2010). The proposed requirements engineering process distinguishes functional and non-functional requirements (Glinz, 2007; Jalote, 1997; Wiegers, 2009). Functional requirements specify actions that must be performed by a system whereas non-functional requirements address system qualities like performance, portability, and maintainability.
The requirement engineering process is generally conducted at the start of the development lifecycle. Obviously, one must know what capabilities a system should obtain before starting the actual development. However, the practice taught us that in large and complex system development, especially those with a long term lifecycle, requirements won’t remain stable or unchanged. For this reason, we consider requirement engineering as an ongoing incremental and iterative process that deals with changing requirements during the entire development lifecycle. The requirement engineering activities can be grouped under the requirements development and requirements management processes. The requirements development process contains activities concerning the discovery, analysis, documentation and validation of requirements, whereas requirements management deals with the traceability and change management of requirements (Pandey et al., 2010).
The main objective of requirement engineering is to obtain quality requirements (i.e. they must be clear, consistent, modifiable, and traceable) in order to produce a quality product. In this paper we elaborate on the requirement engineering process model proposed by Pandey et al. (2010) which aids in the effective implementation of the requirement engineering process. This process defines four phases; requirement elicitation and development, documentation of requirements, validation and verification of requirements, and requirement management and planning. During the requirements elicitation and development phase requirements enter the process via several stakeholders. This phase consists of requirements analysis and the allocation and flow down of requirements. The ‘documentation of requirements’ phase is concerned with the identification of requirements and their specification into software and system requirements. The conformation of requirements is dealt with during the validation and verification phase after which the requirements are implemented into the software development process. The last phase, requirements management and planning deals with changes in the set of requirements that occur during the development lifecycle. In the next section, the requirement engineering process and the four mentioned phases in particular will be elaborated in more detail. D. Pandey, A. K. Ramani and U. Suman – the authors of the requirement engineering process analyzed in this paper – all have an academic background. Pandey, which is the first author, is assistant professor at the Department of Information Technology of the BBA University in India. Besides the research domain of requirement engineering, Pandey’s interests lie in the field of data mining, software engineering and data warehousing. Dr. A. K. Ramani is professor at the School for CSIT of DAVV. His recent work is on information architecture whereas earlier work covers – among many others – the domains of advance computer network, computer architecture and database management systems. Dr. Ugrasen Suman is reader and chair examination at the very same institution as Ramani. Software reuse and software engineering are the current domains of research of Suman. In addition, he conducted research in the fields of knowledge management and service oriented computing.
Besides the requirement engineering process, the authors worked together on various other requirement engineering related research projects. They developed a requirements modeling framework (Pandey, Suman, & Ramani, 2011a), which analyzes modern requirements modeling techniques. In addition, the three authors worked on an approach to information requirement engineering (Pandey, Suman, & Ramani, 2011b) and security requirement engineering (Pandey, Suman, & Ramani, 2011c).

2. Example

In this section we will describe the four different phases of the requirement engineering process model. We will clarify the model by elaborating the interrelated phases into sub phases and/or activities that are guided by a small but realistic example case of a tailor made ERP system that is developed for a wholesaler.

2.1 Requirements elicitation and development

The first phase of the requirement engineering process focuses on the gathering of requirements, regarding to the system that is to be developed, while different viewpoints (e.g. users, customer, marketing, standards, systems operating environment, etc.) are considered. Customers tend to have different demands regarding a system than users, and the environment can cause constraints for the system. For example, in our imaginary situation of the ERP system, the software system should be able to run on a UNIX based operating system.
This phase starts with the identification of all stakeholders of the system, which is depicted as the ‘Identify stakeholders’ activity in figure 2. Thereafter, raw requirements (i.e., requirements that still need to be analyzed and documented in a well formed requirement notation) will be collected from the different viewpoints – during the ‘Collect raw requirements’ activity.

Requirement analysis

The above mentioned raw requirements may be conflicting. In the ‘Analyze requirements’ activity, the communication, negotiation, agreement, and prioritization of requirements are included. In addition, requirement analysis can result in models of the data, processes and behavioral domains. (Pandey et al., 2010)

Allocation and flow down

The allocation of requirements encompasses the assignment of requirements to a (set of) subsystem(s) that cooperate to achieve the system objectives. This architectural task concerns both functional and non-functional requirements. In the example case of the ERP system, a requirement concerning the registration of a customer relation can be allocated to the relation module which is to be implemented. An example of the allocation of a non-functional requirement can be one regarding flexibility, that is addressed by structuring the software according to the Model-View-Controller (MVC) design pattern (Gamma, Helm, Johnson, & Vlissides, 1993).
Requirements can be formulated at different levels of abstraction. The flow down of requirements is an activity that derives more concrete requirements from an abstract parent requirement. In other words, top-level requirements are converted into low-level requirements that are input for the system engineer. Regardless of the level of abstraction, the requirements are allocated to subsystems as mentioned above.

2.2 Documentation of requirements

The second phase consists of requirements identification and requirements specification. Requirements identification deals with the assignment of unique identifiers on requirements. The requirements specification phase combines the output from the flow-down and allocation activities into a software requirements specification document (SRS). This document contains the elaborated non-functional requirements and a set of use cases that describe the user interactions with the software system.
In figure 1, a simplistic example of a use case diagram is depicted from which we can recognize two actors, namely Sales employee and Administrator. An actor represents a certain group of users that must be able to perform one or more use cases. A use case is a series of actions that share an objective (OMG, 2011). The Administrator must be able to perform the use case ‘Change user role’ whereas the Sales employee must be able to register suppliers and customers. Both the ‘Register customer’ and ‘Register supplier’ extend the more general ‘Register relation’ use case. Every actor needs to login before a use case can be performed, which is visualized with the use relation. Use cases are described in more detail in a use case specification, which is a formatted textual description of the series of interactions between the actor and the software system. Although the requirement engineering process does not prescribe the format of an use case specification, A template of a use case specification based on the work of Dutoit and Paech (2002) can be found here: template-use_case_specification.doc

Figure 1 – example of a use case diagram

2.3 Validation and verification of requirements

When all the requirements are specified and described in the SRS, they must be validated and verified by the stakeholders of the software system. Requirements validation concerns whether the correct requirements are stated. Requirements verification is the process of checking whether the requirements are stated correctly (Pandey et al., 2010).

2.4 Requirements management and planning

This phase endures the entire software development lifecycle. As mentioned earlier, it controls and tracks changes in the set of agreed requirements. In addition, this phase its objective is to control the relations and dependencies between requirements, and between all the involved documents created during the software development process. Imagine for example, that the requirement regarding to registering suppliers has to be omitted due to nearing deadlines and time pressures. The impact on related requirements and thus system components is estimated. After deciding that this change will be implemented, the change can be further incorporated into the development process. Models and documents like the use case diagram, use case specification, the SRS, and possibly technical documents or system code are updated.

3. Process description

In this section a more detailed description of the Software Development and Requirements Management process of (Pandey et al., 2010) will be elaborated. This is done by utilizing the meta-modeling technique described in the method engineering approach of Van de Weerd and Brinkkemper (2008), which resulted in a process-deliverable diagram (PDD), an activity table, and a concept table. The PDD is depicted in figure 2 and consists of a process side and a deliverable side. The process side depicts the four main activities which are further specified to a more concrete level with the use of sub activities. The deliverable side depicts the various deliverables that are produced by the activities on the process side. The activity table describes each activity and its sub activities whereas the concept table provides definitions of the concepts used in the PDD.
The sub activity Collect raw requirements that is conducted in the Requirements elicitation and development phase is depicted as a closed activity. This is done because many elicitation techniques, e.g., interviewing, workshops and brainstorming, can be used to obtain the raw requirements. The exact actions performed in the activity are not prescribed and thus not relevant to show in this model. For a similar reason, the Analyze requirements activity is drawn as a closed activity, because of the many prioritization techniques that may be used.
The concepts ANALYZED REQUIREMENTs and RAW REQUIREMENTs (see concept table for definitions) have a many to many relationship. The reason for this is that a raw requirement can be too comprehensive and is split up to more than one analyzed requirement. The other way around, raw requirements can have some overlap and thus can be formulated in one analyzed requirement.

Figure 2 – PDD of the Requirement Engineering Process Model for Software development and Requirements Management.

3.1 Activities

Activity	Sub Activity	Description
Requirements elicitation and development	Identify stakeholders	The system analyst identifies all stakeholders of the system that is to be developed. This activity results in a STAKEHOLDERS DESCRIPTION.
	Collect raw requirements	This activity, performed by the system analyst, concerns the elicitation and collecting of RAW REQUIREMENTs from different viewpoints e.g., customer, users, constraints, marketing, etc.
	Analyze requirements	This activity concerns the negotiation, agreement, communication and prioritization of RAW REQUIREMENTs, which results in a collection of ANALYZED REQUIREMENTs.
	Allocate requirements	Allocation of requirements is an architectural activity that is performed in order to design the structure of the system and to allocate the top-level FUNCTIONAL- and NON-FUNCTIONAL REQUIREMENTs to subsystems (Pandey et al., 2010).
	Flow down requirements	During this iterative process, the allocated top-level REQUIREMENTs are decomposed down to the level at which it can be designed and tested. The deliverable of this activity is a REQUIREMENTS DECOMPOSITION, which consists of top-level requirements which are decomposed in so called DERIVED REQUIREMENTs.
Documentation of requirements	Identify requirements	This activity focuses on assigning a unique identifier to all REQUIREMENTs which is necessary in order to refer to REQUIREMENTs during product development and management. This activity will update the DERIVED REQUIREMENTs – created in the previous phase – with a unique identifier.
	Specify requirements	This activity concerns the elaboration of the SOFTWARE REQUIREMENT SPECIFICATION.
Requirements verification and validation	Validate requirements	During the validate requirements activity is validated whether the correct REQUIREMENTs are stated in the SOFTWARE REQUIREMENT SPECIFICATION. A manner to perform this validation is by conducting REQUIREMENT REVIEWs with the stakeholders – listed in the STAKEHOLDER DESCRIPTION – of the software product.
	Verify requirements	This activity addresses the verification of the REQUIREMENTs that are described in the SOFTWARE REQUIREMENT SPECIFICATION, i.e., check whether the requirements are stated correctly. This includes the correctness, consistency, unambiguousness and understandability of requirements.
Requirement management and planning		This phase manages changes in-, and keeps track of the agreed REQUIREMENTs, their mutually relationships, and the dependencies between the various documents elaborated during the software engineering process. Requirements management is a continuous phase that remains active after the completion of development and during maintenance.

3.1 Concepts

Concept	Description
STAKEHOLDERS DESCRIPTION	The STAKEHOLDERS DESCRIPTION contains details about the different stakeholders of the system, from which raw requirements can be extracted (Pandey et al., 2010).
SOFTWARE REQUIREMENT SPECIFICATION	The SOFTWARE REQUIREMENT SPECIFICATION (SRS) describes what the software system is expected to do and how it is expected to do this. The SRS consists of use cases which specify the user interaction and an elaborate description of the non-functional requirements (Pandey & Ramani, 2009b).
RAW REQUIREMENT	A RAW REQUIREMENT is the type of REQUIREMENT that still needs to be analyzed and written down in a well formed notation (Pandey et al., 2010).
REQUIREMENT	A REQUIREMENT define the needs of stakeholders regarding a potential new system and what a system must do to satisfy those needs (Hull, Jackson, & Dick, 2010).
USE CASE MODEL	A view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’) (OMG, 2011). Every use case can be specified in a use case specification. A template can be found here: template-use_case_specification.doc
ANALYZED REQUIREMENT	This type of REQUIREMENTs is the result of the ‘Analyze requirements’ activity in which RAW REQUIREMENTs are negotiated and agreed on, and are communicated, prioritized and written down in a well formed notation (Pandey et al., 2010).
REQUIREMENTS DECOMPOSITION	A decomposition of top-level requirements – i.e., ANALYZED REQUIREMENTs – towards requirements with a lower level of abstraction – DERIVED REQUIREMENTs (Pandey et al., 2010).
REQUIREMENTS ALLOCATION	An allocation of top-level requirements to subsystems (Pandey et al., 2010).
FUNCTIONAL REQUIREMENT	REQUIREMENTs which specify actions that must be performed by a system (Jalote, 1997).
NON-FUNCTIONAL REQUIREMENT	REQUIREMENTs that address system qualities like performance, portability, maintainability, etc. (Jalote, 1997).
INTERFACE REQUIREMENT	DERIVED REQUIREMENTs that arise when the subsystems need to communicate with one another to accomplish an overall result. This result is needed to share data or power or a useful computing algorithm (Parviainen, Hulkko, Kääriäinen, Takalo, & Tihinen, 2003).
SUBSYSTEM REQUIREMENT	DERIVED REQUIREMENTs that must be imposed on the subsystems themselves but do not necessarily provide a direct benefit to the end user (Parviainen et al., 2003).
DERIVED REQUIREMENT	REQUIREMENTs with a lower level of abstraction, derived from the requirements decomposition process, that must be imposed on subsystems (Pandey et al., 2010).
REQUIREMENT REVIEW	Requirement reviews are conducted with stakeholders in order to validate the requirements as stated in the SOFTWARE REQUIREMENT SPECIFICATION.

4. Related literature

Requirements engineering is a software engineering process – traditionally executed in the early stage of software development – which includes the activities concerning the discovery or elicitation, documentation and maintenance of the requirements for a software system. Since the 1990s, requirements engineering has come into general use after a publication of Dorfman (1990) on system and software requirements engineering.
The appropriate phases constituting the requirements engineering process depend strongly on the type of software or the context of the developing organization. The requirements engineering process of software product companies, for example, differs significantly from that of customized software (Regnell & Brinkkemper, 2005). In addition, various types of requirements and thus requirements engineering processes are distinguished – e.g. the authors of the examined process also worked on an approach to information requirement engineering (Pandey et al., 2011b) and security requirement engineering (Pandey et al., 2011c). However, phases oriented towards requirements elicitation (cf. first phase in the PDD depicted in figure 2), specification (see the SRS concept in the PDD), validation and management are regularly encountered in the literature (Sommerville, 2006), and they are all – in one way or another – included in the requirements engineering process proposed by Pandey et al. (2010).
The authors of the proposed requirement engineering process claim that their process is more effective in producing quality requirements (Pandey et al., 2010) compared to other processes, which have a lack of effective coherence and communication with the software development process (Chatzoglou & Macaulay, 1996; Sommerville & Kotonya, 1998) or have a lack of comprehensiveness and do not cover all the required dimensions of requirement engineering (Sommerville & Kotonya, 1998).
The requirement engineering process proposed by Pandey et al. (2010) adopted some requirement engineering fundamentals described in the work of Jalote (1997), which defines a requirement as a condition or capability that must be met or possessed by a system to satisfy a specification or other formally imposed document. In addition, Jalote (1997) classifies requirements into functional and non-functional requirements (see section 1 for an explanation).
The authors of the process do not explicitly mention suitability for a specific software development context. Market driven development for example, differs significantly from the development of tailor made software, hence the existence of the notion of market driven requirement engineering (MDRE) (Regnell & Brinkkemper, 2005). The process proposed by Pandey et al. (2010) does not address the possible relation with a release planning process and in addition, stakeholders in MDRE are far more complicated and diverse. The processes concerning requirements prioritization and scope change management are located within the release planning process area of the reference framework by Van de Weerd, Brinkkemper, Nieuwenhuis, Versendaal, & Bijlsma (2006). This emphasizes the tight integration of the requirement engineering activities within the market driven context, and indicates that the requirements process model proposed by Pandey et al. (2010) is suited mainly for the development of customer specific software systems. These are just a few of the reasons why requirement engineering for market driven development needs a more specific approach (Carlshamre, 2001; Karlsson, Dahlstedt, och Dag, Regnell, & Persson, 2003; Regnell & Brinkkemper, 2005). However, besides the many differences in requirement engineering dimensions between market driven- and customer specific development, we also recognize several similarities (Van de Weerd et al., 2006). When we compare the phases and activities of the requirement engineering process of Pandey et al. (2010) with the reference framework for software product management proposed by Van de Weerd et al. (2006), it becomes clear that the activities concerning the gathering, identification, and organizing of requirements are addressed in both process descriptions.
We did not find any publications that describe the application of the requirement engineering process by Pandey et al. (2010). However, the authors of the process elaborated a requirements modeling framework (Pandey et al., 2011a), which analyzes modern requirements modeling techniques. Several of these techniques can be incorporated into specific activities of the requirement engineering process analyzed in this paper.

5. References

-- RubenMijwaart - 13 Apr 2012