Best methods for checking and measuring quality of product requirements

By Mahesh Kumar (mkumar@edu.hse.ru)

Numerous product requirements are loaded up with seriously composed prerequisites which cause numerous issues while fostering the product, for instance, Requirement 9 states definitively something contrary to prerequisite 21; which would it be advisable for you to accept? requirement 24 is excessively ambiguous to the point that you don't know what it implies. You just had a drawn-out conversation with two different designers about requirement 30 since each of you three idea it implied something other than what's expected. This load of issues may come when you have terrible requirement composed and we know the nature of any item relies upon the nature of the unrefined substances took care of into it, helpless requirement can't prompt great development. In this essay, I will give you the best methods for checking and measuring the quality of product requirements in Two ways,

1. Methods Of Quality Requirement Statements.

2. Methods Of Quality Requirements Specifications.

In this section, I will give you the knowledge of six different characteristics that every requirement statement should consist and also conventional examination of the SRS by project partners who address alternate points of view is one way of deciding if every requirement has these ideal characteristics. Another amazing quality strategy is to compose test cases against the requirements before you cut a solitary line of code. Experiments solidify your vision of the item's conduct as indicated in the requirements and can uncover fluffiness, oversights, and ambiguities.

Correct. Every requirement should precisely portray the usefulness to be conveyed. The reference for rightness is the wellspring of the requirement, such as, a genuine client or a more elevated level framework requirement detail. A software requirement that contentions with a relating system requirement aren't right (obviously, the system specification could itself be wrong).

Just client agents can decide the rightness of client requirements, which is the reason it is fundamental to incorporate them, or their nearby substitutes, in examinations of the requirements. Requirements reviews that don't include clients can prompt designers saying, “That doesn't bode well. This is presumably what they implied.” This is otherwise called “speculating.”

Feasible. It should be feasible to carry out every requirement inside the known capacities and constraints of the system and its current circumstance. To keep away from infeasible requirements, have a developer work with the requirements investigators or marketing personnel all through the elicitation cycle. This designer can give a rude awakening on what should and can't be possible in fact, and what should be possible just at the unnecessary expense or with different tradeoffs.

Necessary. Each requirement should document something the customers really need or something that is required for conformance to an external requirement, an external interface, or a standard. Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements. Trace each requirement back to its origins, such as a use case, system requirement, regulation, or some other voice-of-the-customer input. If you cannot identify the origin, perhaps the requirement is an example of “gold plating” and is not really necessary.

Prioritized. Assign an implementation priority to each requirement, feature, or use case to indicate how essential it is to include it in a particular product release. Customers or their surrogates have the lion’s share of the responsibility for establishing priorities. If all the requirements are regarded as equally important, the project manager is less able to react to new requirements added during development, budget cuts, schedule overruns, or the departure of a team member. Priority is a function of the value provided to the customer, the relative cost of implementation, and the relative technical risk associated with implementation.

I use three levels of priority. High priority means the requirement must be incorporated in the next product release. Medium priority means the requirement is necessary but it can be deferred to a later release if necessary. Low priority means it would be nice to have, but we realize it might have to be dropped if we have insufficient time or resources.

Unambiguous. The reader of a requirement statement should be able to draw only one interpretation of it. Also, multiple readers of a requirement should arrive at the same interpretation. Natural language is highly prone to ambiguity. Avoid subjective words like user-friendly, easy, simple, rapid, efficient, several, state-of-the-art, improved, maximize, and minimize. Words that are clear to the SRS author may not be clear to readers. Write each requirement in succinct, simple, straightforward language of the user domain, not in the computerese. Effective ways to reveal ambiguity include formal inspections of the requirements specifications, writing test cases from requirements, and creating user scenarios that illustrate the expected behavior of a specific portion of the product.

Verifiable. See whether you can devise tests or use other verification approaches, such as inspection or demonstration, to determine whether each requirement is properly implemented in the product. If a requirement is not verifiable, determining whether it was correctly implemented is a matter of opinion. Requirements that are not consistent, feasible, or unambiguous also are not verifiable. Any requirement that says the product shall “support” something is not verifiable.

A complete SRS is more than a long list of functional requirements. It also includes external interface descriptions and nonfunctional requirements such as quality attributes and performance expectations. Look for the following characteristics of a high quality SRS.

Complete. No requirements or necessary information should be missing. Completeness is also a desired characteristic of an individual requirement. It is hard to spot missing requirements because they aren’t there. Organize the requirements hierarchically in the SRS to help reviewers understand the structure of the functionality described, so it will be easier for them to tell if something is missing.

If you focus on user tasks rather than on system functions during requirements elicitation, you are less likely both to overlook requirements and to include requirements that aren’t really necessary. The use case method works well for this purpose. Graphical analysis models that represent different views of the requirements can also reveal incompleteness.

If you know you are lacking certain information, use “TBD” (“to be determined”) as a standard flag to highlight these gaps. Resolve all TBDs from a given set of the requirements before you proceed with construction of that part of the product.

Consistent. Consistent requirements do not conflict with other software requirements or with higher level (system or business) requirements. Disagreements among requirements must be resolved before development can proceed. You may not know which (if any) is correct until you do some research. Be careful when modifying the requirements, as inconsistencies can slip in undetected if you review only the specific change and not any related requirements.

Modifiable. You must be able to revise the SRS when necessary and maintain a history of changes made to each requirement. This means that each requirement be uniquely labeled and expressed separately from other requirements so you can refer to it unambiguously. You can make an SRS more modifiable by organizing it so that related requirements are grouped together, and by creating a table of contents, index, and cross-reference listing.

Traceable. You should be able to link each software requirement to its source, which could be a higher-level system requirement, a use case, or a voice-of-the-customer statement. Also link each software requirement to the design elements, source code, and test cases that are constructed to implement and verify the requirement. Traceable requirements are uniquely labeled and are written in a structured, fine-grained way, as opposed to large, narrative paragraphs or bullet lists.

There is no formulaic way to write excellent requirements. It is largely a matter of experience and learning from the requirements problems you have encountered in the past. Here are a few guidelines to keep in mind as you document software requirements.

• Keep sentences and paragraphs short. Use the active voice. Use proper grammar, spelling, and punctuation. Use terms consistently and define them in a glossary or data dictionary.

• To see if a requirement statement is sufficiently well defined, read it from the developer’s perspective.

• Requirement authors often struggle to find the right level of granularity. Avoid long narrative paragraphs that contain multiple requirements.

• Watch out for multiple requirements that have been aggregated into a single statement.

Conjunctions like “and” and “or” in a requirement suggest that several requirements have been combined. Never use “and/or” in a requirement statement.

• Write requirements at a consistent level of detail throughout the document.

• Avoid stating requirements redundantly in the SRS.

If you observe these guidelines and if you review the requirements formally and informally, early and often, your requirements will provide a better foundation for product construction, system testing, and ultimate customer satisfaction.