BABOK V3 – STUDY GROUP 3

CH5. REQUIREMENTS LIFE CYCLE

MANAGEMENT

21 – February – 2019

Cristina SLAVITA, CBAP

1

Irina MINOIU
Warm-up questions

Irina MINOIU
Just a thought!

KEEP
CALM
AND
LEARN
BABOK

Irina MINOIU
 Requirement = representation of NEED

BABOK 3
Key Concepts Design = representation of the SOLUTION

Enterprise

Organization

Irina MINOIU
 REQUIREMENT = representation of
need
Same
DESIGN = representation of the solution
lifecycle!!

Irina MINOIU
Business Analysis Core Concept Model (BACCM)

Change Transformation in response to a NEED

Need Problem / opp to be addressed

Solution Specific way to satisfy one or more NEEDS in a CONTEXT

Stakeholder Group/individual in a relation with CHANGE, NEED, SOLUTION

Value Worth, importance, usefulness of something for a STAKEHOLDER in a CONTEXT

Context Circumstance influencing/being influenced by and providing understanding of CHANGE

Irina MINOIU
 Today’s
lesson ☺
HOW?

WHAT?

Irina MINOIU
REQUIREMENTS LIFE CYCLE MANAGEMENT

From need to Up to date Highest value “Respond to

solution first Change” Sign off
Easy access

5.1. Trace 5.2 Maintain 5.3. Prioritize 5.4. Assess

Requirements
5.5.Approve
Requirements Requirements Requirements Changes Requirements

The RLCM’s
TASKs

Irina MINOIU
REQUIREMENTS LIFE CYCLE MANAGEMENT

Requirements  → Design  →Solution

Requirements provide value after the solution is implemented

Requirements TRACEABILITY
Business  Past  Backward  Derivation
==========================================
Allocation ➔ Forward ➔ Future ➔Implementation

Irina MINOIU
 REQUIREMENTS LIFE CYCLE MANAGEMENT

Life cycle = phases / states that requirements pass through as part of change.

10

Irina MINOIU
 Manage how proposed changes to requirements and designs are evaluated during an
Change
initiative.
Need Trace, prioritize and maintain requirements to ensure that the need is met.
Trace requirements and designs to solution components to ensure that the solution
Solution
satisfies the need.
Work closely with key stakeholders to maintain understanding, agreement, and
Stakeholder
approval of requirements and designs.
Value Maintain requirements for reuse to extend value beyond the current initiative.

Context Analyze the context to support tracing and prioritization activities.

BACCM for
RLCM 11

Irina MINOIU
 12

Irina MINOIU
Business

Stakeholders
Transitional

Solution Non-Functional
Functional

13

Irina MINOIU
5. Requirements Life Cycle Management
The CHANGE
Requirements
(different stages)

DESIGN on which the

CHANGE is applied

14

Irina MINOIU
Anchoring
• TRACE Requirements

• MAINTAIN Requirements

• PRIORITIZE Requirements

• ASSESS Requirements CHANGES

• APPROVE Requirements

15

Irina MINOIU
5.1 TRACE REQUIREMENTS
“What” is traced

DESIGN also
has phases

Used in the next

design steps

16

Irina MINOIU
5.1 TRACE REQUIREMENTS

Purpose:
• Requirements and Design to be aligned
• Manage the effects of change on reqs

Traceability helps:
• Scope, change, risk, time, cost, communication management
• Identify missing functionalities, “extra” functionalities
• See the relationships between reqs / design/ solution

Requirements TRACEABILITY
Business  Past  Backward  Derivation
==========================================
Allocation ➔ Forward ➔ Future ➔Implementation

17

Irina MINOIU
5.1 TRACE REQUIREMENTS

Traceability
example

18

Irina MINOIU
5.1 Requirements Traceability – Input(s)

Reqs traced to other reqs or

solution components

Design traced to
requirements

19

Irina MINOIU
5.1 REQUIREMENTS TRACEABILITY
ELEMENTS
.1 Level of Formality .2 Relationships
Consider Consider
• The value brought by each link / relation • DERIVE = solution req derived from business req
• More relations & high formality ➔ higher • DEPENDS
the effort for the BA • Necessity = makes sense to implement only
• Effort = easier to implement after…
• SATISFY = functional req and its solution implementation
• VALIDATE = req and the test case

This level of detail

.3 Repository
and formality brings
VALUE? In accordance with the methods identified by the business
analysis approach

20

Irina MINOIU
5.1 REQUIREMENTS TRACEABILITY
GUIDELINES
Traceability depends on
the business domain

