Requirements management by Dr Matthew Bell

Requirements Management By Matthew Bell

Introduction • What, Why, When and Who?

• Principles, Methods and Issues

• Stakeholder Management

• Management

• Acceptance

• Verification and Validation

What are Requirements

The Industry Service Provider

The Long Term Programme Started 10 years ago

The Modern User The University Grad Or IT Lover

What are Requirements

Beware: We perceive things in Solutions not in Requirements

What are Requirements

What the ‘User’ says?

What does the ‘User’ Need?

What ‘Capabilities’ are required to provide the ‘User’ Need?

I want a Tough Book to review Maintenance Actions in the Field

Portable access to real time Maintenance Information on site

Interfacing Systems Requirements Training Requirements

Data Analytics Commination Network Infrastructure

Integration to Other Users Integration for Reporting

Who are the Users? • Be aware of the Multiple Perspectives

• Different Users have different Perspectives on their ‘Wants’ and ‘Needs’

• Who are the Users?

• It may not just be the End-User

• Look across the Capabilities Required

Set the Scope and Understand the Perspectives

In Scope – Maintenance Systems

What are Requirements • What is the Scope of the Requirements?

USER

System

High Level Capabilities

USER

System

USER

System

Client Information Systems Supplier Training Organisation

Measures of Effectiveness

Service Life 15 Years

Measures of Performance

Operating Profiles

Traceability – User, System, Interfaces

What are Requirements • Definition:

• A requirement is a need, expectation, or obligation. It can be stated or

implied by an organization, its customers, or other

interested parties.

ISO 9000:2015

What are Requirements

• The Software can manage maintenance schedule periodicity

• The User would like all first line maintenance periodicities

• The User would like all first line maintenance periodicities and assets

• The User would a User Friendly Interface

• The Software shall provide access to 10,000 records from 09:00-17:00 hours

Format - Clarity

Ambiguous - Verifiable

Measure of Performance - Attainable

Two Requirements

What are Requirements

• The User Shall be able to manage maintenance schedule periodicity

• MoP: First Line and Second Line maintenance iaw Maintenance Policy Documentation.

• The User Shall be able to aggregate Maintenance Information

• MoP: First and Second line records within 20 seconds, including

Component Asset data iaw with Standard xyz

Verifiable? – Can it be Tested

Constraints – Provenance Attainable – Performance, Cost, Technology

Unambiguous – Clear no jargon, “What” not “How”

Format – “Shall”

What are Requirements • Necessary – Duplication, Over Specification

• Attainable – Realistic, MoEs, MoPs

• Verifiable – Can they be Tested or Proved – Who proves a Database’s User Friendliness?

• Traceable – To Key User Requirements, Mandatory, Safety, Legislative, External

• Unambiguous – “Shall” and Systems Technical Language

• Formatted – Is it a vehicle, platform, system of car? Use the same Terms and Record them

Why Capture Requirements 1. How can you Accept a product without knowing the expectations

or exit criteria?

2. How can you Handover to the Client / Sponsor if you don’t know what your Handing Over?

3. So, how can you design and build a project if you don’t know the User Needs or Expectations?

4. How can you design and build a project if you don’t know the Requirements translated from the User Needs?

Why Capture Requirements

• No Time, No Resource, No Funding ?

• You can build a solution: • Is it the right Solution?

• Are you wasting Effort?

• Do you know really?

• Do you know the User Needs?

• Or are they your Needs?

It stops on Handover and Acceptance

Why Capture Requirements • Range of Project Failures 50 – 70 % due to poor or no requirements definition

• Divergent Expectations – Lack of Stakeholder Engagement and Understanding

• User Needs:

• Understanding

• Translation into Neutral Format

• Level of Performance and Effectiveness

• Capabilities

• Scope included or missing

Why Capture Requirements

• Sets a common agreement of what is Expected for Success

• Takes all Stakeholders perception into account

• It provides a logical structure to Plan from

• It provides a logical structure to develop and deliver your products from

• It sets a framework for acceptance

• It sets expectations at the start of project initiation of handover criteria

Time Restricted Requirements Concept Assessment Demonstration Manufacture In-Service Disposal

Capability Requirements

Acquisition Requirements

Production Requirements

Support Requirements

Disposal Requirements

Functional Non-Functional Context

Requirements

Environmental Safety

Systems Services

Operations Organisation Domain

Who captures Requirements

• Requirements Manager

• Systems Engineering Team

• Requirements Management and Database Administration

