CS%20501:%20Software%20Engineering%20Fall%201999

1
CS 501 Software EngineeringFall 1999
Lecture 4 (a) Documentation (b) Requirements
Analysis
2
Assignments
September 9 Project plan Group September
23 Modify large program Individual October
7 Project interim report Group October
28 Testing large program Individual November
11 Design modeling Individual Nov 29 - Dec
3 Project presentations Group Exam week Final
examination Individual Details are subject to
change.
3
Administration
Project team formation Monday recitation
session. Thursday, September 9 Project plan due
-- report on paper. 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
4
Documentation
? Reasons for documentation visibility (e.g.,
project plan, interim report) user
support (e.g., user manual) team
communication (e.g., interface specifications) ma
intenance and evolution (e.g., requirements)
? Characteristics of documentation accurate
and kept current appropriate for
audience maintained online (usually) simple but
professional in style and appearance Documentation
is expensive --gt Quality not volume
5
Requirements Definition and Analysis
Requirements Definition
System and Software design
Implementation and Unit Testing
Integration and System Testing
Operation and Maintenance
6
The Requirements Process
Feasibility Report
System Models
Definition of Requirements
Specification of Requirements
Requirements Document
7
Requirements Analysis
1. Understand the requirements in depth ?
Domain understanding Examples Tote Investors,
Philips light bulbs ? Stakeholders Example
Andrew project
8
Viewpoint Analysis
Example University Admissions System ?
Applicants ? University administration Admissions
office Financial aid office Special offices
(e.g., athletics, development) ? Computing
staff Operations Software development and
maintenance ? Academic departments
9
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
10
Requirements Analysis
3. Model the requirements ? Informal Prose ?
Systematic Procedural models Data-centric
models Object models ? Formal models
11
Procedural Models Flowchart
Operation Decision Manual operation Report
12
Procedural Models Pseudo-code
Example Check project project plan
check_plan (report) if report (date_time) gt
due_date_time then error (too_late) if report
(client) none then error (no_client) if
report (team) lt min_team or gt max_team
then error (bad_team) if error() none
then comments read_report (report)
return (comments (text), comments (grade))
else return error()
13
Data-Flow Models
External entities Processing steps Data stores or
sources Data flows
14
Example University Admissions
Rejection
Application form
Completed application
Receive application
Evaluate
Applicant
Offer
15
Example University AdmissionsAssemble
Application Stage
Acknowledgment
Acknowledgment
Application form
Completed application
Evaluation request
AND
Initiate evaluation
Receive
Applicant
AND
Supporting information
Applicant database
Pending database
16
Example University AdmissionsProcess Completed
Application Stage
Rejection
Evaluation request
Acceptance
Offer
Financial aid
Evaluation
Special request
Applicant database
17
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, it is important
not to allow the analysis tools to prejudge the
system design.