Download Documentation, Requirements Analysis-Software Engineering-Lecture Slides and more Slides Software Engineering in PDF only on Docsity! CS 501: Software Engineering Fall 2000 Lecture 5 (a) Documentation (b) Requirements Analysis docsity.com 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. docsity.com 5 Projects Teams that are planning to carry out the Internet Butler project, please meet with me after the lecture. docsity.com 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 docsity.com 7 Form of Documentation External • Printed • Web site Internal • Program documentation • Program context (e.g., copyright notices) docsity.com 10 Requirements Analysis 1. Understand the requirements in depth: • Domain understanding Examples: Tote Investors, Philips light bulbs • Stakeholders Example: Andrew project docsity.com 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 docsity.com 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. docsity.com 15 Procedural Models: Flowchart Operation Decision Manual operation Report docsity.com 16 Flowchart: University Admissions Form received New? Database record T Notify student F Update database Complete? Notify student T F Evaluate docsity.com 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) < min_team or > max_team then error (bad_team) if error() = none then comments = read_report (report) return (comments (text), comments (grade)) else return error() docsity.com 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 AND Acknowledgment docsity.com 21 Example: University Admissions Process Completed Application Stage Rejection Evaluation Applicant database Evaluation request Acceptance Financial aid Offer Special request docsity.com 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. docsity.com
