Requirements Gathering IrishDev 7 04 v0 2

Download
Share  Add to  Flag Embed
Uploaded from authorPOINTLite
Views:
 
Category: News & Reports..
     
 
License:   All Rights Reserved

Presentation Description

No description available.

Comments

 

By: vazquezr (44 month(s) ago)

Felipe, can I please have a copy of this powerpoint? I am teaching a class at the local college on this subject and would love to use some of this content. Please let me know. Thank you! Rob

Presentation Transcript

Gathering Requirements - Creating the Right Solution: 

Gathering Requirements - Creating the Right Solution Hugh Ivory Best Outcomes IrishDev Developer Day 2 7th July 2004

Overview: 

Overview Introduction What is “the Right Solution”? Taking a Business Perspective Increasing your chances of success Framework & some Techniques Questions

Introduction: 

Introduction Hugh Ivory, Founder Best Outcomes Growing Irish-based consultancy specialising in Project Management, Facilitation and Consulting using the Business Centred Development approach Certified DSDM Practitioner DSDM Regional Interest Group Co-ordinator for Ireland

What is “the Right Solution”?: 

What is “the Right Solution”? In line with Business Strategy and Objectives Fulfils agreed requirements of all users / stakeholders Enables delivery of business value at the appropriate time Can be sustained by the organisation at a cost which it is prepared to pay (Cost of Ownership) ‘Fit for business purpose’ The right solution normally evolves as we understand more about the problem.

Taking a Business Perspective: 

Taking a Business Perspective Understand the big picture – what is really in/out of scope Involve Empowered Stakeholders – the right people End Users Product Development Technical Architect Testers ………… Different Stakeholders may have competing requirements. Sponsor may need to adjudicate Understand the Impact on the existing operation (people and processes) Remember Training and Communications

Types of Requirements: 

Types of Requirements Functional Requirements What does the solution need to do / not do ? What features does it need to have / not have ? Non-Functional Requirements – the “ITY’s” Usability Maintainability Supportability Security Resilience Performance Constraints & Assumptions will influence requirements

So much to consider : 

So much to consider Non Functional Rqts Feasibility Customer Rqts Competing Stakeholder Rqts Functional Rqts Business Strategy Impact on Current Operation Varying levels of understanding

Increase your chances of success: 

Increase your chances of success By using practices which help us to Be clear and agreed about the overall objective Give some structure and confidence level that requirements have been sufficiently agreed between the stakeholders Enable us to control evolution Consider use of best practice framework e.g. Business Centred Development Concentrate on satisfying the true business needs It is impractical to build systems perfectly first time Change and clarification of requirements is inevitable Active involvement of empowered users is imperative

The Business Centred Development Framework: 

The Business Centred Development Framework Pre-Project Post Project Business Strategy Baselined Requirements Agreed Functionality Built and Tested Feature

Business Centred Development Techniques: 

Business Centred Development Techniques Aid Collaboration and help to control evolution of Requirements Some techniques to help with Requirements Facilitated Workshops Business Modelling MoSCoW Prioritisation Timeboxing Controlled prototyping

Facilitated Workshops: 

Facilitated Workshops Used throughout Agile Projects to achieve Speed Decisions made in days, not months Ownership All stakeholders present Productivity Ideas born and grown quickly Overall perspective Wider involvement of participants possible Consensus Agreement and acceptance from empowered stakeholders Quality decision making All parties hearing the same information

Business Modelling: 

Business Modelling Purpose is to create shared understanding: Use whatever approach will work best to create a shared understanding of what is required Keep it Simple – simple language and tools encourage participation Do just enough to enable you to move to the next stage

MoSCoW Prioritisation: 

MoSCoW Prioritisation Why prioritise? Not enough time or resources to do everything Lack of money or lack of people (or both) Not enough time or resources to respond to changes MoSCoW means important things are done first Musts and Shoulds often deliver 80% of total business benefit MoSCoW priorities drive sequence of delivery

Timeboxing: 

Timeboxing Short, focused, immovable checkpoints Agreed and fixed time period where requirements are gathered / functionality is developed Typically 2-6 weeks Focus is on delivery Deliveries agreed by team, including Ambassador User Concentrates on top priorities Contents of timebox are MoSCoWed Controls function drift

Timeboxing: 

Timeboxing

Controlled Prototyping: 

Controlled Prototyping Evolutionary and incremental prototyping DSDM prototypes evolve to become the working solution Prototyping within a controlled process Investigate, Refine, Consolidate Gives regular opportunities to demonstrate progress and check direction Build the right (business) system before you build it right (technically) Requirement Solution

Let’s try out a few techniques…: 

Let’s try out a few techniques… Facilitated Workshop Define objective & gather requirements Prioritise - MoSCoW Must Have Solution is useless without this) Should Have Important but could work around without it in the short term Could Have Useful – bells & whistles Won’t Have (This time round) Less important – can be left until later Timebox Planning

…Identify Requirements: 

…Identify Requirements Objective : To build a House that a couple can move into in 2 months

House Requirements: 

House Requirements Foundations & Blockwork Electrical Wiring Plumbing Bathroom Garage Shed Curtains Doors & Windows Furniture Kitchen Bedrooms Roof Garden Interior Paint Exterior Paint Driveway Jacuzzi Heating Home Cinema Patio Environment Friendly Low maintenance

…Prioritise Requirements…: 

…Prioritise Requirements…

Prioritising - MoSCoW: 

Prioritising - MoSCoW Interior Paint C Exterior Paint W Foundations & Blockwork M Electrical Wiring M Plumbing M Bathroom M Garage S Shed S Curtains S Doors & Windows M Heating M Low maintenance S Furniture S Kitchen M Bedrooms M Patio C Jacuzzi W Driveway C Environment Friendly C Garden S Roof M Home Cinema C

…arrange Requirements into Timeboxes: 

…arrange Requirements into Timeboxes

Timeboxing: 

Timeboxing Timebox 1 2 weeks Timebox 2 2 weeks Timebox 3 2 weeks Timebox 4 2 weeks

…new Requirement?: 

…new Requirement? Here’s how…

Timeboxing – new requirement?: 

Timeboxing – new requirement? Timebox 1 2 weeks Timebox 2 2 weeks Timebox 3 2 weeks Timebox 4 2 weeks

Get Real about Requirements: 

Get Real about Requirements Requirements can and do evolve Requirements must be defined at increasing levels of granularity as we move through the development lifecycle Use agile frameworks and techniques to guide you through this evolution Involve the right people – all Stakeholders at the appropriate time : ‘Collaborate’ Focus on real business objective / strategy. This will help prioritisation of delivery.

Questions?: 

Questions? More information www.bestoutcomes.ie hugh@bestoutcomes.ie Other events which may be of interest: Agile Business Conference, London 2004 www.agileconference.org