Page 301 -

272 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING

QUICK consequence of requirements How do I ensure that I’ve done it right? Software
LOOK analysis. Like system require- requirements analysis work products must be
ments, software requirements reviewed for clarity, completeness, and consis-
can be represented using a prototype, a specifi- tency.
cation or even a symbolic model.

Requirements analysis and specification may appear to be a relatively simple task,
but appearances are deceiving. Communication content is very high. Chances for
“This sentence
contradicts itself— misinterpretation or misinformation abound. Ambiguity is probable. The dilemma
no actually it that confronts a software engineer may best be understood by repeating the state-
doesn't.” ment of an anonymous (infamous?) customer: "I know you believe you understood
what you think I said, but I am not sure you realize that what you heard is not what
Douglas Hofstadter
I meant."

11.1 REQUIREMENTS ANALYSIS

Requirements analysis is a software engineering task that bridges the gap between
system level requirements engineering and software design (Figure 11.1). Require-
ments engineering activities result in the specification of software’s operational char-
acteristics (function, data, and behavior), indicate software's interface with other
system elements, and establish constraints that software must meet. Requirements
analysis allows the software engineer (sometimes called analyst in this role) to refine
the software allocation and build models of the data, functional, and behavioral
domains that will be treated by software. Requirements analysis provides the soft-
ware designer with a representation of information, function, and behavior that can
be translated to data, architectural, interface, and component-level designs. Finally,
the requirements specification provides the developer and the customer with the
means to assess quality once software is built.
Software requirements analysis may be divided into five areas of effort: (1) prob-
lem recognition, (2) evaluation and synthesis, (3) modeling, (4) specification, and (5)
“We spend a lot of
time—the majority review. Initially, the analyst studies the System Specification (if one exists) and the Soft-
of total project ware Project Plan. It is important to understand software in a system context and to
time—not review the software scope that was used to generate planning estimates. Next, com-
implementing or munication for analysis must be established so that problem recognition is
testing, but trying to
decide what to ensured. The goal is recognition of the basic problem elements as perceived by the
build.” customer/users.
Brian Lawrence Problem evaluation and solution synthesis is the next major area of effort for analy-
sis. The analyst must define all externally observable data objects, evaluate the flow
and content of information, define and elaborate all software functions, understand
software behavior in the context of events that affect the system, establish system