Requirements Analysis and Design Definition

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. This knowledge area covers the incremental and iterative activities ranging from the initial concept and exploration of the need through the transformation of those needs into a particular recommended solution.
Both requirements and designs are important tools used by business analysts to define and guide change. The main difference between requirements and designs is in how they are used and by whom. One person’s designs may be another person’s requirements. Requirements and designs may be either high-level or very detailed based upon what is appropriate to those consuming the information.
The business analyst’s role in modelling needs, requirements, designs, and solutions is instrumental in conducting thorough analysis and communicating with other stakeholders. The form, level of detail, and what is being modelled are all dependent on the context, audience, and purpose.
Business analysts analyze the potential value of both requirements and designs. In collaboration with implementation subject matter experts, business analysts define solution options that can be evaluated in order to recommend the best solution option that meets the need and brings the most value.
The following image illustrates the spectrum of value as business analysis activities progress from delivering potential value to actual value.

Requirements Analysis and Design Definition

Figure 7.0.1: Business Analysis Value Spectrum

The Requirements Analysis and Design Definition knowledge area includes the following 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.

The Core Concept Model in Requirements Analysis and Design Definition
The Business Analysis Core Concept Model™ (BACCM™) describes the relationships among the six core concepts. The following table describes the usage and application of each of the core concepts within the context of Requirements Analysis and Design Definition.

Table 7.0.1: The Core Concept Model in Requirements Analysis and Design Definition

Figure 7.0.2: Requirements Analysis and Design Definition Input/Output Diagram

7.1 Specify and Model Requirements
7.1.1 Purpose
The purpose of Specify and Model Requirements is to analyze, synthesize, and refine elicitation results into requirements and designs.

7.1.2 Description
Specify and Model Requirements describes the practices for analyzing elicitation

results and creating representations of those results. When the focus of the specifying and modelling activity is on understanding the need, the outputs are referred to as requirements. When the focus of the specifying and modelling activity is on a solution, the outputs are referred to as designs.
Important In many IT environments, the word ‘design’ is used specifically for technical designs created by software developers, data architects, and other implementation subject matter experts. All business deliverables are referred to as ‘requirements’.
In addition to the models used to represent the requirements, this task also includes capturing information about attributes or metadata about the requirements. The specifying and modelling activities relate to all requirement types.

7.1.3 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.

Figure 7.1.1: Specify and Model Requirements Input/Output Diagram

7.1.4 Elements

.1 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. Matrices may be used for data dictionaries, requirements traceability, or for gap analysis. Matrices are also used for prioritizing requirements and recording other requirements attributes and metadata.
• 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. Diagrams can also be used to define boundaries for business domains, to categorize and create hierarchies of items, and to show components of objects such as data and their relationships.
Using one or more of the model formats, business analysts determine specific categories and specific models within categories to be used. Model categories can include:
• People and Roles: models represent organizations, groups of people, roles, and their relationships within an enterprise and to a solution. Techniques used to represent people and their roles include OrganizationalModelling, Roles and Permissions Matrixand Stakeholder List, Map, orPersonas.
• Rationale: models represent the ‘why’ of a change. Techniques used to represent the rationale include Decision Modelling, Scope Modelling,Business Model Canvas,Root Cause Analysis, and Business RulesAnalysis.
• Activity Flow: models represent a sequence of actions, events, or a course that may be taken. Techniques used to represent activity flows include Process Modelling,Use Cases and Scenarios,and UserStories.
• Capability: models focus on features or functions of an enterprise or a solution. Techniques used to represent capabilities include BusinessCapability Analysis, Functional Decomposition, and Prototyping.
• Data and Information: models represent the characteristics and the exchange of information within an enterprise or a solution. Techniques used to represent data and information include Data Dictionary,Data FlowDiagrams,Data Modelling,Glossary, State Modelling,and InterfaceAnalysis.

Business analysts should use any combination of models best suited to meet stakeholder needs in a given context. Each modelling technique has strengths and weaknesses and provides unique insights into the business domain.

.2 Analyze Requirements

Business analysis information is decomposed into components to further examine for:
• anything that must change to meet the business need,
• anything that should stay the same to meet the business need,
• missing components,
• unnecessary components, and
• any constraints or assumptions that impact the components.
The level of decomposition required, and the level of detail to be specified, varies depending on the knowledge and understanding of the stakeholders, the potential for misunderstanding or miscommunication, organizational standards, and contractual or regulatory obligations, among other factors.
Analysis provides a basis for discussion to reach a conclusion about solution options.

