Manage Solution Scope and Requirements
This step involves securing approval of requirements from the 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 change to requirements for baselining, if changes
are permitted, involve the use of a change control process and subsequent approval. As requirements are refined or
changed, changes will be tracked.
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 businesses 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.
Manage Requirements Traceability
Managing requirements traceability involves creating and maintaining relationships between business
objectives, requirements, other team deliverables, and solution components to support business analysis or other
Requirements are related to other requirements, to solution components, and to other artifacts such as
test cases. Tracing a requirement refers to the ability to look at a requirement and the others to which it is related.
Tracing links business requirements to stakeholder and solution requirements, to other artifacts produced by the team,
and to solution components.
Maintain Requirements for Re-Use
Maintaining requirements for re-use involves identifying requirements that are candidates for long-term
usage by the agency. These may include requirements that an agency must meet on an ongoing basis, as well as
requirements that are implemented as part of a solution.
Ongoing requirements are those requirements that an agency unit is required to be able to meet on a
continuous basis. These may include contractual obligations, quality standards, service level agreements, business
rules, business processes, or requirements describing the work products the group produces.
Even though a requirement has been satisfied, it is still a requirement as long as the business
stakeholders need it. Maintaining these requirements helps with product enhancements and future system changes.
Existing requirements may also be re-used on related business projects.
Prepare Requirements Package
Preparing the requirements package includes selecting and structuring a set of requirements in an
appropriate fashion to ensure that the requirements are effectively communicated to, understood by and usable by a
stakeholder group or groups.
Requirements should be presented in formats that are understandable by the stakeholder. Requirements
must be clear, concise, accurate, and at the appropriate level of detail. Documentation of the requirements should be
created only to the extent needed to assure clear understanding by the team.
Requirements packages may be prepared for a number of reasons, including but not limited to, early
assessment of quality and planning, evaluation of possible alternatives, formal reviews and approvals, inputs to
solution design, conformance to contractual and regulatory obligations, and maintenance for re-use.
|Communicating requirements includes conversations, notes, documents, presentations and discussions. Requirements
communication is performed iteratively and in conjunction with most of the other business analysis tasks. 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