The Myth Of Requirements

Alan McSweeney
http://ie.linkedin.com/in/alanmcsweeney

Myth Of Requirements

Myth is that requirements gathered from business users and

business stakeholders through requirements gathering
meetings and workshops define the scope and functionality of
the solution
Myth is that in order to define the solution, all that is needed is
business requirements
Requirements Solution
Solution Requirements

Solution is always

January 5, 2016

>>

Requirements

Requirements Gathering Exercises

It is unreasonable to expect that business stakeholders in a

potential solution can articulate a set of complete, fullydeveloped consistent requirements through part-time
involvement in a few requirements gathering exercises

This process always causes problems

So who do project managers do this time and time again?

January 5, 2016

Need For Solution Exists Because

I have a problem

I want to be able to do what I am currently unable to do

I cannot do what I want

I need to be able to do something

A solution is a Resolver, a Provider or an Enabler

January 5, 2016

Any Complete Solution Consists of:

Zero or more of {Changes to Existing Systems}

+ Zero or more of {New Custom Developed Applications}
+ Zero or more of {Information Storage Facilities}
+ Zero or more of {Acquired and Customised Software Products}
+ Zero or more of {System Integrations/Data Transfers/Exchanges}
+ Zero or more of {Changes to Existing Business Processes}
+ Zero or more of {New Business Processes}
+ Zero or more of {Organisational Changes}
+ Zero or more of {Reporting and Analysis Facilities}
+ Zero or more of {Existing Data Conversions/Migrations}
+ Zero or more of {New Data Loads}
+ Zero or more of {Training and Documentation}
+ Zero or more of {Central, Distributed and Communications Infrastructure}
+ Zero or more of {Sets of Installation and Implementation Services}
+ Zero or more of {Cutover/Transfer to Production}
+ Zero or more of {Operational Functions and Processes}
+ Zero or more of {Parallel Runs}
January 5, 2016

Scope Of Complete Solution

Changes to Existing
Systems

System
Integrations/Data
Transfers/Exchanges

Reporting and
Analysis Facilities

Central, Distributed
and Communications
Infrastructure

New Custom
Developed
Applications

Changes to Existing
Business Processes

Existing Data
Conversions/
Migrations

Sets of Installation
and Implementation
Services

Information Storage
Facilities

New Business
Processes

Acquired and
Customised Software
Products

Organisational
Changes

New Data Loads

Training and
Documentation

Cutover/Transfer to
Production

Operational
Functions and
Processes

Parallel Runs
January 5, 2016

Complete Solution

Ignoring some of the components of a complete solution will

not make them go away or reduce their need

Complete solution view allows expectations to be managed

Requirements never capture the detail of the complete

solution

Requirements are just one set of constraints imposed on the

solution design

You will just end-up with apparent project changes as the need
for ignored components become actual

Requirements are not delivered it is the solution and its

components that are delivered
January 5, 2016

Myth Of Changing Requirements

It is not requirements that change

It is that latent requirements were not identified or were

ignored that become apparent or unavoidable during
implementation

Undiscovered and unarticulated requirements then impact

other solution components leading to additional
downstream changes which affects the implementation
project

January 5, 2016

A Solution

Solves a problem or provides new functionality or enables a

new or changed way of operating
Any solution also causes problems in terms of:

Required organisational changes to implement and operate solution

Additional operational overhead
Cost to implement

The solution value equation must be:

Value of Problem(s) Solved and Value Delivered

Cost of Problem(s) Caused

January 5, 2016

>>

Cost of Solution Components

Solution Is:

What has to be done

What costs time and money

The minimum set of components that works and that

solves the problem at the minimum cost with minimum
additional costs

Need to maximise solution efficiency and minimise direct

and indirect solution cost

January 5, 2016

10

Solution Is About Value Obtained

Minimise
Cost
Point of
Best Value

Maximise
Value
January 5, 2016

11

Requirements Tend To Be:

Sparse and disconnected

Isolated and disintegrated statements
Inconsistent
Incomplete
Disjointed
Conflicting
Uncosted
Unprioritised
Representations of specific points of functionality that do not
aggregate into a defined solution
A source of additional unstated and implied requirements
January 5, 2016

12

Requirements

The reality is that what is gathered during requirements workshops,

