Requirements Management and Communication Tutorial

4.1 Requirements Management and Communication

Hello and welcome to the fourth lesson of the Certification of Competency in Business Analysis™ (CCBA®) course offered by Simplilearn. In the first lesson, we covered the overview of the CCBA® test. We discussed planning the analysis approach in the second lesson. We learned about elicitation in the third lesson. In this lesson, we will discuss requirements management and communication. This knowledge area focuses on project requirements management to ensure that the important elements of the project are up-to-date, prioritized, and deliverable as a solution. As the project progresses, information uncovered may alter the need, which, may necessitate new or additional requirements to employ solutions. The project team and stakeholders need to be constantly updated. Communication helps to ensure the right people are involved in developing, understanding, and approving the project requirements. Also, the requirements should be accessible and managed during the requirements development phase and the project life cycle. Let us look into the objectives of this lesson in the next slide.

4.2 Objectives

After completing this lesson, you will be able to: Explain the requirements management and communication knowledge area Describe how to manage the solution scope and requirements Discuss the changes to requirements Prepare the complete requirements package Identify requirements for vendor selection Let us begin with an introduction to requirements mangement and communication in the next slide.

4.3 Introduction to Requirements Management and Communication

Requirements management and communication defines the tasks associated with the requirements management and communication of business analysis activities. This includes communicating with a broad and diverse audience to ensure that all stakeholders have a shared understanding of the nature of a solution and have reached consensus on the requirements. Once the requirements have been documented, the next step is to reach for agreement from approvers on the requirements which the solution will meet. In this step, the business analysis function might have to deal with a great deal of conflict. This process helps to reduce the amount of conflict between approving stakeholders and others. Let us see a diagram that explains requirements management and communication in the next slide.

4.4 Requirements Management and Communication Diagram

The following are the inputs derived from the business analysis planning and monitoring, and elicitation knowledge areas covered in the previous two lessons: BA Communication Plan Organizational Process Assets Requirements Requirements Management Plan Requirements Structure Solution Scope Stakeholder List, Roles, and Responsibilities The following are the outputs: Requirements [Approved] Requirements [Communicated] Requirements [Maintained & Reusable] Requirements [Traced] Requirements Package In the next slide, we will be discussing managing solution scope requirements.

4.5 Manage Solution Scope and Requirements Diagram

The following are the inputs: Requirements Management Plan Solution Scope Stakeholder List, Roles, and Responsibilities Stakeholder, Solution, or Transition Requirements The following are the outputs: Requirements are agreed by the stakeholders and prepared for use in the subsequent business analysis or implementation efforts. The following are the techniques: Problem Tracking Baselining is a point-in-time view of requirements that have been reviewed and agreed on to serve as a basis for further development. In the next slide, we will be discussing solution scope requirements.

4.6 Managing the Solution Scope Requirements

Defining solutions and needs can be an ongoing process that takes place as the BA and project team drill down into the solutions to the defined needs. As the solution morphs or changes direction, the requirements to support the solutions may also change. Hence, the requirements will have to be defined. Sometimes a requirement for a solution may require outsourcing or specialized equipment, and can affect the financial viability of the project. The project team does not want to approach the sponsor with some new costly requirement if all the possible less costly requirements have not been explored first. Hence, there should be constant documentation updating whenever there are any changes in the need-solution-requirement chain. There should be an ongoing management of the solution scope. To help keep track of the solution scope at any point of time, a baseline description of the scope should be documented. This helps identify and track the various changes and current status of the solution scope and the requirements. If costly requirement changes are needed, written proof for the additional labor or equipment will make it easier to obtain approval. When the solution scope has reached a point where the key stakeholders and SMEs agree that the solution and associated requirements have been met, an approval from the sponsor or the designated person will sign-off the current solution scope. This does not mean the solution scope may not be altered in the future; however as a matter of procedure, before any actual implementation takes place, the underlying blueprint for the solutions and requirements must be signed off by the appropriate authority. This is an important procedure that can also become a legal issue if any unauthorized alteration takes place. The next slide deals with managing requirement changes.

4.7 Managing Requirement Changes

Some of the reasons for requirement changes are: Change in perceived value, which means the need or solution is no longer seen as producing sufficient justification for making the change or return on investment. Change in technology, which is needed when the requirement might make the current solution too costly or too complex. There can be change in rules and regulations by regulatory bodies. For example, building codes may prohibit the construction of certain types of structures that might otherwise be part of a solution. In this case, the solution scope and requirements would need to change. Lack of consensus on the solution can affect change. For example, some stakeholders may not agree or may be left out of the elicitation input. There may also be changes in the business need. Finally, lack of traceability may allow solutions and requirements to drift into the variants of the planned solutions and requirements. This also happens with “scope creep,” where the client proposes minor changes that add up to extra costs and delays. The BA must watch out for undocumented scope creep as this can lead to conflicts and unhappy clients. Our next topic is transition requirements.

