One thing a business analyst should ask about any requirement

This blog post was originally posted here on the alvinalexander.com website.

As a business analyst — or any person interested in writing software requirements and quality — there is one thing you should always ask yourself whenever you write a business requirement:

Is this software requirement testable?

I’ve seen some business analysts write some crazy things and call them requirements, but IMHO, if you can’t test it, it’s not a requirement.

(And quality software requirements helps lead to quality software applications.)

Some crazy “requirements”

I’ve seen some really crazy “software requirements” over the years, but I’ll try to keep it simple here and just share some of the slightly-crazy things I’ve seen business analysts write:

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

Right now you should read one of those requirements, and ask yourself, “Is this requirement testable?” Or, more to the point, you should put yourself on the spot and ask, “After the software is written, how am I going to test this requirement?” Again, if you can’t test it, it’s not a requirement.

Software requirements best practice: Write testable requirements

As a quick example, let’s look at the first application “requirement” above (“The system shall be fast.”) and re-write it. Let’s write some testable requirements related to “speed,” something like these:

1. Our minimum PC requirement is a 2 GHz Pentium Core Duo with 2GB RAM, running Windows XP, with XX free disk space.
2. On the minimum system, and with no other applications running:
   1. The splash screen shall display in XX ms.
   2. With nothing else running on the system, the login screen shall be displayed in XX ms.
   3. The user shall be authenticated against the XYZ user data store.
   4. The main landing page of the application shall be displayed and ready for data entry in XX seconds.

Now, compare these requirements to the “requirement” that “The system shall be fast,” and I think you’ll see what I mean: Now you have something that's well-defined and testable. Better requirements leads to better quality software.

I could continue working on the other “requirements” I showed at the beginning, but now that you see the difference, why don’t you give it a try? I think you’ll see the difference, and it will make a world of difference in the quality of your own requirements specifications.

Summary: Software requirements best practice

In the words of the old tv show “Moonlighting,” always remember and never forget (to ask yourself):

Is this software requirement testable?

And then remember this: 

If you can’t test it, it’s not a requirement.

Reporting live from Longmont, Colorado,
Alvin Alexander