As we look to deploy or improve a requirements practice, the output should lead to a set of complete and quality requirements. A way to get there is to ensure that requirements have been captured in all pertinent categories and are testable. Often times, requirements focus on user needs and limited functional areas. But what may be overlooked are lesser requirements categories (e.g., security, usability, etc). It is therefore essential to capture requirements that ensure coverage in the requirements space.
Once requirements cover all pertinent areas, it is critical to ensure that the requirements are testable. Testability implies that the requirements are understood enough that a test case can be established and then run to prove that a requirement has or has not been met. Having a requirement written at this level ensures that developers can build something that aligns with the requirement, reducing the gap of what the requirement specifies versus what gets built.
With this in mind, this article provides a straight forward approach to requirements coverage and testability. More advanced techniques and practices exist in this area. The important thing to consider is what level of practice your organization is ready to address. Once a solid step has been made, then advancements should be considered.
Requirements Coverage is an approach to capturing requirements in all pertinent requirements categories. This ensures a set of robust requirements that are encompassing for the project. Assuming a project will test the requirements, this also helps ensure that during the testing phase, a range of testing occurs for the project that alleviates concerns around insufficient testing in key areas.
The question becomes, "How does a person approach establishing requirements coverage?" Key contributors to defining this include analysts and testers. A sequence of activities would include:
Identify core Requirements Categories
The first activity is to identify the common requirements categories. This, unfortunately, is not as easy as it sounds. The reason is that there is no conclusive set of requirements categories. Terminology varies among organization and what requirements categories are needed also ranges. Searches on the internet reveal that there are various ways to articulate requirements categories. Some examples include:
- In "Isn't Someone Coding Yet (WISCY)? Avoiding Ineffective Requirements" by Charlene Gross (SEI), she lists the traditional requirements
categories of: business, user, functional, non-functional. In non-functional requirements categories, she lists numerous sub-categories including government regulations, platform, legacy interfaces, usability, performance, scalability, security, flexibility, and portability.
- On the Ludwig Consulting site, Ludwig lists some requirements categories to include: Functional, Operational, Development process/Project, Performance, and Contract. In Performance, he lists numerous sub-categories as efficiency, expandability, flexibility, integrity, interoperability, maintainability, portability, usability, reliability, throughput, response times, capacity, availability, and growth.
- In the article, "ABCs of Requirements Engineering", by Mario Moreira on CM Crossroads, he writes, "some examples of the category of requirements are user requirements, system requirements, performance requirements, and security requirements.