4.8 Manage Requirements Traceability Diagram

The following are the inputs: Requirements Requirements Management Plan The following is the output: Requirements that have been traced have clearly defined relationships to other requirements within the solution scope. This makes it relatively easy to identify the effects of one requirement on other requirements of a change. The following is the technique: Coverage Matrix is a table used to manage tracing and usually used when tracing is limited to high-level requirements. In the next slide, we will be discussing traceability.

4.9 Traceability

As mentioned earlier, there needs to be documentation that supports the process of defining needs, solutions, and requirements. This process of documentation is called traceability. The purpose is to present how each solution, requirement, and stakeholder requirement is broken down and decomposed back to the original goal of the defined business need (goal). Brainstorming and creating flow charts and decision trees are common tools used in this process, which can provide a good record of traceability. Once requirements are identified, they are broken down into their components. Also, the logic behind how a need and requirements are identified has to be documented for analysis if required later in the analysis. This is called “tracing.” The objective of the traceability document is to have a record of how requirements and solutions were decided. The business objectives are the deliverables of the project. Traceability traces the history of how solutions and requirements lead back to the need which created the business goals for the project. If a solution or a requirement does not work as hoped, the traceability document can be reviewed to see where mistakes in logic or process might have been made, or modifications can be made to help troubleshoot a problem. Let us look into requirements relationships in the next slide.

4.10 Requirement Relationships

After examining and organizing the set of requirements, record the dependencies and relationships for each of the requirements. Knowing the dependencies and relationships between requirements helps when determining the sequence in which requirements are to be addressed. Common relationships include necesity, effort, subset, cover, and value. Necessity exists when it only makes sense to implement a particular requirement if a related requirement is also implemented. Effort is when a relationship exists such that a requirement is easier to implement if a related requirement is also implemented. Subset requirement is the decomposed outcome of another requirement. Cover exists when a requirement fully includes another requirement. Value exists when including a requirement affects the desirability of a related requirement. In the next slide, we will look at the maintain requirements for re-use diagram.

4.11 Maintain Requirements for Reuse Diagram

The following are the inputs: Organizational Process Assets Requirements The following is the output: Requirement [Maintained and Reusable] In the next slide, we will be discussing preparing the requirements package.

4.12 Prepare Requirements Package Diagram

Let us find out what a requirements package is. A requirements package is used to prioritize a set of requirements for solutions and present them to stakeholders for consensus. It is presented in either written or verbal communication, between the BA and the stakeholder. A requirements package can be a document, a presentation, or a package of requirements, which is ready for the stakeholder to review. The requirements package is an essential step in gathering support and confidence that the proposed solutions and requirements are without controversy, or in checking if they require further investigation and input. It should not be used as a “last resort”, rather, it should seek close scrutiny, and clear and honest consensus. A validated requirements package forms the foundation of the project. Requirements documentation allows stakeholders to fully understand the following: the need and why it must be addressed, the connection between the needs and requirements, how the solution scope will be managed, how changes are made, as well as how the stakeholders will be updated. The following are the inputs: Business Analysis Communication Plan Organizational Process Assets Requirements Requirements Structure The following are the outputs: Requirements Package is a set of requirements grouped together in a document or presentation for communication to stakeholders. The following are the techniques: Requirements Documentation is a set of requirements grouped together in a document for communication to stakeholders. Requirements for Vendor Selection include documents such as request for information (RFI), request for quote (RFQ), and request for proposal (RFP) used to gather information from vendors about their products and services. In the next slide, we will be discussing presentation formats for the requirements package.

4.13 Presentation Formats for the Requirements Package

The requirements package is a set of requirements grouped together in a document or presentation for communication to stakeholders. The presentation format needs to suit the client’s time and schedule. It can be a document, a PowerPoint Presentation, a teleconference, or a format that provides the best distribution to all the identified stakeholders and sponsor. The presentation should not be biased but leave room for doubts and alternative requirements. The requirements package is a quality control filter before proceeding further in the analysis process. Presentation formats can be formal or informal. Formal presentations disseminate information in a well-organized and structured format. Audience participation/questions may be encouraged. Informal presentations are used to check the status of requirements, communicate to delivery team or testing team to ensure there is no ambiguity, communicate to the affected business areas, and to enhance requirements clarity. In the next slide, we will be discussing the stakeholders’ requirements package.

