The Cleanroom Strategy and Functional Specifications

The cleanroom approach makes use of a specialized version of the incremental process model. A pipeline of software increments is developed by small independent software teams. As each increment is certified, it is integrated into the whole. Hence, functionality of the system grows with time.

- Increment Planning : adopts the incremental strategy.
- Requirements Gathering : defines a description of customer level requirements (for each increment).
- Box Structure Specification : describes the functional specification.
- Formal Design : specifications (called “black boxes”) are iteratively refined (with an increment) to become analogous to architectural and procedural designs (called “state boxes” and “clear boxes,” respectively).
- Correctness Verification : verification begins with the highest level box structure (specification) and moves toward design detail and code using a set of “correctness questions.” If these do not demonstrate that the specification is correct, more formal (mathematical) methods for verification are used.
- Code Generation, Inspection and Verification : the box structure specifications, represented in a specialized language, are transmitted into the appropriate programming language.
- Statistical Test Planning : a suite of test cases that exercise of “probability distribution” of usage are planned and designed.
- Statistical Usage Testing : execute a series of tests derived from a statistical sample (the probability distribution noted above) of all possible program executions by all users from a targeted population.
- Certification : once verification, inspection and usage testing have been completed (and all errors are corrected) the increment is certified as ready for integration.

Functional Specifications :
Cleanroom Software engineering compiles with the operational analysis principles by using a method called box structure specification. A "box" encapsulates the system at some level of detail. Three types of boxes are used :
- Black box : It specifies a set of transition rules that describe the behavior of system components as responses to specific stimuli, makes use of inheritance in a manner similar to classes. It also specifies system function by mapping all possible stimulus histories to all possible responses.
S*->R i.e. stimulus history->responses
- State box : It is a generalization of a state machine, encapsulates the data and operations similar to an object, the inputs (stimuli) and outputs (responses) are represented, data that must be retained between transitions is encapsulated. The state is the encapsulation of the stimulus history. State variables are invented to save any stimuli that need to retained.
S x T -> R x T i.e. stimuli X state data -> responses X state data
- Clear box : It contains the procedural design of the state box, in a manner similar to structured programming. It specifies both data flow and control flow.
S x T -> R x T i.e. stimuli X state data -> responses X state data

BOX PRINCIPLES :
- Transaction closure of stimuli and responses
* Users and uses are considered including security and error recovery.
- State migration within box hierarchy
* Downward migration of state data is possible whenever new black boxes are created inside a clear box.
* Upward migration of state date is desirable when duplicate data is updated in several places in the tree.
- Common services
* Reusable boxes from library.