.3 Represent Requirements and Attributes

Business analysts identify information for requirements and their attributes as part of the elicitation results. Requirements should be explicitly represented and should include enough detail such that they exhibit the characteristics of requirements and designs quality (see VerifyRequirements (p. 141)). Various attributes can be specified for each requirement or set of requirements. These attributes are selected when planning for information management (see Plan Business Analysis Information Management (p.42)).
As part of specifying requirements, they can also be categorized according to the schema described in task Requirements Classification Schema (p. 16). Typically elicitation results contain information of different types, so it is natural to expect that different types of requirements might be specified at the same time.
Categorizing requirements can help ensure the requirements are fully understood, a set of any type is complete, and that there is appropriate traceability between the types.

.4 Implement the Appropriate Levels of Abstraction

The level of abstraction of a requirement varies based on the type of requirement and audience for the requirement. Not all stakeholders require or find value in the complete set of requirements and models. It may be appropriate to produce different viewpoints of requirements to represent the same need for different stakeholders. Business analysts take special care to maintain the meaning and intent of the requirements over all representations.
The business analysis approach may also influence the level of abstraction and choice of models used when defining requirements.

7.1.5 Guidelines and Tools

• Modelling Notations/Standards: allow requirements and designs to be precisely specified, as is appropriate for the audience and the purpose of the models. Standard templates and syntax help to ensure that the right information is provided about the requirements.
• Modelling Tools: software products that facilitate drawing and storing matrices and diagrams to represent requirements. This functionality may or may not be part of requirements life cycle management tools.
• Requirements Architecture: the requirements and interrelationships among them can be used to ensure models are complete and consistent.
• Requirements Life Cycle Management Tools: software products that facilitate recording, organizing, storing, and sharing requirements and designs.
• Solution Scope: the boundaries of the solution provide the boundaries for the requirements and designs models.

7.1.6 Techniques

• Acceptance and Evaluation Criteria: used to represent the acceptance and evaluation criteria attributes of requirements.
• Business Capability Analysis: used to represent features or functions of an enterprise.
• BusinessModelCanvas: used to describe the rationale for requirements.
• Business Rules Analysis: used to analyze business rules so that they can be specified and modelled alongside requirements.
• Concept Modelling: used to define terms and relationships relevant to the change and the enterprise.
• Data Dictionary: used to record details about the data involved in the change. Details may include definitions, relationships with other data, origin, format, and usage.
• DataFlowDiagrams: used to visualize data flow requirements.
• Data Modelling: used to model requirements to show how data will be used to meet stakeholder information needs.
• Decision Modelling: used to represent decisions in a model in order to show the elements of decision making required.
• Functional Decomposition: used to model requirements in order to identify constituent parts of an overall complex business function.
• Glossary: used to record the meaning of relevant business terms while analyzing requirements.
• Interface Analysis: used to model requirements in order to identify and validate inputs and outputs of the solution they are modelling.
• Non-Functional Requirements Analysis: used to define and analyze the quality of service attributes.

• Organizational Modelling: used to allow business analysts to model the roles, responsibilities, and communications within an organization.
• Process Modelling: used to show the steps or activities that are performed in the organization, or that must be performed to meet the desired change.
• Prototyping: used to assist the stakeholders in visualizing the appearance and capabilities of a planned solution.
• Roles and Permissions Matrix: used to specify and model requirements concerned with the separation of duties among users and external interfaces in utilizing a solution.
• Root Cause Analysis: used to model the root causes of a problem as part of rationale.
• ScopeModelling: used to visually show a scope boundary.
• Sequence Diagrams: used to specify and model requirements to show how processes operate and interact with one another, and in what order.
• Stakeholder List, Map, or Personas: used to identify the stakeholders and their characteristics.
• State Modelling: used to specify the different states of a part of the solution throughout a life cycle, in terms of the events that occur.
• Use Cases and Scenarios: used to model the desired behaviour of a solution, by showing user interactions with the solution, to achieve a specific goal or accomplish a particular task.
• User Stories: used to specify requirements as a brief statement about what people do or need to do when using the solution.

7.1.7 Stakeholders

