I’ve read a lot of requirements over the years. I mean, a lot. As a developer, it’s amazing how many requirements are missing substance and are either extremely vague such as “Customers should be able to place orders” or have nothing to do with the actual request such as “Orders need to reach the processing department because the sky is blue.”
Sound business requirements should have three important key elements.
- Who – Usually, this is an individual or a group of individuals such as a supervisor or customers.
- What – This tends to be a task, object, or small feature that the individual will receive or interact with. It’s also easy to split this into two areas: the frequency and the object.
- Qualifier – The testable result of satisfying the requirement.
As an example, look at the following:
“As a customer, I must receive an email confirmation after submitting a new order.”
Let’s evaluate this requirement:
- As a customer – the “Who”
- I must receive an email confirmation – the “What”
- after submitting a new order – the “Qualifier”
The “Who” is quite explanatory. The “What” can be broken into two. “I must” lends to the frequency of the object. This implies that 100% of the time, a task must occur. That task, or object, is to “receive an email confirmation.” The testable result is “after submitting a new order.”
Now, you may be thinking to yourself that this isn’t specific enough, hence the parenthesis for user stories. User stories are a way to identify a desired outcome without specifics. Later on, you may ask the question to a business analyst or business unit about the contents of the “what.” Some organizations may require that the specifics be separate requirements. However, they can be as simple as tasks under a user story.
There are several books that provide many more details than I. Most of these are available on Amazon at http://jasong.us/1qI17k0.
If you want to view or submit comments you must accept the cookie consent.