𝑅𝑒𝑞𝑢𝑖𝑟𝑒𝑚𝑒𝑛𝑡 ∈ 𝐼𝑛𝑓𝑜𝑟𝑚𝑎𝑡𝑖𝑜𝑛

If the domain of the

change is regulated

Store / Manage req/info

21

Irina MINOIU
5.1 REQUIREMENTS TRACEABILITY
Techniques

• Business Rules Analysis: trace business rules  → requirements that they support

• Functional Decomposition: break down solution scope into smaller components for allocation,
trace high-level concepts to low-level concepts.

• Process Modelling: visually of the future state process, tracing reqs to the future state process.

• Scope Modelling: visually depicts scope, traces requirements to the area of scope supported

22

Irina MINOIU
5.1 REQUIREMENT TRACEABILITY
Stakeholders

• Customers: affected by how and when requirements are implemented

• DSME: recommendations for the reqs to be linked to a solution component/ release.
• End User: specific dependency relationships
• ISME: awareness of dependencies between solution components during implementation.
• Operational Support: traceability documentation source for help desk support.
• Project Manager: traceability supports project change and scope management.
• Sponsor: is required to approve the various relationships.
• Suppliers: are affected by how and when requirements are implemented.
• Tester: reqs relations needed when creating tests, trace test cases to reqs.

23

Irina MINOIU
5.1 Requirements traceability – Output(s)

Reqs related to other Design related to

reqs, solution reqs, solution
components, components,
releases, iterations releases, iterations
24

Irina MINOIU
5.2 Maintain Requirements “What” is
maintained

DESIGN also
needs to be
maintained

Used further

25

Irina MINOIU
5.2 Maintain Requirements

• Retain requirement accuracy and consistency, throughout and

beyond the change, during the entire requirements life cycle
• Support reuse of requirements in other solutions

Maintainability characteristics:
• Consistently represented
• Reviewed and approved for maintenance using a standardized
process that defines proper access rights and ensures quality
• Easily accessible and understandable.

26

Irina MINOIU
5.2 Maintain Requirements - Inputs

All requirements types

Need to be maintained during the change life

27

Irina MINOIU
 5.2 MAINTAIN REQUIREMENTS
ELEMENTS
.1 Maintain Requirements .3 Reusing requirements
Can be reused
• Maintained req = correct & up to date
• Maintain req and reqs relationship • within the current initiative,
• To maintain reqs: • within similar initiatives,
• Clearly named and defined, • within similar departments
• Easily available to stakeholders • throughout the entire organization.
• Repository Higher the detail and referencing ➔ less reusable
• BA’s duty

.2 Maintain Attributes

• The attributes change during the life cycle ➔ keep up to date!

• Complexity, Absolute Reference, Risks, Author, Source,
Status, Ownership, Urgency, Priority, Stability

28

Irina MINOIU
5.2 MAINTAIN REQUIREMENTS
GUIDELINES

How reqs will be

managed for reuse

29

Irina MINOIU
5.2 MAINTAIN REQUIREMENTS
Techniques

• Business Rules Analysis: similar business rules across the enterprise in order to facilitate reuse.
• Data Flow Diagrams: similar information flow across the enterprise in order to facilitate reuse.
• Data Modelling: similar data structure across the enterprise in order to facilitate reuse.
• Document Analysis: analyze existing documentation about an enterprise = basis for maintaining
and reusing requirements.
• Functional Decomposition: identify requirements associated with the components and available
for reuse.
• Process Modelling: identify requirements associated with the processes that may be available for
reuse.
• Use Cases and Scenarios: identify a solution component that may be utilized by more than one
solution.
• User Stories: identify requirements associated with the story that may be available for reuse.

30

Irina MINOIU
5.2 MAINTAIN REQUIREMENTS
Stakeholders

• DSME: references maintained requirements on a regular basis to ensure they are accurately reflecting
stated needs.
• ISME: utilizes maintained requirements when developing regression tests and conducting impact
analysis for an enhancement.
• Operational Support: maintained requirements are likely to be referenced to confirm the current state.
• Regulator: maintained requirements are likely to be referenced to confirm compliance to standards.
• Tester: maintained requirements are used by testers to aid in test plan and test case creation.

31

Irina MINOIU
5.2 Prioritize Requirements – Output(s)

Defined once
Available for long-time reuse
Can become Organizational Process Assets

Can be reused, once defined

32

Irina MINOIU
5.3 Prioritize Requirements “What” is
prioritized

