CBAP Exam Prep – Requirements Analysis and Design Definition

Inputs
Elicitation Results (any state): modelling can begin with any elicitation result and may lead to the need for more elicitation to clarify or expand upon requirements. Elicitation and modelling may occur sequentially, iteratively, or concurrently.
Elements

Model Requirements
A model is a descriptive and visual way to convey information to a specific audience in order to support analysis, communication, and understanding. Models may also be used to confirm knowledge, identify information gaps that the business analyst may have, and identify duplicate information.
Business analysts choose from one or more of the following modelling formats:
• Matrices: a matrix is used when the business analyst is modelling a requirement or set of requirements that have a complex but uniform structure, which can be broken down into elements that apply to every entry in the table.
• Diagrams: a diagram is a visual, often pictorial, representation of a requirement or set of requirements. A diagram is especially useful to depict complexity in a way that would be difficult to do with words.

Outputs
Requirements (specified and modelled): any combination of requirements and/or designs in the form of text, matrices, and diagrams.

Verify Requirements
Purpose
The purpose of Verify Requirements is to ensure that requirements and designs specifications and models meet quality standards and are usable for the purpose they serve.

Inputs
Requirements (specified and modelled): any requirement, design, or set of those may be verified to ensure that text is well structured and that matrices and modelling notation are used correctly.

Elements

Characteristics of Requirements and Designs Quality
(very Important)
While quality is ultimately determined by the needs of the stakeholders who will use the requirements or the designs, acceptable quality requirements exhibit many of the following characteristics:
• Atomic: self-contained and capable of being understood independently of other requirements or designs.
• Complete: enough to guide further work and at the appropriate level of detail for work to continue. The level of completeness required differs based on perspective or methodology, as well as the point in the life cycle where the requirement is being examined or represented.
• Consistent: aligned with the identified needs of the stakeholders and not conflicting with other requirements.
• Concise: contains no extraneous and unnecessary content.
• Feasible: reasonable and possible within the agreed-upon risk, schedule, and budget, or considered feasible enough to investigate further through experiments or prototypes.
• Unambiguous: the requirement must be clearly stated in such a way to make it clear whether a solution does or does not meet the associated need.
• Testable: able to verify that the requirement or design has been fulfilled. Acceptable levels of verifying fulfillment depend on the level of abstraction of the requirement or design.
• Prioritized: ranked, grouped, or negotiated in terms of importance and value against all other requirements.
• Understandable: represented using common terminology of the audience.

Checklists
Checklists are used for quality control when verifying requirements and designs. The purpose of a checklist is to ensure that items determined to be important are included in the final requirements deliverables, or that steps required for the verification process are followed.

Outputs
Requirements (verified): a set of requirements or designs that is of sufficient quality to be used as a basis for further work.

Validate Requirements
Purpose
The purpose of Validate Requirements is to ensure that all requirements and designs align to the business requirements and support the delivery of needed value.

Description
Requirements validation is an ongoing process to ensure that stakeholder, solution, and transition requirements align to the business requirements and that the designs satisfy the requirements.

Inputs
Requirements (specified and modelled): any types of requirements and designs can be validated. Validation activities may begin before requirements are completely verified. However, validation activities cannot be completed before requirements are completely verified.

Elements

Identify Assumptions
If an organization is launching an unprecedented product or service, it may be necessary to make assumptions about customer or stakeholder response. Stakeholders may have assumed that certain benefits will result from the implementation of a requirement. These assumptions are identified and defined so that associated risks can be managed.

Define Measurable Evaluation Criteria
While the expected benefits are defined as part of the future state, the specific measurement criteria and evaluation process may not have been included.

Evaluate Alignment with Solution Scope
A requirement can be of benefit to a stakeholder and still not be a desirable part of a solution. A requirement that does not deliver benefit to a stakeholder is a strong candidate for elimination. When requirements do not align, either the future state must be re-evaluated and the solution scope changed, or the requirement removed from the solution scope.

Outputs
Requirements (validated): validated requirements and designs are those that can be demonstrated to deliver benefit to stakeholders and align with the business goals and objectives of the change. If a requirement or design cannot be validated, it either does not benefit the organization, does not fall within the solution scope, or both.

Define Requirements Architecture
Purpose
The purpose of Define Requirements Architecture is to ensure that the requirements collectively support one another to fully achieve the objectives.

