Availability Guide for Application Design

Minimizing Programming Errors
Availability Guide for Application Design—525637-004
9-9
Specify and Review the Requirements
helping the designers and developers to organize their ideas, sharing information and
code, and facilitating personnel changes.
Specify and Review the Requirements
The first phase of developing any application must be to specify what you are building
in terms of the goals and objectives of the product and to write it down in a
requirements specification. You must assess the feasibility of the project and its costs,
resolve conflicting requirements, and establish priorities and tradeoffs.
All interested parties must be involved and must agree on what it is you are about to
build. Attempts to alter the purpose of the product later in the development cycle not
only lead to extensive delays but also make it less likely that the final product will
execute as intended. Agreement must be reached before you proceed.
It is usually appropriate to provide prototype screens at this stage in the development
cycle to ensure that the application has the appropriate “touch and feel.”
A formal inspection and sign-off of the requirements documentation is one way of
making sure that consensus is reached before proceeding. For the inspection or other
review process to be effective, it must include empowered representatives of each
interested organization.
Formal review of your product requirements will add time to the early phases of your
schedule. Given the benefits of improved quality and the fact that the review will
probably save you more time and money later in the development cycle, however, it is
clearly a worthwhile investment.
Specify and Review the Design
Once the requirements are agreed upon, the next phase specifies the application
design. Starting with a specification of the external features of the application, your
design team needs to generate a complete design, ultimately specifying the function of
each module in the application, before coding begins.
All groups involved in the design should formally agree on the proposed design. Errors
in the design phase will certainly lead to integration difficulties and to more errors in the
development and testing phase. As a result, not only will time be wasted later in the
development cycle, but also the likelihood is increased of problems occurring when the
application goes into production. A little extra time taken now to get the design right will
clearly pay back later in the development cycle.
Once again, a formal inspection is one way of building quality into your application
design. Whatever the review method you choose, however, the synergy obtained from
a group review will add quality to your design.
Incremental Implementation and Unit Testing
To ensure quality in the final product, you must build each module with a high level of
quality. Delaying testing until all the code is written and then testing each feature of the