Brainstorming can be a simultaneously fun and effective technique for identifying software features or requirements. We’ve written previously about how to facilitate a brainstorming session and how to leverage the results. Timothy Johnson shares another way to use the results effectively. His way is more fun, and maybe just as effective.
Four Assumptions of the Apocalypse
Business Analysts often start with four erroneous assumptions when eliciting requirements. 50% of errors in software projects are caused by requirements errors. These four faulty assumptions, presented by James A. Ward, can exacerbate the error-prone process of gathering requirements.
The Agile Dragon
When Alan Cooper and Kent Beck debated the benefits of eXtreme Programming versus Interaction Design, they disagreed on a lot of things. One thing they agreed on is that Agile processes are designed to minimize the impact of changing requirements. Cooper believes that it makes more sense to minimize future change by understanding the requirements better up front. Beck believes that the requirements can not be understood by the team until something is delivered. Beck’s point is that the customer doesn’t understand the requirements until he has something in his hands. We’ve shown how this is both a strength and a weakness for Agile in the real world. In The Hobbit, the dragon Smaug was missing a scale on his belly, that made him vulnerable. Agile processes have a similar weak spot.
Challenging Requirements
The hardest long term challenge in eliciting requirements is improving our ability to do it. The hardest short term challenge in gathering requirements is getting all of them. We have a lot of techniques for gathering requirements, from interviewing to brainstorming to researching. How do we know we defined all of the requirements? Everyone who manages requirements knows the value of validating requirements. But validation leaves a blind spot as it looks backwards instead of forwards. We propose to do exactly the opposite.
Dilbert gathers requirements
Another great Dilbert – http://dilbert.com/strips/comic/2006-02-26/ I won’t show the cartoon here, but here’s a quote from the first two panels: Pointy-haired boss: Why is your project four months behind? Dilbert: I still don’t have the user’s requirements because she’s a complete nut-job. […] This cartoon does point out the critical […]
The Reason Why
Seth Godin has a post titled The Reason. In each of his examples, Seth asks and answers the reason why we do things that don’t have an obvious rationale.
Requirements elicitation is about asking why. When we ask why correctly, we get great insight, which enables great requirements, which can yield great software. When we ask why incorrectly, we can get a great big mess.