Building Requirements Quality through Coverage and Testability

[article]
Summary:

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.

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
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. 

Pages

About the author

Mario  Moreira's picture Mario Moreira

<strong>Mario Moreira</strong> is a Columnist for the CM Journal, a writer for the Agile Journal, an Author, an Agile and CM expert for CA, and has worked in the CM field since 1986 and in the Agile field since 1998. He has experience with numerous CM technologies and processes and has implemented CM on over 150 applications/products, which include establishing global SCM infrastructures. He is a certified ScrumMaster in the Agile arena having implemented Scrum and XP practices. He holds an MA in Mass Communication with an emphasis on communication technologies. Mario also brings years of Project Management, Software Quality Assurance, Requirement Management, facilitation, and team building skills and experience. Mario is the author of a new book entitled “<strong><a href="http://www.amazon.com/dp/0470746637?tag=cmf06-20&amp;camp=213761&amp;cre... Configuration Management for Agile Teams</a></strong>” (via Wiley Publishing). It provides an Agile Primer and a CM Primer, and how to adapt CM practices for Agile Teams. Mario is also the author of the CM book entitled, “<strong><a href="http://www.amazon.com/Software-Configuration-Management-Implementation-R... Configuration Management Implementation Roadmap.</a></strong>” It includes step-by-step guidance for implementing SCM at the organization, application, and project level with numerous examples. Also consider visiting Mario’s blog on CM for Agile and Agile adoption at <a href="http://cmforagile.blogspot.com/">http://cmforagile.blogspot.com/</a>.
&nbsp;

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!