Requirements Gathering and Management Alan McSweeney

Method for IT Strategy and Architecture - Requirements “ What do Customers Really Want?”

Method for IT Strategy and Architecture - Requirements Agenda: What is Requirements Methodology? Why is it Used? When is it Used? How is it Managed?

Agenda:

What is Requirements Methodology?

Why is it Used?

When is it Used?

How is it Managed?

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? ‘ A body 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

What is Requirements Methodology?

The answer is in three parts:

Firstly, what do we mean by a Methodology?

‘ A body 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

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

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

SD Method for IT Strategy and Architecture - Requirements Requirements Management 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. Requirements Development 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. Gather Analyse Stages and Activities of Requirements Methodology Review Requirements Development Requirements Management STAGES ACTIVITIES Assess Capture Change Assess Capture Change

Requirements Management

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.

Requirements Development

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.

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

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

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

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

System Dynamics Approach Business requirements drive strategy and architecture Capturing business requirements is essential Define key principles/policies/critical success factors for IT Requirements Strategy Architecture Implementation Business Functional Technical Implementation

Business requirements drive strategy and architecture

Capturing business requirements is essential

Define key principles/policies/critical success factors for IT

V Lifecycle Approach V Project Initiation Project Closure System Requirements System Testing High-Level Design Integration Testing Low-Level Design Component Testing Install and Implement Define Requirements and Solution Deliver Solution and Fulfil Requirements

Requirements Definition and Documentation Requirements Definition Requirements Management Gather Analyse Review Assess Capture Change

Requirements Definition

Requirements Management

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.

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.

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

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

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)

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)

Functional Requirements Inputs Outputs Actions Responses Outcomes Usage

Inputs

Outputs

Actions

Responses

Outcomes

Usage

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)

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)

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

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

Project Requirements Implementation Testing Facilities

Implementation

Testing

Facilities

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

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

More Information Alan McSweeney [email_address]

Alan McSweeney

[email_address]