• Any stakeholder: business analysts may choose to perform this task themselves and then separately package and communicate the requirements to stakeholders for their review and approval, or they might choose to invite some or all stakeholders to participate in this task.

7.1.8 Outputs

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

7.2 Verify Requirements

7.2.1 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.

7.2.2 Description

Verifying requirements ensures that the requirements and designs have been defined correctly. Requirements verification constitutes a check by the business analyst and key stakeholders to determine that the requirements and designs are ready for validation, and provides the information needed for further work to be performed.
A high-quality specification is well written and easily understood by its intended audience. A high-quality model follows the formal or informal notation standards and effectively represents reality.
The most important characteristic of quality requirements and designs is fitness for use. They must meet the needs of stakeholders who will use them for a particular purpose. Quality is ultimately determined by stakeholders.

7.2.3 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.

Figure 7.2.1: Verify Requirements Input/Output Diagram

Output

7.2.4 Elements

.1 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.

.2 Verification Activities

Verification activities are typically performed iteratively throughout the requirements analysis process.
Verification activities include:
• checking for compliance with organizational performance standards for business analysis, such as using the right tools and methods,
• checking for correct use of modelling notation, templates, or forms,
• checking for completeness within each model,
• comparing each model against other relevant models, checking for elements that are mentioned in one model but are missing in other models, and verifying that the elements are referenced consistently,
• ensuring the terminology used in expressing the requirement is understandable to stakeholders and consistent with the use of those terms within the organization, and

• adding examples where appropriate for clarification.

.3 Checklists

Checklists are used for quality control when verifying requirements and designs. Checklists may include a standard set of quality elements that business analysts use to verify the requirements, or they may be specifically developed to capture issues of concern. 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.

7.2.5 Guidelines and Tools

• Requirements Life Cycle Management Tools: some tools have functionality to check for issues related to many of the characteristics, such as atomic, unambiguous, and prioritized.

7.2.6 Techniques

• Acceptance and Evaluation Criteria: used to ensure that requirements are stated clearly enough to devise a set of tests that can prove that the requirements have been met.
• ItemTracking: used to ensure that any problems or issues identified during verification are managed and resolved.
• Metrics and Key Performance Indicators (KPIs): used to identify how to evaluate the quality of the requirements.
• Reviews: used to inspect requirements documentation to identify requirements that are not of acceptable quality.

7.2.7 Stakeholders

• All stakeholders: the business analyst, in conjunction with the domain and implementation subject matter experts, has the primary responsibility for determining that this task has been completed. Other stakeholders may discover problematic requirements during requirements communication. Therefore, all stakeholders could be involved in this task.

7.2.8 Outputs

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

7.3 Validate Requirements

7.3.1 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.

7.3.2 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.
Understanding what the desired future state looks like for stakeholders after their needs have been met is valuable to business analysts when validating requirements. The overall goal of implementing the requirements is to achieve the stakeholders’ desired future state. In many cases, stakeholders have different, conflicting needs and expectations that may be exposed through the validation process.

7.3.3 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.

Figure 7.3.1: Validate Requirements Input/Output Diagram

7.3.4 Elements

.1 Identify Assumptions
If an organization is launching an unprecedented product or service, it may be necessary to make assumptions about customer or stakeholder response, as there are no similar previous experiences on which to rely. In other cases, it may be difficult or impossible to prove that a particular problem derives from an identified root cause. 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.

.2 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.
Business analysts define the evaluation criteria that will be used to evaluate how successful the change has been after the solution is implemented. Baseline metrics might be established based on the current state. Target metrics can be developed to reflect the achievement of the business objectives or some other measurement of success.

.3 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.
If a design cannot be validated to support a requirement, there might be a missing or misunderstood requirement, or the design must change.

7.3.5 Guidelines and Tools

• Business Objectives: ensure the requirements deliver the desired business benefits.
• Future State Description: helps to ensure the requirements that are part of the solution scope do help achieve the desired future state.
• Potential Value: can be used as a benchmark against which the value delivered by requirements can be assessed.
• Solution Scope: ensures the requirements that provide benefit are within the scope of the desired solution.

7.3.6 Techniques

• Acceptance and Evaluation Criteria: used to define the quality metrics that must be met to achieve acceptance by a stakeholder.

