CBAP Requirements Management and Communication Tutorial

4.2 Requirements Management and Communication

Hello and welcome to the fourth module of Certified Business Analysis Professional™ (CBAP®) (read as C-Bap) certificaiton course offered by Simplilearn. In the first module, we covered the overview of the CBAP test. We discussed planning the analysis approach in the second module. We learnt about elicitation in the third module. In this module, we will discuss requirements management and communications. This knowledge area focuses on the 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 the solutions. The project team and stakeholders need to be constantly updated. Communications 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 agenda of this module in the next slide.

4.3 Agenda

We will start with finding out how to manage the solution scope requirements. Next, we will discuss the ability to trace back to the origins of the roots of the findings. This is called traceability. An input to the solution scope management is the next topic to be discussed. This will be followed by understanding how to manage the requirement changes. We will then discuss how to prepare the requirements package. Outside vendor requirements will be dealt with next, followed by communicating requirements, and approved requirements traceability. Finally we will look into a structured walkthrough. Let us begin with managing the solution scope requirements in the next slide.

4.4 Managing the Solution Scope Requirements

Defining solutions and needs can be an ongoing process that takes place as the BA and project team drills 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 man hours or equipment will make it easier to obtain the 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 their designated person will sign-off the current solution scope. This does not mean that 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 important procedure can become a legal issue if the project goes wrong. The next slide deals with traceability.

4.5 Traceability

As mentioned earlier, there needs to be a 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 requirements are 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 requirement are identified needs to be documented for analysis if needed later in the analysis. This is called “tracing”. We will understand inputs to solution scope management in the next slide.

4.6 Input to Solution Scope Management

In the previous slide we discussed the potential fluidity of the solutions and requirements as the project progressed. A requirement management plan is essential for the project. It is important to follow an organized method to track the process and continually base line the solution scope status and communicate it to the designated stakeholders. The solution scope is the central implementation document. Once solutions are identified and agreed to, selected stakeholders and SMEs are assigned roles and responsibilities for each solution. It will become their responsibility to ensure best solutions for the best requirements. If resources need to be outsourced, they will need to design and solicit the RFI, RFQ, etc. Also, solution stakeholders will need to help design the transition plan to integrate solutions with connecting processes that may be influenced by the primary solutions. Also, while solving these problems, the designs of the solutions need to avoid interrupting normal operations. All proposed requirements and solutions will need a traceability management plan which will define how any changes will be recorded and communicated. Stakeholder solutions may not be exactly what the BA sees as an industry standard solution, but stakeholder solutions and transition requirements need to be noted if they differ considerably from what the BA sees as a solution. Further study will determine which solution and requirements will be used. We will continue our discussion on inputs to solution scope management in the following slide.

4.7 Input to Solution Scope Management(contd.)

This slide shows the various inputs and documents that support the output which is the solutions scope management plan. Till a firm’s consensus have been formed, many factors within the inputs can change and have a direct impact on the output of the solution scope management plan. Stakeholder’s roles and responsibilities are further defined and refined as solutions and transition requirements take form. Each need, requirement, solution, and associated risks need to be documented in a traceability management plan. This allows the tracking of how and why certain decisions are made. If a solution doesn’t work, being able to trace the logic that supported that wrong solution can help identify where changes should be made. Once the inputs reach a stage where the stakeholders and BA feel it’s time to move to the next phase, the solution scope management plan is submitted to the sponsor for review, comments, and approval. In the next slide, let’s find out how to manage changes to the requirements.

4.8 Managing Requirement Changes

Some of the reasons for requirements change are: Change in perceived value means the need or solution is no longer seen as producing sufficient justification for making the change or return on investment. Change in technology is needed for 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 that might otherwise be part of a solution. In which 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 be changes in the business need. 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. Configuration management is the task of setting up a formalized procedure to establish how and who can make changes to solutions or requirements. If changes are made it is analyzed, planned, and roles and responsibilities assigned to the changes (accountability). These changes are verified by stakeholder’s consensus and documented. Producing traceability is BA’s responsibility for creating and managing requirements traceability for his/her projects, particularly during the requirements development activities. The BA should save these traceable requirement changes so they can be a part of the organizational process assets (OPAs). This is for the client, and the information asset base of the BA’s firm. These requirements can be re-used for other similar situations. Let us understand how to prepare requirement package in the next slide.

