Requirements Gathering And Management
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Requirements Gathering And Management as PDF for free.
More details
- Words: 966
- Pages: 20
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 • The
is Requirements Methodology?
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
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
Gather
Analyse
ure
Review Cha ng
e
pt Ca
ure
Cha ng
ss Asse
pt Ca
ss Asse
ACTIVITIES
Requirements Management
e
Stages and Activities of Requirements Methodology
Requirements Development • Gather — Tasks relating to the initial
gathering of requirements (uses numerous techniques).
Requirements Management • Capture — Ensure that the new
requirements or change requests are captured and notated.
• Analyse — Analysing and categorising requirements. Specifying them.
• Assess — Consider whether the changes will be actioned. Approve or reject.
• Review — Agreeing (with the customer) exactly what the requirements are. Modify if necessary to reach agreement.
• 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 • Define
business requirements is essential
key principles/policies/critical success factors for
IT
Business Functional Technical
Requirements
Strategy
Architecture
Implementation
Implementation
November 26, 2009
9
V Lifecycle Approach Project Closure
Project Initiation
De liv er S Re oluti qu on ire me and nts Ful fil
n tio olu dS an ts en em uir eq eR fin De
System Testing
System Requirements
Integration Testing
HighHigh-Level Design
Component Testing
LowLow-Level Design
Install and Implement
November 26, 2009
10
Requirements Definition and Documentation • Requirements Gather
• Requirements
Definition Review
Analyse
Management
ss Asse
ure t p Ca
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 • Technical
— what it does
— operational and procedural constraints
• Implementation
— how the solution will be
implemented • Project
November 26, 2009
— requirements of the project
13
Business Requirements • Financial
(Market share increase)
• Customer-related • Business
(On-time delivery)
Processes (Business cycle times)
• Innovation
and Learning Measures (Speed of completing transactions)
• Regulatory
November 26, 2009
Requirements (Adherence to regulations)
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
November 26, 2009
— Undertake the changes
19
More Information Alan McSweeney [email protected]
November 26, 2009
20
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 • The
is Requirements Methodology?
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
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
Gather
Analyse
ure
Review Cha ng
e
pt Ca
ure
Cha ng
ss Asse
pt Ca
ss Asse
ACTIVITIES
Requirements Management
e
Stages and Activities of Requirements Methodology
Requirements Development • Gather — Tasks relating to the initial
gathering of requirements (uses numerous techniques).
Requirements Management • Capture — Ensure that the new
requirements or change requests are captured and notated.
• Analyse — Analysing and categorising requirements. Specifying them.
• Assess — Consider whether the changes will be actioned. Approve or reject.
• Review — Agreeing (with the customer) exactly what the requirements are. Modify if necessary to reach agreement.
• 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 • Define
business requirements is essential
key principles/policies/critical success factors for
IT
Business Functional Technical
Requirements
Strategy
Architecture
Implementation
Implementation
November 26, 2009
9
V Lifecycle Approach Project Closure
Project Initiation
De liv er S Re oluti qu on ire me and nts Ful fil
n tio olu dS an ts en em uir eq eR fin De
System Testing
System Requirements
Integration Testing
HighHigh-Level Design
Component Testing
LowLow-Level Design
Install and Implement
November 26, 2009
10
Requirements Definition and Documentation • Requirements Gather
• Requirements
Definition Review
Analyse
Management
ss Asse
ure t p Ca
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 • Technical
— what it does
— operational and procedural constraints
• Implementation
— how the solution will be
implemented • Project
November 26, 2009
— requirements of the project
13
Business Requirements • Financial
(Market share increase)
• Customer-related • Business
(On-time delivery)
Processes (Business cycle times)
• Innovation
and Learning Measures (Speed of completing transactions)
• Regulatory
November 26, 2009
Requirements (Adherence to regulations)
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
November 26, 2009
— Undertake the changes
19
More Information Alan McSweeney [email protected]
November 26, 2009
20
Related Documents
Requirements Gathering And Management
June 2020 4
Gathering Performance Requirements
November 2019 4
De 201 Requirements Management
November 2019 14
Cockpit For Requirements Management
November 2019 22
Business Requirements And System Requirements
November 2019 38
Gathering And Assembling
October 2019 22More Documents from ""
Business Cases And Benefits Management
June 2020 8
