Page 117 -

100 Chapter 4 Requirements engineering

FPO Feasibility studies

A feasibility study is a short, focused study that should take place early in the RE process. It should answer three
key questions: a) does the system contribute to the overall objectives of the organization? b) can the system be
implemented within schedule and budget using current technology? and c) can the system be integrated with
other systems that are used?
If the answer to any of these questions is no, you should probably not go ahead with the project.

http://www.SoftwareEngineering-9.com/Web/Requirements/FeasibilityStudy.html

non-functional requirements, and the user requirements for the system. Later in the
process, in the outer rings of the spiral, more effort will be devoted to eliciting and
understanding the detailed system requirements.
This spiral model accommodates approaches to development where the require-
ments 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. Agile development can be used instead of prototyping so that the
requirements and the system implementation are developed together.
Some people consider requirements engineering to be the process of applying a
structured analysis method, 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, which then serve as a system specification. The set of models
describes the behavior of the system and is annotated with additional information
describing, for example, the system’s 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 on it by rigid system models.
In virtually all systems, requirements change. The people involved develop a bet-
ter 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 I cover in Section 4.7.

4.5 Requirements elicitation and analysis

After an initial feasibility study, the next stage of the requirements engineering
process is requirements elicitation and analysis. In this activity, software engineers
work with customers and system end-users to find out about the application domain,
what services the system should provide, the required performance of the system,
hardware constraints, and so on.