mindavation - requirements enoughness - when is enough enough?

mind a vã shen n.

the use of the creative mindto inspire motivation that results ininnovation, productivity and growth

– mindavate v.

Requirements Enoughness

Haydn Thomas

[email protected]

0410 629 402

Knowledge & Skills

During this presentation we will provide you with the knowledge and skills that will enable you to:-

1. Ensure an understanding of the overall requirements process

2. Discuss who owns and determines requirements 'enoughness'

3. Why Alignment is so important to project success

Copyright Mindavation 2014 www.mindavation.com.au

3

Projects = Miracles? Requirements?


4

IT’S NEVER

'JUST' A…


5

Packaging the Change


6

The Overall Requirements Process

1. Understanding Scope

2. Requirements Gathering

3. Requirements Refinement

4. Requirements Verification

Do these Requirements deliver the expected acceptance criteria?


7

Acceptance Criteria

Are we done yet? How will you know?

• Tie completion criteria back to the Stakeholder requirements

• Must be quantifiable and CLEAR

• Provide examples

• Apply the traceability matrix

• Have completion criteria signed off by the sponsor and customer(s)


8

Why the Confusion?

UnconsciousCompetence

UnconsciousIncompetence

Conscious Competence

ConsciousIncompetence


9

'Specifically' – the magic word

Assumptions suck…– Assumptions are things we believe to be true

– Assumptions are not concrete facts

Step 1 – Document your assumptions

Step 2 – Try and turn them into facts

Step 3 – If still assumptions, manage them as a risk


10

The Requirements Pyramid

Requirements Collection and Analysis involves managing the 'Requirements Pyramid‘

• Needs – 'the problem domain'

• Requirements

• Specifications

• Code or detailed processes (or both)


11

REQUIREMENTS

Requirements must be:

NEEDS HIERARCHYEACH LEVEL OF THE HIERARCHY MUST DRIVE THE LEVEL BELOW

– THEREFORE EACH ITEM MUST BE CROSS REFERENCED TO THE LEVEL ABOVE

EXPLANATION OF

HIERARCHY COMPONENT

LOW LEVEL

WHAT

HIGH LEVEL

WHAT

WHO

WHY

WHEN

WHERE

LOW LEVEL

HOW

RELEVANT

METHODOLOGY

DOCUMENT

SCOPE

PROJECT /

IMPROVEMENT

OBJECTIVE OBJECTIVE OBJECTIVE

REQUIREMENT

FUNCTIONAL

REQ

PROJECT

DEFINITION

This document can guide

you in capturing the

relevant information

required to make an

informed decision about

whether the proposed

change should be

implemented.

Covering:

FUNCTIONAL

REQUIREMENTS

4 A Project or Improvement idea is driven by

an understanding of the current situation and the

desire or need to change the future situation

4 Initial Scope sets the boundaries for the change to

ensure the objectives will be addressed – what’s in

and what’s out

4 Objectives establish the goals that the change

should achieve, e.g. legislative compliance.

Objectives must be measurable

4 Requirements are statements which define what

needs to be provided by a ‘solution’ to achieve the

deliverables

4 Refined Scope is the review and validation of the

‘Initial Scope’. The initial scope may change as a

result of formulating requirements during this phase

4 Functional Requirements describe the behaviours

of the requirements that the solution needs to

manage

4 Performance Criteria describe what is to be used to

judge the solution’s performance

4 Business Rules describe the governance that must

apply to the solution

TIM

E

FUNCTIONAL

REQ

FUNCTIONAL

REQ

FUNCTIONAL

REQ

FUNCTIONAL

REQ

FUNCTIONAL

REQ

DELIVERABLE DELIVERABLE DELIVERABLE

4 Deliverables are what is expected to be achieved by

implementing the change, e.g. business processes

and procedures to support the introduction of XYZ

IDEA

DRIVERS

‘AS IS’ SITUATION

‘TO BE’ SITUATION

STAKEHOLDERS

TIME OBJECTIVE

BUDGET

BOUNDARIES

COMMITMENT

MEASURABLE

CLASSIFIABLE

SPECIFIC

PROCESS

REQUIRED OUTCOME

DETAILED

GOVERNANCE

REQUIREMENT REQUIREMENT REQUIREMENT

Requirements in a Project

• Can be one of the most challenging aspects of a project

