Our Blog

where we write about the things we love




Annabelle, my youngest daughter, is going through the 'why?' stage. If you have kids I'm sure you'll know what I mean. This morning I had a typical conversation with her on the subject of eating toast.

"Sit up when you're eating," I said.


"Because if you lie down when you eat you'll choke."


"Because the food can go down the wrong tube."


"Because the tubes that are used for breathing and for swallowing are connected."


"Because that's how we are made."

When I was growing up, I think my parents would have given the 'Shut up and do as you're told!' answer much sooner than I did but I think her ability to respond to every answer with the question 'why?' would make her a good analyst.

In my blog post on requirements gathering (Everybody Lies) I wrote about how people confuse requirements and solutions. This is such a common problem and, much to my embarrassment, I managed to fall into this trap myself in a recent piece of work. If I had had Annabelle with me during the requirements gathering phase, I would not have made the mistake (actually I would probably still be running the workshops with no end in sight).

I can't remember the requirement exactly, but it was something like: "It must be possible to see the Total Including GST on the purchase invoice screen, without needing to activate the statistics screen." The criteria I had previously given for distinguishing a requirement from a solution was if you can implement it, it's a solution and not a requirement. If I had applied my own rule, I would have known that I needed to keep digging for the real requirement.

Instead, I designed and costed a solution and presented it to the project team. As we discussed my solution design it became clear that they were not too thrilled with my solution, even though I loved what I had designed and couldn't wait to get started on the programming. In our discussions, the answer to the 'why?' question turned up and here is the real requirement: "We need a simple way to trap keying errors and GST rounding differences before a purchase invoice gets posted."

We also came up with a new solution design in the meeting. When keying the purchase invoice, the user will key the Total Including GST into a field on the purchase header. When they post the invoice, the system will check this figure against the actual calculated total and, if there is a difference, it will throw an error.

I think you'll agree that this solution is really simple and quite elegant. I guess it helps when you know what problem you are really trying to solve. So as a final word of advice, which I hope I can remember to apply, use the "can I build it?" rule on your requirements and if the answer is yes, ask why the 'requirement' is needed.

Posted by: David Roys, Technical Lead | 11 February 2009

Tags: Requirements Analysis

Blog archive

Stay up to date with all insights from the Intergen blog