1 / 35

The Importance of the Requirements Phase

The Importance of the Requirements Phase. Shuly Cooper. To Be Discussed. Product Quality – Definition The issues and their root cause Cost of Quality (or lack of it) A Tool – Quality Function Deployment (QFD) Briefly – More quality tools ► Inspections

kedma
Download Presentation

The Importance of the Requirements Phase

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. The Importance of the Requirements Phase Shuly Cooper

  2. To Be Discussed • Product Quality – Definition • The issues and their root cause • Cost of Quality (or lack of it) • A Tool – • Quality Function Deployment (QFD) • Briefly – • More quality tools ► Inspections • ► Iterative/incremental dev. (small deliverables) • The deliverables of the Requirements Phase

  3. Product Quality - Definition • 19451980s • “Higher Accuracy & Reliability” • The Era of Statistical Process Control (SPC) • Dr. W. Edward Deming • Dr. Peter F. Drucker The Deming Cycle: Act Plan Check Do 10/6/2014 3

  4. The Challenges (1 of 2) • Studies by the Standish Group • 2001 data • 44% of software projects finish on time • 56% of projects completed at – • 222% of the duration originally planned • 189% of the original budgeted cost • 70% of projects reduced their planned scope significantly • 30% were cancelled before completion • Ref: http://www.pqa.net/ProdServices/ccpm/W05002001.html

  5. The Challenges (2 of 2) • Capers Jones, Software Productivity Research LLC • 1995 - 2004 data • An analysis of ~250 large software projects • Size > 10,000 function points (~ 1,250,000 statements in C) • Success vs. failure were analyzed at opposite ends of the spectrum • ~ 25 (10%) projects were successful • ~ 50 (20%) projects had delays or overruns below 35% • ~ 175 (70%) projects experienced major delays, budget overruns, reduced scope, or were terminated

  6. Root Cause for Development Schedule Slip • Poor requirements 27% • Unanticipated technical difficulties 25% • Training 20% • Poor Project Management 17% • Lack of management support 6% • Other 5% Source: John Carter - Product Development Consulting, Inc - Spin 1997-

  7. The Current State of the Requirements Phase Engineers’ Awareness at the Start of a Project OthersBest • Priority Decision Criteria 20% 36% • Product Positioning 22% 41% • Strategic Alignment 18% 41 % • Organization Support 20% 43% • Risk Assessment 26% 44% • Competitive Analysis 21% 47% • Understanding User Needs 21% 48% • Regulation Compliance 60% 73% Source: John Carter - Product Development Consulting, Inc Berkeley Software Forum - 1996

  8. Capers Jones • The two most common causes of software project failures are : • Risk analysis • Vague a/o changing customer’s requirements • Ref: http://www.isixsigma.com/library/content/c010618b.asp

  9. The Cost of FixesResources’ bleeding

  10. Log (Cost to Find&Fix per Defect) ($) Cost of QualityIBM -- late 70’s 100K 10K 1K 100 10 0 Reqs. Design Coding Sys.Test Release Phase

  11. Cost to Fix a DefectSemantech -- 90’s SEMATECH Technology Transfer #92111389A-TRG, March 5, 1993 Source: Chuck Hoffman - Virtual Consulting Inc. - Spin 2001

  12. Cost of Quality Log [Cost to Find&Fix per Defect] ($) Log[Cost of NOT Finding & Fixing a req. defect ($/Defect) When faults migrate from phase to phase, they multiply 10-12 times => The most expensive faults are seeded during the Requirements Phase. 100K 10K IBM 1K 100 10 A Quality Gates 0 Reqs. Design Code Sys.Test Release Phase Found 10/6/2014 13

  13. Defects Classified by Time of Introduction (1970s) Jones* Thayer** Boehm*** Bell Labs Requirements 10% 8-10% 15% Functional Design 15% 55% 15-20% Logical Design 20% 25-35% Coding 30% 35% 25% 35% Documentation, etc. 35% 17-20% 45% * “Measuring Programming Quality and Productivity,” Jones, IBM Systems Journal, 1978 ** Software Reliability: A Study of Large Project Reality, Thayer, Lipow & Nelson, North-Holland, 1978 *** “Developing Small Scale Application Software Projects: Some Experimental Results,” Boehm, Proceedings, IFIP 8th World Computer Congress,1980 Source: Chuck Hoffman - Spin 2001

  14. Hewlett Packard’s Experience (1990s) Specification Other Coding Design Source: “Implementing and Sustaining a Software Inspection Program in an R&D Environment,” MacLeod, Hewlett-Packard Journal, June 1993 Source: Chuck Hoffman - Spin 2001

  15. Why Manage Requirements (2000) Distribution of Defects Distribution of Effort to Fix Defects Code 7% Code 1% Other 4% Design 13% Requirements 56% Other 10% Requirements 82% Design 27% Source: Larry Boldt - Technology Builders, Inc. - Spin 2001

  16. Find & Fix Defects as Early as Possible Log Cost to Find & Fix per Defect ($) % of Defects Introduced O Quality Gates 100K 50% 40% 10K 30% 1K O 100 20% 10 10% O O 0 Req. Design Code Sys. Test Release Phase

  17. A New Definition of Quality

  18. Product Quality – Definition 1980  Exceeding Customer expectations Prof. Yoji Akao -- U. of Tokyo Deals withthe total customer experience Part of “Hoshin Kanri” (Japan) Ref – http://www.qfdi.org/

  19. QFD Maps “What” to “How” L=1 M=3 H=5 I M P O R T A N C E FEATURES C O M P E T I T O R T O T A L DEV. HOW MRKT. A B C D E F 1 H H L M 2 N E E D S M L H W H A T 3 L M H 4 H L H 5 M M H 6 L M L H TOTAL 10/6/2014 22

  20. L=1, “Bells & Whistles” M=3 H=7, “A Show Stopper” QFD for this Lecture HOW I M P O R T A N C E C O M P E T I T O R T O T A L DEV. Provide Data Examples Font size Research Sections Colors MRKT. Promote QA/Req. H H M M 91 Correct (no errors) H H M M 91 W H A T Clear/Easy M L H H H H H 108 Low cost M 0 Long shelf life M M L L M 24 Fun/Aesthetic M H L L 39 TOTAL 11066 66423930 353 10/6/2014 23

  21. A Sample of Customers’ Needs (QFD – first column) (1 of 2) • Feature set/Capabilities • Reliability (MTBF) • Safety/Security • Recoverability (zero loss of data) • Scalability (different platforms, apps., tunable, modular)

  22. A Sample of Customers’ Needs (QFD – first column) (2 of 2) • Performance (higher speed) • Usability (easy to set-up, use, maintain) • Friendliness (easy to learn) • Supportability (service, 24x365) • Release date/Availability • Aesthetics

  23. QFD – Benefits – (1 of 2) • A TEAM communication tool • A “semi-mathematical” tool • Drives consensus across organizational • boundaries • Prevents “politics”, “lobbing” and “power • struggle” • Stabilizes requirements

  24. QFD – Benefits – (2 of 2) • Helps organizations to focus on customers’ • satisfaction  Maps customers’ needs into high level features • Cost saving –“Gets it right the first time” • Reduces risk  Identifies competitive features and strategies

  25. QFD – Cost • Planning • Depends on project size, 4-10 marketing and development engineers (all groups involved) • About 1 hr/10X10 matrix • Analyzing, storing, and reporting results

  26. Companies that are using QFD IBM Mitsubishi Digital Toyota AT&T Ford HP GM Sony Daimler Chrysler GE Boeing Raytheon Lockheed Martin Sybase - Clustering Micro Focus - Year 2000 Solution

  27. Entry Criteria for the Requirements Phase • There is – • A vision and an idea • A sponsor for the first phase of the project

  28. Requirements Phase Deliverables • Market Requirements Document • Product Specifications • High Level Project Plan • Management support for the next phase • Process Documents and Infrastructure • Maintenance Documents and Infrastructure • Black Box and Acceptance Test Plans • Initial contracts with potential customersand vendors

  29. Exit Criteria for the Requirements Phase • All documents – • Are written, inspected and approved by all stakeholders • All related issues/risks are resolved or managed • Objectives are measurable, optimized, prioritized and approved

  30. Quality Gates – following the Requirements/Design Phases Documents’ Inspections/Peer Reviews • 1976 – Introduced by M. E. Fagan - IBM • A formal process • Bell Labs experience: • Cost of inspecting all deliverables5-20% of • project development cost* • ROI of inspecting all deliverables 200-1200%* • * Bell Labs data 10/6/2014 33

  31. HP – Inspection Data Grady, R. B. and Van Slack, T., “Key Lessons in Achieving Widespread Inspection Use”, IEEE Software, V. 11, N. 4, Month, 1994, pp. 46-57 10/6/2014 34

  32. The Incremental Model – Web Requirements  H.L.Design L.L.Design L.L.Design L.L.Design Coding Coding Coding Testing Testing Testing Testing Testing Testing Integration Integration Integration Sys.Test Sys.Test Sys.Test Delivery Delivery Delivery

  33. The Incremental Model – Med. Device Requirements  H.L.Design L.L.Design L.L.Design L.L.Design Coding Coding Coding Testing Testing Testing Testing Testing Testing Integration Integration Integration Sub-Sys.Test Sub-Sys.Test Sub-Sys.Test Integration+Test A “big-bang” delivery Delivery

  34. The Iterative Model – Web Reqs+Arch Reqs+Arch. Reqs+Arch. Design Design Design Coding Coding Coding Testing Testing Testing Testing Testing Testing Integration Integration Integration Sys.Test Sys.Test Sys.Test Delivery Delivery Delivery

  35. The Requirements Phase – Lessons Learnt • It is a strategic phase • If this phase is not performed well  the project has a higher probability for failure • Invest about 15-20% of resources • Many organizations skip the phase or implement it poorly • More than 15-20% change in requirements  means a new project and a new round of planning (!)

More Related