Michael Elhadad

Software Engineering - Fall 1999

Lecture 2: Product Definition and Writing Requirements

Context: Project Initiation

  1. Justify
  2. Define and Validate Initial Requirements
  3. Define Initial Management Documents
  4. Define Infrastructure

Stage 1: Product Definition

Program "on purpose"
  1. know who the users will be (audience)
  2. why the product is to be developed (business case)
  3. how it will be used (use case scenarios)
  4. how it compares with other potential solutions (competitive analysis)
  5. what is not required of the product (product delimitation)
Importance of proper product definition:
  1. Cost to correct defects smallest when caught early (from B.W.Boehm):
    Phase in which foundCost Ratio
    Requirements 1
    Design 3-6
    Coding 10
    Development Testing 15-40
    Acceptance Testing 30-70
    Operation 40-1000
  2. Most project time spent in "grey zone" before project formally initiated
  3. Strongest tool to reduce uncertainty about project ("cone of uncertainty")
Tools to do a proper product definition:
  1. Define a standard document structure for Product Definition
  2. Involve users (interviews)
  3. Focus on minimalism
  4. Focus on shipping: realistic deadline (timebox)
Milestones and Deliverables (from McConnell-97, p.65):
  1. Beginning of Project
    1. Identify key decision-maker
    2. Vision statement created
    3. Business case for product established [Product Definition Document]
    4. Preliminary effort and schedule targets created
    5. Development team identified
    6. Change control plan created
    7. Top 10 Risks list created
    8. Project Log started
  2. Project Launch
    1. Quality Assurance persons identified
    2. Documentation persons identified
    3. Key users identified
    4. Prototype user-interface (UI)
    5. UI style-guide created

Product Definition Document

Good Practice:
  1. Define a Standard Document Structure
  2. Make the document easy to change
  3. Define a UI Prototype
A First Product Definition Template:
  1. Vision Statement: one paragraph description of objective
  2. Business case: why product is needed, benefits.
  3. Audience: who the users will be, key users identified.
  4. Competitive Analysis: alternative products, analysis of strengths.
  5. Glossary: definition of key technical terms and concepts.
  6. Main Use Case Scenarios: how the system will be used.
  7. Scope: what will not be addressed by the system
  8. Quality Criteria: how the system will be evaluated. Specific quality objectives.
  9. Functional Description: Decomposition in key functionalities, and for each functionality/feature:
    1. UI Prototype
    2. Relation with other features
  10. Risks: what could make the project fail and how to address them.

Stage 2: Software Requirement Specification (SRS)

Focus on detailed analysis of the software functionality. IEEE/ANSI830-1993 standard for document template: Section 3.1 from [Sommerville and Sawyer].

Stage 3: Define Initial Management Documents

Management documents monitor planning. They are maintained every week. They are made available for public review: a standard "Project Home Page" is maintained.

References

B.W. Boehm
Software Engineering Economics
Prentice Hall, 1981

D.C. Gause and G.M. Weinberg
Exploring Requirements: Quality before Design
Dorset House Publishing, (0-932963313-7), 1989
TS171.G38

McConnell S.
Software Project Survival Guide 
Microsoft Press
(1-572-31621-7) 1997

I. Sommerville and P. Sawyer
Requirements Engineering, a good practice guide.
John Wiley, (0-471-97444-7), 1997.
See also the book's homepage and REAIMS, a research project on 
requirements engineering from which the book derived.

Writing Quality Requirements
by Karl Wiegers, Software Development, May 1999, pp44--48.

Requirements Engineering Tools and Techniques by Didar Zowghi.
Last modified Apr 11th, 1999 Michael Elhadad