Software requirements best practices - Requirements shall be testable

By alvin ~ Posted Tue, 11/29/2011 - 09:13

I've written about this before over on my devdaily.com website, but one software requirement best practice is that all requirements should be testable. In fact, I suggest that whenever you write a software requirement, you should always ask yourself this simple question:

Is this requirement testable?

If you think about it, if a requirement isn't testable, how can it actually be a requirement? How can you prove later that this requirement has been met?

Vague, untestable software requirements

The easiest way to demonstrate this technique is by listing some of the vague, untestable software requirements I've seen in my career as a business analyst:

  • The system shall be fast.
  • The system shall be scalable.
  • The system shall be easy to use.

As written, all of those requirements are subjective and not testable. What these statements are missing is objective criteria that makes them testable.

Writing testable software requirements

To fix these problems, let's specify each requirement in a testable way:

  • The login screen will display in XX ms.
  • The system shall handle a simulated user load of 10,000 with all web pages responding in less than XX seconds.
  • A team of XX sample users, not involved in the design process, shall be used to test the usability of the system. Without a user manual or training, they must be able to do X, Y, and Z in less than XX minutes.

Of course you'll want to add actual numbers to each of those requirements, but I hope you can see that these software requirements are testable, where the earlier requirements were not.

Software requirements best practices - Summary

In summary, I hope you can see that this is a great question to ask:

Is this software requirement testable?

Or, to put it another way, which I prefer:

How would I test this software requirement?

In summary, I hope this "software requirement best practice" has been helpful. I'll try to share more best practices related to software requirements and the Business Analyst role as time permits.

Valley Programming is currently a one-person business, owned and operated by Alvin Alexander. If you’re interested in anything you read here, feel free to contact me at “al” at (“@”) this website name (“valleyprogramming.com”), or at the phone number shown below. I’m just getting back to business here in November, 2021, and eventually I’ll get a contact form set up here, but until then, I hope that works.