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.

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.

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.

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?

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.

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!