The output of the system design phase, like the output of other phases in the development process, should be verified before proceeding with the activities of the next phase. Unless the design is specified in a formal executable language, the design cannot be executed for verification. Other means for verification have to be used. The most common approach for verification is design reviews or inspections.
We’ll be covering the following topics in this tutorial:
Design Reviews
The purpose of design reviews is to ensure that the design satisfies the requirement and is of “good quality”. If errors are made during the design process, they will ultimately reflect themselves in the code and the final system.
The system design review process is similar to the other reviews. In system design review a group of people get together to discuss the design with the aim of revealing design errors or undesirable properties. The review group must include a member of both the system design team and the detailed design team, the author of the requirements document, the author responsible for maintaining the design document and an independent software quality engineer.
The review can be held in the same manner as the requirement review. The aim of meeting is to uncover design errors not to fix them; fixing is done later. The meeting ends with a list of action items, which are later acted on the design team. The number of ways in which errors can come in a design is limited only by the creativity of the designer.
A Sample checklist: The use of checklists can be extremely useful for any review. The checklist can be used by each member during private study of the design and during the review meeting. Here we list a few general items that can be used to construct a checklist for a design review.
Are all of the functional requirements taken into account?
Are there analyses to demonstrate that performance requirement can be met?
Are all assumptions explicitly stated, and are they acceptable?
Are there are any limitations or constrains on the design beyond those in the requirement?
Is external specification of each module completely specified?
Have exceptional conditions been handled?
Are all the data formats consistent with the requirement?
Are the operator and user interfaces properly addressed?
Is the design modular, and does it conform to local standard?
Is the size of data structure estimated? Are provisions made to guard against overflow?
Automated Cross –checking
One of the important issues during system design verification is whether the design is internally consistent. For example, those modules used in a module that is defined in the system design must also be defined in the design. One should also check whether the interface of a module is consistent with the way in which other modules use it. These consistency issues can be checked during design review and is usually the place where they are checked if no automated help is available.
However, if the design is expressed in a language like PDL the design can be “complied” to check for consistency.
Dinesh Thakur holds an B.C.A, MCDBA, MCSD certifications. Dinesh authors the hugely popular