Why?
My 30-month old neighbor knows the most important question she could ever ask – “Why?†We all knew that question at that age. She knows how to use it, and so did we. “Why are you wearing sunglasses?†“Why is the sun out?†“Why does the earth spin around the sun?â€
Why do we stop asking why? When we’re grown-ups, and toddlers ask “why?†for the hundred-thousandth time, why do we say “because I said so?†I’m not on a crusade to enlighten the toddlers of the world (ok, maybe on our street, but that’s not the point of this article).
Stop to think about the best people you work with – developers, project managers, CIOs, you’ll find a common pattern – they ask “why?†all the time. Somehow, they never stopped asking “why?â€. Why?
“WHY?†is the central theme, the underlying cause, and the most important element to developing a successful product. And it plays an important role in documenting requirements. Without knowing why a product is valuable or why people will use it, or why it needs to be done in 3 months instead of 6, you aren’t likely to make the right decisions about what to include, when to include it, or how to market it.
A reader and made a comment about a previous post about requirements testability – he proposed that by rewriting the requirement, we may lose sight of the real requirement. This is really a risk that we lose the underlying “why?†of the requirement. There are ways to prevent this – keeping requirements synchronized with a product roadmap, repeatedly articulating the strategy, and just keeping your eye on the ball.
Another approach, the one we use, is to structure requirements in the context of goals. We document the goals for a product, we identify the use cases that are required to achieve the goals, and we document the functional requirements required to enable the use cases. Maintaining linkage, or tracability, between the requirements and the goals that they ultimately support is the key to not losing sight of the real requirements.
Asking “why?†can also help in requirement elicitation. “Why do we need 99.99% uptime instead of 99.9%?†“Why is it a requirement that the system work without an internet connection?†“Why is it important to the user to be able to save their work in progress?â€
Why will we wait until a later post to talk about elicitation?
Roger L. Cauvin said,
December 13, 2005 at 8:42 am · Edit
http://cauvin.blogspot.com/2005/08/when-to-stop-asking-why.html
Great minds think alike, Scott!
Anthony C. said,
December 13, 2005 at 11:31 pm · Edit
Hey Roger, great post! There is a concept called “rationale†in software engineering which is basically the reason for the requirement. A rationale is effectively equivalent to a goal (even if it is syntactically different).
Without a tool the traceability that you mentioned is very difficult, especially if there are a lot of requirements. In an environment where a requirements management tool is not being used, how do you do the traceability between goals and requirements?
The standard way to document a rationale is to include it under the requirement and in italics. There may end up being some repetition if a single rationale maps to multiple requirements.
Scott Sehlhorst said,
December 14, 2005 at 8:00 am · Edit
Thanks Roger and Tony!
Tony, I hadn’t heard of the technique of including the rationale in italics under each requirement that supports them. As you alluded, in complex systems (where multiple requirements support a given rationale, or where multiple rationale are supported by a given requirement), this would be very hard to manage. Rationale are more stable than requirements, but they are still a moving target – especially in Agile development.
Would it make more sense to reference the rationale from the requirement body? We reduce the risk of stale rationale hiding in the requirements, and we avoid the cost of updating the rationale for a bunch of requirements. Maybe keeping it in the body of the requirement forces us to validate that changes in rationale do/don’t affect their supporting requirements this way.
What do folks who’ve used this (embed the rationale) technique think?
Roger L. Cauvin said,
December 14, 2005 at 9:06 am · Edit
Including rationale in some format, whether it be italics or something else, does mitigate the problem in which readers of the document scratch their heads and wonder how the specification relates to their situation. You want the customer to be able to read the requirements document and connect the dots to their business (or consumer) problems.
But I think there’s some confusion here about the difference, if any, between a “rationale†and a “requirementâ€. In many cases, the requirement and the rationale are one and the same. In fact, if you find yourself tempted to append explanatory rationale to a specification, it’s worth questioning whether the specification is a requirement or a design specification.
To illustrate, here is a concrete example. In my MarketingProfs.com article on requirements (see http://www.cauvin-inc.com/articles/ProductFailure.htm), I wrote:
“Imagine that you tell the user interface designers of a software application that ‘OK’ buttons should be colored red and ‘Cancel’ buttons should be colored blue. You have an important reason for this mandate: all of your key users are used to this color scheme and may press the wrong buttons if you deviate from it. Eureka—now you’re closer to the real requirement—avoiding the data loss or waste of time that might result from a different color scheme.â€
In this example, you might categorize the OK and Cancel button specifications as requirements. The rationale for this mandate is avoiding data loss and waste of user time and effort. I don’t agree with these categorizations.
User interface design specifications are not requirements. In this example, contraints on data loss and user time and effort are not just the rationale, but the requirement. Mandates about the OK and Cancel buttons are useful solutions for the UI designer to consider, but they are not requirements.
My definition of requirement (see http://cauvin.blogspot.com/2005/06/definition-of-requirement.html) is:
“A requirement specifies the least stringent condition that must hold to solve or avoid a prospect problem (problem that a prospective customer faces).â€
In the example, mandates about the colors of UI buttons may be binary conditions, but they by no means are the least stringent ones that must hold to solve or avoid the customer’s problem.
Scott Sehlhorst said,
December 15, 2005 at 8:41 am · Edit
Roger, I couldn’t agree more with your statement “least stringent conditions†– we are definitely on the same page. In a previous post I talk about how to find that Goldilocks spec. Einsten had it right too – “as simple as possible, but not one bit simplerâ€. We’re definitely on the right track with this thread.
Your example about red/green buttons is a good “real world†example, because it can go either way, imho. It’s definitely not a requirement – I agree on that. I also completely agree with the rationale (it could also be structured as a goal) to minimize user confusion in the UI design.
Depending upon the nature of validation/signoff conversations with the stakeholders, it may be a constraint. I’ve worked with clients before who had ‘corporate policies’ to which all new software development must adhere. And I’ve seen those policies talk about the minimum number of pixels between controls, specify fonts, graphics, screen layout, etc. When those are in place, and considered to be “out of scopeâ€, they should be captured as constraints – and referenced as external documents.
I also worked with a client who was given dietific power over all things related to the project (by his boss, who signed the check), and who was a micro-manager with “very strong opinionsâ€. After beating your head against the wall of trying to remove his constraints about every nuance of the deployment, ultimately we elected to pick our battles and fight against his fiats for only the most important issues. In that case, his omnipresent opinions became constraints for our project.
Roger’s right – when you can remove “design details†from the acceptance criteria definitely do it. When you can’t, capture them as constraints.
I think we stop asking why because it is a dangerous, risky question. I posted about it on the IIBA blog. Let me know what you think.
Julian,
Welcome to Tyner Blain and thanks for sharing your article with everyone here. It emphasizes the importance of asking ‘why’ in a non-threatening manner. ‘Why’ is the concept we’re after, but managing the conversation is a key skill everyone needs to get to it.