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.