184 CHAPTER ◆ 2 0 Plan and Document Technology Specifications
Nevertheless, the product team must still communicate clearly the scope and specifi-
cations so the development team knows exactly what is expected. To this end, we recom-
mend the product team assemble a Software Requirements Specification (SRS). An SRS
for a trading/investment system consists of the combined, ordered, and linked descrip-
tions and documents, and prototypes created in earlier stages, including data dictionary,
data maps and data flow maps, GUI requirements, error handling maps, and report gen-
eration maps. An SRS will allow the development team to quickly build the system to the
proper specifications. In this respect, K | V Stages 1 and 2 were essentially requirements
gathering for Stage 3.20.1. Software Requirements Specification
A trading/investment system SRS, adapted from the IEEE Standard 830-1984, includes
all of the required features and functionalities and all of the items that the development
team will need to design and build the production trading/investment system (or at least
the automated parts). The SRS is the parent document; all subsequent Stage 3 documents,
such as design documents, software architecture documents, testing and validation plans,
and documentation plans, will be derived from it. A well-written, agreed-upon SRS is
the product team ’ s assurance that the development team understands the problems to be
solved and the necessary software behaviors. Furthermore, the prototypes that become
part of the SRS also serve as the parent document for testing and validation strategies
that will be applied to the requirements for verification. As software design and devel-
opment proceed, the design elements and the actual code should be tied back to the
requirement(s) that defines them using code comments. Once the team has regression
tested and accepted objects, then quality assurance testers should review and approve all
final code comments prior to user acceptance testing.
While prototypes already exist for most of the application, the development team will
encounter and address them one by one. As with all high-level documents in engineer-
ing, we expect these to be revised in an orderly process as the team iterates through Stage 3.
(This is no different than with the revision process of quality management using ISO
9000.)20.1.1. Elements of a Trading/Investment System ’ s Software
Requirements Specification
While an SRS may appear to be lengthy, most of it is already complete, based upon the
work of previous stages. For specifications that are unclear or non-sequitur, the product
team should take care to link and prioritize concepts with additional written explanation.I. Introduction
A. Purpose of the system
B. Project scope
C. Quality attribute requirements
D. User documentation requirements
E. References