CS 501: Software Engineering Fall 1999 Lecture 4 (a) Documentation (b) Requirements Analysis

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.

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

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

Requirements Definition and Analysis Requirements Definition System and Software design Implementation and Unit Testing Integration and System Testing Operation and Maintenance

The Requirements Process Feasibility Study Requirements Analysis Requirements Definition Requirements Specification Feasibility Report System Models Definition of Requirements Specification of Requirements Document

Requirements Analysis 1. Understand the requirements in depth:  Domain understanding Examples: Tote Investors, Philips light bulbs  Stakeholders Example: Andrew project

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

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

Requirements Analysis 3. Model the requirements:  Informal Prose  Systematic Procedural models Data-centric models Object models  Formal models

Procedural Models: Flowchart Operation Decision Manual operation Report

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()

Data-Flow Models External entities Processing steps Data stores or sources Data flows

Example: University Admissions Applicant Application form Receive application Completed application Evaluate Rejection Offer

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

Example: University Admissions Process Completed Application Stage Rejection Evaluation Applicant database Evaluation request Acceptance Financial aid Offer Special request

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.