As a business analysis we often come to this phase when it is expected to explain what we document to the appropriate audiences or stakeholders. The approach we adapt for this is usually different in different context. This requirements explanation would benefit different stakeholders in different context. For instance: A developer would be benefited from an implementation perspective, A Quality Assurance person would be benefited from an Test Planning Approach perspective. A Manager can be benefited from an Efforts perspective, similarly a Business Stakeholder can be benefited from an Business Value perspective.
But the question here is: How can we cater to different needs for different stakeholders at the same time for same set of requirements. Well! Firstly we need to ask few questions to ourselves.
★ Who are the people to whom this explanation is needed ?
★ What is their influence on this project?
★ How involved are they in this requirement gathering activity?
★ How comfortable are they in understanding these requirements?
★ How will they benefit from this requirement?
Next, We need to check on the list of documentation we have. We might have below list of documentation:
★ Business Requirements Documentation (BRD)
★ Functional Specification Documentation (FSD)
★ UI Screen Mock/Prototype
★ Data Dictionary
★ Business Process Models
★ Data Flow Diagrams
★ Use Cases and many more . . .
Here we need to understand, One size doesn’t fit all. We need to be careful on what needs to be presented to whom.
This can be easily understood by the significance of the documentation for respective stakeholders. For instance. A BRD is a high level documentation which summarizes the entire scope of the project and may not be that beneficial for a developer to visit very often. Instead a developer would focus more on the implementation part and would be much interested in other Low level documentation like a Data Flow Diagram or a Data Dictionary. Similarly, QA would be more interested in the use cases as this would give him more scenarios for Test Planning. In short, We need categorize the documentation for respective stakeholders as per their need an interest. Sometimes, Referred to as BA Communication Package
Next we need to understand how effectively we can present the requirements. For instance: We can easily explain a functional requirement to a non-technical stakeholder with the help of a Screen Mock Up. Similarly, we can easily explain a Non Functional requirement to anyone with the help of Data Flow Diagram. Always, remember as a Business Analyst we need to be very particular about on what modelling techniques we choose for a requirement. Not all modelling techniques outcomes are suitable for all stakeholders.
Once we are done with these activity, We need to plan on the availability of our stakeholders. If they are geographically distributed we would need multiple sessions for each group of stakeholders. A common practice is to categorize stakeholders as Functional and Technical as Functional stakeholders may not be interested on the implementation side and Technical stakeholders might not be much interested on the functional side.