By Neville Turbitt from Project Perfect
Overview[]
Many Business Analysts start a business analysis conversation with users by asking what they do. The conversation tends to drift in no particular direction until a thread is sighted, then the BA follows that thread to the end. The next thread is fleshed out and a similar process is followed by the BA. Hopefully, by taking enough random walks around the person's job, sufficient information will be collected by the Business Analyst to come up with a requirement.
Structured Approach to Business Analysis[]
Project Perfect has developed a better way. In fact, any approach that uses some structure is going to be a better way. The following structure is called "Method H" ™. The reason is that the information falls into a model that is basically an "H" shape.
In talking to business people, the model would look more like this:
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 box.
Business Rules[]
As rules emerge, they should be dropped into the business rules box. Like data, they are woven through everything the BA is told.
Business Process[]
Depending on the scope of the discussion, it may be useful to break it down into discreet business processes. For example, an order fulfilment area may have the following business processes:
* Order placement * Order fulfilment * Invoice creation
It is up to the Business Analyst to determine the appropriate level of granularity to use when undertaking the analysis.
Using Method H[]
Start by explaining to the user that you are going to record information into the "Model H" ™. Explain the type of information that will go into each box. I suggest using the second diagram without the more technical terms of functionality and data. It will depend on the sophistication of the user.
A useful tool is a whiteboard where information can be jotted down, however if the area is extensive, you will quickly run out of space. Another method is to use sheets of paper stuck to the wall where if one sheet fills up, another can be added. The recommended approach is to use the software tool available through Project Perfect
Try to identify the business processes prior to the work being undertaken. It will help if you can do this work first. If it is not clear, spend some time at the start of the discussion to see how the users see the process areas.
The first area to discuss is the inputs and outputs. I suggest the following approach.
"Consider yourself as an integral part of this organisations process. You add value to a part of what the organisation does. To do this you receive things, do work on them, and pass them on. For example, if you were a customer service telephone operator, you would receive a call from a customer who had a question, resolve their issue, and give them advice. What are the things you receive? Think in terms of phone calls, memos, forms, e-mails, visits etc."
The discussion will start on inputs and outputs but quickly expand to functionality. As data and business rules emerge, they can be noted.
This dialogue starts with an order being identified as an input. The user quickly moves onto what they do with the order.
"So you receive an order and check available stock (functionality)? Do you always advise the client of 'out of stocks' and put on back order (business rule)?"
Also identified is data in terms of customers, orders and stock.
It is almost inevitable that someone will want to reorganise functionality. Resist the temptation and tell the user you will come back later with functionality sorted in more detail. Remember to focus on gathering, not sorting.
Example[]
The following is a very simple order processing area but will give enough information to show how "Method H" ™ works.
Summary[]
In my experience, a workshop with users using a structured methodology is the best way to elicit requirements. There are many methodologies including functional decomposition, DFD, Workflows, Use Cases etc. that can be used. A workshop however is not always feasible. "Method H" ™ can provide a useful framework for gathering requirements if you are doing a one on one interview.
Project Perfect can provide An inexpensive Microsoft Access based tool to assist with the collection and reporting of data.
Visit [1]