• Document Analysis: used to identify previously documented business needs in order to validate requirements.
• Financial Analysis: used to define the financial benefits associated with requirements.
• ItemTracking: used to ensure that any problems or issues identified during validation are managed and resolved.
• Metrics and Key Performance Indicators (KPIs): used to select appropriate performance measures for a solution, solution component, or requirement.
• Reviews: used to confirm whether or not the stakeholder agrees that their needs are met.
• Risk Analysis and Management: used to identify possible scenarios that would alter the benefit delivered by a requirement.

7.3.7 Stakeholders

• All stakeholders: the business analyst, in conjunction with the customer, end users, and sponsors, has the primary responsibility for determining whether or not requirements are validated. Other stakeholders may discover problematic requirements during requirements communication. Therefore, virtually all project stakeholders are involved in this task.

7.3.8 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.

7.4 Define Requirements Architecture

7.4.1 Purpose

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

7.4.2 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.
Business analysts use a requirements architecture to:
• understand which models are appropriate for the domain, solution scope, and audience,
• organize requirements into structures relevant to different stakeholders,
• illustrate how requirements and models interact with and relate to each other, and show how the parts fit together into a meaningful whole,
• ensure the requirements work together to achieve the overall objectives, and
• make trade-off decisions about requirements while considering the overall objectives.
Requirements architecture is not intended to demonstrate traceability, but rather to show how elements work in harmony with one another to support the business requirements, and to structure them in various ways to align the viewpoints of different stakeholders. Traceability is often used as the mechanism to represent and manage these relationships (see TraceRequirements(p.79)).
Traceability proves that every requirement links back to an objective and shows how an objective was met. Traceability does not prove the solution is a cohesive whole that will work.

7.4.3 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.

Figure 7.4.1: Define Requirements Architecture Input/Output Diagram

Output

7.4.4 Elements

.1 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.
Requirements viewpoints frequently include standards and guidelines for the:
• model types used for requirements,
• attributes that are included and consistently used in different models,
• model notations that are used, and
• analytical approaches used to identify and maintain relevant relationships among models.

No single viewpoint alone can form an entire architecture. Each viewpoint is stronger for some aspects of the requirements, and weaker for others, as different groups of stakeholders have different concerns. Trying to put too much information into any one viewpoint will make it too complex and degrade its purpose. Examples of viewpoints include:
• Business process models,
• Data models and information,
• User interactions, including use cases and/or user experience,
• Audit and security, and
• Business models.
Each of those viewpoints has different model notations and techniques, and each is important to ensure a cohesive final solution. The solution would likely not be a success if the business analyst only looked at the business process viewpoint.
Similarly, trying to put conventions from many viewpoints in one single viewpoint would make it overwhelming to analyze and contain information irrelevant to particular stakeholder groups.
The actual requirements and designs for a particular solution from a chosen viewpoint are referred to as a view. A collection of views makes up the requirements architecture for a specific solution. Business analysts align, coordinate, and structure requirements into meaningful views for the various stakeholders. This set of coordinated, complementary views provides a basis for assessing the completeness and coherence of the requirements.
In short, the viewpoints tell business analysts what information they should provide for each stakeholder group to address their concerns, while views describe the actual requirements and designs that are produced.

.2 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. Similarly, the framework can be populated with domain-specific information to form a collection of views that is an even more useful template to build architecture from if it is accurate because the information is already populated in it.

.3 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. No requirements should be missing from the set, inconsistent with others, or contradictory to one another. The requirements architecture should take into account any dependencies between requirements that could keep the objectives from being achieved.
Structuring requirements according to different viewpoints helps ensure this

Requirements Analysis and Design Definition Define Requirements Architecture

completeness. Iterations of elicitation, specification, and analysis activities can help identify gaps.

.4 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 analysts examine each relationship to ensure that the relationships satisfy the following quality criteria:
• Defined: there is a relationship and the type of the relationship is described.
• Necessary: the relationship is necessary for understanding the requirements holistically.
• Correct: the elements do have the relationship described.
• Unambiguous: there are no relationships that link elements in two different and conflicting ways.
• Consistent: relationships are described in the same way, using the same set of standard descriptions as defined in the viewpoints.

.5 Business Analysis Information Architecture

