1 / 18

10 Steps to Better Requirements

10 Steps to Better Requirements Larry Fellows Compliance Automation, Inc. Standish Group Survey - 1995 17% On Time & On Budget 33% Cancelled (Cost $81B) 50% Challenged (Cost $59B) Average Challenged Project: 189% Over Budget 222% Behind Schedule

Gabriel
Download Presentation

10 Steps to Better Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 10 Steps to Better Requirements Larry Fellows Compliance Automation, Inc.

  2. Standish Group Survey - 1995 17%On Time &On Budget 33%Cancelled(Cost $81B) 50%Challenged(Cost $59B) Average Challenged Project: 189% Over Budget 222% Behind Schedule Only 61% of originally specified features delivered.

  3. Standish Group Survey - 2002 34%On Time &On Budget 15%Cancelled(Cost $81B) 51%Challenged(Cost $59B)

  4. A Winning Product On Time On Budget Required Functions Right Quality

  5. Step 1 – Define the NEED

  6. Customer Engineering Designers System Engineering Software Marketing Logistics Service Operations Manufacturing Testing Reliability Developers Step 2 – Identify the Stakeholders

  7. Common Knowledge Unique Knowledge Shared Knowledge Stakeholder Knowledge

  8. Common Knowledge Unique Knowledge Shared Knowledge Create Common Vision

  9. Step 3 – Recognize the Drivers Higher Level Requirements Cost Regulations Specification Standards Existing systems & processes User expectations Schedule

  10. Step 4 – Gather Operational Concepts

  11. test hardware other software command & data status command other hardware YourSystem display database Power Physical keyboard Step 5 – Define External Interfaces

  12. Communication problems

  13. Step 6 – Create a Simple Format Who What

  14. Step 7 – Avoid Ambiguous Terminology

  15. Step 8 – Define Requirement Rationale

  16. Step 9 – Capture Verification Method

  17. Step 10 – Use a Standard Template

  18. No Surprises People who write bad requirements should not be surprised when they get bad products But they always are. Ivy Hooks

More Related