Page 287 -

258 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING

• A list of customers, users, and other stakeholders who participated in the
requirements elicitation activity.

• A description of the system’s technical environment.
• A list of requirements (preferably organized by function) and the domain
constraints that apply to each.
• A set of usage scenarios that provide insight into the use of the system or
product under different operating conditions.
• Any prototypes developed to better define requirements.

Each of these work products is reviewed by all people who have participated in the
requirements elicitation.

10.5.2 Requirements Analysis and Negotiation
Once requirements have been gathered, the work products noted earlier form the
basis for requirements analysis. Analysis categorizes requirements and organizes them
into related subsets; explores each requirement in relationship to others; examines
requirements for consistency, omissions, and ambiguity; and ranks requirements
based on the needs of customers/users.
? What As the requirements analysis activity commences, the following questions are
questions
must be asked asked and answered:
and answered • Is each requirement consistent with the overall objective for the
during system/product?
requirements
analysis? • Have all requirements been specified at the proper level of abstraction? That
is, do some requirements provide a level of technical detail that is inappropri-
ate at this stage?
• Is the requirement really necessary or does it represent an add-on feature
that may not be essential to the objective of the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source (generally, a
specific individual) noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will house
the system or product?
Requirements Analysis
• Is each requirement testable, once implemented?
It isn’t unusual for customers and users to ask for more than can be achieved,
given limited business resources. It also is relatively common for different customers
or users to propose conflicting requirements, arguing that their version is “essential
for our special needs.”