Because requirements specification are formally in people ‘s minds, requirements validation must necessarily involve the clients and the user. Requirement reviews, in which the SRS is carefully reviewed by a group of people including representative of the clients and the users, are the most common methods of validation.
Reviews can be used throughout software development for quality assurance and data collection. Requirements review is a review by a group of people to find errors and point out other matters of concern in the requirement specification of system. The review group should include the author of requirement documents, someone who understands needs of the client, a person of the design team, and the person(s) responsible for maintaining the requirement document. It is also good practice to include some people not directly involved with product development like a software quality engineer.
One way to organize the review meeting is to have each participant go over the requirement before the meeting and the mark the items he has doubts about or he feels need further clarification. Checklists can be quite useful in identifying such items. In the meeting each participant goes through the list of potential defects he has uncovered.
As the members ask questions, the requirements analyst (who is the author of the requirement specification document) provides clarifications if there are no errors or agrees to the presence of errors. Alternatively, the meeting can start with the analyst explaining each of the requirements in the document. The participants ask questions, share doubts, or seeks clarification. Checklists are frequently used in reviews to focus the review effort and to ensure that no major source of error is overlooked by the reviewers. A good checklist will usually depend on the project.
Are all hardware resource defined?
Have the response times of functions been specified?
Have all the hardware, external software, and the data interfaces been defined?
Have all the functions required by the client been specified.
Is each requirement testable?
Is the initial state of the system defined?
Are the responses to exceptional conditions specified?
Does the requirement contain restriction that can be controlled by the designer?
Are possible future modifications specified?
Dinesh Thakur holds an B.C.A, MCDBA, MCSD certifications. Dinesh authors the hugely popular