Requirements Gathering And Management

7,633 views

Published on

Published in: Technology, Education, Business
3 Comments
11 Likes
Statistics
Notes
No Downloads
Views
Total views
7,633
On SlideShare
0
From Embeds
0
Number of Embeds
93
Actions
Shares
0
Downloads
599
Comments
3
Likes
11
Embeds 0
No embeds

No notes for slide
  • SD have defined the architecture of methodologies. All development work is based upon this architecture. Key components of this architecture are : Process Structure : Stages-Activities-Tasks Roles: who does what Techniques: Best practice ways of doing things Deliverables: what gets produced Tools: Checklists, templates, etc.
  • Requirements methodology is one on the methods within the IT Strategy & Architecture process group. Its not a large complex methodology, but it is extremely important, so stands on its own. It is tightly integrated to the Project Management methodology.
  • The management stage is iterative in nature, being able to be performed many times. This is because changes cannot be predicted. Note that the development stage can start very early on in the project lifecycle.
  • Having a standard approach to specifying requirements gives us the opportunity to fine engineer the process and so keep making it better. The nirvana is always to get all the requirements perfectly specified and agreed, first time.
  • Who has ever heard of a project where there are no customer requirements? But the methodology is flexible, and bits can be changed or taken out to suit.
  • Requirements Gathering And Management

    1. 1. Requirements Gathering and Management Alan McSweeney
    2. 2. Method for IT Strategy and Architecture - Requirements “ What do Customers Really Want?”
    3. 3. Method for IT Strategy and Architecture - Requirements <ul><li>Agenda: </li></ul><ul><ul><li>What is Requirements Methodology? </li></ul></ul><ul><ul><li>Why is it Used? </li></ul></ul><ul><ul><li>When is it Used? </li></ul></ul><ul><ul><li>How is it Managed? </li></ul></ul>
    4. 4. Method for IT Strategy and Architecture - Requirements <ul><li>What is Requirements Methodology? </li></ul><ul><li>The answer is in three parts: </li></ul><ul><li>Firstly, what do we mean by a Methodology? </li></ul><ul><li>‘ 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 </li></ul>
    5. 5. Method for IT Strategy and Architecture - Requirements <ul><li>And so what about Requirements? </li></ul><ul><li>The Method for IT Strategy & Architecture – Requirements </li></ul><ul><li>is a methodology which captures, synthesises, verifies and manages the requirements that a customer has </li></ul><ul><li>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 </li></ul><ul><li>There are two key outputs: </li></ul><ul><ul><li>An Objectives and Requirements Specification and (optionally) a Functional Specification </li></ul></ul>
    6. 6. SD Method for IT Strategy and Architecture - Requirements <ul><li>Requirements Management </li></ul><ul><li>Capture – Ensure that the new requirements or change requests are captured and notated. </li></ul><ul><li>Assess – Consider whether the changes will be actioned. Approve or reject. </li></ul><ul><li>Change – Undertake the changes. </li></ul><ul><li>Requirements Development </li></ul><ul><li>Gather – Tasks relating to the initial gathering of requirements (uses numerous techniques). </li></ul><ul><li>Analyse – Analysing and categorising requirements. Specifying them. </li></ul><ul><li>Review – Agreeing (with the customer) exactly what the requirements are. Modify if necessary to reach agreement. </li></ul>Gather Analyse Stages and Activities of Requirements Methodology Review Requirements Development Requirements Management STAGES ACTIVITIES Assess Capture Change Assess Capture Change
    7. 7. Method for IT Strategy and Architecture - Requirements <ul><li>Why is it used? A number of reasons. The main ones being: </li></ul><ul><ul><li>It is vital that the customer understand and agree on the requirements from the outset </li></ul></ul><ul><ul><li>There is NO room for ambiguity </li></ul></ul><ul><ul><li>Correcting wrongly specified requirements later is expensive – for the customer </li></ul></ul><ul><ul><li>A common approach to definition and management is something that can be continually improved (so quality is always increased) </li></ul></ul><ul><ul><li>We must have a system to capture and manage requirements changes </li></ul></ul>
    8. 8. Method for IT Strategy and Architecture - Requirements <ul><li>When should it be used? </li></ul><ul><li>Any time a project or assignment has customer requirements </li></ul><ul><li>Each project is different, so it should be tailored to specific needs </li></ul>
    9. 9. System Dynamics Approach <ul><li>Business requirements drive strategy and architecture </li></ul><ul><li>Capturing business requirements is essential </li></ul><ul><li>Define key principles/policies/critical success factors for IT </li></ul>Requirements Strategy Architecture Implementation Business Functional Technical Implementation
    10. 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. 11. Requirements Definition and Documentation <ul><li>Requirements Definition </li></ul><ul><li>Requirements Management </li></ul>Gather Analyse Review Assess Capture Change
    12. 12. Requirements Definition <ul><li>Gather – Tasks relating to the initial gathering of requirements </li></ul><ul><li>Analyse – Analysing and categorising requirements and specifying them </li></ul><ul><li>Review – Agreeing (with the customer) exactly what the requirements are. Modify if necessary to reach agreement. </li></ul>
    13. 13. Requirements Classification <ul><li>Business – objectives and goals to be delivered as a result of the solution </li></ul><ul><li>Functional – what it does </li></ul><ul><li>Technical – operational and procedural constraints </li></ul><ul><li>Implementation – how the solution will be implemented </li></ul><ul><li>Project – requirements of the project </li></ul>
    14. 14. Business Requirements <ul><li>Financial (Market share increase) </li></ul><ul><li>Customer-related (On-time delivery) </li></ul><ul><li>Business Processes (Business cycle times) </li></ul><ul><li>Innovation and Learning Measures (Speed of completing transactions) </li></ul><ul><li>Regulatory Requirements (Adherence to regulations) </li></ul>
    15. 15. Functional Requirements <ul><li>Inputs </li></ul><ul><li>Outputs </li></ul><ul><li>Actions </li></ul><ul><li>Responses </li></ul><ul><li>Outcomes </li></ul><ul><li>Usage </li></ul>
    16. 16. Technical Requirements <ul><li>Performance (Response times, transaction throughput rates, batch job durations.) </li></ul><ul><li>Volumes (Data capacity, network bandwidth, business units) </li></ul><ul><li>Availability (Required uptime, daytime periods for which the system must be available) </li></ul><ul><li>Resilience (No single point of failure, MTBF of components, switchover times) </li></ul><ul><li>Recoverability (Backup times, tolerable data loss, offsite needs, recovery timescales) </li></ul><ul><li>Scalability (How the solution will deal with more users/data, capability for predicted growth) </li></ul><ul><li>Integrity (Degree of problems tolerated, problem detection needs) </li></ul><ul><li>Interfaces (Internal and external, user, hardware, software, communications) </li></ul><ul><li>IT Management (Event handling and classification, detection needs, management roles and processes) </li></ul>
    17. 17. Implementation Requirements <ul><li>Timescales (What are the desired target dates) </li></ul><ul><li>Disruption and Impact (What levels of disruption can be tolerated) </li></ul><ul><li>Data Conversion (What data needs to be migrated, how, and with what constraints) </li></ul><ul><li>Supportability (What levels of support will be needed) </li></ul><ul><li>Training (What staff require what new skills) </li></ul><ul><li>Handover (Process of transfer of control, parallel run) </li></ul><ul><li>Support </li></ul><ul><li>Warranty (Coverage during warranty) </li></ul><ul><li>Post-Warranty </li></ul><ul><li>Operation </li></ul>
    18. 18. Project Requirements <ul><li>Implementation </li></ul><ul><li>Testing </li></ul><ul><li>Facilities </li></ul>
    19. 19. Requirements Management <ul><li>Capture – Ensure that the new requirements or change requests are captured </li></ul><ul><li>Assess – Consider whether the changes will be actioned. Approve or reject </li></ul><ul><li>Change – Undertake the changes </li></ul>
    20. 20. More Information <ul><ul><ul><li>Alan McSweeney </li></ul></ul></ul><ul><ul><ul><li>[email_address] </li></ul></ul></ul>

    ×