CS 501: Software EngineeringFall 2000

Lecture 5

(a) Documentation

(b) Requirements Analysis

2

Nomadic Computing Experiment

RECITATION SESSION, MONDAY SEPTEMBER 11

Dell laptops with wireless cards available for CS 501 projects

• 3 or 4 laptops per project

• 1 or 2 additional wireless cards per project

• surveys at beginning and end of project

Each project as part of the Feasibility Study and Plan must identify which students will take responsibility for the equipment.

3

Assignments

September 13 Feasibility and plan Group

October 4 Requirements Group/individual

October 16 Midterm exam Individual

November 8 Design Group/individual

Nov 29 - Dec 1 Project presentations Group

Exam week Final examination Individual

Details are subject to change.

4

Assignment 1

Wednesday, September 13: Project plan due -- report.

Title of project Client/customer Team members Outline description Current status (e.g., previous work) Plan (e.g., major stages, assignment to tasks, technical environment, schedule, etc.) Any other relevant information

5

Projects

Teams that are planning to carry out the Internet Butler project, please meet with me after the lecture.

6

Documentation

• Reasons for documentation:visibility (e.g., project plan, interim report)

user support (e.g., user manual) team communication (e.g., interface specifications)

maintenance and evolution (e.g., requirements) • Characteristics of documentation:

accurate and kept currentappropriate for audiencemaintained online (usually)simple but professional in style and appearance

Documentation is expensive --> Quality not volume

7

Form of Documentation

External

• Printed

• Web site

Internal

• Program documentation

• Program context (e.g., copyright notices)

8

Requirements Definition and Analysis

RequirementsDefinition

System andSoftware design

Programmingand Unit Testing

Integration andSystem Testing

Operation andMaintenance

9

The Requirements Process

FeasibilityStudy

RequirementsAnalysis

RequirementsDefinition

RequirementsSpecification

FeasibilityReport System

Models Definition ofRequirements

Specification ofRequirements

RequirementsDocument

10

Requirements Analysis

1. Understand the requirements in depth:

• Domain understanding

Examples: Tote Investors, Philips light bulbs

• Stakeholders

Example: Andrew project

11

Viewpoint Analysis

Example: University Admissions System

• Applicants

• University administrationAdmissions officeFinancial aid officeSpecial offices (e.g., athletics, development)

• Computing staffOperationsSoftware development and maintenance

• Academic departments

12

Interviews with Clients

Clients may have only a vague concept of requirements.

• Prepare before you meet with them

• Keep full notes

• If you don't understand, delve further

• Small group meetings are often most effective

Clients often confuse the current system with the underlying requirement.

13

Requirements Analysis

2. Organize the requirements:

• Classification into coherent clusters

(e.g., legal requirements)

• Recognize and resolve conflicts

(e.g., functionality v. cost v. timeliness)

Example: Dartmouth general ledger system

14

Requirements Analysis

3. Model the requirements:

• Informal

Prose

• Systematic

Procedural models

Data-centric models

Object models

• Formal models

15

Procedural Models: Flowchart

Operation

Decision

Manual operation

Report

16

Flowchart: University Admissions

Form received New?

Database record

T

Notify student

F Update database

Complete?

Notify student

T

FEvaluate

17

Procedural Models: Pseudo-code

Example: Check project project plan

check_plan (report)

if report (date_time) > due_date_time then error (too_late) if report (client) = none then error (no_client) if report (team) < min_team or > max_team then error (bad_team) if error() = none then comments = read_report (report) return (comments (text), comments (grade)) else return error()

18

Data-Flow Models

External entities

Processing steps

Data stores or sources

Data flows

19

Example: University Admissions

Applicant

Applicationform Receive

application

Completedapplication

Evaluate

Rejection

Offer

20

Example: University AdmissionsAssemble Application Stage

Applicant

Applicationform

Receive

Completedapplication

Supportinginformation

Pendingdatabase

Acknowledgment

Initiateevaluation

Applicantdatabase

Evaluationrequest

AND

AND

Acknowledgment

21

Example: University AdmissionsProcess Completed Application Stage

Rejection

Evaluation

Applicantdatabase

Evaluationrequest Acceptance Financial

aid

Offer

Specialrequest

22

Requirements Analysis v. System Design

Dilemma.

• Requirements analysis should make minimal assumptions about the system design.

• But the requirements definition must be consistent with computing technology and the resources available.

In practice, analysis and design are interwoven. However, do not to allow the analysis tools to prejudge the system design.