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]
Related posts:
{ 28 comments… read them below or add one }
Good questions. I see “develop” more as a part of “analysis”. Adriana Beal, a columnist over at Bridging the Gap, has offered “discover” as a more powerful word to cover “gather” or “elicit”. I do think we’ve gotten a bit caught up in the words, but using passive words to capture active business analysis activities is part of what it takes to help other professionals understand what it takes to be a business analyst (or be a project manager who is also a business analyst). We see a lot of assumptions that doing requirements-related work is just about collecting information from the stakeholders and pulling it together in a usable form. In reality, there is a lot of active work that happens. The elicitation plan and execution of it, as you mention, as well as the analysis or “development” of requirements, to ensure they are unambiguous and complete.
You can see Adriana’s post here: http://www.bridging-the-gap.com/beyond-gathering-eliciting-and-trawling-for-requirements/
Best,
Laura
Laura,
One of the places to anchor this processes is during the project chartering activities.
Capabilities are the starting point – “what capabilities are needed to fulfill the mission or business case?”
http://www.slideshare.net/galleman/10-tips-for-chartering-a-project-v2
Laura,
Your comments are awesome. They add other dimensions of the requirement process that we may not be able to fully develop in our blogs. Thanks for your feedback and link, I take some time to read it in the next few days.
Glen,
That is a good definition of capabilities and should be brought out in the business case development process.
Thank you also for your feedback and link.
Good questions. I see “develop” more as a part of “analysis”. Adriana Beal, a columnist over at Bridging the Gap, has offered “discover” as a more powerful word to cover “gather” or “elicit”. I do think we’ve gotten a bit caught up in the words, but using passive words to capture active business analysis activities is part of what it takes to help other professionals understand what it takes to be a business analyst (or be a project manager who is also a business analyst). We see a lot of assumptions that doing requirements-related work is just about collecting information from the stakeholders and pulling it together in a usable form. In reality, there is a lot of active work that happens. The elicitation plan and execution of it, as you mention, as well as the analysis or “development” of requirements, to ensure they are unambiguous and complete.
You can see Adriana’s post here: http://www.bridging-the-gap.com/beyond-gathering-eliciting-and-trawling-for-requirements/
Best,
Laura
Laura,
One of the places to anchor this processes is during the project chartering activities.
Capabilities are the starting point – “what capabilities are needed to fulfill the mission or business case?”
http://www.slideshare.net/galleman/10-tips-for-chartering-a-project-v2
Laura,
Your comments are awesome. They add other dimensions of the requirement process that we may not be able to fully develop in our blogs. Thanks for your feedback and link, I take some time to read it in the next few days.
Glen,
That is a good definition of capabilities and should be brought out in the business case development process.
Thank you also for your feedback and link.
Georges distinction is closed in the defense, space, and similar domains with the recognition that Systems Engineering is the second step in the project development process.
The first step is the creation of a “Capabilities Based Plan” in the form of a Concept of Operations (ConOps) (or similar document). Then the SE’s transform the ConOps into a systems description.
Some IT domains have learned how to do this, the Enterprise Content Management (ECM) world for example. AIIM provides templates for writing ConOps and converting them to System Descriptions.
Only then are the SD’s converted to requirements documents.
That’s the process I’m more familiar with too Glen.
I’ve worked in environments where the PM handles the development of requirements, where a BA is primarily responsible for that activity, and most recently a larger project environment where the Chief SE and lead SE’s drive much of the requirements development process with the customer.
In the last environment, it was a tiered requirements approach starting at level 1 (mission) requirements and cascading down to level 5 requirements, with a ConOps (or OpsCon as we called it) from level 1 – level 4.
The realms of a large aerospace project and a small office project are so different in complexity, risk, etc. that it’s difficult to reconcile common practices between the two. Ultimately though, you can usually scale up or scale down a good practice to make it work elsewhere.
In any case, it certainly was never a matter of requirements dropping on your lap or a quick and easy process to figure this stuff out.
Glen,
I am a fan of the ConOps processes and want to see more projects use this in the early phases of the project. It would provide a more detail structure of the solution. Would you agree?
Georges distinction is closed in the defense, space, and similar domains with the recognition that Systems Engineering is the second step in the project development process.
The first step is the creation of a “Capabilities Based Plan” in the form of a Concept of Operations (ConOps) (or similar document). Then the SE’s transform the ConOps into a systems description.
Some IT domains have learned how to do this, the Enterprise Content Management (ECM) world for example. AIIM provides templates for writing ConOps and converting them to System Descriptions.
Only then are the SD’s converted to requirements documents.
That’s the process I’m more familiar with too Glen.
I’ve worked in environments where the PM handles the development of requirements, where a BA is primarily responsible for that activity, and most recently a larger project environment where the Chief SE and lead SE’s drive much of the requirements development process with the customer.
In the last environment, it was a tiered requirements approach starting at level 1 (mission) requirements and cascading down to level 5 requirements, with a ConOps (or OpsCon as we called it) from level 1 – level 4.
The realms of a large aerospace project and a small office project are so different in complexity, risk, etc. that it’s difficult to reconcile common practices between the two. Ultimately though, you can usually scale up or scale down a good practice to make it work elsewhere.
In any case, it certainly was never a matter of requirements dropping on your lap or a quick and easy process to figure this stuff out.
Glen,
I am a fan of the ConOps processes and want to see more projects use this in the early phases of the project. It would provide a more detail structure of the solution. Would you agree?
Thanks George, I like that you’ve called out the difference between developing requirements vs. “gathering” or “eliciting” them.
I’d like to see some thoughts on the negotiations that occur as a part of the requirements development process sometime.
Looking forward to your next post!
You are welcome Josh. Yes, negotiating requirements is an interesting process that we can discuss in a future blog.
Another pathway is ‘Product Management.’
If a BA thinks like a product manager they can better articulate what is really important.
Project managers should be encouraged to ‘enable’ the business analyst with sufficient authority to do this.
One part of this enabling is to connect the BA with the project sponsor and the person who will be the eventual custodian of the project outcomes.
Connect your BA with the decision makers who matter most. Don’t just use them as someone to manage the stakeholders.
Great point Craig, it reminds me, Laura has written before about how the role of product owner in agile has a lot of overlap with the traditional BA role.
Thanks George, I like that you’ve called out the difference between developing requirements vs. “gathering” or “eliciting” them.
I’d like to see some thoughts on the negotiations that occur as a part of the requirements development process sometime.
Looking forward to your next post!
You are welcome Josh. Yes, negotiating requirements is an interesting process that we can discuss in a future blog.
Another pathway is ‘Product Management.’
If a BA thinks like a product manager they can better articulate what is really important.
Project managers should be encouraged to ‘enable’ the business analyst with sufficient authority to do this.
One part of this enabling is to connect the BA with the project sponsor and the person who will be the eventual custodian of the project outcomes.
Connect your BA with the decision makers who matter most. Don’t just use them as someone to manage the stakeholders.
Great point Craig, it reminds me, Laura has written before about how the role of product owner in agile has a lot of overlap with the traditional BA role.
Let’s try something novel … what does the DICTIONARY say?
The main connotation for “gather” is “collect.” This would imply that requirements gathering involves going around and collecting what others tell you. It also implies that there is no real value-add to “gathering.”
“Eliciting” suggests “drawing out” or getting other people to tell you what their requirements are. So it would seem that gathering must follow eliciting or those darn requirements end up all over the floor.
The first definition for “develop” says that it means “create something new.” This would seem to allow for the possibility that the developer never talks to anyone at all, but simply creates the requirements out of his or her own mind. Not a good idea. But “develop” can also mean to refine or improve, and that would seem to be a good thing.
So it seems to me that the first step would be to elicit and gather, followed by developing and refining, and then (hopefully) documenting, distributing, and obtaining agreement.
Using standard dictionary terms might be a starting point, but not too helpful in my opinion because of the general context. Your statement about the possibility of creating requirements in a bubble is an example of that.
I think developing is inclusive of all these activities. Developing is the iterative process that includes eliciting/gathering, negotiating, refining, documenting, communicating, formal approval, etc. (Whatever you choose to call them)
I think the main point George was trying to get across is this:
Gathering and/or eliciting are necessary, but not sufficient.
I think the phrase “A business analyst does not gather or elicit requirements. They develop them.” is an edited version, and I’m the one who phrased it that way. I wonder if I accidentally put words in George’s mouth by doing that.
George, what’s your take on this? Would it be more accurate to your position if I had phrased this opening line as “A business analyst does not JUST gather or elicit requirements.”
The main point here is that requirements are solution oriented and by asking the stakeholder for requirements, we are assuming that the stakeholders know what the “real” problem and they know how to solve those problems. By eliciting information we can analyze the information to discover and develop requirements. BPM is one of the ways a BA can use the elicited information to discover the requirements.
Let’s try something novel … what does the DICTIONARY say?
The main connotation for “gather” is “collect.” This would imply that requirements gathering involves going around and collecting what others tell you. It also implies that there is no real value-add to “gathering.”
“Eliciting” suggests “drawing out” or getting other people to tell you what their requirements are. So it would seem that gathering must follow eliciting or those darn requirements end up all over the floor.
The first definition for “develop” says that it means “create something new.” This would seem to allow for the possibility that the developer never talks to anyone at all, but simply creates the requirements out of his or her own mind. Not a good idea. But “develop” can also mean to refine or improve, and that would seem to be a good thing.
So it seems to me that the first step would be to elicit and gather, followed by developing and refining, and then (hopefully) documenting, distributing, and obtaining agreement.
Using standard dictionary terms might be a starting point, but not too helpful in my opinion because of the general context. Your statement about the possibility of creating requirements in a bubble is an example of that.
I think developing is inclusive of all these activities. Developing is the iterative process that includes eliciting/gathering, negotiating, refining, documenting, communicating, formal approval, etc. (Whatever you choose to call them)
I think the main point George was trying to get across is this:
Gathering and/or eliciting are necessary, but not sufficient.
I think the phrase “A business analyst does not gather or elicit requirements. They develop them.” is an edited version, and I’m the one who phrased it that way. I wonder if I accidentally put words in George’s mouth by doing that.
George, what’s your take on this? Would it be more accurate to your position if I had phrased this opening line as “A business analyst does not JUST gather or elicit requirements.”
The main point here is that requirements are solution oriented and by asking the stakeholder for requirements, we are assuming that the stakeholders know what the “real” problem and they know how to solve those problems. By eliciting information we can analyze the information to discover and develop requirements. BPM is one of the ways a BA can use the elicited information to discover the requirements.
Semantic questions aside, I was most intrigued by your comments, George, that one should “… take the information you get from the stakeholders, analyze that information so that you can develop, analyze and write good requirements.”
I have seen great success when the gathering/eliciting/discovering process is collaborative and real-time. What happens too often is that the vendor listens to the client describe the problems they face All the while, the vendor is thinking about how they will go about solving each one, instead of making sure they understand exactly what the client needs. The vendor then goes away and creates a list of requirements that address–not the client’s problems, but the vendor’s interpretation of those problems.
By collaborating in real time to co-create a requirements document, you can reduce–sometimes dramatically–the usual cycles of communication and misunderstanding. Plus, clients love it when they see that you are not just listening to them–but that you actually understand what they are saying!
Semantic questions aside, I was most intrigued by your comments, George, that one should “… take the information you get from the stakeholders, analyze that information so that you can develop, analyze and write good requirements.”
I have seen great success when the gathering/eliciting/discovering process is collaborative and real-time. What happens too often is that the vendor listens to the client describe the problems they face All the while, the vendor is thinking about how they will go about solving each one, instead of making sure they understand exactly what the client needs. The vendor then goes away and creates a list of requirements that address–not the client’s problems, but the vendor’s interpretation of those problems.
By collaborating in real time to co-create a requirements document, you can reduce–sometimes dramatically–the usual cycles of communication and misunderstanding. Plus, clients love it when they see that you are not just listening to them–but that you actually understand what they are saying!