The structure of the business analysis information is also an information architecture. This type of architecture is defined as part of the task Plan Business Analysis Information Management (p. 42). The information architecture is a component of the requirements architecture because it describes how all of the business analysis information for a change relates. It defines relationships for types of information such as requirements, designs, types of models, and elicitation results. Understanding this type of information structure helps to ensure that the full set of requirements is complete by verifying the relationships are complete. 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.

7.4.5 Guidelines and Tools

• Architecture Management Software: modelling software can help to manage the volume, complexity, and versions of the relationships within the requirements architecture.
• Legal/Regulatory Information: describes legislative rules or regulations that must be followed. They may impact the requirements architecture or its outputs. Additionally, contractual or standards-based constraints may also need to be considered.

Define Design Options Requirements Analysis and Design Definition

• Methodologies and Frameworks: a predetermined set of models, and relationships between the models, to be used to represent different viewpoints.

7.4.6 Techniques

• Data Modelling: used to describe the requirements structure as it relates to data.
• Functional Decomposition: used to break down an organizational unit, product scope, or other elements into its component parts.
• Interviews: used to define the requirements structure collaboratively.
• Organizational Modelling: used to understand the various organizational units, stakeholders, and their relationships which might help define relevant viewpoints.
• Scope Modelling: used to identify the elements and boundaries of the requirements architecture.
• Workshops: used to define the requirements structure collaboratively.

7.4.7 Stakeholders

• Domain Subject Matter Expert, Implementation Subject Matter Expert, Project Manager, Sponsor, Tester: may assist in defining and confirming the requirements architecture.
• Any stakeholder: may also use the requirements architecture to assess the completeness of the requirements.

7.4.8 Outputs

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

7.5 Define Design Options

7.5.1 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.

7.5.2 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. Design options exist at a lower level than the change strategy, and are tactical rather than strategic. As a solution is developed, tactical trade-offs may need to be made

among design alternatives. Business analysts must assess the effect these trade- offs will have on the delivery of value to stakeholders. As initiatives progress and requirements evolve, design options evolve as well.

7.5.3 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 with the highest priorities might deserve more weight in choosing solution components to best meet them as compared to lower priority requirements.
• Requirements Architecture: the full set of requirements and their relationships is important for defining design options that can address the holistic set of requirements.

Figure 7.5.1: Define Design Options Input/Output Diagram

Guidelines and Tools

Output

Solution Scope

7.5.4 Elements

.1 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.
Solution approaches include:
• Create: solution components are assembled, constructed, or developed by experts as a direct response to a set of requirements. The requirements and the design options have enough detail to make a decision about which solution to construct. This option includes modifying an existing solution.
• Purchase: solution components are selected from a set of offerings that fulfill the requirements. The requirements and design options have enough detail to make a recommendation about which solution to purchase. These offerings are usually products or services owned and maintained by third parties.
• Combination of both: not all design options will fall strictly into one of the categories above. Design options may include a combination of both creation and purchase of components.
In all of these types of approaches, proposed integration of the components is also considered within the design option.

.2 Identify Improvement Opportunities

When proposing design options, a number of opportunities to improve the operation of the business may occur and are compared.
Some common examples of opportunities include:
• Increase Efficiencies: automate or simplify the work people perform by re- engineering or sharing processes, changing responsibilities, or outsourcing. Automation may also increase consistency of behaviour, reducing the likelihood of different stakeholders performing the same function in distinctly different fashions.
• Improve Access to Information: provide greater amounts of information to staff who interface directly or indirectly with customers, thereby reducing the need for specialists.
• Identify Additional Capabilities: highlight capabilities that have the potential to provide future value and can be supported by the solution. These capabilities may not necessarily be of immediate value to the organization (for example, a software application with features the organization anticipates using in the future).

.3 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.
Requirements may be allocated between organizational units, job functions, solution components, or releases of a solution. Requirements allocation typically begins when a solution approach has been determined, and continues until all valid requirements are allocated. Allocation typically continues through design and implementation of a solution.

.4 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.
A design option usually consists of many design components, each described by a design element. Design elements may describe:
• business policies and business rules,
• business processes to be performed and managed,
• people who operate and maintain the solution, including their job functions and responsibilities,
• operational business decisions to be made,
• software applications and application components used in the solution, and
• organizational structures, including interactions between the organization, its customers, and its suppliers.

7.5.5 Guidelines and Tools