• Are CRITICAL to the success of the project

• Will drive successful completion criteria

• Refine the scope of your project

• Can change!

• Are derived in stages• High level during Initiation Phase• Detailed during Planning Phase


13

SMART Requirements

Specific - clearly states what is required

Measureable - to confirm when met and value created

Achievable - can be done, e.g. technically possible

Realistic - is reasonable, e.g. cost is not prohibitive

Traceable - who provided the requirement and when


14

SMART Requirements

The system requires a new identifier for any new account transaction.

SALES SYSTEM - SH 3.0 O-1,3,4; S-1,4,6,9;

Andrew in new accounts requires a unique customer identifier starting with CUST and ending with the last 4 digits from the sales order for each new account transaction. The transaction should not allow the user to enter any customer data until the customer identified has been allocated by the sales system.

6 May at 12:35pm – Andrew – Supervisor – New Accounts


15

Your Turn!

Who Decides

Enoughness?


16

Refinement –Ensuring Requirements Reflect Current Business Strategies

Do the requirements gathered align with the objectives and scope of the project?

Additional items to understand and consider

• Where the priority of your project lies in the project portfolio

• Focusing on the synergies and conflicts between business and user needs

• Analysing any 'off task' requests for their 'true motivation'


17

Do Requirements Reflect TODAY’S Needs

• Use pictures, models, diagrams

• Show Before and After

• K - Keep

• R - Remove

• A - Add

• C – Change

• Involve the actual end consumer/user

• Obtain management understanding of the process changes –VERIFY that understanding

• Utilise a traceability matrix


18

Verification Activities

• Document inspection approaches

• Peer review

• Formal inspection

• Deriving findings and follow up

• Creation of procedural manuals or user training documentation outlines

• Confirm acceptance criteria will be met


19

Peer Review

Rule 1 – They are not YOUR requirements

Rule 2 – IT’S…..NOT……PERSONAL

Rule 3 – They are the requirements to deliver the expected outcomes

Rule 4 - Do they pass the SMART review?


20

Requirements Refinement – The Results

• Stakeholder, functional and non-functional requirements that

are understood by MANY

• Complexities have been identified and clarified

• Prioritised requirements

• Requirements that are necessary for the business

• An understanding of how everything 'fits together’

• Documentation that can be leveraged for other areas of the project (training & testing)


21

Verification Pitfalls

• Limiting the validation to 'QA' personnel or testers

• Analysis paralysis – frustrating personnel who contributed to requirements

• Not taking a 'holistic' point of view

• Considering verification a 'one-time event'

• can be performed at end of each project phase


22

Are we done yet?

Will these requirements

deliver on the outcome?

If yes,

you have ‘enoughness’


23

Knowledge & Skills

During this presentation we will provide you with the knowledge and skills that will enable you to:-

1. Ensure an understanding of the overall requirements process

2. Discuss who owns and determines requirements 'enoughness'

3. Why Alignment is so important to project success


24

Question Time


25

How To Communicate With Mindavation

Think A C T! On the back of your business card write the letters as appropriate:

• A – Add me to your mailing list to receive updates and Newsletters.

• C – Contact me. We’ll give you a call!

• T – Template from this presentation to be e-mailed to me (for free!)

• Internet: www.mindavation.com.au

• Email: [email protected]

• Twitter: @mindavation

• Blog: http://www.mindavation.com/IDBLOG

• In My Judgement http://mindavation.com/category/podcasts/


26

About the Presenter

Haydn Thomas Project Manager / Business Analyst/ Coach / Facilitator/ Mentor / Negotiator/ Keynote

Speaker

Haydn has over 20 years of real world experience in project, business analysis and business

consulting. He has worked extensively in large international and domestic banks, semi

government organisations, solution providers and small start-up companies in defining and

implementing structure, business solutions, change management and efficiencies across

Australia, New Zealand & North America. Haydn’s experience in complex integrated

solutions and working knowledge of various project management methodologies (PMBOK,

PRINCE2, SDLC) assists in delivering on client’s project and training needs. Haydn also

provides mentoring and coaching services in project management & business analysis and

is active in enabling capacity building across many organisations.

[email protected] 0410 629 402


27

mindavation - requirements enoughness - when is enough enough?

Business

overall requirements

requirements process

stakeholder requirements

requirements lifecycle

requirements collection

gathering process

verification process

iterative process