These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1 Requirements Engineering ■ The broad spectrum of task and techniques that lead to an understanding of requirements is called requirement engineering ■ Requirement engineering provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification and managing the requirements during transformation into operational system. ■ It encompasses seven distinct tasks : Inception, Elicitation, elaboration , negotiation , specifications, validations and management. ■ Some of these task occurs parallel and all are important for project
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 2 Requirements Engineering-I ■ 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, and ■ the effectiveness of preliminary communication and collaboration between the customer and the developer ■ Elicitation—elicit (obtain) requirements from all stakeholders ■ Elicitation is not simple it faces following problems • Problem of scope • Problem of understanding • Problem of volatility ■ Elaboration—create an analysis model that identifies data, function and behavioral requirements ■ Negotiation—agree on a deliverable system that is realistic for developers and customers These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 3 Requirements Engineering-II ■ Specification—can be any one (or more) of the following: ■ A written document ■ A set of models ■ A formal mathematical ■ A collection of user scenarios (use-cases) ■ A prototype ■ Validation—a review mechanism that looks for ■ errors in content or interpretation ■ areas where clarification may be required ■ missing information ■ inconsistencies (a major problem when large products or systems are engineered) ■ conflicting or unrealistic (unachievable) requirements. ■ Requirements management
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 4 Inception ■ 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, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 5 Eliciting Requirements ■ meetings are conducted and attended by both software engineers and customers ■ rules for preparation and participation are established ■ an agenda is suggested ■ a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting ■ a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin 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, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 6 Eliciting Requirements
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 7 Quality Function Deployment ■ Function deployment determines the “value” (as perceived by the customer) of each function required for the system ■ Information deployment identifies data objects and events ■ Task deployment examines the behavior of the system ■ Value analysis determines the relative priority of requirements
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 8 Elicitation Work Products ■ a statement of need and feasibility. ■ a bounded statement of scope for the system or product. ■ a list of customers, users, and other stakeholders who participated in requirements elicitation ■ a description of the system’s technical environment. ■ a list of requirements (preferably organized by function) and the domain constraints that apply to each. ■ a set of usage scenarios that provide insight into the use of the system or product under different operating conditions. ■ any prototypes developed to better define requirements.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 9 Building the Analysis Model
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 10 Negotiating Requirements ■ Identify the key stakeholders ■ These are the people who will be involved in the negotiation ■ Determine each of the stakeholders “win conditions” ■ Win conditions are not always obvious ■ Negotiate ■ Work toward a set of requirements that lead to “win-win”
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 11 Validating Requirements - I ■ Is each requirement consistent with the overall objective for the system/product? ■ Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? ■ Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? ■ Is each requirement bounded and unambiguous? ■ Do any requirements conflict with other requirements?
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 12 Validating Requirements - II ■ Is each requirement achievable in the technical environment that will house the system or product? ■ Is each requirement testable, once implemented? ■ Does the requirements model properly reflect the information, function and behavior of the system to be built. ■ Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 13
