6e36635a66928deb9a60250c1e4a94cb.ppt
- Количество слайдов: 28
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?
6e36635a66928deb9a60250c1e4a94cb.ppt