That is a very powerful format, and both concise and clear. I like it! It has implicit traceability (the business value) too.

“As a {type of user}, I want {capability} so that {business value}.

As a >, I want > so that >.

The last part, the business value that the capability is providing, answers the “why” question in our requirements documentation. Combine that with the “who” and the “what” in the first half of the sentence, and you get a very powerful requirement format that imparts all of the necessary information to business users and the development staff alike.

Using your bad credit example, we would re-write that requirement something like this:

“As a retailer, I want to prevent the order from completing if the user is not on the ‘bad credit risk’ list so that we can increase bottom line profits by reducing write offs.”

We’ve been able to share requirements amongs many different stakeholders using this format without needing any extra translation steps.

Let me rephrase the premise, so that this particular thread doesn’t become a debate about “what is a requirement.”

First, this is not a product management project, it is a software deployment project – put on a business analyst hat for a moment…

This is the definition of more detailed elements of a migration project from a legacy system to a new system. We have already identified the goals / requirements (such as “User must place order in under five minutes.” We are now dealing with the next level of detail (e.g. defining what is required – from a business perspective – to place an order). Here are some examples that might explain better.

Given a business process of “user can place an order”, we are defining the following level of detail:

1. User will be able to identify the product to be ordered.
2. User will be able to identify the desired delivery date.
3. System will prevent the order if the user is not on the ‘bad credit risk’ list
4. System will confirm that the product can be shipped by the desired delivery date

The point is that in the documentation of this level of detail, which does have to happen at some point in the software development / deployment process, it is important to document the “why” of the particular pieces of information.

Picking one example – we choose to prevent the order for ‘bad credit risk’ users, because the business believes that this strategy will increase bottom line profits by reducing ‘bad credit’ write-offs.

Scott

Requirements are the why in a sense, as they do nothing more than restate the problem to solve in verifiable terms. If the reviewers were having so much trouble understanding the “why”, it’s mostly likely because the specifications were so far removed from the problems that they weren’t requirements.

Problem: It takes the average user more than five minutes to place an order.
Requirement: It shall take no more than five minutes for the average user to place an order.

Sure, it’s helpful to explain that users are frustrated by the amount of time it takes, and that this frustration leads to negative word of mouth, which leads to lower sales, which leads to lower revenue. But I think most reviewers are going to be able to grasp the importance of the requirement without such explanation in this case, because the requirement itself essentially “explains” the problem.