Page 300 -

CHAPTER

ANALYSIS CONCEPTS AND
11 PRINCIPLES

KEY oftware requirements engineering is a process of discovery, refinement,
CONCEPTS modeling, and specification. The system requirements and role allocated
analysis Sto software—initially established by the system engineer—are refined in
principles . . . . . 282
detail. Models of the required data, information and control flow, and opera-
essential view . . 288
tional behavior are created. Alternative solutions are analyzed and a complete
FAST . . . . . . . . . . 275 analysis model is created. Donald Reifer [REI94] describes the software require-
implementation ment engineering process in the following way:
view . . . . . . . . . . 288
information Requirements engineering is the systematic use of proven principles, techniques, lan-
domain . . . . . . . . 283 guages, and tools for the cost effective analysis, documentation, and on-going evo-
partitioning. . . . . 286 lution of user needs and the specification of the external behavior of a system to
prototyping . . . . 289 satisfy those user needs. Notice that like all engineering disciplines, requirements
requirements engineering is not conducted in a sporadic, random or otherwise haphazard fash-
elicitation . . . . . . 274 ion, but instead is the systematic use of proven approaches.
QFD . . . . . . . . . . . 279
Both the software engineer and customer take an active role in software
specification
principles. . . . . . . 291 requirements engineering—a set of activities that is often referred to as analy-
specification sis. The customer attempts to reformulate a sometimes nebulous system-level
review . . . . . . . . 294 description of data, function, and behavior into concrete detail. The developer
use-case . . . . . . . 280 acts as interrogator, consultant, problem solver, and negotiator.

QUICK What is it? The overall role of soft- Why is it important? If you don’t analyze, it’s highly
LOOK ware in a larger system is identi- likely that you’ll build a very elegant software
fied during system engineering solution that solves the wrong problem. The result
(Chapter 10). However, it’s necessary to take a is: wasted time and money, personal frustration,
harder look at software’s role—to understand the and unhappy customers.
specific requirements that must be achieved to What are the steps? Data, functional, and behav-
build high-quality software. That’s the job of soft- ioral requirements are identified by eliciting infor-
ware requirements analysis. To perform the job mation from the customer. Requirements are
properly, you should follow a set of underlying refined and analyzed to assess their clarity, com-
concepts and principles. pleteness, and consistency. A specification incor-
Who does it? Generally, a software engineer per- porating a model of the software is created and
forms requirements analysis. However, for com- then validated by both software engineers and
plex business applications, a “system analyst”— customers/users.
trained in the business aspects of the application What is the work product? An effective representa-
domain—may perform the task. tion of the software must be produced as a

271