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.
Hi, somehow the term “user” seems very cold. Got a term to make me feel a bit warmer as a person?
Thanks for the comment, Robyn. I think I understand the point you’re making. I guess “user” was more a generic example for demonstration of the requirement structure.
Ideally I’d want to be as specific as I can about the user role or some other meaningful descriptor of the user. For example, for a retail application we might use “cashier” or “sales representative” in place of the generic “user”. Not all of these will necessarily make you feel “warmer as a person”, but they will be more useful to the designer and tester in determining who can perform the functions described in the requirements as there is typically more than one generic user type for an application.
Is that what you were getting at?
Again, thanks again for stopping by and dropping a line.
*“A user shall be able to print his/her statement from the account summary page.”*
I feel this sentense should be broken onto two requirements:
R1. “A user shall be able to print his/her statement”
R2. “Statement should be derived from the account summary page”
But at the same time I believe the R2 is more like an item for a project dictionary, if this function exists in your system.
If above is right then the first step in your procedure is to break your biz text onto simple sentenses to fit your formula and then fine-tune them and put into sequience.