meetings, interviews, questionnaires and other activities are not
solution requirements but business stakeholder requirements
Stakeholder requirements must be translated into solution
requirements which is turn must be translated into a solution design
Requirements gathering is a means to an end and not an end in itself
Requirements gathering should never be part of the delivery project
but be the subject of an analysis and architecture design exercise
prior to any delivery project
You cannot know what the scope of the project is until the solution
that needs to be delivered is known
Never let a project manager near requirements

January 5, 2016

13

Requirements Standards Core

IEEE Standard 830-1998 IEEE Recommended Practice for

Software Requirements Specifications
Superseded by

ISO/IEC/IEEE 29148:2011 Systems and Software

Engineering Life Cycle Processes Requirements
Engineering

January 5, 2016

14

ISO/IEC/IEEE 29148:2011 Systems and Software

Engineering Life Cycle Processes Requirements
Engineering

Proposes five key deliverables

1.
2.
3.
4.
5.

Stakeholder Requirements Specification (StRS) Document

System Requirements Specification (SyRS) Document
Software Requirements Specification (SRS) Document
System Operational Concept (OpsCon) Document
Concept of Operations (ConOps) Document

Very detailed and comprehensive and time-consuming to

produce
Level of detail appropriate to large software product solutions
Not really applicable to other solutions

Not necessarily possible to create these deliverables at the

requirements gathering phase
Substantial design effort required to create these deliverables
January 5, 2016

15

ISO/IEC/IEEE 29148:2011 Stakeholder

Requirements Specification (StRS) Document Scope

Business Purpose
Business Scope
Business Overview
Stakeholders
Business Environment
Goal And Objective
Business Model
Information Environment
Business Processes
Business Operational Policies
And Rules
Business Operational
Constraints
January 5, 2016

Business Operation Modes

Business Operational Quality
Business Structure
User Requirements
Operational Concept

Operational Policies And

Constraints
Description Of The Proposed
System
Modes Of System Operation
User Classes And Other Involved
Personnel
Support Environment

Operational Scenarios
Project Constraints
16

ISO/IEC/IEEE 29148:2011 System Requirements

Specification (SyRS) Document Scope

System Purpose
System Scope
System Overview

System Context
System Functions
User Characteristics

Functional Requirements
Usability Requirements
Performance Requirements
System Interfaces
System Operations
Human System Integration
Requirements
Maintainability
Reliability

January 5, 2016

System Modes And States

Physical Characteristics

Physical Requirements
Adaptability Requirements

Environmental Conditions
System Security
Information Management
Policies And Regulations
System Life Cycle Sustainment
Packaging, Handling, Shipping And
Transportation
Verification
Assumptions And Dependencies

17

ISO/IEC/IEEE 29148:2011 Software Requirements

Specification (SRS) Document Scope

Purpose
Scope
Product Perspective

System Interfaces
User Interfaces
Hardware Interfaces
Software Interfaces
Communications Interfaces
Memory Constraints
Operations
Site Adaptation Requirements

Product Functions
Product Functions
Product Functions
Assumptions And Dependencies
January 5, 2016

Apportioning Of Requirements
Specific Requirements
External Interfaces
Functions
Usability Requirements
Performance Requirements
Logical Database Requirements
Design Constraints
Standards Compliance
Software System Attributes
Verification
Supporting Information
18

ISO/IEC/IEEE 29148:2011 System Operational

Concept (OpsCon) Document Scope

Scope

Scope
Document Overview
System Overview

Referenced Documents
Current System Or Situation

Organisational Structure
Profiles Of User Classes
Interactions Among User Classes
Other Involved Personnel

Support Environment

Justification For And Nature Of Changes

Justification For Changes

Description Of Desired Changes
Priorities Among Changes
Changes Considered But Not Included
Assumptions And Constraints

January 5, 2016

Background, Objectives, And Scope

Operational Policies And Constraints
Description Of The Proposed System
Modes Of Operation
User Classes And Other Involved Personnel

Background, Objectives, And Scope

Operational Policies And Constraints
Description Of The Current System Or Situation
Modes Of Operation For The Current System Or
Situation
User Classes And Other Involved Personnel

Concepts For The Proposed System

Organisational Structure
Profiles Of User Classes
Interactions Among User Classes
Other Involved Personnel

Support Environment

Operational Scenarios
Summary Of Impacts

Operational Impacts
Organisational Impacts
Impacts During Development

