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.