Beruflich Dokumente
Kultur Dokumente
Lecture 5
(a) Documentation (b) Requirements Analysis
Each project as part of the Feasibility Study and Plan must identify which students will take responsibility for the equipment. 2
Assignments
Feasibility and plan Group RequirementsGroup/individual Midterm exam Individual Design Group/individual Project presentations Group Final examination Individual
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
Projects
Teams that are planning to carry out the Internet Butler project, please meet with me after the lecture.
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
Form of Documentation
Requirements Document
Specification of Requirements
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
11
Academic departments
Clients often confuse the current system with the underlying requirement. 12
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
13
Requirements Analysis
Data-centric models
Object models Formal models
14
Report 15
Form received
New?
Update database
Complete? T
T
Database record Notify student
F Notify student
Evaluate
16
17
Data-Flow Models
18
Rejection Application Completed form Receive application Evaluate application Applicant Offer
19
Receive
Completed application
Initiate evaluation
Evaluation request
AND
Supporting information
Pending database Applicant database
20
Acceptance
Financial aid
Offer
21
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