The document discusses requirements gathering and management methodology. It defines methodology as a body of practices used in a discipline. Requirements methodology captures, synthesizes, verifies and manages customer requirements. There are two key outputs: an objectives and requirements specification and an optional functional specification. The methodology involves gathering, analyzing, reviewing, assessing, capturing and changing requirements. It should be used anytime a project has customer requirements and be tailored to each specific project.

1. Requirements Gathering and Management Alan McSweeney

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

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

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

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

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

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

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

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

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

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

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

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

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

15. Functional Requirements Inputs Outputs Actions Responses Outcomes Usage

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

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

18. Project Requirements Implementation Testing Facilities

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

20. More Information Alan McSweeney [email_address]