Requirements management by Dr Matthew Bell

1. Requirements Management
By Matthew Bell

2. Introduction
• What, Why, When and Who?
• Principles, Methods and Issues
• Stakeholder Management
• Management
• Acceptance
• Verification and Validation

3. What are Requirements
The Industry Service
Provider
The Long Term Programme
Started 10 years ago
The Modern User The University Grad
Or IT Lover

4. What are Requirements
Beware: We perceive things in Solutions not in Requirements

5. 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

6. 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

7. 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

8. What are Requirements
• Definition:
• A requirement is a need, expectation, or obligation. It can be stated or
impliedby an organization, its customers, or other
interestedparties.
ISO 9000:2015

9. What are Requirements
• The Software canmanage maintenance schedule periodicity
• The User wouldlikeall first line maintenance periodicities
• The User would like all first line maintenance periodicities andassets
• 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

10. What are Requirements
• The User Shallbe able to manage maintenance schedule periodicity
• MoP: First Line and Second Line maintenance iaw Maintenance
Policy Documentation.
• The User Shallbe 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 – ProvenanceAttainable – Performance, Cost, Technology
Unambiguous – Clear no jargon, “What” not “How”
Format – “Shall”

11. 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

12. 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?

13. 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

14. 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

15. 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

16. 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

17. Who captures Requirements
• Requirements Manager
• Systems Engineering Team
• Requirements Management and Database Administration

18. 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

19. 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

20. Stakeholder Management
Maintenance
Team
Operations
Team
Flight Planning
And OpsSupply 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

21. 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

22. 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?

23. 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

24. 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

25. Managing Requirements
• Project Scope
• Small – Large
• Single or Multiple Requirements Sets
• Duration – 2 weeks or 20 years?
• Spreadsheet or Relational Database?
• Update and Assurance

26. 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

27. 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

28. Structuring Requirements
• Fit Users Understanding – Stakeholders
• Multiple Views – Cut - sets
• Think Visualisation
Capabilities
Functions
Engineering
Maintenance Tooling Systems
Functions
Information
Defects Assets Change

29. Structuring Requirements
Capabilities
Maintenance
ToolingSystems
Defects
Assets
Operations
SupplyPlanning
Maintenance Assets

30. External
Structuring Requirements
Capabilities
A A A A
A A A AA A A A
A A A AA A A A
A A A AA A A A
A A A AA 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

31. 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

32. 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

33. This presentation was delivered at an APM
event
To find out more about upcoming events
please visit our website
www.apm.org.uk/events