Information Technology Reference
In-Depth Information
mistake that could entirely derail a project and ruin the reputation of a software
engineering firm. Instead, analysts must continue to engage the client and the end
user in order to highlight incomplete or incorrect information, and then must use
this information to evaluate the requirements specification. During this evaluation,
analysts must keep in mind that analysis serves two distinct purposes based on two
distinct groups, the client and the engineers, and that each group will view the
specification from a different point of view. The vocabulary and technical infor-
mation included in the specification document must thus meet the needs of both
without exceeding the comprehension of either. In addition, assumptions about
information made by one group cannot be assumed to be understood by the other.
To ensure that such mistakes do not occur, in depth discussions concerning the
specification should be conducted amongst all of the parties involved in devel-
opment (Stiller and LeBlanc
2002
). Keeping in mind the issues of accuracy,
completeness and ambiguity, analysts must read over the requirements in order to
formulate questions about the system, which will provide the basis for these dis-
cussions. These questions often come in two major forms. The first expressly
covers the information provided in the existing requirements. Is it accurate? Is it
complete? Is it unambiguous? The second questions, which are much harder to
compose, seek to uncover information that was left out of the original specification
entirely. Often times, experts may consider some piece of information to be too
obvious to include at all, or too simple to require specifying. Unfortunately, such
omissions may represent critical gaps in the system's specification and may result
in the reduced functionality of the final system, which may no longer meet the
client's requirements. To ensure that all necessary information is included in the
final requirements specification, the evaluation must be exhaustive and in depth. It
is far better to provide too much information, which can be refined before the
finalization of the specification document, than to provide too little.
6.2.2 Refining Requirements Specification through
Prototyping
True to its object-oriented roots, the requirements analysis is an iterative process,
creating a more complete, accurate, and unambiguous specification document with
each cycle. At the beginning of the phase, analysts evaluate the requirements
specification for errors. This information is then added to the specification to create
an updated set of requirements. This updated set is then evaluated again, and the
information gained from that second evaluation is used to create an even more
refined version of the set. This sequence is repeated and improved upon until the
requirements specification meets the needs of the project. With each iteration,
the questions produced during the evaluation should better target the needs of the
analysts, and, as such, the discussions that are held should be more efficient and
more focused. The process should refine not only the requirements themselves, but
the communication that takes place.