DESIGN also
needs to be
prioritized

Risks come from

requirements and
design

33

Irina MINOIU
5.3 Prioritize Requirements

Rank requirements based on relative importance

Prioritization:
• On going process
• Relative value
• Sequence of implementation
• Relations between requirements – can be base for prioritization

34

Irina MINOIU
5.3 Prioritize Requirements - Inputs
Any design, in any form
ready to be prioritized
Any req, in any form ready
to be prioritized

35

Irina MINOIU
5.3 PRIORITIZE REQUIREMENTS
ELEMENTS
.1 Basis for prioritization .2 Prioritization challenges
• A req has different values for different stkhs
• Benefit
• All reqs have “high” priority for stkhs
• Penalty
• Stkhs influence
• Cost
• Stkhs conflict
• Risk
• Prioritization trade-offs
• Dependency
• Time sensitivity
• Stability .3 Continual Prioritization
• Regulatory or Policy
Compliance • As more is learned
• As cost/effort is learned
• As dev sequence is learned
• ….
• Stakeholders prioritize!!!

36

Irina MINOIU
5.3 REQUIREMENTS PRIORITIZATION
Contract, regulations, policies

Info costs, timelines, value realization

Just how much is known /

should be known ➔ “Spikes”

Approach for prioritization

Understand relationships
with reqs / prods

Have the reqs attributes

Prioritize according to
scope
37

Irina MINOIU
5.3 PRIORITIZE REQUIREMENTS
Techniques

• Backlog Management: compare requs to be prioritized.

• Business Cases: assess requirements against identified business goals and objectives
• Decision Analysis: identify high-value requirements.
• Estimation: estimates – base for prioritization.
• Financial Analysis: assess the financial value of requirements, how the timing of delivery
will affect that value.
• Interviews: understand stkh’s priorities
• Item Tracking: track issues raised by stakeholders during prioritization.(???)
• Prioritization: facilitate the process of prioritization.
• Risk Analysis and Management: risks - basis of prioritization.
• Workshops: understand stkh’s priorities

38

Irina MINOIU
5.3 PRIORITIZE REQUIREMENTS
Stakeholders

• Customer: order of priorities brings value; can negotiate the priorities

• End User: order of priorities brings value
• Sponsor: order of priorities brings value

• ISME: in what order can be the implementation done – tech constraints

• PM: needed in the project plan
• Regulator: priorities are in line with the legal constraints

39

Irina MINOIU
5.3 Prioritize Requirements – Output(s)

Reqs ranked for Designs ranked for

further work further work

40

Irina MINOIU
5.4 Asses Requirements Changes Current (AS IS)

The change!

Just assessed
No further use ☺?

41

Irina MINOIU
5.4. Assess Requirements Changes

Evaluate implications of proposed change!

Applies to proposed CHANGES and SOLUTIONS

Check if the change:
• In line with the strategy / scope
• Brings value
• Conflicts with other requirements
• Impacts the time-lime
• Adds risks, opportunities, constraints

42

Irina MINOIU
5.4 Asses Requirements Changes - Inputs
Identified at any time
Impact any reqs / design

All reqs / designed can be

impacted

43

Irina MINOIU
5.4 ASSESS REQUIREMENTS CHANGES
ELEMENTS
.1 Assessment Formality

• Continuous evolutions reduces the formality of the assessment

• BA decides the level of formality
• Propose change can be dropt before formal approval needed
• Do not “analyze” more than needed

.2 Impact Analysis .3 Impact Resolution

• Decision: Approve / Deny / Defer
Directions: • Who takes the decision: as per planned approach (Even BA!)
• Benefit • Document decision!!
• Cost: • Communicate decision!!
• Cost to make the change
• Cost of associated rework
• Opportunity cost
• Impact: on processes, customers, …
• Schedule
• Urgency
44

Irina MINOIU
 45

Irina MINOIU
5.4 ASSESS REQUIREMENTS CHANGES
GUIDELINES

Purpose & direction of change, change components

Know-how for assess the change

Change control: “how to”

Must be followed when considering the change

Relations between reqs

Assess the impact against the whole scope!

46

Irina MINOIU
5.4 ASSESS REQUIREMENTS CHANGE
Techniques
• Business Cases: justify a proposed change.
• Business Rules Analysis: assess changes against business policies, rules
• Decision Analysis: facilitate the change assessment process.
• Document Analysis: analyze existing documents
• Estimation: size of the change.
• Financial Analysis: financial consequences of the change.
• Interface Analysis: interfaces that can be affected by the change.
• Interviews: impact on the organization /assets
• Item Tracking: track any issues / conflicts brought by the change
• Risk Analysis and Management: level of risk associated with the change.
• Workshops: understanding of the impact / resolve changes

