“Why?” The question is our inspiration and our muse. “Why?” is the justification for our requirements. The key to identifying “What?” and “When?”, which lead to “How?” and “How Much?” But there is another use for “Why?” – communication of intent (with stakeholders and implementers). Requirements documents are artifacts, but they are also dynamic documents. By documenting “Why?” a requirement is a requirement, we make it easier for future readers to understand.
Meeting Debriefing
I was observing a meeting earlier this week where a member of my team was reviewing a “finalized” requirements document. The requirements in that document were gathered previously, and validated for both correctness and completeness. This review, another step in the elicitation process, involved stakeholders who were not involved in previous sessions. The meeting was not an efficient one.
Inefficiency
Over the course of two hours, the team reviewed and discussed no more than ten requirements. The project is a migration project from a legacy system to a new solution. There are minimal process changes in this phase of the project (and therefore the review is looking minimally at process re-engineering).
The following are some of the questions asked by participants in the review:
- What is the difference between those two [variations of] start dates?
- Why do we need that information in the system?
- Why can’t we simplify X to Y?
The answers to these questions (each was asked multiple times about most of the requirements that were reviewed) generally involved relatively detailed explanations, hypothetical examples, and occasional diagramming of business object relationships to effectively communicate why the existing requirements had been written, and why they had been written in the way they had been written.
Perception
At the end of the meeting, one of the project sponsors expressed concern that a “final review” meeting was so ad-hoc and disorganized. Our sponsor now has a fear that requirements are being missed, or documented incorrectly.
Anecdotally, there were no significant changes to those requirements as of the end of the meeting. Why did we have to spend 20 man-hours to make no perceptable changes?
Because we didn’t document the answers to these questions the first time!
Document Creation
The creation of, and initial validation of the requirements document involved interviews, contextual inquiries, and side-by-side comparisons and gap-analysis with existing process documentation. The resulting requirements were documented.
All of the questions that were raised in this meeting had been raised in previous sessions. None of the answers had been included in the documentation. And the overall project is large enough, and complex enough that people inconsistently remembered or completely forgot the justifications for the requirements.
Documenting Why
Including the justifications, scenarios or examples, snippets of business object models, and other supporting information would have prevented much of the debate. If we had included the underlying “Why” data that drove the “What” data (the requirements) in our documentation, we would have avoided rehashing these same issues.
It isn’t enough to ask why during elicitation – we have to document the justifications along with the requirements.
I agree that providing context and justifications in requirements documents is a good practice. However, the experience you describe makes me think there was a much more serious problem.
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.
Hey Roger, thanks for commenting and reading – as always!
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:
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
At our company, we’ve tried using a very condensed requirement format as described by Mike Cohn in “Agile Planning and Estimating”.
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.
Oops, server couldn’t handle my brackets. Here’s that story format again:
“As a {type of user}, I want {capability} so that {business value}.
Patrick, thanks for reading and commenting!
That is a very powerful format, and both concise and clear. I like it! It has implicit traceability (the business value) too.