REQUIREMENTS SPECIFICATION AN ANALYSIS OF THE FUNDAMENTAL FAILINGS

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 language

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,

4 TH PRINCIPLE: THINK STAKEHOLDERS, NOT JUST USERS AND CUSTOMERS!

Stakeholders 12 q q q Stakeholder: anyone or anything that has an interest in the system Not only users & customers need to be considered 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 q q We specify solutions & designs instead of value or quality requirements Reason: solutions are easier - concrete and not abstract 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 q Requirement itself: Scale, Meter, Goal, Definition, Constraint, Value, etc. 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)

24 Control the Quality of 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?