2 September

1
2 September

• Requirements
• Functional Spec

2
Requirement Level

• Often addressed in two phases
• Customer level
• Developer level (will visit later)
• Once agreement exists with customer, developer
  translates them into his language
• Example
• User must never lose more than 10 minutes of work
• Autosaving is required

3
Sources of requirements

• People
• Broad range of stakeholders
• Conflicting requirements
• Wants and needs
• Helping the customer articulate the requirements
  use cases
• Hardware constraints
• Laws of physics and nature
• Social responsibility

4
Sources of Requirements People vs. Other
(Brackett, CMU)
5
What is a Functional Spec?

• Describes the features of the software product
• Describes the product's behavior as seen by an
  external observer
• Contains the technical information and data
  needed for the design
• Defines what the functionality will be, but not
  how it will be implemented

6
Why a Spec?

• Allows you to communicate with your client and
  users
• Easier to change than code
• Basis for schedule
• Record of design decisions

7
Whats in a Functional Spec?

• Overview
• Use cases (scenarios)
• Interfaces anything the USER sees
• As much as you know
• Note your functional spec will go through
  multiple iterations

8
Reference and Example

• Joelonsoftware.com
• Example

9
Expectations of Software Engineering(Watts
Humphrey)

• Predetermine quantitative quality goals
• Accumulate data for use in later projects
• Keep all work visible
• Design, program and test only against
  requirements
• Measure and achieve quality goals

10
Keeping Work Visible Documentation

• What will be implemented
• Customer contract, requirements, glossy
• User manuals
• How it will be implemented
• Project plan
• The code
• The test plan
• What people will do
• How you will manage code and documents

11
Documentation Principles

• Need to reflect changes
• Version control
• Need to keep all documents synchronized
• Single owner
• Only say it once

12
Risk Management

• Life is a risk.
• Diane Von Furstenberg

13
Should we eliminate risk?

• Take calculated risks. That is quite different
  from being rash. (Patton)
• Great deeds are usually wrought at great risks.
  (Herodotus)
• The policy of being too cautious is the greatest
  risk of all. (Nehru)
• No risk gt no challenge

14
Risks

• 80 of software projects fail
• Standish Report (1995)
• More recently Sauer et al claim 67 delivered
  close to budget, schedule, and scope
  expectations
• Two types of risk
• Avoidable
• Unavoidable

15
Risk Management

• Identification
• Mitigation plan
• Prioritization
• Retirement

16
Sources of Risk

• Top management commitment
• User commitment
• Misunderstood requirements
• Inadequate user involvement
• Mismanaged user expectations
• Scope creep
• Lack of knowledge or skill
• Keil et al, A Framework for Identifying
  Software Project Risks, CACM 4111, November 1998

17
Technical Risks

• New features
• New technology
• Developer learning curve
• Changes that may affect old code
• Dependencies
• Complexity

• Bug history
• Late changes
• Rushed work
• Tired programmers
• Slipped in pet features
• Unbudgeted items

18
What can be controlled?

• Cost
• Number of people
• Hours worked
• Hardware and software used
• Capability
• Function that you ship
• Quality
• Procedures that increase cost and quality
• Testing
• Delivery
• Dates