Requirements Gathering

and Management

Alan McSweeney
Method for IT Strategy and Architecture -
Requirements

“What do Customers Really Want?”

November 26, 2009 2

Method for IT Strategy and Architecture -
Requirements
• Agenda:

− What is Requirements Methodology?

− Why is it Used?

− When is it Used?

− How is it Managed?

November 26, 2009 3

Method for IT Strategy and Architecture -
Requirements
• What is Requirements Methodology?
• The answer is in three parts:
• Firstly, what do we mean by a Methodology?
• ‘Abody of practices, procedures, and rules
used by those who work in a discipline or engage in an
inquiry’ Add to this a rich set of tools and best
practices to give a better view

November 26, 2009 4

Method for IT Strategy and Architecture -
Requirements
• And so what about Requirements?

• The Method for IT Strategy & Architecture — Requirements

• is a methodology which captures, synthesises, verifies and manages the
requirements that a customer has

• It is designed to work alongside other delivery methodologies, being very

much part of the initial phases of a project but is also involved in further
development cycles

• There are two key outputs:

− An Objectives and Requirements Specification and (optionally)
a Functional Specification

November 26, 2009 5

Method for IT Strategy and Architecture -
Requirements
STAGES

Requirements Development Requirements Management

pt ure pt ure
Ca Ca

Asse

Asse
ACTIVITIES Gather Analyse Review

ss

ss
Cha Cha
ng e ng e

Stages and Activities of Requirements Methodology

Requirements Development Requirements Management

• Gather — Tasks relating to the initial
gathering of requirements (uses
numerous techniques).
• Analyse — Analysing and categorising
requirements. Specifying them.
• Review — Agreeing (with the customer)
exactly what the requirements are.
Modify if necessary to reach agreement.
• Capture — Ensure that the new
requirements or change requests are
captured and notated.
• Assess — Consider whether the changes
will be actioned. Approve or reject.
• Change — Undertake the changes.

November 26, 2009 6

Method for IT Strategy and Architecture -
Requirements
• Why is it used? A number of reasons. The main ones being:

− It is vital that the customer understand and agree on the

requirements from the outset

− There is NO room for ambiguity

− Correcting wrongly specified requirements later is expensive —

for the customer

− A common approach to definition and management is something that

can be continually improved (so quality is always increased)

− We must have a system to capture and manage requirements changes

November 26, 2009 7

Method for IT Strategy and Architecture -
Requirements
• When should it be used?

• Any time a project or assignment has customer requirements

• Each project is different, so it should be tailored to specific needs

November 26, 2009 8

 Approach

• Business requirements drive strategy and architecture

• Capturing business requirements is essential
• Define key principles/policies/critical success factors for
IT

Business

Functional
Requirements Strategy Architecture Implementation
Technical

Implementation

November 26, 2009 9

V Lifecycle Approach

Project Project
Initiation Closure
De

System System
fin

Requirements Testing
eR

fil
eq

nts Ful
uir

Integration
em

High-
High-Level

me and
Design Testing
en

qu on
ts

Re oluti
an

ire
dS

Low-
Low-Level Component

S
olu

er
Design Testing

liv
tio

De
n

Install and
Implement

November 26, 2009 10

Requirements Definition and Documentation

• Requirements Definition

Gather Analyse Review

• Requirements Management

p ture
Ca

Asse
ss
Cha
nge

November 26, 2009 11

Requirements Definition

• Gather— Tasks relating to the initial gathering of

requirements

• Analyse — Analysing and categorising requirements and

specifying them

• Review— Agreeing (with the customer) exactly what the

requirements are. Modify if necessary to reach
agreement.

November 26, 2009 12

Requirements Classification

• Business — objectives and goals to be delivered as a

result of the solution
• Functional — what it does
• Technical — operational and procedural constraints
• Implementation — how the solution will be
implemented
• Project — requirements of the project

November 26, 2009 13

Business Requirements

• Financial (Market share increase)

• Customer-related (On-time delivery)
• Business Processes (Business cycle times)
• Innovation
and Learning Measures (Speed of
completing transactions)
• Regulatory Requirements (Adherence to regulations)

November 26, 2009 14

Functional Requirements

• Inputs

• Outputs

• Actions

• Responses

• Outcomes

• Usage

November 26, 2009 15

Technical Requirements

• Performance (Response times, transaction throughput rates, batch job

durations.)
• Volumes (Data capacity, network bandwidth, business units)
• Availability (Required uptime, daytime periods for which the system must be
available)
• Resilience (No single point of failure, MTBF of components, switchover times)
• Recoverability (Backup times, tolerable data loss, offsite needs, recovery
timescales)
• Scalability (How the solution will deal with more users/data, capability for
predicted growth)
• Integrity (Degree of problems tolerated, problem detection needs)
• Interfaces (Internal and external, user, hardware, software, communications)
• IT Management (Event handling and classification, detection needs,
management roles and processes)

November 26, 2009 16

Implementation Requirements

• Timescales (What are the desired target dates)

• Disruption and Impact (What levels of disruption can be
tolerated)
• Data Conversion (What data needs to be migrated, how, and
with what constraints)
• Supportability (What levels of support will be needed)
• Training (What staff require what new skills)
• Handover (Process of transfer of control, parallel run)
• Support
• Warranty (Coverage during warranty)
• Post-Warranty
• Operation

November 26, 2009 17

Project Requirements

• Implementation

• Testing

• Facilities

November 26, 2009 18

Requirements Management

• Capture — Ensure that the new requirements or change

requests are captured

• Assess— Consider whether the changes will be

actioned. Approve or reject

• Change — Undertake the changes

November 26, 2009 19

More Information

Alan McSweeney
alan@alanmcsweeney.com

November 26, 2009 20