Manage Solution Scope & Requirements - Business Analyst


Obtain and maintain consensus among key stakeholders regarding the overall solution scope and the requirements that will be implemented.


This task involves securing approval of requirements from those stakeholders who have the appropriate authority, and managing issues that emerge during elicitation and analysis. Approval of requirements may be sought at the end of a project phase or at a number of intermediate points in the business analysis process.

Requirements may be baselined following approval. Any changes to requirements after baselining, if changes are permitted, involves use of a change control process and subsequent approval. As requirements are refined or changed as the result of new information, changes will be tracked as well.

The solution scope is required as a basis for requirements management and is used to determine whether a proposed requirement supports the business goals and objectives. If the business need changes during the lifetime of an initiative, the solution scope must also change. Changes to the solution scope may also lead to changes in previously approved requirements, which may not support the revised scope.

Change - driven approaches typically do not use a formal change control process, as requirements are prioritized and selected for implementation at the beginning of each iteration and no changes to the requirements occur during an iteration.


Requirements Management Plan: Defines the process to be followed in managing the solution scope and requirements.

Solution Scope: Requirements must support the solution scope in order to be approved, unless the solution scope is modified accordingly. The solution scope is also a requirement that can be managed in its own right. Changes to other business requirements generally do not fall within the normal change management process of a project, as they are external to the project scope.

Stakeholder List, Roles, and Responsibilities: This defines which stakeholders are involved in reviewing and approving requirements.

Stakeholder, Solution, or Transition Requirements [Communicated or Traced]: Requirements may be managed at any point in their lifecycle (stated, specified and modeled, verified, validated, etc.), although stakeholder approval is normally restricted to requirements that have been verified and validated. Requirements must be communicated to be managed, as stakeholders cannot consent to requirements if they are not aware of them. Requirements may also be managed if they can be traced to requirements that have been approved, as those requirements are a basis for determining whether other requirements fall within the scope of the solution.


1. Solution Scope Management

All stakeholder and solution requirements must be assessed to ensure that they fall within the solution scope. Stakeholders will frequently identify additional needs that the solution may be capable of addressing. However, if these additional requirements are invalid (that is, they are not aligned with the approved business requirements) or they do not fall within the solution scope, the business analyst must act to resolve the conflict. This may be done by amending the business requirements and solution scope or by reaching agreement that the requirement does not fall within the scope of the initiative.

2. Conflict and Issue Management

As requirements are developed and reviewed, conflicts often arise. A conflict may result from stakeholders in different areas viewing requirements from different perspectives. It may also result from conflicting priorities.Inconsistent requirements cannot be satisfied by a single solution and so any inconsistency must be resolved.

Facilitate communication between the stakeholders who are in conflict over the requirement in order to resolve the issue. Conflicts may be resolved through formal meetings among affected stakeholders, through research, resolution by a third party, or other methods as appropriate. Conflicts that affect the requirements must be resolved before formal approval is given to those requirements.

3. Presenting Requirements For Review

Determine how requirements will be presented to various stakeholders and whether presentations will be formal or informal. A formal presentation may be a written system requirements specification or a structured walkthrough with various levels of stakeholders, including executive summaries as well as a structured model including all of the associated diagrams, supporting text, detailed attributes, and revision information. A requirement may be presented informally in an e-mail message, a note, or verbally.

Assess the requirements, audience, and organizational process assets to determine the level of formality appropriate for business analysis communication. Generally, the more formal the communications, the more time that will be required to prepare for meetings, for reviews, for the presentation or requirements package, etc. Less formal communications may result in key stakeholders missing information or in increased ambiguity in requirements.

When presenting requirements for review and approval, there needs to be enough formality to support the methodology and ensure that the stakeholders will review, understand, and approve them.

4. Approval

Ensure that the stakeholder(s) responsible for approving requirements understands and accepts the requirements. Stakeholder approval may be required for the result of other business analysis work, including allocation of requirements, proposed problem resolutions, and other decisions. Approval may be obtained from stakeholders individually or as a group.

A record of the decision may be kept. A decision record may include the decision made (whether or not to include the requirement or modify the scope), the reason for the decision, and the parties involved.


1. General Techniques

Problem Tracking : Allows the business analyst to manage any issues identified with requirements by stakeholders and ensure that those issues are resolved.

2. Baselining

Once requirements are approved, they may be baselined, meaning that all future changes are recorded and tracked, and the current state may be compared to the baselined state. Subsequent changes to the requirement must follow the change control process.

As changes are approved, the requirements management plan may require that the base lined version of the requirement be maintained in addition to the changed requirement. Additional information is often maintained such as description of the change, person who made the change, and the reason for the change.

3. Signoff

Requirements signoff formalizes agreement by stakeholders that the content and presentation of documented requirements is accurate and complete. A formal sign - off of requirements documentation may be required by organizational standards or for regulatory reasons.

Obtaining requirements sign - off typically involves a face - to - face final review of requirements documentation with each stakeholder with authority to approve requirements. At the end of each review, the stakeholder is asked to formally approve the reviewed requirements document. This approval may be verbal or be recorded either physically or electronically.

If a stakeholder only has authority to sign - off on a subset of the requirements, a specific list of the requirements the stakeholder is approving, and a complementary list of the requirements the stakeholder is not approving (but to which the stakeholder explicitly has no objection) should be prepared. Under such circumstances, it is incumbent upon the business analyst to assure that each individual requirement is explicitly approved by at least one appropriate stakeholder with the authority to do so.


Domain SME: May be involved in the review and approval of requirements, as defined by the stakeholder roles and responsibility designation.

Implementation SME: Will likely be involved in this process to ensure that the requirements can be implemented.

Project Manager: The project manager is responsible and accountable for the project scope. The project manager must be involved in assessing the solution scope in order to define the project scope, and must be involved in reviewing any changes to the solution scope for the same reason. In addition, if a proposed requirement is not accepted by key stakeholders, the project manager must manage the associated risk to the project (by altering the project scope, escalating the issue, or through other appropriate responses).

Sponsor: The business case, solution or product scope and all requirements must be reviewed and approved by the sponsor(s) according to the approval authority stated in the requirements management plan.


Requirements [Approved]: Requirements which are agreed to by stakeholders and ready for use in subsequent business analysis or implementation efforts.

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

Business Analyst Topics