• Existing Solutions: existing products or services, often third party, that are considered as a component of a design option.
• Future State Description: identifies the desired state of the enterprise that the design options will be part of, and helps to ensure design options are viable.
• Requirements (traced): define the design options that best fulfill known requirements.
• Solution Scope: defines the boundaries when selecting viable design options.

7.5.6 Techniques

• BenchmarkingandMarketAnalysis: used to identify and analyze existing solutions and market trends.
• Brainstorming: used to help identify improvement opportunities and design options.
• Document Analysis: used to provide information needed to describe design options and design elements.

• Interviews: used to help identify improvement opportunities and design options.
• Lessons Learned: used to help identify improvement opportunities.
• MindMapping: used to identify and explore possible design options.
• Root Cause Analysis: used to understand the underlying cause of the problems being addressed in the change to propose solutions to address them.
• Survey or Questionnaire: used to help identify improvement opportunities and design options.
• VendorAssessment: used to couple the assessment of a third party solution with an assessment of the vendor to ensure that the solution is viable and all parties will be able to develop and maintain a healthy working relationship.
• Workshops: used to help identify improvement opportunities and design options.

7.5.7 Stakeholders

• Domain Subject Matter Expert: provides the expertise within the business to provide input and feedback when evaluating solution alternatives, particularly for the potential benefits of a solution.
• Implementation Subject Matter Expert: use their expertise in terms of the design options being considered to provide needed input about the constraints of a solution and its costs.
• Operational Support: can help evaluate the difficulty and costs of integrating proposed solutions with existing processes and systems.
• Project Manager: plans and manages the solution definition process, including the solution scope and any risks associated with the proposed solutions.
• Supplier: provides information on the functionality associated with a particular design option.

7.5.8 Outputs

• Design Options: describe various ways to satisfy one or more needs in a context. They may include solution approach, potential improvement opportunities provided by the option, and the components that define the option.

7.6 Analyze Potential Value and Recommend Solution

7.6.1 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.

7.6.2 Description

Analyze Potential Value and Recommend Solution describes how to estimate and model the potential value delivered by a set of requirements, designs, or design options. Potential value is analyzed many times over the course of a change. This analysis may be a planned event, or it may be triggered by a modification to the context or scope of the change. The analysis of potential value includes consideration that there is uncertainty in the estimates. Value can be described in terms of finance, reputation, or even impact on the marketplace. Any change may include a mix of increases and decreases in value.
Design options are evaluated by comparing the potential value of each option to the other options. Each option has a mix of advantages and disadvantages to consider. Depending on the reasons for the change, there may be no best option to recommend, or there may be a clear best choice. In some cases this means the best option may be to begin work against more than one design option, perhaps to develop proofs of concept, and then measure the performance of each. In other instances, all proposed designs may be rejected and more analysis may be needed to define a suitable design. It is also possible that the best recommendation is to do nothing.

7.6.3 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.

Figure 7.6.1: Analyze Potential Value and Recommend Solution Input/Output Diagram

7.6.4 Elements

.1 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. Benefits are determined based on the analysis of the benefit that stakeholders desire and the benefit that is possible to attain. Expected benefits can be calculated at the level of a requirement or set of requirements by considering how much of an overall business objective the set of requirements contribute to if fulfilled. 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.

.2 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.
Expected costs can include:

• timeline,
• effort,
• operating costs,
• purchase and/or implementation costs,
• maintenance costs,
• physical resources,
• information resources, and
• human resources.

Expected costs for a design option consider the cumulative costs of the design components.
Business analysts also consider opportunity cost when estimating the expected cost of a change_. _Opportunity costs are alternative results that might have been achieved if the resources, time, and funds devoted to one design option had been allocated to another design option. The opportunity cost of any design option is equal to the value of the best alternative not selected.

.3 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).
Business analysts consider potential value from the points of view of stakeholders. Value to the enterprise is almost always more heavily weighted than value for any individual stakeholder groups. There might be increases in value for one set of stakeholders and decreases in value for another set, but an overall positive increase in value for the enterprise as a whole justifies proceeding with the change.
Potential value is uncertain value. There are always events or conditions that could increase or decrease the actual value if they occur. Many changes are proposed in terms of intangible or uncertain benefits, while costs are described as tangible, absolute, and might grow. When benefits are described as intangible and costs expressed as tangible, it may be difficult for decision makers to compare their options. Business analysts define a complete estimate of the purpose-driven and monetary effects of a proposed change by considering the tangible and intangible costs alongside the tangible and intangible benefits. The estimate of costs and benefits must take into account the degree of uncertainty pertaining at the time the estimates are made.

