1. CMPT 275 Software Engineering
Requirements Analysis Phase
Requirements Analysis Activity (use cases)
Janice Regan,

2. 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,

3. 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,

4. 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,

5. 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,

6. 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,

7. 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,

8. 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,

9. 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,

10. 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,

11. 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,

12. 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,

13. 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,

14. 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,

15. 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,

16. 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,

17. 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,

18. 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,

19. 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,

20. 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,

21. 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,

22. 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,

23. 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,

24. 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,

25. 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,