The common response by a business analyst when asked to describe his or her primary activity is “I gather requirements”. Management tells business analysts when assigning them the next problem to solve: “Go gather the requirements”. This is unfortunate. Let’s examine what one would do if one were truly to “gather requirements”.
As a business analyst gathering requirements, I grab a basket or some suitable container in which to place the requirements I gather (one needs a basket to put things that are gathered). I go to the business community and ask them to give us the requirements. I collect the requirements and then transcribe them as carefully as possible, recording them word for word, onto the organization-prescribed template – a Requirements Document. I then take the Requirements Document back to the stakeholders to make sure we transcribed the requirements correctly. The stakeholders may add some new requirements or change some of those they had previously given us which I dutifully transcribe into the Requirements Document. Then I take the Requirements Document to an authority that approves it. Having obtained the approval, I turn the Requirements Document over to the solution team and my job is done.
The concept of “gathering requirements” comes from a basic premise: there are requirements out there someplace that the business analyst has to find. This means that users or stakeholders have the requirements to be gathered in the first place. Do users or stakeholders really have requirements?
Users Don’t Have Requirements
That’s right, users don’t have requirements. Nor do stakeholders. Nor does anyone in the business.
The job of the user is not to create requirements for us. The job of users of a system is to sell more product, book orders, enter payables vouchers, or produce payroll. Even if they were assigned by their manager to take a few weeks off the production line and write up some requirements, they are not trained or skilled in the job of writing requirements. However, the business analyst is.
Some organizations attempt to make defining requirements the job of the business. Here are reasons why that approach won’t necessarily work:
- Users are focused on their own jobs. They see the business, problem and solution from the perspective of their part of the business process.
- The best user for the job of explaining issues may not be the one given the assignment to write requirements.
- Users don’t know what IT wants – they don’t know what requirements are. For example, they may not know what non-functional requirements are and/or how to express them.
- Users may not want to commit to a specific requirement or set of requirements for fear they will be held responsible for those requirements and may give us vague or ambiguous statements if anything at all.
- Users don’t know what is available technologically.
- Users may not be able to visualize the solution because they are too close to the problem or simply cannot see it.
- Users are not aware of the overall implications of what they ask for and are likely to specify requirements that conflict.
- When asked for their requirements, users feel obligated to specify something whether it is pertinent, useful, required, incidental or non-germane.
So where do requirements come from? They are analyzed into existence. Requirements are defined or created by the business analyst. The business analyst’s job is to define the solution to a business problem. The requirements document is the representation of the complete and accurate statement of what must be done to solve the business problem. Requirements are a business analyst’s job, not to gather, but to create.
Gather Information, Not Requirements
So if users don’t have requirements, what do they have? They have information. They provide us with relevant information: how they do their job, what they would like to work differently, what a solution may look like, why they perceive there is a problem, what a solution will mean to them, who else may be impacted by the problem or solution. They can describe the business problem, define the problem domain, identify conditions that cause the problem, and tell us which solutions are preferable.
What do we gather? Not requirements. We gather information.
It is from this skillfully elicited information that we, the business analysts, derive and define the solution to the business problem and we write this solution as a set of requirements. These requirements state completely and accurately what must be done to solve the problem. We analyze the information to deduce the solution.
The goal of the elicitation phase of the business analyst solution cycle is to gather information, not requirements. Whoever gathers the most information wins.
What’s in a Word?
There is more to this than just changing our language and using a new catch phrase. We also change our expectations by doing so. We assume users really don’t know what they want and make it our job to help them determine the solution to their business problem. As Steve McConnell says, “The most difficult part of requirements gathering is not the act of recording what users want; it is helping users figure out what they want.”
The interesting aspect of this change to our vocabulary is that we improve our ability to elicit pertinent information, information that will lead us to the solution. When we expect users to have requirements, we ask questions focused on “What do you want (or need)?”
When we assume users do not have requirements and defining requirements is our responsibility not theirs, we begin to realize that we need a bigger and better view of the problem: a domain view, one that allows us to gain business insight and knowledge of what is going on with the business process. At that point, our line of questioning changes to:
- “How do you do what you do?” How do you perform your tasks?
- “What information do you need to do your job? Where do you get it? What do you do with it?”
- “What don’t you like about the current process?”
- “How do you know…?”
- “Where does the information you use come from, and where does it go when you finish with it?”
- “What happens if we don’t solve this problem?”
We will also find that we might expand our elicitation focus away from the one Subject Matter Expert (SME) who “has the requirements” to a number of stakeholders who work in the business process so that we can confirm the information we have received and so that we can get different perspectives. We might also find we want to spend some time observing the business process to further understand what is needed and what conditions exist that are causing the problem, in other words, what must be changed to solve the problem.
And when we are not collecting requirements from stakeholders, we are forced to do the job we are being paid to do: analyze. When requirements are only the result of analysis, we are not tempted to simply copy requirements statements received from stakeholders into our requirements document. We are more likely to spend time verifying information, distilling it down to its essence, eliminating requests that do not contribute to the solution, identifying additional questions that need to be asked of stakeholders, reconciling conflicting information, and so forth.
Though we are defining requirements, the business community still has to agree to the solution. Stakeholders are going to be using the solution in their day-to-day operations long after we have gone on to solve other problems. As we are defining their solution we are going to confirm requirements with those who are affected by the changes in their processes. We inculcate a partnership with stakeholders: they provide the information; we do the analysis and produce a solution; they confirm the solution will work for them (or provide additional or revised information so we can come up with a new solution). It is an iterative process that requires the business analyst to establish a good relationship with the user community so that there is no problem when the business analyst shows up in user’s office for the seventh time, Columbo style, to ask just one more question.
Removing the Obstacles
Will changing our thinking about gathering requirements really improve our requirements process? Consider that if users don’t have requirements, they can’t change requirements. They can only change information. I don’t think anyone would have a problem with changing information.
When users don’t have requirements, then there is no single user we have to find to give us requirements. We are no longer subject to locating “the right person with the right requirements”. We can focus on information rather than individuals.
When all users have is information, then they are not giving us solutions, they are giving us information that we may or may not use to define the requirements.
“Changing customers and users” means only that the information changes not requirements (unless you choose to alter them). We do not need to have “technically sophisticated users” when users are not supplying us with requirements. We do not need users to “articulate their requirements”, just what they need to make their jobs easier or better. We do not need users to “understand the big picture”; it is our job to put together the big picture from the information users give us.
Get the facts first. You can distort them later – Mark Twain
There’s another subtle benefit when you gather information instead of requirements: increased confidence and better relationships with the business community. Users may have trouble defining requirements for you because of the criticality that such definitions have. No one has trouble describing what they do for a living. Users can identify what they like and do not like about the current process. And, as they describe the current process and what they would like to see to make it better, they will gain confidence in you because you are listening to them. You understand their situation first, then you analyze the information and come back with the solution. When you return for their confirmation, they realize that you are listening to them and are truly interested in solving their problem.
Here’s one last tip. As business analyst you are defining the solution to the problem as a set of requirements. Basically you own the requirements. That is, you are fully responsible for their accuracy and currency. It is your job to make sure you have not included your own assumptions and so forth. However, throughout the process refer to the solution as theirs. Requirements define the solution to the business’ problem. The requirements document that describes the solution belongs to the business analyst; the solution belongs to the business. When you refer to the solution as belonging to the business community, they will take possession of it and participate more fully in its development.
CHANGES IN PLATITUDES, CHANGES IN ATTITUDES
It is not only a matter of changing a word or two in our process definition: it is a matter of changing how we go about our job, too. As Dr. Stephen Covey says, “Seek first to understand, then to be understood.” Gather information and analyze that information into requirements. The more information you get, the better your analysis will be. The better your analysis, the better your solution will be. And when we change our expectations and attitude, the stakeholders change theirs as well.
It is a good feeling to end an information gathering session with a group of stakeholders and have them say to you “Good session. When will you be back with our requirements?” And even better to have them say, “When you do what you have described in these requirements, our problem will be solved. Thank you!”
Don’t forget to leave your comments below.
Powered by Facebook Comments