Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chương VII: Requirement Analysis and Design Definition - Coggle Diagram
Chương VII: Requirement Analysis and Design Definition
Define requirements achitecture
Element
Requirements viewpoints and views
Viewpoints
define how requirements are represented, how be organized and how they be related
includes standards and guideline for:
model types used
attributes included
model notations used
identify maintain relevant relationships among models
Examples
business process models
data models and information
User interactions, including use cases and/or user experience
Audit and security
Business models
Views
The actual requirements and designs for a particular solution from a chosen
viewpoint are referred to as a view
In short
Viewpoints -> Views -> Requirement architecture
Template architectures
BA can treat framework as predefined templates
Framework populated with domain-specific information is very useful
Architectural template is a collection of viewpoints that standard across an industry, sector or organization
ví dụ mỗi ngành có thể có những khung tiêu chuẩn khác nhau
Completeness
No requirement should be missing, inconsistent with others or contradictory to one another
The requirement architecture should take into account the dependencies between requirements
The entire of requirements should be cohesive and tell a full story
Iteration of elicitation, specification and analysis activities can help find gap
Relate and verify requirement relationship
Requirements may be related to each other in several ways when defining the
requirements architecture. BA ensure the relationships satisfy the following quality criteria:
Defined
Necessary
Correct
Unambiguous
Consistent
Business analysis information architecture
The structure of the business analysis information is also an information
architecture
It defines the relationship for types of information such as requirements, designs, types of models, elicitation result
It is useful to define business information architecture before setting up tool/infrastructure
Guideline and tool
Legal/Regulatory information
Methodologies or Framework
Architecture management software
Input
Information management approach
how information be stored and accessed
Requirements (any state)
Solution scope
ensure that requirement align to the boundaries of solution scope
Technique
Workshops
Functional decomposition
Interviews
Scope modelling
Data modelling
Organizational modelling
Description
Is structure of all requirements to ensure
support the overall business objectives
produce a useful outcome for stakeholders
BA uses requirement architecture to
understand appropriate model
organize relevant structures to different stakholders
illustrate how the requirement interact with or relate to others
ensure requirements work for the overall business objectives
make trade-off decision
Stakeholder
Domain SMEs, Implementation SMEs, PM, Sponsor, Tester: define and confirm
Any stakeholder: assess the completeness
Purpose
ensure that the requirements collectively support other requirement to achieve the business objectives
Output
Requirement architecture
Analyze potential value and Recommend solution
Element
Expected costs
potential negative value associated with a solution
includes the cost acquire the solution, negative impact it may have on the stakeholders and the cost maintain it overtime
timeline, effort
operation/purchase/implementation/maintenance costs
physical/human/information resources
BA should consider the opportunity cost. It equals to the value of the best alternative solution not selected
Determine value
Based on the benefits and costs. Value may be positive (if benefits > costs) or negative (if benefits < costs)
Value to the whole enterprise is most important
must consider the uncertainty
Expected benefits
Expected benefits = positive value
Positive value may include benefits, reduced risk, compliance with business policies and regulation, an improved user experience, or any other positive outcome
Benefits based on value stakeholders desire + possible to attain
Expected benefits can be calculated for each or a set of requirements.
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.
Assess design options and recommend solution
Constraints on the solutions
Dependencies between requirements
Available resources
Others: Relationships with vendors, dependencies on other initiatives, corporate culture, investment
Guideline and tool
Risk analysis result
Future state description
Solution scope
Current state description
Business objectives
Input
Potential value
Design options
Technique
Metrics and Key performance indicator (KPIs)
Risk analysis and management
Decision analysis
SWOT analysis
Brainstorming
Survey or Questionaire
Workshops
Interviews
Acceptance and Evaluation criteria
Backlog management
Business model canvas
Business case
Financial analysis
Estimation
Focus group
Description
This task describe how to estimate and model the potential value
Potential value is analyzed many times over the course of a change.
may be planned
or triggered by a modification to the
context or scope of the change
Estimation may has uncertainty
Design options are compared based on the potential value
may not have the best option
may be to begin work against more than one design option or proof of concept
all proposed designs may be rejected and more analysis may be needed
It is also possible that the best
recommendation is to do nothing.
Value may in term of financial, reputation or impact on market place.
Any change may include a mix of increases and decreases in value.
Stakeholder
Customer
End user
Implementation SMEs
Project manager
Domain SMEs
Regulator
Sponsor
Purpose
to estimate the potential value of each design option and to establish the most appropriate to meet the enterprise's requirements
Output
Solution recommendation
Define design options
Element
Identify improvement opportunities
Improve access to information
for employees
Identify additional capabilities
capabilities in future
Increase efficiencies
Automation/Reengineering/Outsource
Requirements allocation
Requirements may be allocated between organizational units, job functions,
solution components, or releases of a solution
begins when a solution approach has been determined, continue until all valid requirements are allocated
Allocation is supported by assessing the trade-offs between alternatives in order to maximize benefits
and minimize costs
Allocation typically continues through design
and implementation of a solution
Define solution approaches
Purchase: mua sẵn
Combination of both: kết hợp 2 phương án trên
Create: tự phát triển
Describe design options
A design option usually consists of many design components, each described by a
design element
Design element 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
organizational structures, including interactions between the organization,
its customers, and its suppliers
Guideline and tool
Solution scope
Requirements (traced)
Existing solution
Future state description
Input
Requirements (validated and prioritized): requirements with high priority will deserve more weight in choosing solution components
Requirement architecture
Change strategy
Technique
Brainstorming
Mind mapping
Survey or questionaire
Root cause analysis
Interviews
Workshops
Document analysis
Vendor assessment
Benchmarking and market analysis
Lesson learned
Description
Design option exists in tactical level, lower than change strategy (ở mức chiến thuật, không phải chiến lược. Chiến lược mang tính dài hạn hơn)
Trade-off may need to be made to develop solution. BA must assess the effect of these trade-off on delivering value to stakeholders
Iterative progress, requirements evolve, designs may evolve too
Output
Design options
various way to satisfy one or more needs in a context
includes: solution approach, potential improvement opportunities, components of solution
Purpose
define opportunities to improve business
allocate the requirements across the solution components
define solution approach
represent design options that achieve the desired future state
Stakeholder
Operational Support
assess the difficulty and cost of integrating the solution into the existing process
PM
plan and manage solution scope, risk
Implementation SMEs
evaluate for the constraints of solution and its cost
Supplier
provides information functionality associated with the solution
Domain SMEs
evaluate for the potential benefits of solutions
Specify and model requirements
Element
Model requirement
convey information to a specific audience in order to support analysis, communication and understanding
may be used to confirm knowledge, identify information gaps, identify duplicate information
Format
Matrices
suitable for: Requirements complex but in a uniform structure; can break down into elements in a table
Examples: data dictionaries, requirement traceability, gap analysis
can be used for prioritizing requirements or recording requirement attributes or metadata
Diagrams
visual, pictorial , representation of requirement or a set of requirement
suitable for: Requirements complex and difficult to do with words
Examples: boundaries of business domain, categorize items, data and their relationship
Categories
Activity Flow
represent a sequence of actions, events, or a course
that may be taken
Techniques
Process modelling, Use Cases and scenarios, User Stories
Capability
focus on features or functions of an enterprise or a
solution
Techniques
Functional decomposition, Capability analysis, Prototyping
Rationale
represent 'why' of a change
Techniques
Root cause analysis, decision modelling, scope modelling, business model canvas, business rule analysis
Data and information
represent the characteristics and the
exchange of information within an enterprise or a solution
Techniques
Data modelling, Data dictionary, Data flow diagrams, State analysis, Glossary, Interface analyis
People and roles
represent organizations, groups of people,
roles, and their relationships within an enterprise and to a solution
Techniques
Organization modelling, Roles and permission matrix, Stakeholder list, map and personas
Analyze requirements
Information is decomposed into components to further examine:
anything must change to meet the business need
anything should stay to meet the business need
missing components
unnecessary components
any constraints or assumptions may impact the components
Level of decomposition, level of detail varies depend on:
Knowledge and misunderstanding of stakeholders
Stakeholders càng hiểu rõ và có kiến thức rồi thì không cần detail quá và ngược lại
Organization standards
một số doanh nghiệp có tiêu chuẩn riêng
contractual or regulatory obligations
industry
Analysis provides a basis for discussion to reach a conclusion about solution
options
Represent Requirements and Attributes
Various
attributes can be specified for each requirement or set of requirements
selected when planning for information management
As part of specifying requirements, they can also be categorized
Business requirements
Stakeholders requirements
Solution requirements
Functional
Non-functional
Requirements should be explicitly represented and include enough detail such as characteristics of
requirements and designs quality (detail in verify requirement task)
Categorizing requirements can help ensure the requirements are fully
understood, a set of any type is complete, appropriate traceability
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
It may be appropriate to produce
different viewpoints of requirements to represent the same need to different stakeholders
The business analysis approach may also influence the level of abstraction and
choice of models used when defining requirements
Guideline and tool
Modelling tools
Requirement architecture
Requirement life cycle management tool
Solution scope
Modelling Notations/Standards
Input
Elicitation result (any state)
Elicitation and modelling may occur sequentially, iteratively, or concurrently
Technique
Functional decomposition
Acceptance and evaluation criteria
Prototyping
Business model canvas
Sequence diagrams
Business capability analysis
Root cause analysis
Business rules analysis
User stories
Decision modelling
Use cases and scenarios
Interface analysis
Concept modelling
Non-functional requirement analysis
Role and permission matrix
Stakeholder list,map,personas
Organizational modelling
Data dictionary
Scope modelling
Data flow analysis
State analysis
Glossary
Process modelling
Data modelling
Description
Describes the task of analyzing elicitation results and create representation of those.
If specify and model activity focus on understanding the needs, then the output are requirements
If specify and model activity focus on the solution, then the output are designs
In some IT company, the word 'design' is used for technical output. All business output are called 'requirements'
Also includes capturing information for attributes or metadata for the requirement
Stakeholders
any stakeholders
Purpose
analyze, synthesize, refine the elicitation results into requirements and designs
Output
requirements (specified and modelled)
any combination of requirements
and/or designs in the form of text, matrices, and diagrams
Verify requirements
Element
Verification activities
Checking for compliance with organizational performance standards
Checking for the correct use of modelling notations, templates or forms
Ensuring the terminology used in expressing the requirement is understandable to stakeholders and consistent with the use of those terms
within the organization
Checking for the completeness of each model
Compare with other model and verifying that the elements are referenced consistently
Add examples where appropriate
Checklists
may include
a standard set of quality elements
specifically developed to capture
issues of concern
purposes
ensure that items determined to
be important are included in the final requirements deliverables
steps required for the verification process are followed
Characteristics of Requirements and Designs Quality
Complete: enough to guide for further work
Consistent: no conflict with other requirements and designs
Understandable: represented using common terminology of the audience
Concise: no extraneous or unnecessary contents
Prioritized
Feasible: reasonable and possible within the agreed-upon risk, schedule,
and budget
Unambiguous: clear enough
Testable: able to verify that the requirement or design has been fulfilled
Atomic: be understood independently of other requirements and designs
Technique
Items tracking
Metrics and Key performance Indicator (KPIs)
Acceptance and Evaluation Criteria
Reviews
Input
Requirements (specified and modelled)
Output
Requirements (verified)
Description
Verifying requirements ensures that the requirements and designs have been
defined correctly
determine that
the requirements and designs are
ready for validation
provides the information needed for further work to be
performed
high-quality specification is well written and easily understood by its intended
audience
high-quality model follows the formal or informal notation standards
and effectively represents reality
most important characteristic
fitness for use (Quality is ultimately determined by stakeholders)
Stakeholder
All stakeholders
BA, domain SMEs, implementation SMEs: primary responsibility
others: define problematic while communication
Purpose
ensure that requirements and designs
specifications and models
meet quality standards
usable for the purpose
they serve
Guideline and tool
Requirement life cycle management tool
Validate requirements
Element
Identify assumptions
When?
launching an unprecedented product or service
difficult or impossible to prove that a particular problem derives from an identified
root cause
How?
stakeholders may assume that certain benefits will result from
the implementation of a requirement
For what?
associated risks can be managed
Define measurable evaluation criteria
For what?
to evaluate how
successful the change has been after the solution is implemented
How?
Baseline metrics
Based on current state
Target metrics
reflect the achievement of the business objectives or some other
measurement of success
Evaluate alignment with Solution scope
When requirement not align
Re-evaluate the future state
Remove requirement
Change solution scope
When design not support any requirement
Missing or misunderstood requirement
Change design
A requirement does not support stakeholders' benefit -> should eliminate
Guideline and tool
Future state description
Potential value
Business Objectives
Solution scope
Input
Requirements (specified and modelled)
any types of requirements and designs
validation requirements can begin before requirements can be completely verified but can not complete before requirements can be completely verified
Technique
Metrics and Key performance indicators (KPIs)
Reviews
Financial analysis
Item tracking
Document analysis
Risk analysis and management
Acceptance and Evaluation Criteria
Description
is an ongoing process to ensure
stakeholder, solution and transition requirements are align to business requirements
design satisfy the requirements
Achieve stakeholders' desired future state is the overall goal of implementing requirements
The conflict and difference between stakeholders can be exposed through this validation
Stakeholder
All stakeholders
BA, customers, end users, sponsor: primary responsibility
other stakeholders may discover problematic requirements through communication
Purpose
ensure that requirements and designs align to the business requirements and the delivery of needed value
Output
Requirements (validated)