Are you new to requirements elicitation?
What you do after the event is every inch as important as what you do before and during the event. From analysing data and preparing deliverables to supporting stakeholders through other stages of the solution development lifecycle, the role of the BA is certainly key to successful projects. The end of the elicitation event does not signify the end of business analysis activities, but the beginning of the BA’s involvement in other aspects of the project.
This guide touches on how to adopt different thinking styles, spot logical fallacies and identify the root causes of business problems. It's all about knowing what you need to do before you get to the point where you need to do it. In addition, it describes the best practices for success and the role of the BA once requirements have been elicited to a considerable extent. It is a collection of simple but essential tips that can easily be taken for granted.
It also includes Action Plan & Requirements Specification Templates
Action Plan Template: One of the outcomes of an elicitation event, which could be as simple as a 30-minute interaction with a stakeholder or as elaborate as a gathering of 20-30 stakeholders from different parts of an organization, can be a list of actions to be completed.
This template can be used for recording and tracking stakeholders’ actions for increased visibility and monitoring after the event. The actions that a stakeholder needs to take to resolve issues can also be logged using this template.
Requirements Specification Template: Specification documents are a means of documenting the requirements elicited after discussions with stakeholders. This template highlights relevant sections that should be filled out when describing requirements and can be customized to suit your requirements.
Take a peek here.