January 2011 Edition
Computer Science Department, University of Cape Town
| MIT Notes Home | Edition Home |
| MSc-IT Study Material January 2011 Edition Computer Science Department, University of Cape Town | MIT Notes Home | Edition Home | |
At its most essential, requirements engineering is focused on discovering what it is that should be developed (and not how it should be developed). There are a number of aspects to this:
What does the customer want?
What does the user require in order to use the system?
What will the software's impact on the users be?
To discover this information, requirements engineering contains a number of overlapping steps:
Inception, in which the nature and scope of the system is defined.
Elicitation, in which the requirements for the software are initially gathered.
Elaboration, in which the gathered requirements are refined.
Negotiation, in which the priorities of each requirement is determined, the essential requirements are noted, and, importantly, conflicts between the requirements are resolved.
Specification, in which the requirements are gathered into a single product, being the result of the requirements engineering.
Validation, in which the quality of the requirements (i.e., are they unambiguous, consistent, complete, etc.), and the developer's interpretation of them, are assessed.
Management, in which the changes that the requirements must undergo during the project's lifetime are managed.
Requirements engineering will usually result in one or more work products being produced. These products, taken together, represent the software's specification (see the specification step previously mentioned, and detailed below). These work products, however, do not have to be formal, written documents — indeed, the work products can be a set of models, a formal mathematical specification, a collection of use cases or user stories, or even a software prototype.
These steps are overlapping for a variety of reasons. You should be able to notice that some of them, such as management, must occur throughout the communication and modelling activities. Negotiation will also occur at each of the various requirements engineering steps. More importantly, a process model which understands that requirements may be (initially) poorly understood, and that they may change through the project's lifetime, will also iteratively collect and detail the use cases (consider the unified process model from the previous chapter). This iterative process will forcefully overlap all of these steps.