Communicate Requirements - Business Analyst


Communicating requirements is essential for bringing stakeholders to a common understanding of requirements.


Communication Requirements in Business

Communicating requirements includes conversations, notes, documents, presentations, and discussions. Concise, appropriate, effective communication requires that the business analyst possess a significant set of skills, both soft (communication) and technical (i.e. requirements).


Business Analysis Communication Plan: Defines what information is to be communicated, which stakeholders need to receive it, when communication should occur, and the form it should occur in.

Requirements: Any requirement may be communicated.

Requirements Package: Requirements may be communicated without being in a requirements package, but if a package has been assembled, it must be distributed, reviewed, and the contents must be communicated to stakeholders.


1. General Communication

Requirements communication is performed iteratively and in conjunction with most of the tasks in the other knowledge areas.

Not all communication can or should be planned, and informal communication of requirements is likely to be needed during the performance of most business analysis tasks. In many cases, requirements communication may lead to elicitation of additional requirements.

  • Enterprise Analysis Tasks: Business case and solution scoping information is communicated.
  • Elicitation Tasks:Each elicitation technique requires specific communication skills. Communication of requirements may be useful during elicitation activities, as it may help stakeholders to identify other related requirements.
  • Requirements Analysis Tasks:Requirements are refined, modified, clarified and finalized through effective communication.
  • Solution Assessment and Validation Tasks:Assessments of the solution,allocation of requirements to solution components, organizational readiness, and transition requirements all must be communicated.

2. Presentations

Before making any presentations of requirements to an audience,determine an appropriate format for the presentation.The formality of the presentation is driven by the objective of the communication and the audience needs. For example, the business analyst may be required to present key points using a formal presentation using presentation slides and handouts. This may be desirable when presenting to senior business representatives who are not actively involved in the detail of the project but need to understand requirements at a higher level.

A presentation may be used:

  • to ensure that internal project quality standards have been adhered to
  • to ensure cross-functional fit with other business process areas within the same
  • to obtain business acceptance and sign-off
  • to obtain delivery team sign-off
  • to obtain testing team sign-off
  • as a precursor to delivery (e.g. examining solution options with a delivery team)

Formal Presentation

Formal presentations typically disseminate information in a well-organized, structured format. Audience members may be given supporting materials before or during the presentation. Audience participation/questions may be encouraged.

Informal Presentation

An informal presentation may be used:

  • as an informal status check of requirements (e.g.completeness, correctness, impact on other areas).
  • to communicate requirements to the delivery team or testing team to ensure there is no ambiguity.
  • to communicate requirements to affected business areas (those not having sign-off authority but where knowledge of changes is required).
  • to communicate requirements to other project teams as a facilitation exercise to enhance requirement clarity. For example, by bringing business users and technical teams together, a common understanding can be reached on the relevance / importance of individual requirements as well as the feasibility of delivering individual requirements.


Requirements Workshops : Requirements may be presented as part of a requirements workshop to familiarize all parties with the existing solution scope and the current requirements.

Structured Walkthrough : A structured walkthrough often begins with a review of the requirements to be discussed.




Communicated Requirements: Stakeholders should understand what the requirements are and their current state.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

Business Analyst Topics