Requirements Documentation: A Systematic Approach
Unless you have a complete and precise description of a
product’s requirements, it
is very unlikely that those requirements will be satisfied. An incomplete or
inconsistent requirements document can mislead developers.
A collection of statements in English, or some other natural language, cannot
be
checked for completeness and will not be precise. Even if you translate an informal
requirements statement into a mathematical language, and show that the result
is
complete and unambiguous; the original may still be faulty.
This talk describes a sound procedure for documenting requirements - one that
lets
you know when your document is complete and consistent. Documents produced
by following this procedure can be reviewed by potential users and specialists
and
can serve as the input to tools that generate prototypes and monitors.
Paper
Decomposition of Software Into Components
Most software products are too large to be completed by
a single person in short period.
To make the development manageable, the software must be divided into components
that can be developed (and later maintained) separately. Each component will
be a work
assignment for a team or individual.
It is often thought that this decomposition is a management decision, determined
primarily by the talent available. This lecture explains that the decomposition
is a
critical design decision to be made on the basis of simple technical criteria,
which will
be stated and illustrated. The result is a very unconventional, but easily maintained,
design.
Paper
A Procedure for Interface Design
Improperly designed interfaces can make modular programs
almost indistinguishable
from “monoliths”. An interface encapsulates design decisions only
if it need not be
changed when those design decisions are changed. This talk presents a principle
for
interface design and a procedure for applying that principle. The principle
and procedure
are illustrated with a variety of examples.
Paper
Design through Documentation: The Path to Software
Quality
In traditional engineering design, preparation of
a sequence of documents precedes the actual
construction begins. Each document is used for review and analysis and, after
revision, serves as
input to the next phase in the development. When errors are discovered or changes
are required,
the design documents previously approved are updated and reviewed again. Each
new document
is reviewed against the previous documents. Whenever a document is revised,
those based on it
are reviewed and revised if necessary.
In software design this approach is rarely properly applied. Practitioners seem
unable or willing to
write the precise documents that would be required. Instead, they write vague
statements that
cannot be subject to rigorous analysis and are of little value to those making
the next decisions.
We will provide precise de?nitions of a set of software documents and how these
documents can be produced as part of an improved software development process.
Paper
Software Inspections We Can Trust
Software is devilishly hard to inspect. Serious errors can escape attention
for years. Consequently,
many are hesitant to employ software in safety-critical applications and developers
and users are finding
the correction of software errors to be an increasingly burdensome cost.
This talk describes a procedure for inspecting software that consistently finds
subtle errors in software
that is believed to be correct. The procedure is based on four key principles:
The inspectors produce and review mathematical documents. The
mathematics allows them to check for
complete coverage; tabular notation allows the work to proceed systematically
in small steps.
Paper
Documentation Based Software Testing
Testing is sometimes viewed as an “add on” step in software development
- something you
do to demonstrate that the product is ready for use. Test planning is often
postponed until
the development is near its end. This results in incomplete testing, ambiguous
test results,
and the release of products of doubtful quality.
After reviewing fundamental software testing issues, we describe a document-driven
testing
approach in which test plans and test result evaluation are done with the aid
of
documentation prepared throughout the design process. The policies about testing,
and
response to test results are determined in advance and high quality standards
can be
enforced on a project.
Paper
Back to Research page | Evaluation Form | Search CSIS Web Site |
|