Analysis Of The Proposed System

Benefits
Disadvantages And Limitations
Alternatives Considered

19

ISO/IEC/IEEE 29148:2011 Concept of Operations

(ConOps) Document Scope

Purpose
Scope
Strategic Plan
Effectiveness
Overall Operation

Context
Systems
Organisational Unit

Governance

Governance Policies
Organisation
Investment Plan
Information Asset Management
Security
Business Continuity Plan
Compliance

January 5, 2016

20

Extended Requirements Standards And Linkages

Co-Ordinated
With

ISO/IEC TR
24766:2010
Information
Technology
Systems And
Software Engineering
Guide For
Requirements
Engineering Tool
Capabilities

Used With

IEEE 1220 (ISO/IEC

26702) Systems
Engineering
Application And
Management Of The
Systems Engineering
Process

Co-Ordinated
With
Co-Ordinated
With

ISO/IEC/IEEE
24765:2010 Systems
And Software
Engineering
Vocabulary

January 5, 2016

ISO/IEC 25010:2011
Systems And
Software Engineering
Systems And
Software Quality
Requirements And
Evaluation (SQuaRE)
System And
Software Quality
Models

ISO/IEC/IEEE
15288:2002 Systems
And Software
Engineering
System Life Cycle
Processes

Refers To

CoOrdinated
With

ISO/IEC 25030:2007
Software Engineering
Software Product
Quality Requirements
And Evaluation
(SQuaRE) Quality
Requirements
Uses
Elements Of

Used
With

Co-Ordinated
With
ISO/IEC/IEEE
12207:2008 Systems
And Software
Engineering
Software Life Cycle
Processes

Extends

ISO/IEC/IEEE
29148:2011
Systems And
Software
Engineering Life
Cycle Processes
Requirements
Engineering
21

Requirements Standards

Complicated set of standards that are rarely, if ever, applied to

in-house projects
Tend to be used for product development, if at all

Difficult to apply and use without substantial overhead

Suited only to large developments and large organisations

Standards are quite generic and need to be customised to the

needs of the development
Standards are very focused on software product requirements
and associated developments and do not cover wider solution
requirements
Processes contained in the standards lack the customer
interaction dimension
Need a more balanced, realistic and achievable approach to
linking requirements to solution design
January 5, 2016

22

Requirements And Overall Solution

= Specific Requirement
January 5, 2016

= Solution Factor Not Explicitly Listed As Requirement

23

Business Stakeholder Requirements And Solution

Requirements Example
How will intervals be named?
What naming standards, if any,
will apply? What approval
workflow will apply to the
creation of new intervals? Who
will have the right to define
and approve and make changes
to trading intervals?

What is the expected

volume of changes?
How frequently will
intervals change?

How will the

specified period in
the future be defined
and maintained?
January 5, 2016

When an interval
has passed, will it be
retained? If so, for
how long?

Will customers see

only intervals in the
future?

Sample Business Stakeholder Requirement: In the

customer energy trading portal, there shall be a
facility to define intervals (for which the customer
will be able to fix or unfix previously fixed energy
prices at the currently available price) for
individual months, quarters of a year, halves of a
year, summer and winter seasons and full years for
a specified period into the future.

What will happen previously defined intervals in

this specified future period is changed so those
intervals are now partially or completely outside the
period? What will happen customer trades made for
those intervals?

What record is
made of changes?
How long is this
record retained?

What interval definition

and maintenance facility
is required? Should there
be a bulk change/upload
facility? How should it
operate? What
functionality should it
have? How secure
should it be? Who
should have access to it?
24

Business Stakeholder Requirements And Solution

Requirements

Single business stakeholder requirements statement will

contain a large number of implied solution requirements

January 5, 2016

25

Business Stakeholders

These are the business users at all levels in the

organisation who will interact or causes users to interact
with the solution or have a direct interest in the solution

January 5, 2016

26

Characteristics Of A Solution
What It
Does, How It
Operates
the
Functionality

Cost/Time/Risk
To Implement

The
xAbles
January 5, 2016

27

Solution xAbles

Usable
Affordable
Deliverable
Operable
Supportable
Maintainable
Flexible
Adaptable
Capable
Scalable
Reliable
Securable
Available
January 5, 2016

These are very important

