Business requirements statement verification techniques.

Business requirements are supposed to be high level statements that are then translated into the System requirements statements.  The following article will help you capture more accurate requirements from the business user/stakeholder perspective. It is a practical technique that can be used if you haven't done enough stakeholder analysis, you are a newbie to the team, area, organisation or not clear on the organisation structure, existing systems and processes.

The technique suggested here is Abstraction.

By definition it means that breaking the requirement statement into logical elements and attaining higher or lower level of abstraction by relating the element to a common entity or specific value.

Let us take an example:

Business user says - I want all the inventory held in XYZ system to help the planning team manage capacity.

First glance at this statement seems like it is a correct, precise, objective and complete requirement.
However lets try and dissect the statement into logical elements e.g:

I want
all the inventory
held in XYZ system
planning team
manage capacity

Lets analyse each element.

I want - It is a good idea to established who is this person who is raising this requirement. Is he a business user, stakeholder, authority. A way to understand and establish this is to ask questions like will this inventory be used only by the planning team in a particular location or will it be consumed by some other team, person or system. This mean converting the specifics to higher level of abstraction.

all the inventory - It is a good idea to get some more specific information about the inventory here. This can be done by asking question like what kind of inventory it is, category of inventory (e.g supplier inventory, customer inventory). Thus we need to convert this element to a lower level of abstraction.

held in XYZ system - Well the business user has already mentioned the system he thinks he would use, this may be because the user has been using it before or has heard about it somewhere. This may not be the right place to hold the data requested. To get around this question like type and category of data would help. Thus converting to a higher level of abstraction.

planning team - It may be right that only the planning team is going to use the data held somewhere to do their job, But its always a good idea to verify and confirm that your understanding is correct. And remember it also depends on who is placing the requirement the scope of that person may be limited to his team. Thus a possible conversion to higher level of abstraction or multiusers may be required here.

manage capacity - This relates to the objective of the user. This may help you realise whether the requirement stated is valid or no.  Ask yourself is this the best way to manage capacity, will the data held in XYZ system will really help them manage capacity, what are other option that can be explored and arrive at the best possible solution. If the user never mentioned about the manage capacity element at all, you need to probe him with a why question to understand the objective behind the requirement. Thus a possible conversion to higher level of abstraction may be required here.

Well you may think its going to take me ages to gather requirements if I have to apply this technique to every requirement statement. Not quite right, you can think of the technique when the user has placed the requirement and ask the question upfront to get more idea, information and probe new questions based on ideas and information given to arrive at the most accurate requirement possible.

It would be difficult in the beginning to apply, ask questions, probe, revalidate and state. Also watch the user may get frustated with your questions and reciprocate with weird answers if he doesnt care.

Practice, learn and practice and it will all be fine one day and you will be the perfect most desired analyst!!

So the most probable result statement could be:

Planning, Commisioning and Capacity management function must have access to all the physical inventory held in Physical Assets / Inventory repository.

Note the words function, repository, physical used in the statement above, these are the abstract terms that may be pre defined or newly created. Where possible the abstract terms should be from the common vocabulary used in your organisation. It may be a good idea to established and communicate these terms so that everyone involved is on the same page.

I hope this technique helps you eliciting business requirements.

Click here to learn some techniques for gathering system level requirements.