لخّصلي

Page number
2
This preview may have altered the layout of this file. You can still download the original file.
Pharos University in AlexandriaFaculty of Computer Science & Artificial IntelligenceCourse Title: Software EngineeringCode: CS 106Week 5 - Chapter 8Understanding RequirementsDr. Abdulfatah FarawilaEmail: [email protected][email protected]: 01015382683Slides are adopted from “Software Engineering: A Practitioner’s Approach,by Roger S. Pressman and Bruce R. Maxim; 8th edition, 2014”
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 2Chapter 8 Understanding RequirementsSlide Set to accompanySoftware Engineering: A Practitioner’s Approach, 8/eby Roger S. Pressman and Bruce R. MaximSlides copyright © 1996, 2001, 2005, 2009, 2014 by Roger S. PressmanFor non-profit educational use onlyMay be reproduced ONLY for student use at the university level when used in conjunctionwith Software Engineering: A Practitioner's Approach, 8/e. Any other reproduction or use isprohibited without the express written permission of the author.All copyright information MUST appear if these slides are posted on a website for studentuse.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 3Requirements Engineering-I1. Inception بداية ً—ask a set of questions that establish ... basic understanding of the problem the people who want a solution the nature of the solution that is desired, and2. Elicitation—elicit استفسر requirements from all stakeholders3. Elaboration—create an analysis model that identifies data,functional and behavioral requirements4. Negotiation—agree on a deliverable system that is realisticfor developers and customers
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 4Requirements Engineering-II5. System Requirement Specification (SRS) —can beone or more of the following: A written document A formal mathematical model A collection of user scenarios (Use-Cases) A prototype6. Validation—a review mechanism that looks for errors in content or interpretation areas where clarification may be required missing information inconsistencies (a major problem with large systems) conflicting or unrealistic (unachievable) requirements7. Requirements management
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 5Inception Identify stakeholders “who else do you think I should talk to?” Recognize multiple points of view Work toward collaboration The first questions Who is behind the request for this work? Who will use the solution? What will be the economic benefit of a successful solution? Is there another source for the solution that you need?
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 6Eliciting Requirements meetings are conducted/attended by both developers & customer rules for preparation and participation are established an agenda is suggested a facilitator (customer, developer, or outsider) controls the meeting a "definition mechanism" (can be work sheets, flip charts, wall stickers,eBulletin board, chat room or virtual forum) is used the goal is to identify the problem propose elements of the solution negotiate different approaches, and specify a preliminary set of solution requirements
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 7Elicitation Work Products a statement of need and feasibility a bounded statement of scope for the system a list of customers, users, and other stakeholders whoparticipated in requirements elicitation a description of the system’s technical environment a list of requirements (organized by function) and thedomain constraints that apply to each. a set of scenarios that provide insight into the use of thesystem under different operating conditions prototypes developed to better define requirements