VIEWS: 1 PAGES: 28 POSTED ON: 7/16/2013
TOM GILB, “WHAT'S WRONG WITH REQUIREMENTS SPECIFICATION? AN ANALYSIS OF THE FUNDAMENTAL FAILINGS OF CONVENTIONAL THINKING ABOUT SOFTWARE REQUIREMENTS, AND SOME SUGGESTIONS FOR GETTING IT RIGHT. “ J. SOFTW. ENGINEERING & APPS. 3(9) PP. 827-838 SEP 2010 CONSULTANT, AUTHOR, BLOGGER KNOWN GUEST LECTURER 50+ YEARS OF EXPERIENCE Presented by Lior Ebel Summary 2 Bad requirements often lead to project failure Problems: We think as programmers, not as Engineers/Managers Code delivery, use cases & functions take over value delivery Management does not work to improve this 10 principles for improvement are outlined ST 1 PRINCIPLE: UNDERSTAND THE TOP LEVEL CRITICAL OBJECTIVES ‘Worst Requirement Sin of All’ What’s Typically Wrong 4 Not measurable or quantified E.g. “Will provide a much more efficient user experience” Mixing optional designs E.g. “need password” instead of “need X level security” Insufficient background description E.g. “Major improvements in data quality over current practices” Failure to sufficiently explain business target details How to Get it Right 5 Top 10 critical requirements should (and can) be put in one page Can take one day of work to reach a good first draft Case study: It took 1 hour to rewrite one of the previous problematic requirements to be clear, measurable & quantified ND 2 PRINCIPLE: LOOK TOWARDS VALUE DELIVERY Systems Thinking, not Just a Focus on Software Concentrate on Value 7 Value: The benefit we think we get from something Requirements typically are not closely enough coupled with value We concentrate on functionality & user stories Product owners and marketing management define value Concentrate on Value – Cont’d 8 q Dangers: q Failure to deliver value, even if requirements met q Failure to understand full prerequisites needed to deliver value q How can we systematically document value as part of requirements? q Planguage – A proposed requirements specification language RD 3 PRINCIPLE: DEFINE A ‘REQUIREMENT’ AS A ‘STAKEHOLDER-VALUED END STATE’ What is a ‘Requirement’? 10 q Many opinions, most at variance with each other q Requirement: ‘stakeholder-valued end state’ q Make a distinction: q A requirement q A requirement specification q An implemented requirement q A partial or full design of implementing a requirement q Types & concepts of requirements: functional, performance, resource and more TH 4 PRINCIPLE: THINK STAKEHOLDERS, NOT JUST USERS AND CUSTOMERS! Stakeholders 12 q Stakeholder: anyone or anything that has an interest in the system q Not only users & customers need to be considered q Stakeholders can be: q IT development/maintenance q Senior management q Government q And more… TH 5 PRINCIPLE: QUANTIFY REQUIREMENTS AS BASIS SOFTWARE ENGINEERING The Problem 14 Classic Engineering is about numbers & measures So called ‘Software Engineers’ use only words to define requirements E.g. ‘high usability’ Lord Kelvin (1824-1907): “If you can’t measure it, you can’t improve it” Quantification 15 Most software projects strive for ‘improved quality’ over previous products Software Engineers quantify things, but we don’t ‘quantify quality’. Claim: any quality can be quantified Quality: How well something functions - a scalar or binary value Quantifying Quality with Planguage 16 q Ambition: high-level summary q Scale: formal scale of measure q Meter: the measuring process/instrument q Meter ~= speedometer , Scale ~= Km/hour q Goal: requirement level type – stakeholder valued future state (80% ± 10%) q There is also a Value language element (to support 2nd Principle) q Example: TH 6 PRINCIPLE: DON’T MIX ENDS AND MEANS End and Means 18 q We specify solutions & designs instead of value or quality requirements q Reason: solutions are easier - concrete and not abstract q Problems: q Might not get where we really want q Solution described by us might not be optimal q Why do I want X? because I want Y, and assume I’ll get it with X. Why do I want Y?... TH 7 PRINCIPLE: FOCUS ON REQUIRED SYSTEM QUALITY, NOT JUST ITS FUNCTIONALITY Functionality vs. Quality 20 Functionality: what a system does Quality: how well it does it Quality improvements drive most new projects Requirements focus too much on functionality and too little on quality Example of good quality statement: “Time to set up typical market research report has reduced from 65 min to 20 min” TH 8 PRINCIPLE: ENSURE THERE IS ‘RICH SPECIFICATION’ Requirement Specifications need Far More Information than the Requirement itself Requirement Background 22 q Requirement itself: Scale, Meter, Goal, Definition, Constraint, Value, etc. q Requirement background: Useful information, not central for implementation q Benchmarks, Owner & Stakeholders, Version, Impact & Supports q Benefits: q Helps prioritize, understand, present for audience, establish relationships and dependencies between requirements TH 9 PRINCIPLE: CARRY OUT SPECIFICATION QUALITY CONTROL (SQC) Control the Quality of Requirements 24 Requirements specifications should pass quality control tests before being internally released Claim: Initial inspection of new requirements validating rules: ‘Unambiguous to reader’ Testable ‘No optional design’ Finds 26% - 66% of text as ambiguous or unclear TH 10 PRINCIPLE: RECOGNIZE THAT REQUIREMENT CHANGE Use Feedback and Update Requirements as Necessary Requirements are Dynamic 26 Develop requirements with ongoing feedback from stakeholders about value External factors can change requirements: Politics Law International differences Economics Technological change Prepare and support an evolving process Final Words & Conclusions 27 Requirements are problematic Gilb is pessimistic about the future, and says requirements process should be thought at University Gilb proposes 10 principles My opinion: Well written, important for sw. eng. because it exhibits the fundamental problems The methods proposed do not immediately justify massive investment, but are rather ‘best practices’ A positive step, not mature yet THANK YOU! QUESTIONS?
Pages to are hidden for
"Tom Gilb_ Whats wrong with requirements specification An "Please download to view full document