Page 286 -

CHAPTER 10 SYSTEM ENGINEERING 257

• Problems of scope. The boundary of the system is ill-defined or the cus-
? Why is it so tomers/users specify unnecessary technical detail that may confuse, rather
difficult to
gain a clear than clarify, overall system objectives.
understanding of • Problems of understanding. The customers/users are not completely sure of
what the
customer wants? what is needed, have a poor understanding of the capabilities and limitations
of their computing environment, don’t have a full understanding of the prob-
lem domain, have trouble communicating needs to the system engineer, omit
information that is believed to be “obvious,” specify requirements that con-
flict with the needs of other customers/users, or specify requirements that
are ambiguous or untestable.
• Problems of volatility. The requirements change over time.

To help overcome these problems, system engineers must approach the requirements
gathering activity in an organized manner.
Sommerville and Sawyer [SOM97] suggest a set of detailed guidelines for require-
ments elicitation, which are summarized in the following steps:
• Assess the business and technical feasibility for the proposed system.
• Identify the people who will help specify requirements and understand their
Be sure you’ve
assessed overall organizational bias.
feasibility before you • Define the technical environment (e.g., computing architecture, operating
expend effort and time system, telecommunications needs) into which the system or product will be
eliciting detailed
requirements. placed.
• Identify “domain constraints” (i.e., characteristics of the business environ-
ment specific to the application domain) that limit the functionality or perfor-
mance of the system or product to be built.
• Define one or more requirements elicitation methods (e.g., interviews, focus
groups, team meetings).
• Solicit participation from many people so that requirements are defined from
different points of view; be sure to identify the rationale for each requirement
that is recorded.
• Identify ambiguous requirements as candidates for prototyping.
• Create usage scenarios (see Chapter 11) to help customers/users better iden-
XRef tify key requirements.
Requirements
elicitation methods are The work products produced as a consequence of the requirements elicitation activ-
presented in ity will vary depending on the size of the system or product to be built. For most sys-
Chapter 11.
tems, the work products include
• A statement of need and feasibility.
• A bounded statement of scope for the system or product.