Requirements Quality Criteria with Examples (Part 1)

COMPLETENESS (or “completeness”).
Each requirement must contain all the information necessary to understand it, leaving no gaps or omissions. This criterion applies to both business and technical requirements.

Example 1: “The user can download data in PDF, CSV, etc.” It is unclear what other formats are supported besides those listed. What is meant by “etc.”?
Full requirement: “The user can download data in PDF, CSV and JSON formats.”

Example 2: “The app must work on all popular mobile platforms.” It is unclear which platforms are considered “popular.”
Full requirement: “The application must be supported on Android platforms version 10.0 and above, iOS version 13.0 and above.”

Example 3: “The system must process requests with high performance.” It is not specified what exactly is meant by “high performance” (what metrics are important).
Full requirement: “The system must process up to 1000 requests per second with a latency of no more than 200 milliseconds.”

CONSISTENCY (or “coherence”).
Requirements should not contradict each other. Detecting inconsistencies can be extremely difficult if requirements for the same product functionality are located in different places.

Example 1:
– “The user should be automatically logged out after 15 minutes of inactivity.”
– “The user must remain logged in until he/she has finished editing the document.”
The first requirement implies automatic exit after a time has elapsed, while the other does not allow exit while working on a document.
Non-conflicting requirements: “The user should be logged out after 15 minutes of inactivity, except while actively editing a document.”

Example 2:
– “The report must be generated and sent to the user instantly.”
– “Report generation may take up to 30 minutes depending on the volume of data.”
The first requirement promises instant processing, while the second indicates a significant delay, creating uncertainty in expectations.
Non-conflicting requirements: “The report should be generated instantly for small data volumes and sent within 30 minutes for large volumes.”

CORRECTNESS
Correctness is understood as an exact match to user and business needs. This means that the requirements must fully satisfy the needs of stakeholders who will use these requirements to achieve specific goals.

Example 1: “The user should be able to set up two-factor authentication for increased security”
This is a requirement for the user, not for the program. We make a product and can dictate its requirements, but we cannot control the state of its users.
Correct requirement: “The app must support two-factor authentication and provide the user with the option to enable this feature in the security settings.”

Example 2: “After the file download is complete, the user should see a pagination with a message stating that the download was successful.”
Pagination refers to the division of content into pages, which makes no sense in the context of file download completion. Instead, it should indicate that the user should see a message that the download was successful.
Correct requirement: “Once the file has finished downloading, the user should see a notification that the download was successful.”

UNAMBIGUITY (or “unambiguity”)
The Russian language, like any other, can contain ambiguities, which usually manifest themselves in two forms: when one requirement can be interpreted in different ways, and when different people understand the same requirement in their own way. Requirements testing helps to identify such problems, although it is impossible to completely eliminate ambiguity. It is important that requirements are formulated unambiguously, without jargon, abbreviations, and unclear phrases, so that different interpretations do not arise.

Example 1: “The order can be cancelled by the moderator and the site administrator.”
Several interpretations of this requirement are correct. A programmer may decide that a decision by BOTH a moderator AND a site administrator is needed to cancel an order, while a tester may decide that a decision by only a moderator OR only an administrator is enough to cancel an order.
A clear requirement: “The order can be cancelled by the moderator and the site administrator. One of these employees is enough to perform the operation.”

Example 2: “The service must be integrated with the insurance company.”
What does SC mean? Cryptography System? Communication Server? Quality System? Consulting Service? What if a company has all of these services?
A clear requirement: “The service must be integrated with the Control System (CS), which provides access control differentiation.

FEASIBILITY (or “feasibility”).
Feasibility of requirements in a project is determined by their ability to be implemented given technical, budgetary, and time constraints. Incremental development and prototypes can be used to assess feasibility. If a requirement cannot be implemented, it is important to consider its impact on the project and make decisions about its exclusion.

Example 1: “The application must recognize and execute the users' mental commands.”
At the current level of technology, there are no reliable and accessible methods for reading and interpreting users' thoughts. Implementing such functionality requires technologies that are still at the stage of scientific research and are not available for mass use.

Example 2: “The application should recognize emotions from the text and automatically select the color background of the message that matches the user's mood”
Developing such a feature would require significant time and resources, as it would require machine learning on a large amount of data and subsequent lengthy testing. In addition, most users would likely find the feature redundant and unnecessary.

VERIFICABILITY (or “testability”).
Testability of requirements means their ability to be verified through objective test cases that clearly demonstrate the correctness of the implementation. Incomplete, inconsistent, or ambiguous requirements are not testable.

Example 1: “Some products are automatically discounted by 15%.”
It is unclear which products exactly qualify as “some”, meaning we cannot verify whether this requirement has been met.
The requirement being tested is: “Products from the 'Electronics' category are automatically given a 15% discount.”

Example 2: “The 10% Premium Member discount applies where available to Premium Member orders.”
It is unclear what “if possible” means and how to check whether this possibility has occurred or not.
The requirement being tested is: “The 10% Premium Member discount is automatically applied to all Premium Member orders.”

PRIORITIZATION (or “orderliness”).
Requirements should be prioritized by importance, stability, and urgency. Importance determines how much the project's success depends on the requirement's fulfillment; stability indicates how unlikely it is that the requirement will change; and urgency affects how the team allocates its efforts over time. Incorrectly prioritized tasks can result in inefficient resource allocation, unnecessary work, and missed deadlines.

Example 1:
“1. The user should be able to switch between light and dark interface themes.
2. The payment system must be integrated with the new partner. The partner's API may change as it is developed.
3. The user must be able to view information about their orders”

The order of importance and urgency is broken, since the latter requirement is much more useful for the user than having a light and dark theme. The order of stability is broken, since integration with a system whose API may change creates a high degree of uncertainty and the risk of unreliable operation of the function, which may require significant improvements and testing. The implementation of this requirement can be postponed until the release of a stable version of the API by the partner.

The remaining 5 criteria will be discussed in the second part of the article.