CMPT 275 Software Engineering Requirements Analysis Phase Requirements Analysis Activity (use cases) Janice Regan, 2008-2014

Class Project: Requirements Analysis Next you will proceed using use case centered development (UCCD) to your requirements model System Context Diagram Identifying Actors and developing Use Cases Primary classes Use cases and Scenarios (formal and informal) Use case Diagram Class (object) Diagram State Diagrams Janice Regan, 2008-2014

Requirements Analysis Activity Software Developer Client/User Update SRS Use Case Centered Development (UCCD) Questions Use Case Diagram Use Cases Class Diagram Primary Classes System Context Diagram Scenarios State Diagram Janice Regan, 2008-2014

Actor Entity outside the software system interacts with the system Operates on objects in the system but cannot be operated upon by objects in the system. Human, hardware device, another software system Represents coherent role played by users e.g.: In an automated registration system teacher, student, registrations data base Janice Regan, 2008-2014

Actor A user of software system may take on more than 1 role, usually at different times e.g.: Eva interacts with the system not only as a student actor but also as a teacher actor Eva teaches math, but is a student of French An actor may represent more than one user e.g.: Both Eva and John may take the role of a student Janice Regan, 2008-2014

Primary and Secondary Actors Primary Actors Actors who initiate a scenario (use case) causing the system to achieve a goal automated registration system example the student or teacher is a primary actor Secondary Actors Actors supporting the system so primary users goals can be completed (do not initiate the use case or scenario) automated registration system example the registration data base is a secondary actor Janice Regan, 2008-2014

System Context Diagram: LMS Show how the software system interacts with its environment Librarian Resources (Books, CDs ..) Patron Software System Being created Employee Information Repository (DB) Web Libraries Resource Information Repository (DB) Online Journals Student Information Repository (DB) Janice Regan, 2008-2014

Use Cases Specify the behaviour of the system from the user’s perspective Provides value to at least one user of the system Describe a sequence of actions, performed by the system, to yield a result desired by that user The behavior of the system is expressed without specifying how the behavior is implemented (What is behavior, not how is it done) To get started generalize an informal scenario (or closely related set of informal scenarios) Informal scenarios are a good starting point Janice Regan, 2008-2014

Use Case Format Use Case Name (+ Functional Requirement #s) Usually short active verb phrase related to behavior modelled by the use case Participating actors Preconditions What conditions must be true at the beginning of the use case? Main flow of events Janice Regan, 2008-2014

Use Case Format Main flow of events Post conditions Indicate how and when use case starts Describe the essential behavior associated with the use case Post conditions What occurs as a result of the use case executing Describe state of system Exceptional flow of events (zero to many) Enumerate possible erroneous flow of events Janice Regan, 2008-2014

Building a use case Start with your informal scenario for a basic function of the system As an example use the Check in resource case for the LMS, using an example scenario illustrating the most common case. (Book checked in, no extra problems) Build a first draft of your use case based on this use case Consider other related use cases, add the exceptional conditions that may occur in related informal scenarios Revise your use case to include actions needed to also model the related informal scenarios. Janice Regan, 2008-2014

Sample LMS use case: 1 Use case name: CheckInResource (Functional Requirement #7) Participating actors: Librarian and Patron Preconditions Librarian and patron validated to LMS Library DB initialized Janice Regan, 2008-2014

Sample LMS use case: 2 Main flow of events Librarian enters resource’s call number The status of the resource is changed to "reshelve“ Return date is reset Librarian indicates that he is done Janice Regan, 2008-2014

Sample LMS use case: 3 Postconditions Patron DB entry updated to reflect returned resource Resource DB entry updated to reflect changed status: reshelve Exceptional flow of events (some examples) Resource call number not valid Resource is overdue There is a hold on the resource Janice Regan, 2008-2014

Building Use Cases Building your use cases is an iterative process When you have a use case like the one we just built read through it carefully and identify exceptional (special) cases The exceptional cases we have identified are shown in part F of the previous slide Determine what needs to be done in each of these exceptional cases and add the information to the use case Janice Regan, 2008-2014

Revised Check in Use Case: 1 Use case name: CheckInResource (Functional Requirement #7) Participating actors: Librarian (Patron does not directly interact with the system so is not a participating actor unless they are doing the check out themselves) Janice Regan, 2008-2014

Revised Check in Use Case: 2 Preconditions: Librarian is a valid librarian LMS is ready to go (DB has been populated and LMS has been initialized) Initial Option screen displayed (your mock up should tell you what information will be on the option screen) Main flow of events: The use case starts when Librarian selects CheckInResource option. Janice Regan, 2008-2014

Revised Check in Use Case: 3 Main flow of events (cont): Librarian enters the Dewey call number for the resource (HOW: either scan or type in #) then checks and commits the entry (HOW: by pressing the Enter key). The LMS checks that the Dewey call number for the resource has been entered successfully and it is valid (i.e., it does refer to a resource of this library) The LMS finds the resource and finds its borrower, then displays the resource and patron information on the screen. Janice Regan, 2008-2014

Revised Check in Use Case: 4 Main flow of events: (cont) The DetermineOverdueCharge use case is initiated. LMS verifies that there is no outstanding request for this resource. The LMS changes the status of the resource to "reshelve" and cancels its "due date" and "date of loan" and updates "date of return". LMS updates the screen showing the newly checked-in resource along with the updated dates. The use case terminates when Librarian indicates that she/he is done. Janice Regan, 2008-2014

Revised Check in Use Case: 5 Postconditions: Patron record updated to reflect the newly checked in resource. Resource record updated to reflect its checked in status and dates. Return to the initial Option screen. Janice Regan, 2008-2014

Revised Check in Use Case: 6 Exceptional flow of events: Exceptional flow of events #1 If the Dewey call number was entered incorrectly, LMS states so and the use case terminates. Exceptional flow of events #2 If the Dewey call number entered is invalid (does not exists in LMS DB), LMS states so and the use case terminates. Janice Regan, 2008-2014

Revised Check in Use Case: 7 Exceptional flow of events: Exceptional flow of events #3 If there is an outstanding request for this resource, LMS changes the status of the resource to “requested“, cancels its "due date" and "date of loan" (perhaps updates "date of return"), updates the screen showing the new state of the resource and the use case terminates. Janice Regan, 2008-2014

Building Use Cases Remember that building your use cases is an iterative process When you have a use case like the one we just built read through it carefully and look for more possibilities E.G. what happens if the resource the patron is trying to check in has not been checked out Add these additional possibilities and integrate them into the use case. Continue iterating till you cannot see any other possibilities Janice Regan, 2008-2014

Characteristics of Use Cases Use cases are more abstract than informal scenarios, because … A single use case may encompass multiple informal scenarios Use cases avoid redundancy Use cases are more formally structured than informal scenarios Use cases seek to capture complete breadth of system behavior Janice Regan, 2008-2014

Use case modeling Identify actors Define the scope of the system (context diagram) Use scenarios, along with mock ups for visual support, to help you validate requirements with the client Build a set of use cases that encapsulates the requirements How do we verify that our use cases are complete, consistent, and unambiguous? Use a use case diagram Janice Regan, 2008-2014