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 misconceptionheld by most business analysts. This misconception is that users have therequirements, and the business analyst simply has to gather them. Manybusiness analysts say that the primary activity of their job is to gatherrequirements. After all, that is what management tells us to do: go gather therequirements.

 

Let us consider the directive to gather the requirements and picturewhat the process might look like:The business analyst grabs a basket or some suitable container inwhich to place what is gathered. The BA wanders over to the businesscommunity and asks each product stakeholder for his or herrequirements which he places in the basket, like apples or eggs. Ofcourse, since it is unlikely the members of the business communitywill have the requirements written down, the business analyst faithfullyand accurately records their list of requirements. The businessanalyst collects all the requirements, brings them back to his cubicle,and transcribes them as carefully as possible, recording themword for word, into the organization-prescribed template—arequirements document. The business analyst’s sole analytical effortmight be to remove redundancy when two or more product stakeholdersdefine the same requirement. Then the BA takes the requirementsdocument back to the product stakeholders to makesure the requirements have been transcribed correctly. The stakeholdersmay add some new requirements or change some of thosethey had previously given, which the BA dutifully transcribes.Finally, the BA takes the requirements document to an authority toget the document approved. Having obtained the approval, the BAturns the requirements document over to the solution team and thejob is done.This scenario may describe a requirements documenter or requirementsrecorder but certainly not a business analyst. There are two major problemswith this scenario. First of all, there is no analysis performed and analysis iswhat we business analysts do. Analyst is our last name. In this scenario thereis no analysis. Is it any wonder I hear business analysts all over the worldcomplaining about getting no respect from the developers and even lessfrom the stakeholders? I think business analysts have considerably more tooffer the organization than simply recording requirements. The only wayyou can elevate yourself from being a requirements recorder is to stop gatheringrequirements.

 

The second problem with the scenario is much more insidious. Itassumes that the requirements are already there, and have already been definedby someone. If you are going to gather requirements, they must alreadyexist. 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 toferret them out, by coercing, extracting, or forcing the users to divulge therequirements to us. For the gathering requirements scenario to work, wehave to assume that the users can completely identify their business problemand come up with the appropriate solution to that problem which they thencan relay to us. And further, the users can completely and unambiguouslystate the requirements that implement the solution in a way that the solutionteam 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 payablesvouchers, or produce the payroll. Even if they were assigned by theirmanager 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 businesscommunity to produce valid requirements:

* They have tunnel vision. This is not a negative statement; when the processworkers 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 onegiven the assignment to write the requirements.

* They do not know what IT wants—they do not know what requirementsare. For example, they may have no idea of what non-functionalrequirements are or how to express them.

* They may not want to commit to a specific requirement or set of requirementsfor fear that they will be held responsible for thatcommitment.

* They do not know what is available technologically.

* They may not be able to visualize the solution because they are tooclose 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 needrequirements, or even want them. They don’t even want software orsystems, or computers. What they want is a solution to their problem.

 

We need the requirements so they put up with, tolerate or humor usduring the requirements process so that they can get their problemsolved.

 

Gather Information, Not Requirements

So if the users do not have requirements, what do they have? What they haveis information. They provide us with information: how they do their job,what aspects of their job they want to work differently, why they perceivethere is a problem, what a solution means to them, who else may be impactedby 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 muchinformation as we can get. The goal of the elicitation phase of the businessanalyst solution cycle is to gather information, not requirements. Whoevergathers 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 solutionas a set of requirements which state completely and accurately whatmust be done to solve the problem.

 

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

 

When workers do not have requirements, then there is no singleworker you have to find to give you the requirements. You can focuson information rather than individuals. When you gather information,you focus on just getting information, all the information, as much informationas you can get. The information you gather may expose otherproblems, shed new light on the process under investigation, clarify anissue, eliminate an assumption, or establish a good or better relationshipwith the responder. You determine how to apply the information. Youare the business analyst.And when you are defining requirements instead of gathering them, theproduct stakeholders cannot change the requirements. They cannot changescope. Only you, the business analyst, can change the requirements that youcreated. The product stakeholders can only change information. And changinginformation is never a problem.

 

It is during the analysis of the elicited information that the business analystdefines 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 uncoveradditional problems that the organization needs to address, thus increasingvalue.

Back to Top