资料内容：
Requirements elicitation and analysis may involve a variety of different kinds of
people in an organization. A system stakeholder is anyone who should have some
direct or indirect influence on the system requirements. Stakeholders include end
users who will interact with the system and anyone else in an organization who will
be affected by it. Other system stakeholders might be engineers who are developing
or maintaining other related systems, business managers, domain experts, and trade
union representatives.
A process model of the elicitation and analysis process is shown in Figure 4.13.
Each organization will have its own version or instantiation of this general model
depending on local factors such as the expertise of the staff, the type of system being
developed, the standards used, etc.
The process activities are:
1.
Requirements discovery This is the process of interacting with stakeholders of the
system to discover their requirements. Domain requirements from stakeholders and
documentation are also discovered during this activity. There are several comple
mentary techniques that can be used for requirements discovery, which I discuss
later in this section.
2.
Requirements classification and organization This activity takes the unstruc
tured collection of requirements, groups related requirements, and organizes
them into coherent clusters. The most common way of grouping requirements is
to use a model of the system architecture to identify sub-systems and to associ
ate requirements with each sub-system. In practice, requirements engineering
and architectural design cannot be completely separate activities.
3.
Requirements prioritization and negotiation Inevitably, when multiple stake
holders are involved, requirements will conflict. This activity is concerned with
prioritizing requirements and finding and resolving requirements conflicts
through negotiation. Usually, stakeholders have to meet to resolve differences
and agree on compromise requirements.
