Requirements Engineering Process
The goal of the requirements engineering process is to create and maintain a system requirements document. The overall process includes four high-level requirements engineering sub-processes. These are concerned with assessing whether the system is useful to the business (feasibility study); discovering requirements (elicitation and analysis); converting these requirements into some standard form (specification); and checking that the requirements actually define the system that the customer wants (validation). Figure 7.1 illustrates the relationship between these activities, It also shows the documents produced at each stage of the requirements engineering process. Specification and documentation are covered in Chapter 6; this chapter concentrates on the other requirements engineering activities.
The activities shown in Figure 7.1 are concerned with the discovery, documentation, and checking of requirements. In virtually all systems, however, requirements change. The people involved develop a better understanding of what they want the software to do: the organization buying the system changes; modifications are made to the system’s hardware, software, and organizational environment. The process of managing these changing requirements is called requirements management, which is covered in the final section of this chapter.
I present an alternative perspective on the requirements engineering process in Figure 7. 2. This presents the process as a three-stage activity where the activities are organized as an iterative process around a spiral. The amount of time and effort devoted to each activity in an iteration depends on the stage of the overall process and the type of system being developed. Early in the process, most effort will be spent on understanding high-level business and non-functional requirements and the user requirements. Later in the process, in the outer rings of the spiral, more effort will be devoted to system requirements engineering and system modeling.
This spiral model accommodates approaches to development in which the requirements are developed to different levels of detail. The number of iterations around the spiral can vary, so the spiral can be exited after some or all of the user requirements have been elicited. If the prototyping activity shown under requirements validation is extended to include iterative development, this model allows the requirements and the system implementation to be developed together.
Some people consider requirements engineering to be the process of applying structured analysis methods such as object-oriented analysis (Larman, 2002). This involves analyzing the system and developing a set of graphical system models, such as use-case models, that then serve as a system specification. The set of models describes the behavior of the system and are annotated with additional information describing, for example, its required performance or reliability.
Although structured methods have a role to play in the requirements engineering process, there is much more to requirements engineering than is covered by these methods. Requirements elicitation, in particular, is a human-centered activity and people dislike the constraints imposed by rigid system models. I focus on general approaches to requirements engineering here.