Please enable JavaScript.
Coggle requires JavaScript to display documents.
Requirement Analysis and Design Definition - Coggle Diagram
Requirement Analysis and Design Definition
Input
Requirements (any state)
Information management approach
Elicitation Results (any state)
Potential Value
Solution Scope
Change Strategy
Output
Requirements (specified and modelled)
Requirements (verified)
Requirements (validated)
Requirements Architecture
Design Options
Solution Recommendation
Specify and Model Requirements
Purpose
: to analyze, synthesize, and refine elicitation results into requirements and designs.
Input: Elicitation Results (any state)
Specify and Model requirements describes the practices for analyzing elicitation results and creating representations of those results.
Output
: Requirements (specified and modelled)
Elements
Model Requirements
:
Model is a descriptive and visual way to convey information to a specific audience.
Modelling formats:
:diamonds: Matrices: modelling a requirement that have a complex but uniform structure, which can be broken down into elements that apply to every entry in the table.
:diamonds: Diagrams: is a visual, often pictorial, representation of a requirement. Especially useful to depict complexity in a way that would be difficult to do with words.
Model categories:
:checkered_flag: People and Roles: represent organizations, people, roles and their relationships.
:checkered_flag: Rationale: represent the WHY of a change such as Decision Modelling, Business Model Canvas,..etc..
:checkered_flag: Activity Flow: represent a sequence of actions, events or a course that may be taken.
:checkered_flag: Capability: focus on features or functions of an enterprise or a solution.
:checkered_flag: Data and Information: represent the characteristics and the exchange of information within an enterprise or a solution.
Analyze Requirements
:
BA information is decomposed into components to further examine.
Represent Requirements and Attributes
: Requirements should be explicitly represented and should include enough detail such that they exhibit the characteristics of requirements and designs quality.
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.
Verify Requirements
Purpose
: 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)
Verifying requirements ensure that the requirements and designs have been defined correctly, 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. It follow 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.
Output
: Requirements (verified): a set of requirements or designs that is of sufficient quality to be used as a basis for further work.
Elements
Characteristics of Requirements and Designs Quality
:
Atomic
: self-contained and capable of being understood independently.
Complete
: enough to guide further work and at the appropriate level of detail for work to continue.
Consistent
: aligned with the business needs and not conflicting with other requirements.
Concise
: contains no extraneous and unnecessary content.
Feasible
: reasonable and possible.
Unambiguous
: must be clearly stated.
Testable
: able to verify.
Prioritized
: ranked in terms of importance and value.
Understandable
: represented using common terminology of the audience.
Verification Activities
: performed iteratively throughout, includes:
Checking for compliance with org standards, such as right tools and methods.
Checking for correct use of modelling notation, templates, forms.
Checking for completeness within each model.
Comparing each model against relevant models.
Ensuring terminology used is understandable and consistent.
Adding examples where appropriate for clarification.
Checklist
:
Used for quality control.
Validate Requirements
Purpose
: to ensure that all requirements and designs align to the business requirements and support the delivery of needed value.
Inputs
: Requirements (specified and modelled)
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)
Elements
Identify Assumptions:
Need to identify and define assumptions so that associated risks can be managed.
Define Measurable Evaluation Criteria
BA defines 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.
Evaluate Alignment with Solution Scope
:
A requirement can be of benefit to a stakeholder and still not be a desirable part of a solution.
Define Requirements Architecture
Purpose
: to ensure that the requirements collectively support one another to fully achieve the objectives.
Requirement 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.
Input
:
Information Management Approach
Requirements (any state)
Solution Scope
Output
: Requirement Architecture: the requirements and the interrelationships among them, as well as any contextual information that is recorded.
Elements
Requirements Viewpoints and Views
Viewpoint is a set of conventions that define how requirements will be represented or organized or related.
Viewpoints provide templates for addressing the concerns of particular stakeholder groups.
View is the actual requirements and designs for a particular solution from a chosen viewpoint.
A collection of views makes up the requirements architecture for a specific solution.
Template Architectures
:
An architectural framework is a collection of viewpoints that is standard across an industry, sector or organization.
Completeness
: Structuring requirements according to different viewpoints help ensure this completeness.
Relate and Verify Requirements Relationships
:
BA 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 requirement 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.
Business Analysis Information Architecture
: understanding BA information architecture helps to ensure that the full set of requirements is complete.
Define Design Options
Purpose
: 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.
Input
:
Change Strategy
Requirements (validated, prioritized): only validated requirements are considered in design options.
Requirement Architecture
Output:
Design Options: describe various ways to satisfy one or more needs in a context.
Elements
Define Solution Approaches
:
Solution approach describes whether solution components will be created or purchased or combination of both.
Identify Improvement Opportunities
:
Increase Efficiencies: automate or simplify the work people perform.
Improve Access to Information: provide greater amounts of information to staff.
Identify Additional Capabilities: highlight capabilities that have the potential to provide future value and can be supported by the solution.
Requirements Allocation
:
Is the process of assigning requirements to solution components and releases to best achieve the objectives.
The objective of allocation is to maximize that value.
Describe Design Options
:
Solution performance measures are defined for each design option.
Analyze Potential Value and Recommend Solution
Purpose
: to estimate the potential value for each design option and to establish which one is most appropriate to meet the enterprise's requirements.
Input
:
Potential Value
Design Options
Output
: Solution recommendation
Elements
Expected Benefits
:
The positive value that a solution is intended to deliver.
Benefits are often realized over a period of time.
Expected Costs
Any potential negative value associated with a solution, include acquire and maintain cost.
Determine Value
:
The potential value of a solution to a stakeholder is based on the benefits delivered by that solution and the associated costs, can be negative or positive.
Assess Design Options and Recommend Solution
:
There are several factors to take into consideration:
Available resources
Constraints on the solution
Dependencies between requirements