Page 285 -

256 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING

the role of requirements engineering is to establish the interfacing mechanisms that
will enable this to happen.
The element view for product engineering is the engineering discipline itself applied
to the allocated component. For software engineering, this means analysis and design
modeling activities (covered in detail in later chapters) and construction and integra-
tion activities that encompass code generation, testing, and support steps. The analy-
sis step models allocated requirements into representations of data, function, and
behavior. Design maps the analysis model into data, architectural, interface, and soft-
ware component-level designs.

10.5 REQUIREMENTS ENGINEERING

The outcome of the system engineering process is the specification of a computer-
based system or product at the different levels described generically in Figure 10.1.
“The hardest single But the challenge facing system engineers (and software engineers) is profound: How
part of building a can we ensure that we have specified a system that properly meets the customer’s
software system is
deciding what to needs and satisfies the customer’s expectations? There is no foolproof answer to this
build. . . . No other difficult question, but a solid requirements engineering process is the best solution
part of the work so we currently have.
cripples the resulting Requirements engineering provides the appropriate mechanism for understand-
system if done ing what the customer wants, analyzing need, assessing feasibility, negotiating a rea-
wrong. No other part
is more difficult to sonable solution, specifying the solution unambiguously, validating the specification,
rectify later. and managing the requirements as they are transformed into an operational system
Fred Brooks [THA97]. The requirements engineering process can be described in five distinct steps
[SOM97]:

• requirements elicitation
• requirements analysis and negotiation
• requirements specification
• system modeling
• requirements validation
• requirements management
WebRef
10.5.1 Requirements Elicitation
A detailed report entitled
“Issues in Requirements It certainly seems simple enough—ask the customer, the users, and others what the
Elicitation” can be
downloaded from objectives for the system or product are, what is to be accomplished, how the sys-
www.sei.cmu.edu/ tem or product fits into the needs of the business, and finally, how the system or prod-
publications/ uct is to be used on a day-to-day basis. But it isn’t simple—it’s very hard.
documents/92.
reports/ Christel and Kang [CRI92] identify a number of problems that help us understand
92.tr.012.html why requirements elicitation is difficult: