You have the vision of what the project is about and some high-level objectives. If not refer to the article around how to identify scope. The correct stakeholders have been identified and have turned up for the meeting with you to discuss their requirements. However in the meeting you aren’t getting much information and nothing has been written down.
So there are a number of things that the business will know that you can use to help yourself and them to understand their requirements. This is a key reason for how business analysts can add value as it is not as simple as asking someone what they want.
Answers the business attendees will be more likely to know are:
- The problems they have that the solution needs to resolve
- The opportunities the solution needs to meet
- The inputs
- The outputs
- The business events – the scenario’s for wanting to use the solution
- Their processes
If the inputs and outputs already exist then it may be possible to get copies of these. It may be the case that you are aware of some of the inputs, output or business events. If so it might be worth preparing some mind maps to walk through with the attendees so additional ones can be added.
Once the business events have been identified process mapping can used to provide more detail.
Business process mapping the end to end process will also highlight problems and uncover opportunities for improvement. The guide to business process modelling provides more detail on how to do this.
Another benefit of business process modelling is that it will allow agreement of which of the tasks in each of the processes relate to the required solution. This will form a basis of the requirements.
In terms of conducting the activities described above it is important to capture the information visually in front of everyone.
The reason for this is:
- to slow the pace of the meeting down to enable you to capture what has been said
- to enable the attendees to see what you have captured
- to provide any corrections and ensure you have understood correctly
- to enable them to think of additional information to add
- to encourage contribution
It will also be of benefit to have a flip chart available to write on with car park at the top. This is a useful tool to ensure the meeting is kept on topic. If attendees talk about something that isn’t relevant to your meeting you can reassure them that you will capture their topic in the car park flip chart so that it isn’t forgotten and can be picked up after the meeting.
Also make sure that all actions are captured, there is an agreement on who will do each of the actions and by when. This then helps with following up on these.
Always ask whether they think they will need another meeting and mention if you think another one is needed. This will help get buy in for another meeting if it is required and allow the requirements to be played back or if there is a need to drill down into each of the processes that are part of the required solution.
If putting together a traditional Business requirements document (BRD) as a result of this workshop then see What to include in a Business Requirements Document (BRD) for what needs to go in it. It may be the case that you will need to go back through it with the business afterwards to identify additional information such as priorities.
By addressing the activities suggested in this article should also be an enabler for putting together a use case model. The actors will have been identified by the stakeholder roles using the solution and the system inputs. The use cases can be identified from the tasks in the processes that need to be part of the solution. If you need any more help on this then see How to elicit high level requirements by identifying use cases. A reason for putting together a use case model earlier on in the requirements is that it is a good tool for estimating and planning purposes. See Using a use case model for estimating and planning for further information.
Thoughts? Questions? Please share in the comments.
