22 January

Requirements (cont.)Software Engineering

Overview

Team Rules

Handled the simple questions What are your back up plans? How are you going to recognize if

someone is behind? Extended absences

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

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

Sources of Requirements: People vs. Other

(Brackett, CMU)

Relatively highRelatively low % of requirements gathered from people

Typ

e of

ap

plic

atio

n

highly constrained

unconstrained

missile guidance system

flight control system for airliner

enhancement to corporate accounting system

manufacturing control system

corporate accounting system

video game

decision support system for military tactics

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

Why a Spec?

Allows you to communicate with your client and users

Easier to change than code Basis for schedule Record of design decisions

What’s in a Functional Spec?

Overview Use cases (scenarios) Interfaces: anything the USER sees As much as you know

Note: your functional spec witll go through multiple iterations

Reference (thanks to Shaddi)

Joelonsoftware.com

Software Engineering

Expectations of Software Engineering(Watts Humphrey)

1. Predetermine quantitative quality goals

2. Accumulate data for use in later projects

3. Keep all work visible4. Design, program and test only

against requirements5. Measure and achieve quality goals

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

Documentation Principles

Need to reflect changes

Version control Need to keep all documents

synchronized Single owner

Only say it once

Quality Management Principles Customer focus Leadership Involvement of people Process approach System approach to management Continual improvement Factual approach to decision making Mutually beneficial supplier

relationshipshttp://www.iso.ch/iso/en/iso9000-14000/iso9000/qmp.html

Customer Focus Organizations depend on customers

Understand needs, requirements, expectations

Increases market share Implies

Market research Customer understanding throughout

the organization Measuring satisfaction

Involvement of People

Essence of the organization “Buy in” Two way street

Treating people with respect They will take on ownership of

responsibility Encourage a collaborative

environment

Software Engineering Fundamental Steps

Requirements Design Implementation Integration Test

(elaborated versions to be covered later)

Processes

Differ by how often you do the steps Points on the spectrum Differences in overhead

Three fundamental models Waterfall Spiral Iterative

Waterfall Do it once Traditional model Used for large next version releases,

especially when tightly coupled changes Pros

Simple documentation management Clean design phase

Cons Least flexibility No early feedback