BABOK Study Group - meeting 5

BABOK
Study
Group
Meeting 5. Requirements Analysis
http://zubkiewicz.com 1
Paweł Zubkiewicz TOGAF 9, OCEB, CCBA, ArchiMate 2
pawel@zubkiewicz.com

Requirements Analysis
http://zubkiewicz.com
2

BABOK – Knowledge Areas &
Tasks
Paweł Zubkiewicz TOGAF 9, OCEB, CCBA,
ArchiMate 2 pawel@zubkiewicz.com
Source: www.projerra.ca
5.4 Define
Solution Scope
3

6 – Requirements Analysis
7/30/2016Paweł Zubkiewicz 4
ask Name Inputs Elements Techniques Stakeholders Outputs
1 Prioritize Requirements
decision process to determine
e relative importance of
equirements. Ensures that
fort is focused on most critical
ems.
Business case (5.5)
Business need (5.1)
Requirements
Requirements
Management Plan (2.5)
Stakeholder list, roles,
responsibilities (2.2)
Implicit Input:
BA plan(s) (2.3)
1. Basis for prioritization:
Business value; Business or
techni-cal risk; Implementation
difficulty; Likelihood of success;
Regulation or policy compliance;
Relationship to other
Requirements; Stakeholder
agreement; Urgency
2. Challenges:
Non-negotiable demands,
General:
Decision analysis (9.8)
Risk analysis (9.24)
Other:
MoSCoW analysis
Timeboxing/budgeting
Voting
Domain SME
Implementation
SME
Project Manager
Sponsor
Requirements [Prioritized] (6.1)
Implicit Output:
BA perf metrics
2 Organize Requirements
reate a set of views of
equirements.
Org process assets
Requirements (stated)
(3.3)
Solution scope (5.4)
Implicit Input:
BA plan(s) (2.3)
1. Levels of abstraction
2. Model selection:
User classes, profiles, roles; Con-
cepts and Relationships; Events;
Processes; Rules
General:
Business rule analysis (9.4)
Data modeling (9.7)
Organizational modeling (9.19)
Scenarios & use cases (9.26)
User stories (9.33)
Data flow diagrams (9.6)
Functional decomposition (9.12)
Process modeling (9.21)
Scope modeling (9.27
Domain SME
End User
Implementation
SME
Project Manager
Sponsor
Requirements Structure (6.2)
Implicit Output:
BA perf metrics
3 Specify and Model
equirements
xpress current or future state
an organization (or system)
sing a combination of text,
atrices, diagrams, and
odels.
Requirements (stated)
(3.3)
Requirements structure
(6.2)
Implicit Input:
BA plan(s) (2.3)
1. Text
2. Matrix documentation
3. Models
4. Capture requirement attributes
5. Improvement Opportunities
General:
Acceptance and evaluation criteria (9.1)
Data dictionary & glossary (9.5)
Data modeling (9.7)
Interface analysis (9.13)
Non-functional req. analysis (9.17)
Process modeling (9.21)
Scenarios & use cases (9.26)
State diagrams (9.29)
Any Requirements [Analyzed] (6.3)
Implicit Output:
BA perf metrics
<--- any stakeholder
4 Define Assumptions &
onstraints
entify assumptions, limitations,
r restrictions that may influence
e set of viable solutions.
Stakeholder concerns
(3.3)
Implicit Input:
BA plan(s) (2.3)
1. Assumptions
2. Business constraints
3. Technical constraints
General:
Problem tracking (9.20)
Implementation
SME
Project Manager
All stakeholders
Assumptions & Constraints
(6.4)
Implicit Output:
BA perf metrics
5 Verify Requirements
nsure that the requirements
pecifications and models meet
e standard of quality.
Requirements (any
except stated)
Implicit Input:
BA plan(s) (2.3)
1. Characteristics of quality:
Cohesive; Complete; Consistent;
Correct; Feasible; Modifiable; Un-
ambiguous; Testable
2. Verification activities
General:
Problem tracking (9.20)
Structured walkthrough (9.30)
Other:
Checklists
All stakeholders Requirements [Verified] (6.5)
Implicit Output:
BA perf metrics
6 Validate Requirements
nsure that all requirements
upport the delivery of value to
e business and meet stake-
older need.
Business case (5.5)
Stakeholder, solution, or
Transition requirements
(verified)
Implicit Input:
BA plan(s) (2.3)
1. Identify assumptions
2. Define measurable evaluation
criteria
3. Determine business value
4. Determine dependencies for
benefits realization
5. Evaluation alignment with
business case and opportunity
cost
General:
Metrics & KPI (9.16)
Prototyping (9.22)
Structured walkthrough (9.30)
All stakeholders Requirements [Validated] (6.6)
Implicit Output:
BA perf metrics
Business rule analysis (9.4)
Data flow diagrams (9.6)
Functional decomposition (9.12)
Metrics and KPI (9.16)
Organizational modeling (9.19)
Prototyping (9.22)
Sequence diagrams (9.28)
User stories (9.33)

6.1 Prioritize Requirements
Techniques
• General
o Decision Analysis (9.8)
o Risk Analysis (9.24)
• MoSCoW
• Timeboxing/Budgeting
o All in/ All out / Selective
• Voting
5
Elements
• Basis for Prioritization
• Challenges
o Non-negotiable Demands
o Unrealistic Tradeoffs
Prioritization of requirements ensures that analysis and implementation efforts
focus on the most critical requirements.

6.2 Organize Requirements
Techniques
• Business Rules Analysis (9.4)
• Data Flow Diagrams (9.6)
• Data Modeling (9.7)
• Functional Decomposition (9.12)
• Organization Modeling (9.19)
• Process Modeling (9.21)
• Scenarios and Use Cases (9.26)
• Scope Modeling (9.27)
• User Stories (9.33):
6
Elements
• Levels of Abstraction
• Model Selection
o User Classes, Profiles, or Roles
o Concepts and Relationships.
o Events
o Processes.
o Rules
The purpose of organizing requirements is to create a set of views of the
requirements for the new business solution that are comprehensive, complete,
consistent, and understood from all stakeholder perspectives.

6.3 Specify and Model Reqs
1. Acceptance and Evaluation Criteria
Definition (9.1) ▶
2. Business Rules Analysis (9.4) ▶
3. Data Dictionary and Glossary (9.5) ▶
4. Data Flow Diagrams (9.6) ▶
5. Data Modeling (9.7) ▶
6. Functional Decomposition (9.12) ▶
7. Interface Analysis (9.13) ▶
8. Metrics and Key Performance Indicators
(9.16) ▶
9. Non-functional Requirements Analysis
(9.17) ▶
10. Organization Modeling (9.19) ▶
11. Process Modeling (9.21) ▶
12. Prototyping (9.22) ▶
13. Scenarios and Use Cases (9.26) ▶
14. Sequence Diagrams (9.28) ▶
15. State Diagrams (9.29) ▶
16. User Stories (9.33)
7
Elements
• Text
• Matrix Documentation
• Models
• Capture Requirements
Attributes
• Improvement
Opportunities
To analyze expressed stakeholder desires and/or the current state of the organization
using a combination of textual statements, matrices, diagrams and formal models.

6.4 Define Assumptions and Constraints
8
Elements
• Assumptions
• Business Constraints
o They may reflect budgetary restrictions, time restrictions, limits on the number
of resources available, restrictions based on the skills of the project team and
the stakeholders, a requirement that certain stakeholders not be affected by
the implementation of the solution, or any other organizational restriction.
• Technical Constraints
o may include development languages, hardware and software platforms, and
application software that must be used. Technical constraints may also
describe restrictions such as resource utilization, message size and timing,
software size, maximum number of and size of files, records and data
elements. Technical constraints include any enterprise architecture standards
that must be followed.
Identify factors other than requirements that may affect which solutions are
viable.

6.5 Verify Requirements
Techniques
• General
o Acceptance and Evaluation
Criteria Definition (9.1)
o Problem Tracking (9.20)
o Structured Walkthrough (9.30)
• Checklists
9
Elements
• Characteristics of
Requirements Quality
• Verification Activities
Requirements verification ensures that requirements specifications and models meet
the necessary standard of quality to allow them to be used effectively to guide further
work

6.6 Validate Requirements
Techniques
• Acceptance and
Evaluation Criteria
Definition (9.1)
• Metrics and Key
Performance Indicators
(9.16)
• Prototyping (9.22)
• Risk Analysis (9.24)
• Structured Walkthrough
(9.30)
10
Elements
• Identify Assumptions
• Define Measurable
Evaluation Criteria
• Determine Business Value
• Determine Dependencies
for Benefits Realization
• Evaluate Alignment with
Business Case and
Opportunity Cost
The purpose of requirements validation is to ensure that all requirements support the
delivery of value to the business, fulfill its goals and objectives, and meet a stakeholder
need.

V&V
Verify Req. Validate Req.
• Are the requirements of the highest
quality?
• Do they meet the organizational
standards for documenting reqs?
• Do they meet the characteristics of
excellent requirements?
• Do the requirements describe a
solution that will bring business
value?
• Will the solution meet the project
objectives and solve the original
business problems?
11
Verify
requirements
6.5
Validate
requirements
6.6
Build or buy
Solution (out
of BABOK)
Validate
Solution 7.5

Opportunity cost
• At the project level, opportunity cost refers to the benefits that
could have been achieved with an alternative investment
rather than this one. In other words, it is the cost of what you
cannot do or have because you chose to invest in this project
instead of another one.
• This concept can also be applied to decisions made within a
project. For example, if a project team spends time and
energy implementing a feature in a software application, that
effort cannot be applied towards additional testing, training for
the users, bug fixes, or other project work. That lost work
represents the opportunity cost of the decision.
• The opportunity cost of any decision is equal to the value
of the best alternative use of those resources.
12

Q1
Your organization is trying to determine which one of two
opportunities they will pursue. The Project A is worth $235,987
and Project B is worth $567,000 but carries significant risk. The
organization elects to purse Project B and not Project A. What is
the opportunity cost in this scenario?
A. $331,013
B. There is not enough information to know as the risk for Project
B has not been quantified.
C. $235,987
D. $567,000
Answer: C
13

Q2
A business analyst is helping management determine which
solution they should choose. As it happens that the organization
can only choose one of the two solutions due to time and
resource restrictions. Solution A worths $456,000 to the
organization while solution B worths $565,000 to the
organization. While solution A costs less, it is less risky and
takes less time to complete so management elects to seize
Solution A. What is the opportunity cost?
A. $565,000
B. There is not enough information to know how much the
solution will cost the organization.
C. $109,000
D. $456,000
Answer: A
14

And remember
6.6.4.5 Ultimately, each requirement must be traceable to
the objectives in the business case, and should also
minimize the opportunity cost of implementation.
http://zubkiewicz.comPaweł Zubkiewicz 15

Did you enjoy the presentation?
Do you have any questions?
Or maybe you just want to say "thanks"
Just click the pic above to visit my blog http://zubkiewicz.com
http://zubkiewicz.com 16

BABOK Study Group - meeting 5

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Empfohlen

Empfohlen (20)

BABOK Study Group - meeting 5

Hinweis der Redaktion