Requirements, design and technical specifications can be tested in their own right.
The purpose of the evaluation of a specification is threefold:
• To ensure accuracy, clarity and internal consistency (verification).
• Assess how well it reflects reality and hopes that the end user (validation).
• Make sure it's compatible with all upstream and downstream of the project.
The technical specification is an embodiment of the conditions then must flow through the later stages such as production and testing. If the requirements are not well specified then the product is not only inadequate but also be incredibly difficult to verify.
If the technical specification is out of tune with the requirements, then it is likely that the development team will be well on its way of producing the wrong product. Because these documents are often produced in parallel (i.e., the steps in the cascade overlap model) is very common that the discrepancies to creep.
Every assertion in a specification should be reviewed with a list of desirable attributes:
• Specific - is essential to eliminate uncertainty as possible, as soon as possible.
Words such as "likely," "maybe" or "may" indicate indecision by the author and therefore the ambiguity. Requirements, including these words should be deleted or rewritten to provide some kind of assurance about the desired result.
• Measurable - a requirement that use comparative words such as "better" or "faster" must specify quantitative or qualitative improvements to do with a specific value (100% faster or 20% more accurate).
• check - according to the above, a requirement should be specified with an idea of what should be evaluated. A requirement that is not verifiable is ultimately no "demonstrable" and therefore cannot be confirmed, either positively or negatively.
• Okay, if one requirement contradicts another, the contradiction must be resolved.
Often, the division of a requirement into its component parts helps to uncover the assumptions incompatible in each, which can then be clarified.
• Delete - requirements should be simple, clear and concise. Requirements consist of
Breathe long prison sentences or several clauses involving multiple possible
Results and ambiguously. Split into individual statements.
• Exclusive - Registration form must not only what will be done, but what is not explicitly made. Take unspecified leave something to the assumptions.
It is also important to differentiate the demands of design documents. Requirements should not talk about "how to" do something and design specification should not talk about "why" doing things.
0 comments:
Post a Comment