1. Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation - Continued

2. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2 Software Lifecycle Activities Application Domain Objects SubSystems class... Implementat ion Domain Objects Source Code Test Cases ? Expressed in Terms Of Structured By Implemented By Realized By Verified By System Design Object Design Implemen- tation Testing class.... ? Requirements Elicitation Use Case Model Requirements Analysis

3. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 Requirements Elicitation Activities  Identify actors  Identify scenarios  Identify use cases  Identify relationships among use cases  Refine use cases  Identify nonfunctional requirements  Identify participating objects

4. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 Scenarios  “A narrative description of what people do and experience as they try to make use of computer systems and applications” [M. Carrol, Scenario-based Design, Wiley, 1995]  A concrete, focused, informal description of a single feature of the system used by a single actor.  Scenarios can have many different uses during the software lifecycle

5. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 A Good Scenario?  Example 1. The guest makes a reservation with the hotel. The hotel will take as many reservations as it has rooms available. When a guest arrives, he or she is processed by the registration clerk. The clerk will check the details provided by the guest with those that are already recorded. Sometimes guests do not make a reservation before they arrive. Some guests want to stay in non-smoking rooms. [Roberts et al., 1998: 68]

6. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 Types of Scenarios  As-is scenario  Used in describing a current situation. Usually used during re- engineering. The user describes the system.  Visionary scenario  Used to describe a future system. Usually described in greenfield engineering or reengineering.  Can often not be done by the user or developer alone  Evaluation scenario  User tasks against which the system is to be evaluated  Training scenario  Step by step instructions designed to guide a novice user through a system

7. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 How do we find scenarios?  Don’t expect the client to be verbal if the system does not exist (greenfield engineering)  Don’t wait for information even if the system exists  Engage in a dialectic approach (evolutionary, incremental)  You help the client to formulate the requirements  The client helps you to understand the requirements  The requirements evolve while the scenarios are being developed

8. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8 Heuristics for finding Scenarios  Ask yourself or the client the following questions:  What are the primary tasks that the system needs to perform?  What data will the actor create, store, change, remove or add in the system?  What external changes does the system need to know about?  What changes or events will the actor of the system need to be informed about?  Insist on task observation if the system already exists (interface engineering or reengineering)  Ask to speak to the end user, not just to the software contractor  Expect resistance and try to overcome it

9. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9 Example Scenario  It is 2 o'clock in the morning, and Ian cannot get his new HyperCam software to install properly. He points his browser to www.camerahype.com, gets the splash page, and waits for the corporate home page to appear. He scrolls down the page and clicks on the tech support link. On the provided form, he types his name, then gets his customer ID off the packing slip for the HyperCam and types it in. He clicks the Submit button. He scans the Tech Support home page and finally clicks on the GIF showing a befuddled user with a packing crate. This takes him to the Installation Help page, where he begins filling out the Incident Report form. Dissatisfied with the suggestion supplied by the system after the form is submitted, he goes to the Contact Us page and sends an email message.

10. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 Example Use Case  The use case begins when the customer goes to the Customer Log-On page. There, the customer types in his/her name and customer ID on the form and submits it. The system then displays the Tech Support home page with a list of Problem Categories. The customer clicks on Installation Help within the list, and the system supplies the Incident Report Form. The customer completes and submits the form, and the system presents a suggested resolution.

11. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 Detailed Narrative Use Case A cash withdrawal transaction is started from within a session when the customer chooses cash withdrawal from the menu of possible transaction types. The customer chooses a type of account to withdraw from (e.g., checking) from a menu of possible accounts, and then chooses a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request. If not, it reports a failure to the session, which initiates the Failed Transaction Extension to report the problem. if there is sufficient cash it sends the customer's card number, PIN, chosen account and amount to the bank, which either approves or disapproves the transaction. If the transaction is approved, the machine dispenses the correct amount of cash and issues a receipt. If the transaction is disapproved due to an incorrect PIN, the Incorrect PIN extension is executed. All other disapprovals are reported to the session, which initiates the Failed Transaction Extension. The bank is notified whether or not an approved transaction was completed in its entirety by the machine; if it is completed then the bank completes debiting the customer's account for the amount. [Bjork, 1998; used with permission]

12. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 Figure 4-8. Example of communication relationships among actors and use cases in FRIEND (UML use case diagram). The FieldOfficer initiates the ReportEmergency use case and the Dispatcher initiates the OpenIncident and AllocateResources use cases. FieldOfficers cannot directly open an incident or allocate resources on their own. ReportEmergency FieldOfficer Dispatcher OpenIncident AllocateResources >

13. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13 Figure 4-9. Example of use of extend relationship (UML use case diagram). ConnectionDown extends the ReportEmergency use case. The ReportEmergency use case becomes shorter and solely focused on emergency reporting. ReportEmergency FieldOfficer ConnectionDown >

14. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14 Figure 4-10. Example of include relationships among use cases. ViewMap describes the flow of events for viewing a city map (e.g., scrolling, zooming, query by street name) and is used by both OpenIncident and AllocateResources use cases. ViewMap OpenIncident AllocateResources >

15. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15 Figure 4-12. Activities of JAD (UML activity diagram). The heart of JAD is the Session activity during which all stakeholders design and agree to a system specification. The activities prior to the Session maximizes its efficiency. The production of the Final document ensures that the decisions made during the Session are captured. Management definition guide Project definition Research Preparation Session Session agenda Preliminary specification Working document Session script Scribe forms Final document preparation Final document

16. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16 Summary  Requirements Elicitation:  Greenfield Engineering, Reengineering, Interface Engineering  Scenarios:  Great way to establish communication with client  As-Is Scenarios, Visionary scenarios, Evaluation scenarios Training scenarios  Use cases: Abstraction of scenarios  Pure functional decomposition is bad:  Leads to unmaintainable code  Pure object identification is bad:  May lead to wrong objects, wrong attributes, wrong methods  The key to successful analysis:  Start with use cases and then find the participating objects  If somebody asks “What is this?”, do not answer right away. Return the question or observe: “What is it used for?”