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. Quality Requirement Statements. 2. 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. Each requirement must accurately describe the functionality to be delivered. The reference for correctness is the source of the requirement, such as an actual customer or a higher-level system requirements specification. A software requirement that conflicts with a corresponding system requirement is not correct (of course, the system specification could itself be incorrect).

Only user representatives can determine the correctness of user requirements, which is why it is essential to include them, or their close surrogates, in inspections of the requirements. Requirements inspections that do not involve users can lead to developers saying, “That doesn’t make sense. This is probably what they meant.” This is also known as “guessing.”

Feasible. It must be possible to implement each requirement within the known capabilities and limitations of the system and its environment. To avoid infeasible requirements, have a developer work with the requirements analysts or marketing personnel throughout the elicitation process. This developer can provide a reality check on what can and cannot be done technically, and what can be done only at excessive cost or with other 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.