TOM GILB WHAT S WRONG WITH REQUIREMENTS SPECIFICATION AN

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

1 ST 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

2 ND 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

3 RD 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

4 TH 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…

5 TH 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 q q q 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 2 nd Principle) Example:

6 TH 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? . . .

7 TH 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”

8 TH 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 q Benchmarks, Owner & Stakeholders, Version, Impact & Supports Benefits: q Helps prioritize, understand, present for audience, establish relationships and dependencies between requirements

9 TH 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

10 TH 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?