requirements management by dr matthew bell
TRANSCRIPT
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
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