VANCOUVER Chapter Study Group

BABOK Chapter 6 – Requirements Analysis

February 24, 2016

Hossam Saleh, CBAP

2

Introduction

• PD Hours

• Presentation and quizzes at IIBA Vancouver

Chapter website

• Certification Update

• Hossam Saleh

CBAP Location Jan-2016 Current Notes

All 5989 6077

BC 78 80 Victoria and Burnaby

CCBA Location Jan-2016 Current Notes

All 817 840

BC 11 11 Victoria

3

Agenda

• Chapter 6 Requirements Analysis (one hour)

•6 tasks

•Techniques

•Pop quiz

• Break

• Chapter 7 Solution Assessment & Validation

(one hour)

•5 tasks

•Techniques

•Pop quiz

5

Chapter 6 – Requirements Analysis

6

Chapter 6 – Requirements Analysis

Tasks

1. Prioritize Requirements

2. Organize Requirements

3. Specify and Model Requirements

4. Define Assumptions & Constraints

5. Verify Requirements

6. Validate Requirements

POMAVV (“Poam a Vee Vee”)

7

Requirements Analysis Input and Output Diagram

8

• What criteria have you used to prioritize and organize requirements?

• In your organization, how do you decide which models to use when analyzing requirements?

• In your experience, what are the best models you have used for analyzing requirements?

• Please share your experience with requirement walk through. Why bother?

Intro (1/2)

9

Analyze stated requirements to define the required capabilities of a potential solution that will fulfill stakeholder needs.

Water fall vs. Agile – how does requirement analysis differ?

Intro (2/2)

10

6.1 Prioritize Requirements

11

6.1 Prioritize Requirements

Basis for prioritization• Business value

• Business or technical risks

• Implementation difficulty

• Likelihood for success

• Regulatory or policy compliance

• Stakeholder agreement

• Relationship to other

• requirements

• Urgency

Challenges

• Non-negotiable demands

• Unrealistic trade offs

12

6.2 Organize Requirements

13

6.2 Organize Requirements

6.2 Elements• Level of Abstraction

• What vs. how

• High-level vs. low level

• Methodology

• Model Selection (Model- simplify

reality)• Use classes, profiles or roles

• Concepts & relationships

• Events

• Processes

• Rules

14

6.3 Specify and model requirements

15

6.3 Specify and model requirements

Elements

• Text

• Matrix documentations

• Models• Modeling formats

• Notations

• Formal vs. informal models

• Capture requirements attributes

• Improvement opportunities

16

6.3 Specify and model requirements

Improvement Opportunities

• Automate or simplify work people perform

• Improve access to information

• Reduce complexity of interfaces

• Increase consistency of behaviour

• Eliminate redundancy

17

6.3 Specify and model requirements

Techniques• Acceptance and evaluation criteria

• Business rules analysis

• Data dictionary and glossary

• Data flow diagram

• Functional decomposition

• Interface analysis

• Metrics and key performance indicators

• Non-functional requirements analysis

• Organization modeling

• Process modeling

• Prototyping

• Scenarios and use cases

• Sequence diagrams

• State diagrams

• User Stories

18

6.4 Define Assumptions & Constraints

19

6.4 Define Assumptions & Constraints

• Assumptions• Anything believed to be true but not verified

• Source of potential project risk

• Business Constraints• Budgetary, time, resource, skills, organizational

limits

• Technical Constraints• Architecture design, development language,

hardware & software platforms, application limits

• Resource utilization, message size & timing, size

of software, file records, data elements

20

6.4 Define Assumptions & Constraints

Stakeholders

• Implementation SME

• Project Manager

• All stakeholders

Techniques

• Problem tracking

• Risk analysis

21

6.5 Verify Requirements

22

6.5 Verify Requirements

Elements

Characteristics of requirements quality

• Cohesive

• Complete

• Consistent

• Correct

• Feasible

• Modifiable

• Unambiguous

• Testable

23

6.5 Verify Requirements

Elements of Verifying Requirements

• Verification activities• Check for completeness

• Compare requirements with others, updated

consistently

• All variations of processes documented

• Triggers/outcomes

• Consistent terminology

• Use of examples

24

6.5 Verify Requirements

Stakeholders

• All stakeholders

Techniques

• General technique

• Acceptance and evaluation criteria

• Problem tracking

• Structured walk through

• Check list

25

6.6 Validate Requirements

26

6.6 Validate Requirements

• Elements• Identify Assumptions

• Define Measurable Evaluation Criteria

• Determine Business Value

• Determine Dependencies for Benefits

Realization

• Evaluate Alignment with business case and

opportunity cost

27

6.6 Validate Requirements

• Elements• Identify Assumptions

• Define Measurable Evaluation Criteria

• Determine Business Value

• Determine Dependencies for Benefits

Realization

• Evaluate Alignment with business case and

opportunity cost

28

6.6 Validate Requirements

Stakeholders

• All stakeholders

Techniques

• Acceptance and evaluation criteria

• Matrices and key performance indicators

• Prototyping

• Risk Analysis

• Structured Walkthrough

29

Requirements States

Stated

3.3

Specified /

Modeled

Analyzed

6.3

Verified

6.5

Validated

6.6

ApprovedCommunicated

4.5

Prioritized

6.1

Confirmed

3.4

Traced

4.2

30

Chapter 6 – Requirements Analysis

Pop Quiz