Download presentation
Presentation is loading. Please wait.
Published byArleen Jackson Modified over 9 years ago
1
CS 501: Software Engineering Fall 1999 Lecture 4 (a) Documentation (b) Requirements Analysis
2
Assignments September 9Project planGroup September 23Modify large programIndividual October 7Project interim reportGroup October 28Testing large programIndividual November 11Design modelingIndividual Nov 29 - Dec 3Project presentationsGroup Exam weekFinal examinationIndividual 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) 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 Documentation is expensive --> 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 Study Requirements Analysis Requirements Definition Requirements Specification Feasibility Report System Models Definition of Requirements Specification of 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) > due_date_time then error (too_late) if report (client) = none then error (no_client) if report (team) 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 Applicant Application form Receive application Completed application Evaluate Rejection Offer
15
Example: University Admissions Assemble Application Stage Applicant Application form Receive Completed application Supporting information Pending database Acknowledgment Initiate evaluation Applicant database Evaluation request AND Acknowledgment
16
Example: University Admissions Process Completed Application Stage Rejection Evaluation Applicant database Evaluation request Acceptance Financial aid Offer Special request
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.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.