Everything I Needed To Know I Forgot in Kindergarden
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?
(Be The First to Rate This Article)
Loading ...
Add Tyner Blain to Google Toolbar
January 4th, 2006 at 1:56 am
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!
January 4th, 2006 at 1:56 am
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.
January 4th, 2006 at 1:56 am
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?
January 4th, 2006 at 1:57 am
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.
January 4th, 2006 at 1:58 am
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.
January 6th, 2006 at 12:34 pm
[...] The elmocerous [...]
January 8th, 2006 at 12:48 am
[...] Presents an “inside-out” view of the sytem. This description reflects “what it is” not “why it is” - and it is easy to lose sight of why a particular use case is important. [...]
January 14th, 2006 at 11:44 pm
[...] Interviewing. One on one conversations with stakeholders and users. A key piece of information to get is why. The most important thing to remember when interviewing is to ask open ended questions. When our interviewees tell us what they want, and how they want it (good open ended questions), make sure to capture the information of why they want it. [...]
January 15th, 2006 at 4:35 pm
[...] We previously stressed the importance of understanding why something is a requirement. Unfortunately, we can’t just ask “why why why?!” until we reach the end of the chain. This won’t be any more effective for us now than it was when we were in kindergarden. Eventually, our listeners will get frustrated, or worse, defensive. [...]
January 22nd, 2006 at 3:25 pm
[...] E1 - The wrong requirements. The first source of errors is stakeholders who don’t describe (or don’t know) what they really want. Or they don’t know why they want it. Everyone who’s gathered requirements has heard things like “Now that I see it working, I realize that what I really want is…” We’ve had the most success in minimizing this situation through rapid-development techniques (repeated iterations of deployment), development of prototypes, and interaction with stakeholders throughout the design process - helping them envision what you are creating before you create it. We won’t succeed by using the spec as a defense: “But we implemented what the spec says” - your clients should not be expected to visualize what a software solution would look like just by reading a spec - that’s your job. [...]
January 30th, 2006 at 11:20 am
[...] This is an ideation task. A product manager must apply high level design skills when writing the specification. Haven’t we said repeatedly that requirements should not describe the implementation or design? Yes. Previously, we talked about the importance of asking why, this is the same issue, approached in the other direction - starting with the why and asking how. [...]
February 11th, 2006 at 1:42 pm
[...] There is an ideation step, where we perform an analysis - as engineers, we would call this a root cause analysis, where we identify why the customers make software decisions based on support-call length, why the call lengths are long, etc. After we identify the root causes, we determine which ones are properly addressed with software, versus process, project, expectation setting or any other solution. [...]