Download Scenarios and Use Cases in Software Engineering and more Lecture notes Software Engineering in PDF only on Docsity! Cornell University Compu1ng and Informa1on Science CS 5150 So(ware Engineering Scenarios and Use Cases William Y. Arms Scenarios Scenario A scenario is a scene that illustrates some interac>on with a proposed system. A scenario is a tool used during requirements analysis to describe a specific use of a proposed system. Scenarios capture the system, as viewed from the outside, e.g., by a user, using specific examples. Note on terminology Some authors restrict the word "scenario" to refer to a user's total interac>on with the system. Other authors use the word "scenario" to refer to parts of the interac>on. In this course, the term is used with both meanings. Developing a Scenario with a Client: a Typical Student Purpose: Scenario that describes the use of an online Exam system by a representa>ve student Individual: [Who is a typical student?] Student A, senior at Cornell, major in computer science. [Where can the student be located? Do other universi7es differ?] Equipment: Any computer with a supported browser. [Is there a list of supported browsers? Are there any network restric7ons?] Scenario: 1. Student A authen>cates. [How does a Cornell student authen7cate?] 2. Student A starts browser and types URL of Exam system. [How does the student know the URL?] 3. Exam system displays list of op>ons. [Is the list tailored to the individual user?] Developing a Scenario with a Client (con>nued) 4. Student A selects CS 1234 Exam 1. 5. A list of ques>ons is displayed, each marked to indicate whether completed or not. [Can the ques7ons be answered in any order?] 6. Student A selects a ques>on and chooses whether to submit a new answer or edit a previous answer. [Is it always possible to edit a previous answer? Are there other op7ons?] 7. [What types of ques7on are there: text, mul7ple choice, etc.?] The first ques>on requires a wri]en answer. Student A is submi^ng a new answer. The student has a choice whether to type the solu>on into the browser or to a]ach a separate file. Student A decides to a]ach a file. [What types of file are accepted?] Developing a Scenario with a Client (con>nued) 8. For the second ques>on, the student chooses to edit a previous answer. Student A chooses to delete a solu>on previously typed into the browser, and to replace it with an a]ached file. [Can the student edit a previous answer, or must it always be replaced with a new answer?] 9. As an alterna>ve to comple>ng the en>re exam in a single session, Student A decides to saves the completed ques>ons work to con>nue later. [Is this always permiMed?] 10. Student A logs off. 11. Later Student A log in, finishes the exam, submits the answers, and logs out. [Is this process any different from the ini7al work on this exam?] 12. The Student A has now completed the exam. The student selects an op>on that submits the exam to the grading system. [What if the student has not aMempted every ques7on? Is the grader no7fied?] Scenarios for Analyzing Special Requirements Scenarios are very useful for analyzing special requirements. Examples • Reversals. In a financial system, a transac>on is credited to the wrong account. What sequence of steps are used to reverse the transac>on? • Errors. A mail order company has several copies of its inventory database. What happens if they become inconsistent? • Malfeasance. In a vo>ng system, a voter has houses in two ci>es. What happens if he a]empts to vote in both of them? Scenarios for error recovery Murphy's Law: "If anything can go wrong, it will". Create a scenario for everything that can go wrong and how the system is expected to handle it. Modeling Scenarios as Use Cases Models Scenarios are useful in discussing a proposed system with a client, but requirements need to be made more precise before a system is fully understood. This is the purpose of requirements modeling. A use case provides such a model. There is a good discussion of use cases in Wikipedia. The approach used in this course is less complex than the Wikipedia ar7cle. Two Simple Use Cases 12 Borrow Book BookBorrower Record Pressure PressureSensor Use Cases for Exam System Take Exam ExamTaker Check Grades Request Regrade Three separate use cases Describing a Use Case Some organiza>ons have complex documenta>on standards for describing a use case. At the very least, the descrip>on should include: • The name of the use case, which should summarize its purpose • The actor or actors • The flow of events • Assump>ons about entry condi>ons Outline of Take Exam Use Case Name of Use Case: Take Exam Actor(s): ExamTaker Flow of events: 1. ExamTaker connects to the Exam server. 2. Exam server checks whether ExamTaker is already authen>cated and runs authen>ca>on process if necessary. 3. ExamTaker selects a exam from a list of op>ons. 4. ExamTaker repeatedly selects a ques>on and either types in a solu>on, a]aches a file with a solu>on, edits a solu>on or a]aches a replacement file. Rela>onships Between Use Cases: <<includes>> ExamTaker Authen>cate Take Exam <<includes>> <<includes>> Check Grades The Authen>cate use case may be used in other contexts Rela>onships Between Use Cases: <<extends>> Take Exam ExamTaker Connec>on Fails <<extends>> <<includes>> is used for use cases that are in the flow of events of the main use case. <<extends>> is used for excep>onal condi>ons, especially those that can occur at any >me. Scenarios and Use Cases in the Development Cycle Scenarios and use cases are both intui>ve -‐-‐ easy to discuss with clients Scenarios are a tool for requirements analysis. • They are useful to validate use cases and in checking the design of a system. • They can be used as test cases for acceptance tes>ng. Use cases are a tool for modeling requirements. • A set of use cases can provide a framework for the requirements specifica>on. • Use cases are the basis for system and program design, but are o(en hard to translate into class models An Old Examina>on Ques>on The Pizza Ordering System The Pizza Ordering System allows the user of a web browser to order pizza for home delivery. To place an order, a shopper searches to find items to purchase, adds items one at a 7me to a shopping cart, and possibly searches again for more items. When all items have been chosen, the shopper provides a delivery address. If not paying with cash, the shopper also provides credit card informa7on. The system has an op7on for shoppers to register with the pizza shop. They can then save their name and address informa7on, so that they do not have to enter this informa7on every 7me that they place an order. Develop a use case diagram, for a use case for placing an order, PlaceOrder. The use case should show a rela>onship to two previously specified use cases, Iden7fyCustomer, which allows a user to register and log in, and PaybyCredit, which models credit card payments. An Old Examina>on Ques>on Shopper PlaceOrder <<includes>> Iden>fyCustomer PaybyCredit <<includes>> Correct solu1on Is link is op>onal An Old Examina>on Ques>on Wrong Solu1on SearchMenu PaybyCredit <<includes>> Iden>fyCustomer <<includes>> AddtoCart Pay Shopper