47

Irina MINOIU
5.4 ASSESS REQUIREMENTS CHANGE
Stakeholders

• Customer: feedback con the impact of change on the value.

• DSME: know how
• End User: impact of change on the activities
• Operational Support: will they be able to support the change
• PM: impact on project plan
• Regulator: compliance with standards
• Sponsor: impact on the solution scope
• Tester: integrate the change in the tests

48

Irina MINOIU
5.4 Assess Requirements Changes – Output(s)

Approved / modify / reject

Change
Design

49

Irina MINOIU
5.5 Approve Requirements

What need to be approved

Use further where-ever

needed

50

Irina MINOIU
5.5 Approve Requirements

Obtain AGREEMENT & APPROVAL

• BA responsible for the decision makers having info

for taking the decision!
• BA helps the decision taken process
• Informal/formal (adaptive/predictive)

51

Irina MINOIU
5.5 Approve Requirements - Inputs

Where is the quality

Reqs with enough quality
to be used further
defined?

Designs ready to be used further

The SOLUTION itself!!
Verify = needed quality
Validate = what is needed

52

Irina MINOIU
 5.5 APPROVE REQUIREMENTS
ELEMENTS
.1 Understand Stakeholders Roles
• BA responsible to get stakeholders approval
• BA to know who are the decision makers (Plan BA
Governance)
• BA to know RACI and act accordingly (influencers!)
.2 Conflict and Issue Management
Consensus to be obtain before asking for approval
Source of conflicts:
• Different interpretations of reqs /design
• Conflicting values
BA – facilitate the conflict resolution
BA’s
Responsibility!!!
.3 Gain Consensus
Approval = confirm stkhs believe that sufficient value will
be created to justify the investment
BA obtaining approval (How to):
• Review reqs / changes with the rAci
• Ask for approval
• Indicate agreement of stkhs (Y/N)
• Use: “Communicate BA Info”& “Plan BA Governance”
“Complete agreement may not be necessary for a successful
change, but if there is a lack of agreement, the associated
risks are to be identifies and managed accordingly” (?!?!)
.4 Track and Communicate Approval
• BA records approval decision
• Tracking tool:
• stkhs to know the status
• Audit trail
53
Irina MINOIU
5.5 APPROVE REQUIREMENTS
GUIDELINES

Approval to be in line with the strategy

Who has the right to approve

To respect the law

Tracking

Impact on solution / in line with

solution

54

Irina MINOIU
5.5. APPROVE REQUIREMENTS
Techniques

• Acceptance and Evaluation Criteria: used to define approval criteria.

• Decision Analysis: used to resolve issues and gain agreement.
• Item Tracking: used to track issues identified during the agreement process.
• Reviews: used to evaluate requirements.
• Workshops: used to facilitate obtaining approval.

55

Irina MINOIU
5.5 APPROVE REQUIREMENTS
Stakeholders

• Customer: ensure needs are met.

• DSME: involved as per RACI
• End User: involved as per RACI
• Operational Support: the approved change can be sustained by opps
• Project Manager: includes in project plan
• Regulator: involved as per RACI
• Sponsor: involved as per RACI
• Tester: integrate in tests

56

Irina MINOIU
5.5 Approved Requirements – Output(s)

Approved and ready for

further use!

57

Irina MINOIU
Wrap-up questions (next 10)...and the score is:… ☺!!!

58

Irina MINOIU
Study Groups Calendar
Introduction 30.01.2019 / Thu

BAPM & EC 09.02.2019 / Sat

RLCM 21.02.2019 / Thu

RADD &SE 02.03.2019 / Sat

SA 14.03.2019 / Thu

Underlying competencies 04.04.2019 / Thu

Techniques 04.05.2019 / Sat

Perspectives 18.05.2019 / Sat

59

Irina MINOIU
 RADD
7&8
Solution Evaluation

02.03.2019

60

Irina MINOIU
This Year.
Romania BA Conference
| Cluj | Tickets and Call for Speakers from 8 Feb
12 April 2019

| Bucharest
1-2 November 2019

Balkan BA Conference
| Belgrade | Serbia
11-12 October 2019
61

61
61
Irina MINOIU
THANK YOU &
SEE YOU NEXT TIME!!!!
62

Irina MINOIU