I recently posted about the need for accuracy and precision in requirements. In that post, I mentioned that natural language requirements are probably the least precise format for expressing requirements. Many BA’s, myself included, write specs composed of natural language requirements and a few flow diagrams for clarification and context. So, given that natural language is not inherently precise, how do we at least make them as precise as possible?

To me, it boils down to a few main points.

  • Uniformity of requirement structure
  • Clearly defined requirement syntax and project vocabulary
  • Attention to grammar and word usage
  • Repeat, Repeat, Repeat

In this post, I’ll cover the first bullet – requirement structure, and touch on the last.

Uniformity of requirement structure

I’ve always thought it logical to apply a consistent structure to each requirement in a specification, but it was in a recent training session that I was shown a simple technique for ensuring consistency. It isn’t a major process breakthrough, or a cutting-edge meeting management technique. As I said, it is actually a very, very simple. And the simplicity is, in fact, the benefit. Here’s how my requirements will be structured:

Subject + Capability + Constraint*

There it is. That’s my formula. I’ll explain.

  • Subject: Every requirement will begin with the subject, or entity performing the action. This will typically be the user of the system or the system itself. In times past, I’d be inclined to start out with a condition, like, “If the user is logged in, the system shall….”, or, “When the order is in open status, a user shall be able to….” Always leading with the subject helps me to avoid writing in passive voice, which might be great for prose, but is less than ideal for requirements.
  • Capability: This is what the subject “shall be able” to do. There will be one and only one capability in each of my requirements.
  • Constraint: The reason for the asterisk next to “Constraint” is that not all of my requirements will necessarily include a constraint. Most probably will, though. The constraint will be a condition or that will be applied to the Capability.

So, as a sample requirement I’d write:

“A user shall be able to print his/her statement from the account summary page.”

In this case, “user” is my subject, the ability to print the statement is the capability, and the fact that it will be printed from the account summary page is the constraint.

Note that the subject, capability and constraint are also included in the requirement in that order. The reason for this is that uniformity makes the requirements easier to understand.

With “S+C+C”, I’ve found that by using the same formula for EVERY requirement (repeat, repeat, repeat), consumers of my documents became accustomed to the structure and the flow. For a system requirements spec (SRS), many of the document’s consumers are designers or developers who are versed in the language of software development. Logic expressed in software code is very uniform and consistent. Using the same structure for all requirements is – albeit only slightly – more like “speaking in their language.”

Now before I finish, I want to make it clear that there is nothing wrong or inaccurate about stating requirements that lead with a condition, or that vary from my adopted format. My point is that it’s important to pick a way that works for you and your document’s consumers and to not deviate from it. Ever.

I’ll write more on my other main points listed above in the coming days. In the meantime, I’ll be interested in hearing any other ideas you may have on what works and what doesn’t regarding requirement structure.