|
 |
|
Measurable and Testable Requirements 1.Introduction
Measurable and testable requirements go a long way in reducing the cost due to errors found in the requirements phase. In this article, we look at how to make requirements measurable and, thus, testable 2 Measurable and Testable Requirements Measurable and testable requirements go a long way in reducing the cost due to errors found in the requirements phase. In this article, we look at how to make requirements measurable and, thus, testable A requirement is measurable if there is an unambiguous way of determining whether a given solution fits that requirement. Requirements, if they are to be at all useful, must be measurable. That is, they must be given quantifiable characteristics so that testers can accurately determine whether the eventual solution satisfies a requirement, and so that the client can determine if the requirement's value is worth the cost of construction. Conversely, a test is seen to be worthwhile because it verifies one or more requirements. It has a trace back to each of those requirements, which it verifies. A crucial part of test design is the engineering of a complete set of verification traces, so that the system is known to conform to its requirements. A tool like ReMa is very helpful for constructing and checking large numbers of traces. Following sections explain some of the guidelines to make sure that the requirements are measurable and testable while eliciting the requirements.
2.1 Measurable and Testable Requirements At first glance, a requirement is just a piece of text, possibly with a 'shall' in the middle. But this isn't enough. Requirements are shared, so each requirement must have an identifier enabling people to refer to it uniquely. Product Managers also need to know the priority and status of each item: the requirement becomes a database record, with a set of fields or slots or attributes holding different pieces of information.
2.2 Deterministic requirements The goal is to derive a set of requirements that are testable. The requirement is testable if it is written in such a way that each statement is deterministic. Deterministic means that for a given starting condition and a set of inputs, the reader can determine exactly what the expected outcomes will be. Each statement in the requirements can then be used to prove or disprove whether the behavior of the software is correct 2.2 Deterministic requirements An Ambiguity Review is a test of the requirements to ensure that they are written in a clear, concise and unambiguous manner. The Ambiguity Review occurs prior to the review of requirements for content by the domain experts. The intent of the Ambiguity Review is to provide the domain experts with a better quality set of requirements to work from, so they can better identify missing requirements, and improve the content, completeness and accuracy of all requirements. The Ambiguity Review can be based on a checklist of common problems people have in writing requirements like dangling else, built-in assumptions, implicit cases etc. A requirements management tool, such as ReMa can facilitate the review process very well. It can increase the review efficiency because of the improved logistics in making the requirement available to the reviewers and the increased visibility of the comments from the various reviewers without the need to manually merge and redistribute them. They are entered into the database with the requirement itself.
2.4 Requirements creep A requirements management tool, such as ReMa can facilitate the review process very well. It can increase the review efficiency because of the improved logistics in making the requirement available to the reviewers and the increased visibility of the comments from the various reviewers without the need to manually merge and redistribute them. They are entered into the database with the requirement itself. To prevent failure, even during requirements creep, it is vital to ensure that the new requirements are measurable and that the requirements process includes a measuring and testing activity to which all requirements are subject, without exception. Having a strong change control process supplemented by an automated tool like ReMa can control the problems of requirements creep and make sure that the requirements are measurable and testable. In a change control process an approving "authority" is identified to approve all the new requirements based on a standard checklist. Whenever there is a new requirement or requirement change, a change request is generated which is approved by the approving "author"ity before acceptance. An automated tool can assist by making the change request and its approval status visible to the whole team. The history of each requirement along with the date of change, "author", comments etc. is entered in to the database. A standard checklist of the approving "authority" can check whether the new requirement or requirement change is viable and relevant. 2.4.1 Relevant Requirements Relevant requirements are those that can be shown to be part of the context. To test whether the requirement fits with the context, examine the flows of data to and from the system on the context diagram. 1. Do any of these flows carry the data needed for this requirement? 2.Do any of the flows bring data into the system to be stored for this requirement? 3.Do any of the flows carry data from the system that is a result of this requirement? 4.If none of the boundary data flows contribute to, or are a result of, the requirement, then either the requirement is irrelevant or the context is incomplete. 2.4.2 Viable Requirements Viable requirements are those that the organization is capable of both building and operating once they are built. For a requirement to be viable, answer to the following questions should be in affirmative. 1. Does the organization have the technological skills necessary to build the requirement? 2 Does the organization have the money and the time needed to build this requirement? 3. Is this acceptable to all stakeholders? 4. If we build this requirement, will everybody use it? 3.Software requirements metrics As the requirements become more and more measurable, the metrics generated from these requirements become more and more reliable. Software requirements metrics are leading indicators of project scope, growth, stability, and progress. Software requirements metrics characterize the problem that a project is addressing, as opposed to metrics such as LOC that characterize the solution. Software requirements metrics are also available very early in a project and can form the basis for early analyses and predictions of project plans, alternatives, risks, and results. Following are the examples of metrics, which can be collected in requirements phase whose collection will be easier with an automated requirements management tool. 1. Function Points - To predict size or cost and to assess project productivity 2. Number of requirements errors found - To assess quality 3. Change request frequency - To assess stability of requirements 4.References http://www.atlsysguild.com/index.html http://www.stsc.hill.af.mil/index.html http://easyweb.easynet.co.uk/~iany/index.htm
Pankaja P K
|
|
|
|
Copyright©Accord Software & Systems Pvt Ltd
|
A
stitch in time saves nine says a proverb. It explains a lot
about the cost of fixing the bugs in software development. The
cost of fixing an error is lowest in the first phase of software
development i.e., requirements. This is because there are very
few deliverables at the beginning of a project to correct if an
error is found. As the project moves into subsequent phases of
software development, the cost of fixing an error rises
dramatically since there are more deliverables affected by the
correction of each error. Of the bugs rooted in requirements,
many are due to poorly written, ambiguous, unclear, and
incorrect requirements.
