Project Management Software
Specialists in Project Infrastructure
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 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.
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.
As rules emerge, they should be dropped into the business rules box. Like data, they are woven through everything the BA is told.
Depending on the scope of the discussion, it may be useful to break it down into discreet business processes. For example, an order fulfillment area may have the following business processes:
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.
The first area to discuss is the inputs and outputs. I suggest the following approach.
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.
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.
The following is a very simple order processing area but will give enough information to show how "Method H" works.
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.