George Bridges, PMP
Requirements Development
A business analyst does not gather or elicit requirements. They develop them.
In fact collecting requirements from stakeholders is a subtle problem for most people who are responsible for managing the requirements process.
The problem with gathering requirements
The problem with gathering requirements is that it implies that you already know the solution to the problem. By collecting information, we determine the “real” problem(s).
Once we have confirmed the problem(s), we will move into the phase of developing requirements that will solve the problem(s) for the current project. What a Business Analyst or someone acting in that capacity should do is collect information from the stakeholders. This person should elicit the “right” information that will lead to the development of the requirements.
To do this, you need to have an elicitation plan that will guide you through the process of requirements development. So take the information you get from the stakeholders, analyze that information so that you can develop, analyze and write good requirements.
If you need a framework to work from, I suggest you check out the Business Analysis Body of Knowledge (BABOK), published by the International Institute for Business Analyst(IIBA) (www.theiiba.org) ….. more on this subject in my next blog.
[Editor's loud mouth]
If you are reading this right now, what do you think of George’s distinction here between developing versus gathering or eliciting? Is it just semantics, or is this an example of language influencing practice? I like George’s approach, mostly because I want to be sure new business analysts and project managers realize that you can’t just go to the customer and ask for their requirements. (Well, you can….) There’s a process of refining and as George points out, developing, those statements and documentation until they reflect what the project will truly seek to fulfill.
[/Editor's loud mouth]
{ 28 comments }
