Use Cases Requirements Engineering & Project Management Lecture 2

J.Nawrocki, Use Cases Key Roles in XPrince Project Manager Analyst Architect Time

J.Nawrocki, Use Cases Architecture Aim & Scope XPrince Artefacts Business Model and System Scope Most Important Use Cases Architect. Vision & Tools Requirements Spec. Mockup Accept. Tests Frame Initial Prototype (code + test cases) GUI Design A&S Plan Init. Project Plan Architect. Plan Updat. Proj. Plan Analyst Architect Project Manager

J.Nawrocki, Use Cases Business Model & Scope: Use Cases Dean Dean: Sets number of places for each MS Degree Programme. Gets list of students assigned to each MS Programme. Student Student: Enters her preferences by sequencing MS Degree Programmes from the most to the least interesting. Gets information about the MS Programme to which she has been assigned.

J.Nawrocki, Use Cases Agenda Historical Perspective Scenarios vs. Use Cases Poorly-Written Use Case Patterns for Effective Use Cases Elicitation of Use Cases Use Cases vs. User Stories Introduction XPrince Team Project Lifecycle The Analyst Role The Architect Role The Project Manager Role Scaling up Conclusions

J.Nawrocki, Use Cases Ivar Jacobson 1967: Ericsson, telecommunication systems 1985: Ph.D., Dep. of Computer Systems, The Royal Institute of Tech., Stockholm 1987: Founder of Objectory AB -> (Objectory Process) 1995: Objectory AB merges with Rational 2003: IBM buys Rational

J.Nawrocki, Use Cases Ivar Jacobson Addison-Wesley, 1992

J.Nawrocki, Use Cases Use Case Diagram in UML Construct itinerary Merchant bank Find flight Travel agent Airline reservation Reserve flight Issue ticket

J.Nawrocki, Use Cases Agenda Historical Perspective Scenarios vs. Use Cases Poorly-Written Use Case Patterns for Effective Use Cases Elicitation of Use Cases Use Cases vs. User Stories Introduction XPrince Team Project Lifecycle The Analyst Role The Architect Role The Project Manager Role Scaling up Conclusions

J.Nawrocki, Use Cases The same goal Use Case as a set of scenarios Scenario #1 Scenario #2 Scenario #3 Use Case

J.Nawrocki, Use Cases Behavioural scenario Get Paid for Car Accident Actors : Claimant -- Accident victim making claim Insurance Company -- Company insuring Claimant Agent -- Insurance Company representative Scenario #1 1. Claimant submits claim with substantiating data. 2. Insurance Company verifies that Claimant owns a valid policy. 3. Insurance Company assigns Agent to examine the case. 4. Agent verifies that all details are within policy guidelines. 5. Insurance Company pays Claimant.

J.Nawrocki, Use Cases Behavioural scenario Get Paid for Car Accident Actors : Claimant -- Accident victim making claim Insurance Company -- Company insuring Claimant Agent -- Insurance Company representative Scenario #2 1. Claimant submits claim with substantiating data. 2. Submitted data is incomplete and Insurance Company requests missing information. 3. Claimant supplies missing information. 4. Insurance Company verifies that Claimant owns a valid policy. 5. Insurance Company assigns Agent to examine the case. 6. Agent verifies that all details are within policy guidelines. 7. Insurance Company pays Claimant.

J.Nawrocki, Use Cases Behavioural scenario Get Paid for Car Accident Actors : Claimant -- Accident victim making claim Insurance Company -- Company insuring Claimant Agent -- Insurance Company representative Scenario #3 1. Claimant submits claim with substantiating data. 2. Insurance Company verifies that Claimant owns a valid policy. 3. Claimant does not own a valid policy, so Insurance Company declines claim, notifies Claimant, records all this, and terminates proceedings.

J.Nawrocki, Use Cases A use case Get Paid for Car Accident Actors : Claimant -- Accident victim making claim Insurance Company -- Company insuring Claimant Agent -- Insurance Company representative Main Scenario 1. Claimant submits claim with substantiating data. 2. Insurance Company verifies that Claimant owns a valid policy. 3. Insurance Company assigns Agent to examine the case. 4. Agent verifies that all details are within policy guidelines. 5. Insurance Company pays Claimant. Extensions 1a. Submitted data is incomplete: 1a1. Insurance Company requests missing information. 1a2. Claimant supplies missing information. 2a. Claimant does not own a valid policy:...

J.Nawrocki, Use Cases Agenda Historical Perspective Scenarios vs. Use Cases Poorly-Written Use Case Patterns for Effective Use Cases Elicitation of Use Cases Use Cases vs. User Stories Introduction XPrince Team Project Lifecycle The Analyst Role The Architect Role The Project Manager Role Scaling up Conclusions

J.Nawrocki, Use Cases Poorly written use case 1.Display a blank schedule. 2.Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule. 3.Do. 4.Student clicks on a course. 5.Update the lower window to show the times the course is available. 6.Student clicks on a course time and then clicks on the „Add Course” button.... Register for Course (Main Scenario)

J.Nawrocki, Use Cases Poorly written use case 1.Display a blank schedule. 2.Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule. 3.Do. 4.Student clicks on a course. 5.Update the lower window to show the times the course is available. 6.Student clicks on a course time and then clicks on the „Add Course” button.... Too much user interface detail.

J.Nawrocki, Use Cases Well-written use case 1.Student requests a new schedule. 2.The system prepares a blank schedule form and pulls in a list of open and available courses from the Course Catalog System. 3.Student selects primary and alternate courses from the available offerings. 4. For each course, the system verifies that the Student has the necessary prerequisities and adds the Student to the course, marking the Student as „enrolled” in that course in the schedule.... Register for Course (Main Scenario)