Description
Requirements architecture is the structure of all of the requirements of a change. A requirements architecture fits the individual models and specifications together to ensure that all of the requirements form a single whole that supports the overall business objectives and produces a useful outcome for stakeholders.

Inputs
Information Management Approach: defines how the business analysis information (including requirements and models) will be stored and accessed.
Requirements (any state): every requirement should be stated once, and only once, and incorporated into the requirements architecture so that the entire set may be evaluated for completeness.
Solution Scope: must be considered to ensure the requirements architecture is aligned with the boundaries of the desired solution.

Elements

Requirements Viewpoints and Views
A viewpoint is a set of conventions that define how requirements will be represented, how these representations will be organized, and how they will be related. Viewpoints provide templates for addressing the concerns of particular stakeholder groups.

Template Architectures
An architectural framework is a collection of viewpoints that is standard across an industry, sector, or organization. Business analysts can treat frameworks as predefined templates to start from in defining their architecture.

Completeness
An architecture helps ensure that a set of requirements is complete. The entire set of requirements should be able to be understood by the audience in way that it can be determined that the set is cohesive and tells a full story.

Relate and Verify Requirements Relationships
Requirements may be related to each other in several ways when defining the requirements architecture. Business analysts examine and analyze the requirements to define the relationships between them. The representation of these relationships is provided by tracing requirements (see Trace Requirements (p. 79)).

Business Analysis Information Architecture
The structure of the business analysis information is also an information architecture. It is useful to start defining this architecture before setting up infrastructure such as requirements life cycle management tools, architecture management software, or document repositories.

Outputs
Requirements Architecture: the requirements and the interrelationships among them, as well as any contextual information that is recorded.

Define Design Options
Purpose
The purpose of Define Design Options is to define the solution approach, identify opportunities to improve the business, allocate requirements across solution components, and represent design options that achieve the desired future state.

Description
When designing a solution, there may be one or more design options identified. Each design option represents a way to satisfy a set of requirements.

Inputs
Change Strategy: describes the approach that will be followed to transition to the future state. This may have some impact on design decisions in terms of what is feasible or possible.
Requirements (validated, prioritized): only validated requirements are considered in design options. Knowing the requirement priorities aids in the suggestion of reasonable design options.
Requirements Architecture: the full set of requirements and their relationships is important for defining design options that can address the holistic set of requirements.

Elements

Define Solution Approaches
The solution approach describes whether solution components will be created or purchased, or some combination of both. Business analysts assess the merits of the solution approaches for each design option.

Identify Improvement Opportunities
When proposing design options, a number of opportunities to improve the operation of the business may occur and are compared.

Requirements Allocation
Requirements allocation is the process of assigning requirements to solution components and releases to best achieve the objectives. Allocation is supported by assessing the trade-offs between alternatives in order to maximize benefits and minimize costs. The value of a solution might vary depending on how requirements are implemented and when the solution becomes available to stakeholders. The objective of allocation is to maximize that value.

Describe Design Options
Design options are investigated and developed while considering the desired future state, and in order to ensure the design option is valid. Solution performance measures are defined for each design option.

Outputs
Design Options: describe various ways to satisfy one or more needs in a context.
Analyze Potential Value and Recommend Solution
Purpose
The purpose of Analyze Potential Value and Recommend Solution is to estimate the potential value for each design option and to establish which one is most appropriate to meet the enterprise’s requirements.

Inputs
Potential Value: can be used as a benchmark against which the value delivered by a design can be evaluated.
Design Options: need to be evaluated and compared to one another to recommend one option for the solution.
Elements

Expected Benefits
Expected benefits describe the positive value that a solution is intended to deliver to stakeholders. Value can include benefits, reduced risk, compliance with business policies and regulations, an improved user experience, or any other positive outcome. The total expected benefit is the net benefit of all the requirements a particular design option addresses. Benefits are often realized over a period of time.

Expected Costs
Expected costs include any potential negative value associated with a solution, including the cost to acquire the solution, any negative effects it may have on stakeholders, and the cost to maintain it over time.

Determine Value
The potential value of a solution to a stakeholder is based on the benefits delivered by that solution and the associated costs. Value can be positive (if the benefits exceed the costs) or negative (if the costs exceed the benefits).