CS 501: Software Engineering Fall 2000 Lecture 5 (a) Documentation (b) Requirements Analysis

2 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.

3 Assignments September 13Feasibility and planGroup October 4RequirementsGroup/individual October 16Midterm examIndividual November 8Design Group/individual Nov 29 - Dec 1Project presentationsGroup Exam weekFinal examinationIndividual Details are subject to change.

4 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

5 Projects Teams that are planning to carry out the Internet Butler project, please meet with me after the lecture.

6 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

7 Form of Documentation External Printed Web site Internal Program documentation Program context (e.g., copyright notices)

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

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

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

11 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

12 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.

13 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

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

15 Procedural Models: Flowchart Operation Decision Manual operation Report

16 Flowchart: University Admissions Form received New? Database record T Notify student FUpdate database Complete? Notify student T F Evaluate

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

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

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

20 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

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

22 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.