Information Technology Reference
In-Depth Information
A requirement specifies an externally visible function or attribute of a system. A
design describes a particular subcomponent of a system or its interfaces with other
subcomponents or both. This criterion should be applied throughout the creation of
the requirements analysis diagrams; the addition of any design details to the
requirements models should be delayed until the design phase. Once the use case is
complete, we can analyze the use case for object interactions, state changes
contained within the use case, and the functional or data requirements of the use
case. These requirements are discovered and documented in the corresponding
object, state transition, and DFDs. Again, only externally visible objects and object
interactions should be captured. Not all associations, attributes, and methods are
shown in the diagrams. In addition, most of the classes represented in our object
diagram will each yield a single object in the finished system. We have blurred the
distinction between classes and objects. When writing specifications, it is impor-
tant to state whether the requirement applies only to an object of the class or to the
entire class being specified.
Once all externally visible objects and behavior have been captured graphically,
it is a simple matter to translate the pictures into words. The translation is
accomplished by walking through the diagrams and stating the associations
depicted in plain language. It is sometimes helpful to select aggregate constructs
from the object diagram and describe their requirements first. This helps establish
the context for the rest of the system. We recommend conducting an informal peer
review prior to translation to make sure all requirements are contained in the
diagrams and that no design information has been included. Each requirement
should be numbered or otherwise marked for inclusion in a requirements-tracking
database. Requirements tracking is needed to complete the trace tables in the
testing documentation and to verify requirements flow down from higher level
specifications. In our example, requirement numbers are contained in parenthesis
following the requirement. The external interface requirements are readily visible
from the DFD. When capturing interface requirements, care must be taken to avoid
specifying design detail when adding the DID-required data characteristics. By the
same token, design constraints that form externally visible restrictions on inter-
faces must be specified. A detailed example of an SRS section is given in the
sidebar at the end of the article titled ''Sample SRS Section''.
6.2 Requirements Specification and the Specification
Document
A software system is characterized based on its behavior, which must be engi-
neered to suit the needs of the client and end user. As we discussed in the previous
chapter, these needs are known as requirements, and are initially gathered during
the requirements elicitation phase of the software life cycle. In the last section, we
introduced the concept of requirements analysis, whereby those requirements
