George Bridges, PMP
Development of Requirements
Business analysts don’t gather requirements. They create them.
Actually, gathering requirements from stakeholders is a subtle problem that most people who manage the requirements process face.
Gathering requirements is a problem
Gathering requirements can lead to the assumption that you already know the solution. We can determine the “real problem(s)” by gathering information.
Once we have identified the problem(s), then we can move on to the phase of creating requirements that will solve the current problem. A Business Analyst, or someone acting in this capacity, should collect information from stakeholders. This person should collect the information necessary to develop the requirements.
You will need an elicitation strategy to guide you through the requirements development process. Take the information from stakeholders and analyze it to help you develop, analyze, and write great requirements.
If you are looking for a framework to work with, I recommend the Business Analysis Body of Knowledge(BABOK) published by the International Institute for Business Analyst (IIBA). (www.theiiba.org ….. I will be writing more about this topic in my next blog.
[Editor’s loud mouth]
What do you think George’s distinction between gathering and eliciting information is? Is this just semantics or is it a case of language influencing practice? George’s approach is great because it makes it clear that project managers and business analysts must understand that you cannot just ask the customer for their requirements. (Well, you can….)? George points out that there is a process of refining, and then developing, these statements and documentation until they truly reflect the purpose of the project.
[/Editor’s loud voice]