Please enable JavaScript.
Coggle requires JavaScript to display documents.
7.Requirements Analysis and Design Definition - Coggle Diagram
7.Requirements Analysis and Design Definition
Specify and Model Requirements
Inputs:
Elicitation Results (any state)
Outputs:
Requirements (specified and modelled)
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'.
Elements
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 Verify Requirements).
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.
Model Requirements
Business analysts choose from one or more of the following modelling formats:
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.
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.
Rationale:
models represent the ‘why’ of a change.
Activity Flow:
models represent a sequence of actions, events, or a course that may be taken.
Capability:
models focus on features or functions of an enterprise or a solution.
Data and Information:
models represent the characteristics and the exchange of information within an enterprise or a solution.
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.
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.
Purpose:
The purpose of Specify and Model Requirements is to analyze, synthesize, and refine elicitation results into requirements and designs.
Analyze Potential Value and Recommend Solution
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.
Outputs:
Solution Recommendation
Inputs:
Potential Value
Design Options
Elements
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.
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).
Expected Benefits
Expected benefits describe the positive value that a solution is intended to deliver to stakeholders.
Assess Design Options and Recommend Solution
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
Constraints on the Solution
Dependencies between Requirements
Other considerations may include relationships with proposed vendors, dependencies on other initiatives, corporate culture, and sufficient cash flow for investment.
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.
Verify Requirements
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.
Inputs:
Requirements (specified and modelled)
Outputs:
Requirements (verified)
Elements
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.
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.
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.
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.
Define Requirements Architecture
Requirements architecture is the structure of all of the requirements of a change.
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.
Outputs:
Requirements Architecture
: the requirements and the interrelationships among them, as well as any contextual information that is recorded.
Inputs:
Information Management Approach
Requirements (any state)
Solution Scope
Elements
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
Business analysts examine and analyze the requirements to define the relationships between them.
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.
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.
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.
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.
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.
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.
Purpose:
The purpose of Define Requirements Architecture is to ensure that the requirements collectively support one another to fully achieve the objectives.
Validate Requirements
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.
Outputs:
Requirements (validated)
Inputs:
Requirements (specified and modelled)
Elements
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.
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.
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.
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.
Define Solution Options
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.
Outputs:
Design Options
Inputs:
Change Strategy
Requirements (validated, prioritized)
Requirements Architecture
Elements
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
Improve Access to Information
Identify Additional Capabilities
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.
Define Solution Approaches
The solution approach describes whether solution components will be created or purchased, or some combination of both.
Solution approaches include:
Create
Purchase
Combination of both
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.
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.
Outputs
Requirements (specified and modelled)
Requirements (verified)
Requirements (validated)
Requirements Architecture
Design Options
Solution Recommendation
Inputs
Elicitation Results (any state)
Requirements (specified and modelled)
Information Management Approach
Requirements (any state
Solution Scope
Change Strategy
Requirements (validated, prioritized)
Requirements Architecture
Potential Value
Design Options