This is an extremely important knowledge area when it comes to CBAP Exam Prep. A critical knowledge area when it comes to passing the CBAP Certification. When I wrote my CBAP exam I reviewed this chapter 5 times before the CBAP exam. And why not, it has the highest weightage of all the other knowledge areas.
Let’s learn all about it!!
The Requirements Analysis and Design Definition knowledge area describes the tasks that business analysts perform to structure and organize requirements discovered during elicitation activities, specify and model requirements and designs, validate and verify information, identify solution options that meet business needs, and estimate the potential value that could be realized for each solution option.
The Requirements Analysis and Design Definition knowledge area includes Six tasks:
• Specify and Model Requirements: describes a set of requirements or designs in detail using analytical techniques.
• Verify Requirements: ensures that a set of requirements or designs has been developed in enough detail to be usable by a particular stakeholder, is internally consistent, and is of high quality.
• Validate Requirements: ensures that a set of requirements or designs delivers business value and supports the organization’s goals and objectives.
• Define Requirements Architecture: structures all requirements and designs so that they support the overall business purpose for a change and that they work effectively as a cohesive whole.
• Define Solution Options: identifies, explores and describes different possible ways of meeting the need.
• Analyze Potential Value and Recommend Solution: assesses the business value associated with a potential solution and compares different options, including trade-offs, to identify and recommend the solution option that delivers the greatest overall value.
Specify and Model Requirements
The purpose of Specify and Model Requirements is to analyze, synthesize, and refine elicitation results into requirements and designs.
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.
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.
Requirements (specified and modelled): any combination of requirements and/or designs in the form of text, matrices, and diagrams.
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.
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.
Characteristics of Requirements and Designs Quality
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 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.
Requirements (verified): a set of requirements or designs that is of sufficient quality to be used as a basis for further work.
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.
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.
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.
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.
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
The purpose of Define Requirements Architecture is to ensure that the requirements collectively support one another to fully achieve the objectives.
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.
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.
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.
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.
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.
Requirements Architecture: the requirements and the interrelationships among them, as well as any contextual information that is recorded.
Define Design Options
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.
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.
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.
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 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.
Design Options: describe various ways to satisfy one or more needs in a context.
Analyze Potential Value and Recommend Solution
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.
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.
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 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.
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).
Assess Design Options and Recommend Solution
Each design option is assessed based on the potential value it is expected to deliver. At any point in analyzing the design options, it may become necessary to re-evaluate the initial allocation of design elements between components. Outputs
Solution Recommendation: identifies the suggested, most appropriate solution based on an evaluation of all defined design options. The recommended solution should maximize the value provided to the enterprise.