Information Technology Reference
In-Depth Information
Chapter 6
Object-Oriented Analysis
6.1 Introduction to Analysis
During the requirements elicitation phase of the software life cycle, information
that will be used to define the software system is gathered from numerous sources
and organized for this purpose. This information comes in the form of require-
ments, which are categorized into functional and non-functional requirements.
Functional requirements lay out what a system must do, while non-functional
requirements dictate the environment and constraints within which a system must
operate. At the end of the requirements phase, this information is composed into an
initial system specification that provides both a general outline for the system and
a detailed view of the qualities that the system will have. So, with our requirements
understood and our system defined, are we ready to move onto design?
No, we are not. It is crucial to never forget the vast difference between
''understood'' and ''well understood'', and between ''defined'' and ''well defined''.
The requirements specification produced during the elicitation phase does provide
some level of definition for our system, but this is a rough draft at best. To ensure
the success of a software engineering project, this initial specification must be
scrutinized, appended, and refined as many times as needed to produce a require-
ments specification that satisfies the client's demands, meets the user's needs, does
not exceed the system constraints, and is fully understood by the software devel-
opment team. All of this must be fully accomplished before system design begins,
and encompasses the second phase of the software engineering life cycle: Analysis.
Analysis is the systematic evaluation, modification, and refinement of a sys-
tem's requirements, gathered during the requirements elicitation phase, into a final,
functional requirements specification. During analysis, systems analysts review
requirements with a goal of identifying and correcting missing or erroneous
information. As a part of this, they ensure that no requirements were left out during
the elicitation phase, neither due to incomplete interviews and information gath-
ering nor due to the decision made by an engineer that some piece of information
was too obvious to include. They also review the questions asked during client and
user interviews, to ensure that both the interviewer and the interviewee were
