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 1ST PRINCIPLE: UNDERSTAND THE TOP LEVEL CRITICAL OBJECTIVES ‘Worst Requirement Sin of All’ What’s Typically Wrong 4 Not measurable or quantified Mixing optional designs E.g. “need password” instead of “need X level security” Insufficient background description E.g. “Will provide a much more efficient user experience” 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 2ND 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 Dangers: Failure to deliver value, even if requirements met Failure to understand full prerequisites needed to deliver value How can we systematically document value as part of requirements? Planguage language – A proposed requirements specification 3RD PRINCIPLE: DEFINE A ‘REQUIREMENT’ AS A ‘STAKEHOLDER-VALUED END STATE’ What is a ‘Requirement’? 10 Many opinions, most at variance with each other Requirement: ‘stakeholder-valued end state’ Make a distinction: A requirement A requirement specification An implemented requirement A partial or full design of implementing a requirement Types & concepts of requirements: functional, performance, resource and more 4TH PRINCIPLE: THINK STAKEHOLDERS, NOT JUST USERS AND CUSTOMERS! Stakeholders 12 Stakeholder: anyone or anything that has an interest in the system Not only users & customers need to be considered Stakeholders can be: IT development/maintenance Senior management Government And more… 5TH 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 Ambition: high-level summary Scale: formal scale of measure Meter: the measuring process/instrument Meter ~= speedometer , Scale ~= Km/hour Goal: requirement level type – stakeholder valued future state (80% ± 10%) There is also a Value language element (to support 2nd Principle) Example: 6TH PRINCIPLE: DON’T MIX ENDS AND MEANS End and Means 18 We specify solutions & designs instead of value or quality requirements Reason: solutions are easier - concrete and not abstract Problems: Might not get where we really want Solution described by us might not be optimal Why do I want X? because I want Y, and assume I’ll get it with X. Why do I want Y?... 7TH 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” 8TH PRINCIPLE: ENSURE THERE IS ‘RICH SPECIFICATION’ Requirement Specifications need Far More Information than the Requirement itself Requirement Background 22 Requirement itself: Scale, Meter, Goal, Definition, Constraint, Value, etc. Requirement background: Useful information, not central for implementation Benchmarks, Owner & Stakeholders, Version, Impact & Supports Benefits: Helps prioritize, understand, present for audience, establish relationships and dependencies between requirements 9TH 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 10TH 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?