J.Nawrocki, Use Cases Other frequent defects Too many use cases at low goal levels („Authorize user”). Using a use case for non-behavioral information (e.g. forms description – use adornments). Too long (should be short, usually 3-9 steps). Not a complete goal accomplished (also lack of alternative behaviors description). Sentence fragments (e.g. omitting the actors’ names in steps).

J.Nawrocki, Use Cases Poorly written use case 1.Display a blank schedule. 2.Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule. 3.Do. 4.Student clicks on a course. 5.Update the lower window to show the times the course is available. 6.Student clicks on a course time and then clicks on the „Add Course” button.... Register for Course (Main Scenario)

J.Nawrocki, Use Cases Agenda Historical Perspective Scenarios vs. Use Cases Poorly-Written Use Case Patterns for Effective Use Cases Elicitation of Use Cases Use Cases vs. User Stories Introduction XPrince Team Project Lifecycle The Analyst Role The Architect Role The Project Manager Role Scaling up Conclusions

J.Nawrocki, Use Cases Patterns for effective use cases User Valued Transactions User Valued Transactions: Identify the valuable services that the system delivers to the actors to satisfy their business purposes. Book trip Search for flights Promote vacations Create trip itinerary Update trip itinerary Delete trip itinerary Book trip Search for flights Promote vacations Change booking Cancel booking

J.Nawrocki, Use Cases Patterns for effective use cases Ever Unfolding Story Ever Unfolding Story: Organize the use case set as a hierarchical story that can be either unfolded to get more detail or folded up to hide detail and show more context.

J.Nawrocki, Use Cases Use case goal levels Book hotelBook flight User Level Book trip Business Level Find flight Reserve seat Find hotel Reserve room Subfunction Level

J.Nawrocki, Use Cases Agenda Historical Perspective Scenarios vs. Use Cases Poorly-Written Use Case Patterns for Effective Use Cases Elicitation of Use Cases Use Cases vs. User Stories Introduction XPrince Team Project Lifecycle The Analyst Role The Architect Role The Project Manager Role Scaling up Conclusions

J.Nawrocki, Use Cases Elicitation of Use Cases Breadth Before Depth Breadth Before Depth: Conserve your energy by developing an overview of your use cases first, then progressively add detail. Spiral Development Spiral Development: Develop use cases in an iterative, breadth-first manner, with each iteration prograssively increasing the precision and accuracy. Multiple Forms Multiple Forms: Select the format based on the risks associated with the project and the preferences of the people involved.

J.Nawrocki, Use Cases Short FormatActor Administrator Use Case Set Monitor Parameters Select MonitorDescription Person monitoring and controlling job control systemDescription Allow administrator to specify boundaries and Precision of items being monitored Choose something to monitor (e.g. a process or wait queue)

J.Nawrocki, Use Cases Fully Dressed Format (1) Buy Something Primary Actor Primary Actor: Requestor Goal in Context Goal in Context: Requestor buys something through the system, gets it. Does not include paying for it. Scope Scope: Business – The overall purchasing mechanism, electronic adn non-electronic, as seen by the people in the company. Level Level: Summary Stakeholders and Interests Requestor Requestor: Wants what he/she ordered. Company Company: Wants to control spending but allow needed purchases. Vendor Vendor: Wants to get paid for any goods delivered. Precondition Precondition: None

J.Nawrocki, Use Cases Fully Dressed Format (2) Success Guarantees Success Guarantees: Requestor has goods, correct budet ready do be debited. Trigger Trigger: Requestor decides to buy something. Main Success Scenario 1.Requestor 1.Requestor: Initiate a request. 2.Approver 2.Approver: Check money in the budget, check price of goods, complete request for submission. 3.Buyer 3.Buyer: Check contents of storage, find best vendor for goods. 4.Authorizer 4.Authorizer: Validate Approver’s signature....Extensions 1a. Requestor does not know vendor or price: leave those parts blank and continue.

J.Nawrocki, Use Cases Fully Dressed Format (3) Priority Priority: Various Response Time Response Time: Various Frequency Frequency: Three times a day Channel to Primary Actor Channel to Primary Actor: Internet browser, mail system, or equivalent Channels to Secondary Actors Channels to Secondary Actors: Fax, phone, car Open Issues Open Issues: When is a canceled request deleted from the system? What authorization is needed to cancel a request?

J.Nawrocki, Use Cases Elicitation of Use Cases Quitting Time Quitting Time: Stop developing use cases once they are complete and satisfactorily meet audience needs. Writers Lincense Writers Lincense: Small diffrences in writing style are inevitable.

J.Nawrocki, Use Cases Agenda Historical Perspective Scenarios vs. Use Cases Poorly-Written Use Case Patterns for Effective Use Cases Elicitation of Use Cases Use Cases vs. User Stories Introduction XPrince Team Project Lifecycle The Analyst Role The Architect Role The Project Manager Role Scaling up Conclusions

J.Nawrocki, Use Cases Use Cases vs. User Stories Customer User story Analyst Use case

J.Nawrocki, Use Cases Summary Behavioural description Several scenarios & 1 goal Good and bad use cases Elicitation process Use cases and user stories

J.Nawrocki, Use Cases Questions?

J.Nawrocki, Use Cases Quality assessment 1. What is your general impression? (1 - 6) 2. Was it too slow or too fast? 3. What important did you learn during the lecture? 4. What to improve and how?