44 PART | II ITS users
• Their goals are varying and conflicting since they depend on stakeholders’
perspectives of the work environment and the tasks to be accomplished by
the new system.
• The difficulty to clearly define and quickly communicate these goals slows
down the implementation process and further constrains their satisfaction.
4.2 Requirements elicitation
Because requirements engineering handles system requirements and maps them
to the system development process, the elicitation of these requirements is one
of the first and most critical steps of the development life-cycle. The require-
ment elicitation process attempts to define end-users’ needs and problems, to
address them and resolve them respectively and deliver a high-quality software
product. Software quality depends largely on the quality of the requirements
upon which it has been developed. However, the elicitation of users’ require-
ments can be difficult, because users’ needs are constantly changing, making it
hard to determine, or to gather completely. In addition, many social issues can
affect the elicitation process.
According to Bell & Thayer (1976), “The requirements for a system do
not arise naturally; instead, they need to be engineered and be continuously
reviewed and revised.” It is therefore important to understand the stakeholders’
needs and constraints and successfully integrate them into the system develop-
ment process (Mead & Stehney, 2005). According to Kotonya & Sommerville
(1998), the major phases of requirements engineering are:
• Elicitation: During this phase we find the real customer needs and record
the actual requirement of the system. It also evaluates alternative solutions
and examines how they can serve stakeholders in achieving their goals (Hof-
mann & Lehner, 2001).
• Analysis and negotiation: In this second phase, analysts identify conflict-
ing requirements that come from different stakeholders, discuss it with each
stakeholder individually, and negotiate with them in order to reach a solution
without conflicts.
• Documentation: This phase includes the formal specification of all require-
ments, using proper requirement specification templates (e.g., IEEE soft-
ware requirements specification template). The resulting document will be a
guide for the remaining development stages.
• Validation: The aim of the validation phase is to ensure that the requirement
specifications produced so far are free of any conflicts, omissions, or mis-
takes and that they cover the stakeholders’ needs collected in the elicitation
phase.
• Management: The last phase concerns the long-term management of re-
quirements, which are the next steps of the software development life cycle.
Since many issues may arise at later stages of the development process, it