Mindavation - Requirements Enoughness - when is enough enough?

mind a vã shen n.
the use of the creative mind
to inspire motivation that results in
innovation, productivity and growth
– mindavate v.

Requirements
Enoughness
Haydn Thomas
hthomas@mindavation.com
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?
Unconscious
Competence
Unconscious
Incompetence
Conscious
Competence
Conscious
Incompetence
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

STAKEHOLDERS
COMMITMENT
BOUNDARIES
REQUIREMENTS
Requirements must be:
NEEDS HIERARCHY
EACH LEVEL OF THE HIERARCHY MUST DRIVE THE LEVEL BELOW
– THEREFORE EACH ITEM MUST BE CROSS REFERENCED TO THE LEVEL ABOVE
EXPLANATION OF
HIERARCHY COMPONENT
HIGH LEVEL
WHAT
WHO
WHY
WHEN
WHERE
TIME
LOW LEVEL
WHAT
LOW LEVEL
HOW
apply to the solution RELEVANT
METHODOLOGY
DOCUMENT
PROJECT /
IMPROVEMENT
OBJECTIVE OBJECTIVE OBJECTIVE
SCOPE
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:
SPECIFIC
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 Objectives establish the goals that the change
should achieve, e.g. legislative compliance.
Objectives must be measurable
4 Initial Scope sets the boundaries for the change to
ensure the objectives will be addressed – what’s in
and what’s out
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
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
TIME OBJECTIVE
BUDGET
MEASURABLE
CLASSIFIABLE
DETAILED
PROCESS
GOVERNANCE
REQUIRED OUTCOME
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: info@mindavation.com
• 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.
hthomas@mindavation.com 0410 629 402
27

Mindavation - Requirements Enoughness - when is enough enough?

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to Mindavation - Requirements Enoughness - when is enough enough?

Similar to Mindavation - Requirements Enoughness - when is enough enough? (20)

Recently uploaded

Recently uploaded (20)

Mindavation - Requirements Enoughness - when is enough enough?