4.9 Prepare Requirements Package

Let us find out what a requirements package is. A requirements package is used to prioritize a set of requirements for solutions, in order to present it to stakeholders for consensus validation and approval. It is presented in a communication, either written or verbal, 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 require further investigation and input. It should not be used as a “last best offer,” rather it should seek close scrutiny and clear, and honest consensus. A validated requirements package forms the foundation of the project. Presentation format needs to suite the client’s time and schedule. It can be presented as a document, a Power Point Presentation, a teleconference or a format to provide the best distribution to all of 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. Work product and deliverables should be described in the “requirements” presentation of documentation. They support the solutions, how they plan to be implemented, and how the results of the solution will meet the needs of the company. 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. In the next slide we will discuss outside vendor requirements.

4.10 Outside Vendor Requirements

During the process of identifying solutions and requirements, the expertise or essential equipment may not be within the 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 have demonstrated their experience and capability through RFI solicitation, RFQ’s 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 stakeholder requirement package in the next slide.

4.11 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 design of the solution, which should help during implementation. While 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 high level explanation of requirements, the solution Scope, ROI, benefits, costs, and schedule. Whereas testers 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.12 Communicating Requirements

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 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 level of 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 key stakeholders and sponsor are updated with current state of the project, and problems or concerns if any. Communications 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 communicated; 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 event, so that when communication events take place, the details can be put into context with the overall project progress. Let us look at Communications Plan Diagram in the next slide.

4.13 Communications Plan

The slide depicts the flow of inputs into the communication plan, and to help 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 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 have been established to be in the communications plan. The stakeholders and SMEs would then review the new information and send their input back to be either incorporated into the updated plan, or open for more discussion. Once a new information is validated, it becomes a part of the updated solution scope plan and once it is implemented, it is tracked through its implementation and effect on delivering the forecast benefits. We will move on to approved requirements traceability.

4.14 Approved Requirements Traceability

The objective of the traceability document is to have a record of how requirements and solutions were decided. 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. As the diagram depicts, the process starts with the requirements list, which supports the solution scope. If a problem develops with a the solution of requirement, those problems are entered into a problem tracking worksheet. If a new solution works, it is placed into the traceability document as the solution may help with other troubleshooting events. Let us look into a structured walk through in the next slide.

4.15 Structured Walkthrough

Once the solution scope has been approved by the sponsor or other 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 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. Let us summarize what we have learnt so far in the next slide.

4.16 Summary

In this module, we reviewed the tools and processes used to develop and manage the project requirements, solutions, and how to maintain timely communication updates to the project teams, stakeholders, SMEs, and sponsor. We started by discussing how fluid plans are, as they develop toward consensus and sign off for implementation. Traceability was described as the process of documenting the development of requirements and solutions. This allows analysis and validation as being suitable for implementation. Also, traceability allows problem review if the solution does not work out as planned. We moved on to discuss how inputs and updates are distributed throughout the project teams, stakeholders, SMEs, and sponsor. We went over how changes to requirements are managed. The typical process is to formulate the changes, seek consensus, and document. Also, traceabilty is required to be documented. We then dealt with the management of outside vendors applied by the use of RFP, RFQ, and RFI. Once changes have been made and validated, the requirements package is made to formalize the requirements list and its impact on the solution scope. Once the sponsor has approved the updated solution scope, the assigned implementation teams of stakeholders design the actual implementation of the solution they are assigned to. The traceability document is brought up-to-date before the structured walk through testing takes place. In the next module we will understand 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*
Phone Number*
Job Title*