December 12, 2005
Everything I needed to know I forgot in kindergarden
We’ve moved to tynerblain.com/blog – this page is now here
- Comment
- Reblog
-
Subscribe
Subscribed
Already have a WordPress.com account? Log in now.
Tyner Blain 
Roger L. Cauvin said,
December 13, 2005 at 8:42 am
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
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.
tynerblain said,
December 14, 2005 at 8:00 am
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
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.
tynerblain said,
December 15, 2005 at 8:41 am
Roger, I couldn’t agree more with your statement “least stringent conditions” – we are definitely on the same page. In a previous post (https://tynerblain.wordpress.com/2005/11/25/telescopes-microscopes-and-macro-scopes-%e2%80%93-how-to-view-requirements/) 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.
Tyner Blain » Why we should invest in requirements management said,
January 4, 2006 at 2:23 am
[…] There is a lot more in the post, but the key high level “Why should we invest in managing our software projects?â€? answers are summarized from several research reports: […]