I’ve been away at a “Mastering the Requirements Process” course led by Suzanne Robertson of the Atlantic Systems Guild.
I’m looking for a method/process/techniques to gather (or “trawl for” as Suzanne calls it) requirements, to integrate with my customer’s existing process. The “Volere” tools seem quite suitable, especially the techniques to define the context, goal and business events. I often see teams jump directly into defining the product, “what will the system do?”. Before thinking about what, you have to know why.
What is the context and goal of the business in your current project? Do you know? Have you asked? Is success of the project defined as how close you come to the business goal?
What could happen if you don’t have the answers to these questions?
Your product scope might become too large. Feature upon feature gets added to the product. On what basis? How can you decide if this feature should be in or out of the project? How can you prioritize requirement, unless you have some way of guessing how much they contribute to the business goal?
People might disagree about whether the project is succesful. There is a danger with saying “a good product is one that conforms to requirements.”. What kind of requirements? Product requirements? What good is a product that does everything we agreed it would do, unless the product requirements are linked to business requirements. Have you ever been in a project where the customer was dissatisfied, even though you implemented all the requirements? Maybe you misunderstood each other. Maybe you had a different definition of success.
Start asking those business questions today. That means you have to understand the lingo. At least ask “why?” a lot…