.4 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. The

reasons for re-evaluation include better understanding of the cost to implement each component and to determine which allocations have the best cost-to- benefit ratio.
As costs and effort are understood for each solution component, business analysts assess each design option to ensure that it represents the most effective trade-offs. There are several factors to take into consideration:
• Available Resources: there may be limitations regarding the amount of requirements that can be implemented based on the allocated resources. In some instances, a business case can be developed to justify additional investment.
• Constraints on the Solution: regulatory requirements or business decisions may require that certain requirements be handled manually or automatically, or that certain requirements be prioritized above all others.
• Dependencies between Requirements: some capabilities may in and of themselves provide limited value to the organization, but need to be delivered in order to support other high-value requirements.
Other considerations may include relationships with proposed vendors, dependencies on other initiatives, corporate culture, and sufficient cash flow for investment.
Business analysts recommend the option or options deemed to be the most valuable solution to address the need. It is possible that none of the design options are worthwhile and the best recommendation is to do nothing.

7.6.5 Guidelines and Tools

• Business Objectives: used to calculate the expected benefit.
• Current State Description: provides the context within which the work needs to be completed. It can be used to identify and help quantify the value to be delivered from a potential solution.
• Future State Description: describes the desired future state that the solution will be part of in order to ensure the design options are appropriate.
• Risk Analysis Results: the potential value of design options includes an assessment of the level of risk associated with the design options or initiative.
• Solution Scope: defines the scope of the solution that is being delivered so that a relevant evaluation can be made that is within the scope boundaries.

7.6.6 Techniques

• Acceptance and Evaluation Criteria: used to express requirements in the form of acceptance criteria to make them most useful when assessing proposed solutions and determining whether a solution meets the defined business needs.
• Backlog Management: used to sequence the potential value.

Requirements Analysis and Design Definition Analyze Potential Value and Recommend Solution

• Brainstorming: used to identify potential benefits of the requirements in a collaborative manner.
• Business Cases: used to assess recommendations against business goals and objectives.
• Business Model Canvas: used as a tool to help understand strategy and initiatives.
• Decision Analysis: used to support the assessment and ranking of design options.
• Estimation: used to forecast the costs and efforts of meeting the requirements as a step towards estimating their value.
• Financial Analysis: used to evaluate the financial return of different options and choose the best possible return on investment.
• Focus Groups: used to get stakeholder input on which design options best meet the requirements, and to evaluate a targeted, small group of stakeholders’ value expectations.
• Interviews: used to get stakeholder input on which design options best meet the requirements, and to evaluate individual stakeholders’ value expectations.
• Metrics and Key Performance Indicators (KPIs): used to create and evaluate the measurements used in defining value.
• Risk Analysis and Management: used to identify and manage the risks that could affect the potential value of the requirements.
• Survey or Questionnaire: used to get stakeholder input on which design options best meet the requirements, and to identify stakeholders’ value expectations.
• SWOT Analysis: used to identify areas of strength and weakness that will impact the value of the solutions.
• Workshops: used to get stakeholder input on which design options best meet the requirements, and to evaluate stakeholders’ value expectations.

7.6.7 Stakeholders

• Customer: represents the market segments affected by the requirements and solutions, and will be involved in analyzing the benefit of those requirements and costs of the design options.
• Domain Subject Matter Expert: may be called upon for their domain knowledge to assist in analyzing potential value and benefits, particularly for those requirements where they are harder to identify.
• End User: provides an insight into the potential value of the change.
• Implementation Subject Matter Expert: may be called upon for their expertise in implementing the design options in order to identify potential costs and risks.

Analyze Potential Value and Recommend Solution Requirements Analysis and Design Definition

• Project Manager: manages the selection process so that when effecting the change they are aware of potential impacts on those supporting the change, including the risks associated with the change.
• Regulator: may be involved in risk evaluation concerning outside regulatory bodies or place constraints on the potential benefits.
• Sponsor: approves the expenditure of resources to purchase or develop a solution and approve the final recommendation. The sponsor will want to be kept informed of any changes in potential value or risk, as well as the resulting opportunity cost, as he/she may prefer another course of action.

7.6.8 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.