Requirements Analysis and Design
Definition
Intro
(5) Define Design Options
Core Concept
(1) Specify and Model Requirements
(3) Validate Requirements
Output
(4) Define Requirements Architecture
Input
(6) Analyse Potential Value and Recommend Solution
(2) Verify Requirements
One person’s designs may be another
person’s requirements
May be high-level or very detailed depending on who views the information
Tasks that BA performs to structure and organise requirements
Solution: Define solution options and recommend the one that is most likely to address the need and has the most value
Stakeholder: Tailor the reqs and des so that they are understandable and usable by each stakeholder group
Need: Analyse the needs in order to recommend a solution that meets the needs
Value: Analyse and quantify the potential value of the solution options
Change: Transform elicitation results into reqs and des in order to define the change
Context: Model and describe the context in formats that are understandable and usable by all stakeholders
Elicitation Results (any state)
Potential Value
Information Management Approach
Solution Scope
Requirements (any state)
Change Strategy
Requirements (validated)
Requirements Architecture
Requirements (verified)
Design Options
Requirements (specified and modelled)
Solution Recommendation
Input: Elicitation Results (any state)
Output: Requirements (specified and modelled)
Description
Elements
Purpose: To analyse, synthesise, and refine elicitation results into reqs and des
Input: Requirements (specified and modelled)
Output: Requirements (verified)
Description: BA makes sure that the reqs and des have been defined correctly. High quality spec = well written and easily understood. High quality model = follows formal and informal notation standards + represent reality. High quality reqs and des = fitness for use
Elements
Purpose: Ensure that reqs and des specs and models meet quality standards and are usable for the purpose they serve
Input: Requirements (specified and modelled)
Output: Requirements (validated)
Description: Ongoing process to make sure stakeholders, solutions and transition reqs align to the business reqs and that the design satisfy the reqs
Elements
Purpose: Ensure that all reqs and des align to the business requirements and support the delivery of needed value
Input
Output
Description: RA -> the structure of all the req of a change. It fits the individual models and specs 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.
Purpose: Ensure that the requirements collectively support one another to fully achieve the objectives
Elements
Input
Output
Description: 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
Elements
Purpose: 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
Output: Solution Recommendation
Description: describes how to estimate and model the potential value delivered by a set of requirements, designs, or design options. It is also possible that the best reco is to do nothing.
Elements
Purpose: to estimate the potential value for each design option and to establish which one is most
appropriate to meet the enterprise’s requirements
When the focus of the specifying and modelling activity is on a solution, the outputs are referred to as designs
BA analyse 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
Analyse Requirements
Represent Requirements and Attributes
Model Requirements
Implement the Appropriate Levels of Abstraction
Visual and descriptive way to convey information to a specific audience
Modelling format
Matrices (for complex but uniform in structure)
Diagrams (visual such as hierarchies)
Can include
Data and information (Data Dictionary, Data Flow Diagrams, Data Modelling, Glossary, State Modelling, and Interface Analysis)
Capability (Business Capability Analysis, Functional Decomposition, and Prototyping)
Activity flow (Process Modelling, Use Cases and Scenarios, User Stories)
Rationale (Decision Modelling, Scope Modelling, Business Model Canvas, Root Cause Analysis, Business Rules Analysis)
People and roles (Organisational Modelling, Roles and Permission Matrix, Stakeholder List, Map or Personas)
Business analysis information is decomposed into components to further examine for:
Missing components
Unnecessary components
Anything that should stay the same to meet the business need
Any constraints or assumptions
Anything that must change to meet the business need
Should exhibit the characteristics of requirements and designs quality
Based on
Type of requirement
Audience for the requirement
Verification Activities
Checklists
Characteristics of Reqs and Des Quality
Concise
Feasible
Consistent
Unambiguous
Complete
Testable
Atomic
Prioritised
Understandable
Checking for completeness within each model
Comparing each model against other relevant model, checking for elements that are mentioned in one model but are missing in other models, verifying that the elements are referenced consistently
Checking for correct use of modelling notation, 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 organisation
Checking for compliance with organizational performance standards
. 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
Used for quality control when verifying requirements and designs
Define Measurable Evaluation Criteria
Evaluate Alignment with Solution Scope
Identify Assumptions
Information Management Approach
Requirements (any state)
Solution Scope
Requirements Architecture
Template Architecture
Completeness
Requirements Viewpoints and Views
Relate and Verify Requirements Relationships
Business Analysis Information Architecture
Standard and guidelines for
Attributes
Model notations
Model types
Analytical approaches
Example of viewpoints include
Audit and security
User interactions
Data models and information
Business models
Business process models
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.
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.
Correct
Unambiguous
Necessary
Consistent
Defined
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
The structure of the business analysis information is also an information architecture.
Identify Improvement Opportunities
Requirements Allocation
Define Solution Approach
Describe Design Options
Change Strategy
Requirements Architecture
Requirements (validated, prioritized)
Design Options
Combination of both
Purchase
Create
Improve access to information
Identify additional capabilities
Increase efficiencies
Requirements allocation is the process of assigning requirements to solution components and releases to best achieve the objectives.
Design elements
Business policies and business rules
Business processes to be performed and managed
People who operate and maintain the solution (job functions and responsibilities)
Operational business decisions to be made
Software applications and application components used in the solution
Organisational structures, including interactions between the organisation, its customers and its suppliers
Potential value
Design options
Expected Costs
Determine Value
Expected Benefits
Assess Design Options and Recommend Solution
Constraints on the solution
Dependencies between requirements
Available resources