4.14 Stakeholder Requirements Package

This slide demonstrates how the requirements package needs to address each domain and stakeholder in that domain, and how the requirements will affect them. Each stakeholder category given on the left side of the diagram may require a slightly different level of detail depending on the role of the stakeholder. For example, the domain SMEs and end users will need to understand how the solution will work from an operational point of view. The implementation SMEs, on the other hand, will need to understand the reasoning behind the design of the solution, which should help during implementation. A project manager will need to focus on the deliverables of the milestones. Regulators will need information for legal, contractual, and governance standards. Sponsors need a requirements package that presents a high-level explanation of requirements, the solution scope, ROI, benefits, costs, and schedule. Testers, on the other hand, will need a requirements package that targets the metrics or concepts that define success for the users of the solution. The next slide deals with communicating requirements.

4.15 Requirements for Vendor Selection

During the process of identifying solutions and requirements, the expertise or essential equipment may not be part of company assets. Therefore, an outside vendor will be needed as a requirement. This requirement will set off a chain of events to help identify, price, and solicit a proposal from a qualified vendor. RFI is a request for information. Qualified vendors are contacted to obtain their input on the solution and needs. They may or may not have the expertise required. Vendor qualifications are established by the company SMEs, domain stakeholders, and the BA. RFQ is a request for a price quote. Once a group of vendors has demonstrated its experience and capability through RFI solicitation, RFQs are sent out for bidding the projects. As a result of the price quotations and experience level, an accurate cost of the requirement can be obtained to see if it fits within the goals and financial constraints of the company. RFP is a request for a formal proposal. Here, the outside vendor makes a formal proposal to do the required work. Let us understand communicating requirements in the next slide.

4.16 Communicate Requirements Diagram

During this stage of the project, the BA is responsible for setting up and supporting the communications within and between stakeholders. Different stakeholder groups may require different levels of communication and delivery format. The BA designs a communication plan based on the stakeholder’s roles and sequence of tasks. For example, if a particular solution is being installed, the team responsible for installation will need a higher frequency of communication and more detail. Other stakeholders may not be directly involved with certain tasks, and may not need the frequency and detail. However, the BA must ensure that the sponsor and key stakeholders are updated on the current state of the project, and problems or concerns, if any. Communication formats will vary according to the situation and the need. For example, for stakeholders geographically removed from the action, weekly email situation reports may be sufficient. For stakeholders working closely with a solution, on-site meetings and brainstorming sessions may be needed. Not all communications need to be documented or shared. However, traceability is always a concern and should be at least documented. In other situations, group workshops or focus groups may be needed. The Business Analyst and the project manager will need to coordinate important communication events; when communication events take place, the details can be put into context with the overall project progress. The following are the inputs: Business Analysis Communication Plan Requirements Requirements Package The following is the output: Requirements Communicated The following are the techniques: Requirements Workshops Structured Walkthrough Let us look at the Communications Plan in the next slide.

4.17 Communications Plan

The slide depicts the flow of inputs in the communication plan, which helps manage the ongoing development of the solution scope and associated requirements. Also, all problems or changes are documented and traced as a part of the problem tracking and traceability plan. For example, new information would flow into the requirements list and the requirements package is updated. The changes are moved on to the requirements package. The new information would then be distributed to those stakeholders who are part of the communications plan. The stakeholders and SMEs would then review the new information and send their input back to be either incorporated in the updated plan, or be kept open for more discussion. Once new information is validated, it becomes a part of the updated solution scope plan. Once it is implemented, it is tracked through its implementation and effect on delivering the forecast benefits. We will move on to structured walkthough in the next slide.

4.18 Structured Walkthrough

Once the solution scope has been approved by the sponsor or an appointed decision making process, a solution design is developed by the team (BA, assigned stakeholders, and SMEs) and documented. Then, a test is set up to walkthrough all the steps of the proposed solution with specifically assigned stakeholders, without disturbing the real time company processes. At this point, transition problems may arise from other processes that connect with the solution. Normally, several walkthroughs are done prior to moving to the actual implementation phase. Now, let us go through a few questions to check your understanding of the concepts discussed.

4.20 Summary

Here is a quick recap of what we have learned in this lesson: Managing solution scope and requirements is the most important task completed by a business analyst. Excessive changes to requirements can cause an unsuccessful implementation. Plan and prepare for your audience to communicate the complete requirements package. Vendor selection involves having adequate criteria to decide on the best vendor to implement a solution.

4.21 Thank You

In the next lesson, we will cover enterprise analysis.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*