operational requirements that
may not be articulated by business
users and stakeholders
They are essential to the success
of the solution and its enduring
operation and use

28

Getting The Solution xAbles Right

January 5, 2016

29

Getting The Solution xAbles Wrong

January 5, 2016

30

Requirements And Standard V Lifecycle Approach

Project
Closure

Project
Initiation

System
Testing

System
Requirements

Integration
Testing

High-Level
Design

Component
Testing

Low-Level
Design

Install and
Implement

January 5, 2016

31

Requirements And Standard V Lifecycle Approach

Simplistic view of solution testing

You do not test requirements you test the functionality

of the overall solution and its ability to deliver on the
business processes

Requirements testing will omit significant elements of

overall solution functionality

You also need to validate the solution xAbles

January 5, 2016

32

Solution Design Process

Initial Concept Of Need/ Goal/ Objective

Formal Statement Of Need/ Goal/

Objective

Initial Architecture Review and Options

Stakeholder Requirements Collection

and Specification

Elicit Stakeholder Requirements

Formalise Stakeholder
Requirements

Solution Requirements Collection and

Specification

Define Solution Requirements

Analyse Solution Requirements

Solution Architecture Design and

Specification

Define Solution Architecture and

Design

Analyse, Evaluate and Refine

Solution Architecture

Implementation Project
January 5, 2016

33

Solution Design Process

Initial Concept Of Need/ Goal/ Objective

Each stage uses the output

from the previous stage as
an input

Detail is refined, extended

and elaborated on in
successive stages

Formal Statement Of Need/ Goal/

Objective

Initial Architecture Review and Options

Stakeholder Requirements Collection

and Specification

Solution Requirements Collection and

Specification

Solution Architecture Design and

Specification

Implementation Project
January 5, 2016

34

Solution Design Process

Stage

Scope

Initial Concept Of Need/

Goal/ Objective

The business have an idea for a solution based on an apparent need to solve a problem, to
do what is currently not possible, to react or respond to an external demand or to be able
to achieve a new objective.
Formal Statement Of
This formalises the initial concept to introduce greater consistency and detail. It serves to
Need/ Goal/ Objective
understand the business, objectives, purposes and potential organisational impacts. It
describes what the ideal solution will do. It also identifies the high-level potential system
impacts.
Initial Architecture Review This uses the formal statement of need to create an initial high-level view of the overall
and Options
solution, its new and existing systems and applications components, the required
functionality, their interfaces, the required processes and the business functions impacted.
This provides a container for the requirements and a vision for the solution.
Stakeholder Requirements This uses this initial architectural review output in a structured way to elicit and formalise
Collection and
the set of stakeholder requirements across the dimensions of functionality and processes.
Specification
Solution Requirements
The solution requirements specification is a fuller, more detailed and elaborated set of
Collection and
solution requirements encompassing all the solution components. This includes the
Specification
requirements explicitly identified by stakeholders and the implied requirements.
Solution Architecture
This is the detailed solution specification derived from the stakeholder and solution
Design and Specification requirements.
Implementation Project
This uses the detailed solution specification to act as an input to project definition and to
create a realistic implementation plan, schedule, set of costs and required resources.
January 5, 2016

35

Solution Design Process

Initial Concept Of Need/ Goal/ Objective

Formal Statement Of Need/ Goal/

Objective

Initial Architecture Review and Options

Stakeholder Requirements Collection

and Specification

Decision Points

There is a decision
point after each
stage where a
decision is made if
it is worthwhile to
proceed to the
next stage

Solution Requirements Collection and

Specification

Solution Architecture Design and

Specification

Implementation Project
January 5, 2016

36

Solution Design Process

Initial Concept Of Need/ Goal/ Objective

Not all concepts

make it all the way
to implementation
Process needs to
accommodate this
Do as little as
possible to achieve
as much as possible
to make an informed
decision on whether
and how to proceed
to the next stage in
the solution journey

Formal Statement Of Need/ Goal/ Objective

Initial Architecture Review and Options

Stakeholder Requirements Collection

and Specification

Solution Requirements Collection

and Specification

Solution Architecture Design

and Specification

Implementation
Project
January 5, 2016

37

Solution Design Process - Iterations

Initial Concept Of Need/ Goal/ Objective

Solution design process is

not necessarily linear

Stages can be iterated a

number of times to
different levels of detail

Formal Statement Of Need/ Goal/

