David Parnas Lecture Series


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 Back to Research page Please fill out our evaluation form Evaluation Form Search the CSIS Web Site Search CSIS Web Site
Selectable Site Contents


Last updated : 6 March 2003
e-mail : CSISwebeditor@ul.ie