Lecture 5

CS 501: Software Engineering
Fall 2000
Lecture 5
(a) Documentation
(b) Requirements Analysis
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.
2
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.
3
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
4
Projects
Teams that are planning to carry out the Internet Butler

project, please meet with me after the lecture.
5
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 current
appropriate for audience
maintained online (usually)
simple but professional in style and appearance
6 Documentation is expensive --> Quality not volume
Form of Documentation
External
• Printed
• Web site
Internal
• Program documentation
• Program context (e.g., copyright notices)
7
Requirements Definition and Analysis
Requirements
Definition
System and
Software design
Programming
and Unit Testing
Integration and
System Testing
Operation and
8 Maintenance
The Requirements Process
Feasibility Requirements
Study Analysis
Requirements
Definition
Feasibility Requirements
Report System Specification
Models Definition of
Requirements
Requirements Specification of
Document Requirements
9
Requirements Analysis
1. Understand the requirements in depth:

• Domain understanding
Examples: Tote Investors, Philips light bulbs
• Stakeholders
Example: Andrew project
10
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
11
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.
12
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
13
3. Model the requirements:

• Informal
Prose
• Systematic
Procedural models
Data-centric models
Object models
• Formal models
14
Procedural Models: Flowchart
Operation
Decision
Manual operation
Report
15
Flowchart: University Admissions
Form F Update
received New? Complete? T
database
T F
Evaluate
Notify
Database student
record
Notify
student
16
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()
17
Data-Flow Models
External entities
Processing steps
Data stores or sources
Data flows
18
Example: University Admissions
Application Rejection
Completed
form Receive application
application Evaluate
Applicant
Offer
19
Assemble Application Stage
Acknowledgment Acknowledgment
Application Completed AND

Evaluation
form application Initiate request
Receive
evaluation
Applicant AND
Supporting
information
Pending Applicant
database database
20
Process Completed Application Stage
Rejection
Evaluation
request Acceptance Offer
Evaluation Financial
aid
Special
request
Applicant
database
21
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.
22

Lecture 5

Uploaded by

Copyright:

Available Formats

Lecture 5

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture 5

Uploaded by

Copyright:

Available Formats

CS 501: Software Engineering

RECITATION SESSION, MONDAY SEPTEMBER 11

September 13 Feasibility and plan Group

Details are subject to change.

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

Teams that are planning to carry out the Internet Butler

• Reasons for documentation:

1. Understand the requirements in depth:

Example: University Admissions System

Clients may have only a vague concept of requirements.

2. Organize the requirements:

3. Model the requirements:

Example: Check project project plan

Data stores or sources

Application Completed AND

You might also like