Objective

Initial Architecture Review and Options

Stakeholder Requirements Collection

and Specification

Solution Requirements Collection and

Specification

Solution Architecture Design and

Specification

Implementation Project
January 5, 2016

38

Solution Design Process

Business stakeholder requirements are just one input into

a fully developed solution design

Taking this approach means the solution implementability,

operability, usability, maintainability and supportability
can be quantified in advance

It is only after the solution design is defined and agreed

that the implementation project can be started

January 5, 2016

39

Analysis And Architecture In Solution Design

Analysis is used to gather information and requirements

Analysis does not solve problems or deliver solutions

Analysis is an important step in solution design

Analysis interfaces between the business and IT

Structured approach to gathering requirements in the context

of indicative solution architecture yields greater results

Analysis and architecture translates business stakeholder

requirements into solution requirements

Architecture synthesises and actualises overall solution design

and options from requirements and other constraints
January 5, 2016

40

Architecture Options And Structured Business

Stakeholder Requirements

January 5, 2016

Initial solution view

comprising processes,
functionality, actors and
changes to existing
applications and new
applications will provide
a framework and a
structured approach for
gathering and organising
business stakeholder
requirements

41

Architecture Options And Structured Business

Stakeholder Requirements

January 5, 2016

42

Architecture Options And Structured Business

Stakeholder Requirements
Use this architecture
component view to
define required
functionality

January 5, 2016

43

Architecture Options And Structured Business

Stakeholder Requirements

Initial architecture view provides a scaffold to support

individual requirements

Requirements can be drawn-out by identifying their place

in the overall solution and flow

Requirements then exist within the context of an overall

solution journey and the business processes being enabled
by the solution

January 5, 2016

44

Solution Design Process

Stakeholder
Requirements
Collection and
Specification

Initial Concept
Of Need/ Goal/
Objective
Formal
Statement Of
Need/ Goal/
Objective

Implementation
Project

Solution
Requirements
Collection and
Specification
Initial
Architecture
Review and
Options

Solution
Architecture
Design and
Specification

Solution Design Process

Solution Architecture
Business
Stakeholders

January 5, 2016

Analysis

Solution
Delivery
IT Operations

45

Following A Solution Design Process

Following a solution design process needs solution

leadership and ownership

Lack of solution leadership/solution design authority can

cause subsequent implementation project to take shortcuts or ignore key solution elements

Solution design must be subject to reviews to ensure that

it consists of the minimum set of components that works
and that solves the problem at the minimum cost with
minimum additional costs

January 5, 2016

46

Solution Design Process Attempts To Solve The All

Too Common Problems Of
Lack of response to business needs
Slow and costly solution delivery
High solution maintenance and operation costs
Fragile solutions with many manual workarounds
Excessive and duplicated development effort and
operation
Duplicated and costly investments in many solutions
Siloed applications with lack of integration
Poor return on investment
Too little, too late, not what is wanted or needed

January 5, 2016

47

Business Stakeholder Requirements Scope

Business Solution

Solution purpose and objectives

Organisation and business environment
Organisation and business model

Business Operational and Usage Requirements

Solution components and their requirements
Business functions
Business processes
Information model
Organisation structure
Actors
Component interfaces

Solution Concept

Operational scenarios
Solution operation and use

January 5, 2016

48

Solution Requirements Scope

Solution

Scope, purpose
Solution components and interactions
Solution characteristics

Solution Requirements

Solution components and their functionality and requirements

Solution components and overall solution operation and use
Solution processes
Information model
Solution component interactions and information exchanges
Security architecture
Solution components and overall non-functional requirements
Roles and responsibilities
Solution options
Solution packaging

January 5, 2016

49

Summary

Myth of requirements is that:

Requirements gathered from business users through requirements gathering
meetings and workshops define the scope and functionality of the solution
Requirements gathering workshops at the start of a project are sufficient to
understand business needs
Requirements change

The solution is always greater than the sum of the articulated

business stakeholder requirements
Good solution design requires solution ownership and technical
leadership from the start and throughout the process
Solutions cause as well as fix problems that need to be factored into
the process
Requirements do not belong in the context of a project
Never let a project manager near requirements
January 5, 2016

50

More Information
Alan McSweeney
http://ie.linkedin.com/in/alanmcsweeney

05 January 2016

51