; Tom Gilb_ Whats wrong with requirements specification An
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Tom Gilb_ Whats wrong with requirements specification An

VIEWS: 1 PAGES: 28

  • pg 1
									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?

								
To top