Application Development
Gather requirements
This is a template designed to facilitate gathering user and system requirements.
In some cases, many of these requirements will have been collected prior
to this step and may be found in other documents such as the IS&C project
request document, project scope document, or a service request. These will
be very specific requirements that outline precisely what the software ought
to do, and may optionally include an interface mock-up. A requirements document
may be developed by anyone, it need not be written by a programmer.
Perform and document analysis of requirements
This document starts with a set of use cases for the functional and non-functional
requirements that were documented in the requirements document, to be
addressed by the software. It also includes scenarios for each use case
that describe all the possible outcomes of a use case, given various input.
Outline a proposed design for the software
This template captures specific details that describe the software at
several levels. The first section includes UML models that show how various
components (objects) will interact. Following that is an API section that
documents fields and methods within a given object. The last section revisits
the functional and non-functional requirements, and shows how the proposed
design addresses each requirement. The developer(s) will likely refine
the design document as they begin to write code, so step three is essentially
an iterative stage and results in both a design document and an implementation.
Another key component of this stage is the design review, where a group
that is familiar with the requirements sits down and reviews the proposed
design with the developer(s).
Document test cases
This document outlines and guides three types of testing. First, it documents
a comprehensive series of tests to determine if each method handles invalid
argument values appropriately (referred to as invariant testing). Next,
it documents tests that verify that the application's methods perform
correctly given raguments that falls within the range of acceptable values.
These tests are derived from scenarios in the analysis document, and there
should be tests that correspond to each method described in the API section
of the Design document. The first two types of testing can be automated
to a certain extent using a testing harness such as JTest for Java or
similar software. Finally, the document outlines system testing. These
tests will verify that the system as a whole does what it is supposed
to do (as outlined in the requirements document). This may include functional
testing by testing and/or user support staff, based on usage scenarios,
usability testing by representative end users (if the application has
a user interface) and load testing, to ensure that the application performance
is acceptable using a tool such as LoadRunner.
Prepare deployment documentation
This document outlines the requirements for the environment in which the
software will be deployed, and also provides other support documentation
that can be used in the administration of the software once it is deployed
in production. This content would typically be included in a run book
for the application or system. Sections include: System/Environment Requirements,
input and output sources, monitoring, maintenance/backup, and contact
information. The deployment document also recommends a format for a README
file and an installation document.
 |