Principles and Methods

Concept of Operation

Requirements

Detailed Specs

Implement

Acceptance & Validation

System Verification

Integration & Test

Capability Scope

Stakeholders

System Modelling

Design Methodology

Verify Design - Analysis

Verify Design - Integration Test

Validate Solution

Validate Capabilities

Multiple Use Cases

Gap Analysis

Risk Mitigation

Opportunity Management

Assurance

Systems of Systems

User Expectations

Needs

Issues to address

• Involve all Stakeholders – Not just the Easiest to engage

• Scope and Time Constraints – Objectives and Aims

• Get the Buy-In and Endorsement

• Stakeholder Engagement – Plan it, have a Strategy

• Engage Stakeholders – Continually Develop and Communicate

• Ensure Stakeholders understand the Intent and Requirements

Stakeholder Management

Maintenance Team

Operations Team

Flight Planning And Ops Supply Chain

Corporate

External Freight

Forwarder

Suppliers

Suppliers

Suppliers

Design Engineers

Developers

DBAs

Support Develop Configuration

Assets Configuration

Safety Operations Feedback Configuration

Maintenance Actions Defects Skills Assets

Stakeholder Management

• Systems Construction – Strategic bigger picture

• Understand the Scope

• Understand the Time Boundaries – Lifecycle Phases

• Understand the Capabilities

• Map out the Stakeholders

• Problems are Wicked – General no one Solution

• Users have multiple Diverse Viewpoints

Stakeholder Management

Observer • Understand the bigger picture

• Understand the Dynamics

• Map the engagement plan

• Who has influence, power and is supportive?

• Who needs developing, training and engaging?

• What's the message, deliver a direct communication message?

• Does the balance of power change across the Lifecycle?

Stakeholder Management

Participative • Execute the Engagement Plan

• Embed into the Users domain

• Translate their Needs and Solutions

• Use Requirements Language and Anatomy

• No personal inflections

• Agile and Adaptable – Communication Language

Stakeholder Management • Externalisation – Observer and Document

• Participative – Understanding the User

• Management of Perceptions and Unification

• Language and Communication Methods

• We don’t see what we see ; We see what we Perceive Einstein and Heisenberg

Managing Requirements

• Project Scope

• Small – Large

• Single or Multiple Requirements Sets

• Duration – 2 weeks or 20 years?

• Spreadsheet or Relational Database?

• Update and Assurance

Managing Requirements

Flash to Bang

• Quick Capture

• Small Stakeholder Group

• One Requirements Manager

• Single Engineering and Test Teams

• One-Off Deliver

Capture

Plan

Deliver

Verify Validate

Managing Requirements

Long Lead Time

• Cyclical Capture “Axial Development”

• Large Multiple Stakeholder Group

• Many Requirements Managers - Integration

• Multiple Systems and Test Teams

• Incremental and Phased Delivery

Capture

Plan

Deliver

Verify Validate

Structuring Requirements

• Fit Users Understanding – Stakeholders

• Multiple Views – Cut - sets

• Think Visualisation

Capabilities

Functions

Engineering

Maintenance Tooling Systems

Functions

Information

Defects Assets Change

Structuring Requirements

Capabilities

Maintenance

Tooling Systems

Defects

Assets

Operations

Supply Planning

Maintenance Assets

External

Structuring Requirements Capabilities

A A A A

A A A A A A A A

A A A A A A A A

A A A A A A A A

A A A A A A A A

• Functional / Non-Functional – Views – Logical

• Hierarchical

• Relational – Interdependent

• External – Relational or Non-Relational

Capabilities

A

A

A

Non-Relational

Relational

Traceability – User, System, Interfaces

Testing Requirements

• Sets Resource Required

• Sets Expectations for Acceptance

• Define Exit Criteria

• Verify During Assessment

• Are we building the right Solution?

• Validate Demonstration onwards

• Have we built the right Solution?

Verification

Documentation

Modelling

Analysis

Validation

Inspection

System Assurance

Capability Assurance

Lifecycle Time (t)

Simulation

Product Assurance

Summary • Requirements – Help you fight the battle

• They help you understand your own biases

• They help the User understand their needs

• Enables you to be more effective in developing the Solution

• Enables you to manage the developing Solution more effective

• Enables you plan your Efforts, Resources, Risks, Opportunity's and Success

Upfront investment for longer term gains – Set the Vision and Direction

This presentation was delivered at an APM

event

To find out more about upcoming events

please visit our website

www.apm.org.uk/events