In one of our previous blogs, we discussed Total Software Quality and how quality must be engineered into the product throughout the development lifecycle and not just rely on testing. If we just test at the end, we’re missing great opportunities to improve quality and requirements engineering is one of them.

Requirements engineering and formal requirements have given way to user stories and story points in today’s agile world. But even in the world of 2-week sprints, it stands to reason that poor requirements are still one of the primary sources of defects. Not only that, we need to measure requirements because:

  1. Requirements creep needs to be controlled or we’ll be in development forever
  2. Satisfaction of requirements leads to customer satisfaction
  3. Effort and time required depends on requirements

Requirements metrics can be key indicators of software quality down the production line enabling managers to predict trouble before its too late. There are many requirements engineering metrics that are widely known, but few organizations actually use them. Why? I’d say the same reasons as always with respect to metrics:

  • Hard to define, count and calculate. With agile moving so fast, stakeholders rarely sit down and think about what metrics would be useful for their project.
  • Hard to interpret and questionable reliability. With no benchmarks or indicators of good or bad, some stakeholders begin to question what they mean and what they should do with them.
  • Hard to collect so by the time you get them all assembled, its too late.

Using metrics is not new – but sometimes it just seems too darn hard.  Let’s take a look at 3 potential metrics that overcome these difficulties and help us to monitor and improve quality early in the development lifecycle:

  • Actual versus planned requirements: At the beginning of the sprint or at the beginning of the software development cycle, the product owner and the team finalize what will be in the sprint. At the end of the sprint, you get to see what the actual number of requirements that were completed. The term requirements in this case can mean user stories, story points, etc. as long as the units are consistent.
  • Requirements change: This quantifies the type of requirements changes that are made each sprint. Types of changes can include added or increased, edited and deleted. As the project goes forward, the rate of change should decrease. In the final sprints, requirement changes can have significant negative effects on the product and its quality.
  • Requirements volatility: This quantifies the percent of requirements that change within each sprint. Since subsequent design, development and testing depend on stable requirements, if requirements are changing, then there is a lot of re-work to implement the change and it may also affect already implemented features. Volatility in the first few sprints is expected, but high volatility toward the end of the project will surely lead to a delayed release.

These are just a few of the agile software quality metrics that can be used within each sprint with respect to requirements. Typically we don’t think of using requirements engineering metrics with agile projects because agile is supposed to be light on documentation and everyone thinks of requirements documents as being those thick specifications that no one reads. However, a requirement can be a simple user story or story point, as long as units are maintained consistently. You’d be surprised if you just try one metric, how your software quality can improve solely through the increased awareness and attention to requirements.