A New Technique for Business Analysts - Method Hä

Source - Neville Turbit, Principal, Project Perfect Pty Ltd., 2003

The Role of the BA

When a Business Analyst gathers requirements, there is a chain, or sequence of events that usually happen.

· The BA gets a general understanding of the area to be specified

· The BA asks Users questions to deepen that understanding

· The User answers those questions

· The User raises topics that are peripheral to the specific question

· The BA follows those threads

· The BA takes all the information away and tries to put it into a logical structure.

· The BA brings the structured document back to the User and reviews the document

· The User provides further elaboration, and the process goes through another iteration.

Where to start?

The starting point is usually a question such as:

· Tell me what you do?

· Tell me about your job?

· What does the current system do?

· What do you want the new system to do?

· What data do you want to track?

What in fact is happening is a roving dialogue, which is exploring different streams as they arise. There is no focus on extracting the useful information from the flood of data until later. The information is extracted after the interview - usually when the BA sits down to review his or her notes.

Structuring the Interview

On the other hand, it is unrealistic to say to the user

“For the first ten minutes, I want you to tell me all the data you want in the new system. The next ten minutes will focus on functionality. The next ten minutes on reports ….”.

If the User were an IT trained person may be able to go some of the way down this path in providing requirements but it is an unnatural way to think because of the inter-dependencies between the components of a system. Requirements tend to evolve rather than be specified in a structured manner.

A good analogy I was once told was that the difference between a software engineer and a network engineer is the same difference at that between a civil engineer and a horticulturist. A civil engineer uses proven formulas and precise calculations to produce a result that is completely predictable on paper. The end result can be predicted with almost 100% accuracy.

On the other hand a horticulturist plans a garden, but the end result depends on factors outside their control. The shape of plants, or how well they will grow is not absolutely predictable. Intervention by the weather or pests is not always foreseeable. Adaptation and modification are employed all through the process.

So it is with developing software and networks. A network can be specified on paper, and the results will usually match the specification. Specifying software on paper is only the first step in building the system. It is a working draft of the design.

Method Hä

So how does the BA better guide the discussion? Project Perfect has developed a technique called Method Hä. Method Hä bridges the gap between how the User wants to explain their requirements, and how the BA needs to sort the information. Basically we need to extract the information from the data, and sort it into “buckets”. These “buckets” are interdependent. When functionality is identified, it uses data. The functionality goes in one “bucket” and the data in another. In talking to business people, the “buckets” would look more like this:

What do other people give you?	What do you do?	What do you give other people?
	What rules apply?
	What do you need to keep track of?

From the perspective of the BA, the information is seen as:

Inputs	Functionality	Outputs
	Business Rules
	Data

As you can see, the information falls into a model that is basically an “H” shape – hence the name Method Hä.

Using Method H

A good way to use the model is to draw up the “H” shape on a whiteboard or use a data projector. As pieces of information evolve, enter them in the appropriate “bucket”. Explore other “buckets” to see if information should be entered in those areas.

For example, a user might mention that they need to process address changes. “Edit addresses” goes into “Functionality”. Exploring this piece of functionality may also create:

· “Letter re change of address”, “Phone call re change of address” into “Inputs”

· “Address Details” in “Data”

· “Address changes must be signed by the customer” in “Business Rules”

· “Letter confirming address change” in “Outputs”.

So what goes into the “buckets”? The following gives some guidance as to what you enter into each of the areas.

Inputs & Outputs

By defining the inputs and outputs, the scope can be further refined. Obviously this should have happened at project inception but by defining what comes into the area, and what is produced, it helps define scope at a lower level of detail.

It is likely that the questioning will go in loops. For example, an input may be an order. The order is checked to ensure it is an existing customer and sent off somewhere else for credit checking. It comes back as an authorised invoice, so it is input twice – first as a received invoice, and second as an authorised invoice. There is an output of an invoice sent for credit checking. Try to differentiate how it is different

Functionality

Functionality will be at different levels of granularity. One piece of functionality may be to check it is an existing customer. Another may be to check if the customer is part of a group (which is a lower level than checking the customer). Another may be to check customer details, which covers both above. At the first interview, it is better to keep focused on getting information rather than sorting information.

Data

The question “What are the people, places and things you want to keep track of?” is invaluable for a BA. The vast majority of users don’t think in terms of databases. Nor should they. They just keep track of things. Data comes up all through a discussion. When it does, drop it in this “bucket”.

Business Rules

As rules emerge, they should be dropped into the business rules “bucket”. Like data, they are woven through everything the BA is told.

Conclusion

Method Häis a communication technique. It gives both parties a structure to carry on their discussion. They might see the information they are providing/collecting in different terms, but the result is the same.

The benefits of using the Method Hästructured technique are many.

· Both the BA and the User are talking the same language albeit different dialects.

· All the aspects of a particular topic are covered i.e. data, functionality, business rules etc.

· Both parties can see what has been recorded and gaps are more likely to be identified. This will reduce the number of iterations required to get a complete picture.

· The Users will quickly fall into a pattern of providing information in a more usable format for the BA

· The process works equally well in a workshop or a one-on-one interview

About the Author

Neville Turbit has almost 30 years experience in Business and IT consulting. He is the principal of Project Perfect Pty Ltd., a project management software consulting and training organisation based in Sydney Australia. Project Perfect sells Method Hä software as well as other project management tools.

Their web site contains many white papers on project management topics, as well as useful links. For more information visit www.projectperfect.com.au.