Requirements elicitation and analysis

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.
Requirements elicitation and analysis may involve a variety of people in an organisation.
The term stakeholder is used to refer to any person or group who will be affected
by the system, directly or indirectly. Stakeholders include end-users who interact with
the system and everyone else in an organisation that may be affected by its installation.
Other system stakeholders may be engineers who are developing or maintaining
related systems, business managers, domain experts and trade union representatives.
Eliciting and understanding stakeholder requirements is difficult for several reasons:
I. Stakeholders often don't know what they want from the computer system except
in the most general terms. They may find it difficult to articulate what they
want the system to do or make unrealistic demands because they are unaware
of the cost of their requests.
2. Stakeholders naturally express requirements in their own terms and with
implicit knowledge of their own work. Requirements engineers, without experience
in the customer's domain, must understand these requirements.
3. Different stakeholders have different requirements, which they may express in
different ways. Requirements engineers have to consider all potential sources
of requirements and discover commonalities and conflict.
4. Political factors may influence the requirements of the system. For example,
managers may demand specific system requirements that will increase their influence
in the organisation.
5. The economic and business environment in which the analysis takes place is
dynamic. It inevitably changes during the analysis process. Hence the importance
of particular requirements may change. New requirements may emerge
from new stakeholders who were not originally consulted.general model, depending on local factors such as the expertise of the staff, the type
of system being developed and the standards used. Again, you can think of these
activities within a spiral so that the activities are: interleaved as the process proceeds
from the lOner to the outer rings of the spiral.
The process activities are:
1. Requirements discovery This is the process of interacting with stakeholders in
the system to collect their requirements. Domain requin:ments from stakeholders
and documentation are also discovered during this activity.
2. Requirements classijication and organisation This activity takes the unstructured
collection of requirements, groups related requirements and organises them
into coherent clusters.
3. Requirements prioritisation and negotiation Inevitably, where multiple stakeholders
are involved, requirements will conflict. This a,ctivity is concerned with
pnonusmg requirements, and finding and resolving requirements conflicts
through negotiation.
4. Requirements documentation The requirements are documented and input into
the next round of the spiral. Formal or informal requirements documents may
be produced.