Information Technology Reference
In-Depth Information
talking about the same thing. If not controlled, such miscommunications and
misunderstandings can lead to inaccurate responses and thus incorrect require-
ments. Similarly, the analysts must ensure that requirements are written using
terminology and concepts that are well understood by everyone involved in the
project. Failure to do so can lead to a misunderstanding between those who
conducted the interviews and the engineers who will be responsible for designing
and building the system. This will result in a system that does not meet the client's
intended requirements, even though the system is representative of their under-
standing of what was thought to be a complete requirements specification.
When the analysts discover errors or omissions during this evaluation period,
new information is gathered to fill in the gaps, using improved techniques or new
interview questions. If requirements are determined to be poorly worded,
ambiguous, or incomplete, they are corrected and rewritten. This new information
is then composed into a more well-refined, updated requirements specification.
Various methods will be used to verify this new system definition. Then, when the
results are in, the analysts will start the whole process over again. This sequence
will be repeated as needed, as the requirements specification evolves from the
initial rough draft to a final, workable characterization of the intended system. The
resulting requirements specification must be composed of requirements that are
well understood, concise, able to be measured and tested, realistic, and sufficiently
detailed for system design.
6.1.1 What is Object-Oriented Analysis?
Requirements analysis is a traditional practice in the field of engineering. As we
have discussed with other concepts throughout this topic, the concepts behind the
object-oriented paradigm have been applied to this field to produce a new practice:
object-oriented requirements analysis. During requirements analysis, the prob-
lem statement is studied to identify objects or classes of objects and the rela-
tionship between objects. A set of scenarios or use cases are developed that help
identify objects and describe the behavior of the system. The objects and their
relationships are expressed graphically on an object diagram. A State Transition
Diagram (STD) depicts the permitted states of an object and the events that cause a
change of state. This captures the dynamic behavior of the system. Finally,
functional relationships and data requirements are shown on a Data Flow Diagram
(DFD) We shall extract software requirements from all three diagrams to build our
software requirements specifications (SRS). A common problem in requirements
analysis is determining the difference between a software requirement and a design
implementation. Since the object-oriented models created during the requirements
analysis phase are adorned with design information in later phases, there is a
tendency to over specify, which adds design constraints to requirements. The
Institute of Electrical and Electronics Engineers (IEEE) recommended practice for
SRSs (IEEE
1998
) provides guidance for differentiating requirements from design.
