Information Technology Reference
In-Depth Information
6.3.1 Software Development Manager's Documents
Software requirements
are the foundation on which all subsequent documentation and
code are written. If these critical documents are either missing (see Chapter 1's game
of “Gossip”) or incorrect, then no programming staff can deliver the correct soft-
ware. The format for requirements varies widely from company to company. If your
company is new to writing requirements for your software, consider starting with the
software requirements templates found in the Rational Software Development Tool
RequisitePro. [23] The templates in this tool enjoy a good industry reputation. So why
not use recognized quality templates until your company has gained enough of its
own experience to customize the requirements templates where appropriate … if you
really fi nd the need to customize.
Software project plans
contain the roadmap that the software development will
follow for this particular system or product. If your software development projects
always come in on time and under budget, then perhaps you do not need to static test
this document. If your software development projects tend to be late or over budget,
then perhaps a little static testing can help identify some of the planning gaps that
contribute to those overruns.
6.3.2 Software Developers' Documents
Use cases
are the formal documentation of the business processes that the new
system must provide. This documentation identifi es the actors (different roles
the system users play) and activities (processes that are performed by specifi c
actors). There is no industry consensus about who should write these use cases
or how much process detail the use cases need to express. Because the develop-
ment managers typically do not write use cases and the test teams typically base
part of their test plans on use cases, it seems expedient to place the authorship of
use cases somewhere in the development team's realm with or without business
assistance.
Software designs
contain the high-level technical solution (the
how
) for the
business requirements (the
what
) that are expressed in part by use cases. It is the
what
to
how
linkage that is most often incomplete, leading to missed, or poorly understood
features and capabilities. All the software developer's documents below
software
designs
, that is,
s o f t w a r e s p e c i fi c a t i o n s , d a t a fl o w d i a g r a m s , d a t a b a s e a n d fi l e d e s i g n s ,
online operating environment specifi cations, batch operating environment specifi -
cations, interfaces, connectivity (network) specifi cations, security specifi cations,
screen/window/page specifi cations, report specifi cations, and code
are successively
deeper details of the technical implementation of the business requirements. Not all
documents are needed for every system or application. Part of the software develop-
ment manager's job is to identify which of these documents need to be written for the
new project. There are two static testing concerns that run through this list of more
detailed documents. The fi rst static testing concern is completeness, that is, the more
detailed documents must completely describe the next level of technology needed to
Search WWH ::
Custom Search