Please enable JavaScript.
Coggle requires JavaScript to display documents.
Requirements Analysis and Design Definition - Coggle Diagram
Requirements Analysis and Design Definition
Overview: Scope of requirements analysis & design definition
Validate requirements
Define Requirements Architecture
Verify requirements
Define Solution Options
Specify and Model Requirements
Analyze Potential Value and Recommend Solution
1) Specify and Model Requirements:
The overall goal of this activity is to transform the elicitation results into requirements and designs.
1.1) Modeling
Definition
: A model is a descriptive and visual way to convey information to a specific audience
Modelling formats
Matrices
: for complex but uniform structures
Diagrams
: for visual representation of requirements
1.2) Analysis
Definition
: Analysis provides a basis for discussion to reach a conclusion about solution options.
Modelled information is decomposed into components to:
Identify what needs to be changed to meet the needs
Identify what needs to stay untouched
Find missing elements
Find unnecessary elements
Identify assumptions or constraints
1.3) Presentation
Definition
: When finalising requirements, BAs should focus on all the aspects and characteristics of them.
Take into account:
Characteristics of requirements (meta-data)
Clarification of requirements
1.4) Abstraction
Definition
: The level of abstraction of a requirement varies based on the type of requirement and its intended audience.
Key output:
Requirements (specified and modelled): any combination of requirements and/or designs in the form of text, matrices, and diagrams
1.5) Techniques
Process modelling
Process modelling is a standardized graphical model used to show how work is carried out and is a foundation for process analysis.
Externals
(square/ rectangle icon)
a person, organization, automated system, or any device capable of producing or receiving data
Data store
(rectangle with boxed sides icon)
a collection of data where data may be read repeatedly and where it can be stored for future use.
Process
(circle/ round conner square icon)
a manual or automated activity performed for a business reason
Data flow
(arrow icon)
a collection of data where data may be read repeatedly and where it can be stored for future use.
Scope Modelling
Scope models define the nature of one or more limits or boundaries and place elements inside or outside those boundaries.
Prototypes
is a tool used to elicit and validate stakeholder needs through an iterative process that creates a model or design of requirements. It is also used to optimise user experience, to evaluate design options, and as a basis for development of the
final business solution.
Examples of prototypes
: Proof of concept/ Wireframes
Type of Prototypes
Evolutionary (functional)
Produces a workable solution
Forms a part of the final shipment
Extends initial requirements into a functional solution
Throw-away:
Serves a single purpose (e.g. test a hypothesis)
Never becomes or is intended to become a functional product
Is composed with simple tools
Functional Decomposition
Functional decomposition helps manage complexity and reduce uncertainty by breaking down processes, systems, functional areas, or deliverables into their simpler constituent parts and allowing each part to be analysed independently
Elements
Define subjects
Define objectives
Define appropriate level
Define representation method
Type of Functional Decomposition modelling
Dynamic
- “what does the object do?”
Static
- “What is the object?"
Generalisation
Inheritance
Association
Aggregation
State Modelling:
State modelling is used to describe and analyse the different possible states of an entity within a system, how that entity changes from one state to another, and what can happen to the entity when it is in each state.
Use cases and scenarios
Use cases and scenarios describe how a person or system interacts with the solution being modelled to achieve a goal.
What do we include in a use case?
Name
Goal
Actors
Preconditions
Triggers
Flows
Post conditions
Sequence diagrams & interface analysis
A sequence diagram
shows how processes or objects interact during a scenario
Interface Analysis
Definition: An interface
is a connection between two components or solutions.
Most solutions require one or more interfaces to exchange information with other solution components, organisational units, or business processes.
Interface types
user interfaces (UI)
people external to the solution such as stakeholders or regulators
business processes
data interfaces between systems
application programming interfaces (APIs)
hardware devices
User stories
A user story represents a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.
As a <...> I want <...> So that <...>
User stories can be used
to capture stakeholder needs and prioritise development
as a basis of estimating and planning solution delivery
as a basis for generating user acceptance tests
as a metric for measuring the delivery of value
as a unit for tracing related requirements
as a basis for additional analysis
as a unit of project management and reporting
User story map:
A “big” user story that can be broken down into smaller more detailed stories is called an “epic”.
A user story map is a canvas that helps plot larger themes of requirements to epics and user stories.
You can use it to scope the solution.
Non-Functional Requirements
Non-functional requirements analysis examines the requirements for a solution that define how well the functional requirements must perform.
Typical categories
Availability
: how easy it is to access the solution at different times and through different means
Compatibility:
degree to which the solution works well together with other components
Functionality:
degree to which the solution functions meet user needs, e.g. suitability, accuracy, and interoperability.
Maintainability
: how easy it is to correct errors, improve performance, perform standard servicing
Performance efficiency
: avoiding excessive consumption of resources
Portability
: ease of transfer from one environment to another
Reliability
: ability of a solution to perform its required functions under specific conditions for expected duration
Scalability:
degree with which a solution is able to grow or evolve to handle increased amounts of work
Security:
protection from from accidental or malicious access, use, modification, destruction, or disclosure.
Usability:
ease with which a user can learn to use the solution
Certification:
ability to meet certain industry conventions
Compliance:
regulatory, financial, or legal constraints
Localisation:
requirements dealing with local languages, laws, currencies, cultures, spellings, etc.
Service Level Agreement:
constraints of provider-user relationships
Extensibility:
the ability of a solution to incorporate new functionality in the future.
Accessibility
It is
hard
to produce good NFRs
Role and Permission Matrix
A roles and permissions matrix is used to ensure coverage of activities by denoting responsibility, to identify roles, to discover missing roles, and to communicate results of a planned change.
4) Define Design Options
BABOK 7.5
4.1) Improvement opportunities
Typical ones:
❖ Increase Efficiencies. ❖ Improve Access to Information. ❖ Identify Additional Capabilities
4.2) Requirements allocation
4.3) Elements of the options may be:
1/ Business policies and business rules
2/ Business processes
3/ People and their roles
4/ Decisions
5/ Software
6/ Hardware
7/ Org. structures
4.4) Key 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
2) Verify & Validate the requirements
BABOK 7.2 & 7.3
2.2) Validate the Requirements
Typical validation activities:
Identify assumptions
Define measurable evaluation criteria
Evaluate alignment with solution scope
2.1 )Verify the Requirements
Why do we verify?
To ensure that requirements and designs specifications and
models meet quality standards and are usable for the purpose they serve
❖ Atomic ❖ Complete ❖ Consistent. ❖ Concise. ❖ Feasible
❖ Unambiguous. ❖ Testable. ❖ Prioritised. ❖ Understandable
Typical verification activities:
Checking for compliance
Checking for correct use of notations, templates
Checking for completeness within each model
Cross-checking the models against other relevant models
Ensuring the terminology used is understandable
2.3) Key Output:
●
Requirements
(
verified):
a set of requirements or designs that is of sufficient quality to be used as a basis for further work.
●
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.
2.4 Technique: Reviews
Reviews are used to evaluate the content of a work product.
Objectives of the review
❖ to remove defects ❖ to ensure conformance standards. ❖ to ensure completeness ❖ to establish consensus. ❖ to answer a question, resolve an issue, or explore alternatives ❖ to educate reviewers. ❖ to measure quality
Techniques of the review
Formal:
❖ Inspection. ❖ Formal Walkthrough. ❖ Single Issue Review (Tech review)
Informal:
❖ Informal Walkthrough. ❖ Desk Check. ❖ Pass Around
Participants of the review:
Define your role
❖ Author. ❖ Scribe. ❖ Reviewer. ❖ Facilitator
3) Define requirements architecture
A viewpoint is a set of conventions that define how requirements will be represented.
Key outputs
Requirements Architecture: the requirements and the interrelationships among them, as well as any contextual information that is recorded.
BABOK 7.4
3.1) Benefits of having an architecture:
❖ Templating. ❖ Completeness
3.2)
When defining requirements architecture, define expected relationships
Good relationships are:
❖ Defined. ❖ Necessary. ❖ Correct
❖ Unambiguous. ❖ Consistent
3.3) Data Modelling
A data model describes the entities, classes or data objects relevant to a domain, the attributes that are used to describe them, and the relationships among them to provide a common set of semantics for analysis and implementation
How does Data modelling work?
Release ( title, date)
Requirement (title, description, stakeholder, status)
Epics (title, description)
Component (title, description, visual, design)
Levels of data modelling
Conceptual (boxes and arrows)
Logical (standards & procedures)
Technical (how datas are organised in virtual/physical server)
5) Analyze Potential Value and Recommend Solution
BABOK 7.6
5.1) Define design options
Describe solution approach
Allocate requirements
Identify improvement opportunities
Describe the options
5.2) Identify potential value
Expected benefits
Expected costs
Potential value
5.3) Recommend solution
Understand decision criteria
Give recommendations
Key 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.
5.4) Techniques
Financial analysis
Financial analysis is used to understand the financial aspects of an investment, a solution, or a solution approach.
BABOK 10.20
Cost
Cost of change: APEX vs OPEX
Total cost of ownership
Benefits
Financial
Non-financial
Acceptance and evaluation criteria
BABOK 10.1
Acceptance criteria
Acceptance criteria are used to define the requirements, outcomes, or conditions
that must be met in order for a solution to be considered acceptable to key stakeholders.
One Solution -> use acceptance
Evaluation criteria
Evaluation criteria are the measures used to assess a set of requirements in order to choose between multiple solutions
Multiple solutions -> use evaluation