The following is a sample chapter from Business Analysis: Best Practices for Success.  I will be posting sample chapters and excerpts from the book on a regular basis until publication.  Please send me comments, criticisms, or thoughts you have on the excerpt.  I appreciate your input.

Stop Gathering Requirements

Many of the obstacles on these lists arise from one common misconception held by most business analysts. This misconception is that users have the requirements, and the business analyst simply has to gather them. Many business analysts say that the primary activity of their job is to gather requirements. After all, that is what management tells us to do: go gather the requirements.

Let us consider the directive to gather the requirements and picture what the process might look like:The business analyst grabs a basket or some suitable container in which to place what is gathered. The BA wanders over to the business community and asks each product stakeholder for his or her requirements which he places in the basket, like apples or eggs. Of course, since it is unlikely the members of the business community will have the requirements written down, the business analyst faithfully and accurately records their list of requirements. The business analyst collects all the requirements, brings them back to his cubicle,and transcribes them as carefully as possible, recording them word for word, into the organization-prescribed template—a requirements document. The business analyst’s sole analytical effort might be to remove redundancy when two or more product stakeholders define the same requirement. Then the BA takes the requirements document back to the product stakeholders to make sure the requirements have been transcribed correctly. The stake holders may add some new requirements or change some of those they had previously given, which the BA dutifully transcribes.Finally, the BA takes the requirements document to an authority to get the document approved. Having obtained the approval, the BA turns the requirements document over to the solution team and the job is done.This scenario may describe a requirements documenter or requirements recorder but certainly not a business analyst. There are two major problems with this scenario. First of all, there is no analysis performed and analysis is what we business analysts do. Analyst is our last name. In this scenario there is no analysis. Is it any wonder I hear business analysts all over the world complaining about getting no respect from the developers and even less from the stakeholders? I think business analysts have considerably more to offer the organization than simply recording requirements. The only way you can elevate yourself from being a requirements recorder is to stop gathering requirements.

The second problem with the scenario is much more insidious. It assumes that the requirements are already there, and have already been defined by someone. If you are going to gather requirements, they must already exist. That means the users have to already have the requirements,even when they do not know they do; and our job as business analysts is to ferret them out, by coercing, extracting, or forcing the users to divulge the requirements to us. For the gathering requirements scenario to work, we have to assume that the users can completely identify their business problem and come up with the appropriate solution to that problem which they then can relay to us. And further, the users can completely and unambiguously state the requirements that implement the solution in a way that the solution team can understand.

Users Do Not Have Requirements

The job of the process worker or user is not to define requirements for us.The job of the users of a system is to sell product, book orders, enter payables vouchers, or produce the 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 task.Here are the reasons why we cannot depend on members of the business community to produce valid requirements:

• • They have tunnel vision. This is not a negative statement; when the process workers are doing their job, they should see the business, problem,and solution from the perspective of their own jobs and functions.
  • The best person for the job of explaining the issues may not be the one given the assignment to write the requirements.
  • They do not know what IT wants—they do not know what requirements are. For example, they may have no idea of what non-functional requirements are or how to express them.
  • They may not want to commit to a specific requirement or set of requirements for fear that they will be held responsible for that commitment.
  • They do not know what is available technologically.
  • They may not be able to visualize the solution because they are too close to the problem and simply cannot see it.
  • They are not aware of the overall implications of what they ask for andare likely to specify requirements that conflict.
  • When asked for their requirements, they feel obligated to specify something,whether it is pertinent, useful, required, incidental, or nongermane.
  • It comes down to this: Users and the business community do not need requirements, or even want them. They don’t even want software or systems, or computers. What they want is a solution to their problem.

 

We need the requirements so they put up with, tolerate or humor us during the requirements process so that they can get their problem solved.

Gather Information, Not Requirements

So if the users do not have requirements, what do they have? What they have is information. They provide us with information: how they do their job,what aspects of their job they want to work differently, why they perceive there is a problem, what a solution means to them, who else may be impacted by the problem or solution. They can describe the business problem,define the problem domain, identify the conditions that cause the problem,and tell us which solutions are preferable. They can relate stories, descriptions,wants, needs, gripes, facts, lies, solutions, words of wisdom, complaints,and probably a joke or two. And that is what we want: as much information as we can get. The goal of the elicitation phase of the business analyst solution cycle is to gather information, not requirements. Whoever gathers the most information, wins.It is from skillfully elicited information that we, the business analysts,derive and define the solution to the business problem and write the solution as a set of requirements which state completely and accurately what must be done to solve the problem.

There is more to this than just changing our language and using a new catch phrase. We change our expectations when we change our language.Start by assuming the process workers really do not know what they want and make it your job to help them determine the solution to their business problem.

When workers do not have requirements, then there is no single worker you have to find to give you the requirements. You can focus on information rather than individuals. When you gather information,you focus on just getting information, all the information, as much information as you can get. The information you gather may expose other problems, shed new light on the process under investigation, clarify an issue, eliminate an assumption, or establish a good or better relationship with the responder. You determine how to apply the information. You are the business analyst.And when you are defining requirements instead of gathering them, the product stakeholders cannot change the requirements. They cannot change scope. Only you, the business analyst, can change the requirements that you created. The product stakeholders can only change information. And changing information is never a problem.

It is during the analysis of the elicited information that the business analyst defines the functional requirements, the nonfunctional requirements,and the constraints. Analysis defines the problem and the problem domain.Analysis characterizes the solution and the impacts. Analysis may also uncover additional problems that the organization needs to address, thus increasing value.