1. Use Cases Discuss the what and how of use cases: Basics Examples Benefits Parts Stages Guidelines

2. Basics: What Are They For? Use Cases are living documents to be used continously in development to : Describe a work process Focus discussion about system actions Be the functional requirements for a system Document the design of a system Generate procedures for testing a system Write instructions, help and training materials for end users.

3. Basics: Document Requirements Identify the function requirements (goals) that the system will need to perform Some functions cannot be accomplished in a system as it is installed: A programmer will need to customize the system Example: you may need to build a new report or add a new field to capture additional data.

4. Basics: Writing A Use Case A use case describes how to achieve a specific goal, or function, using the system. Should describe the main system behavior Should not list all the requirements Plain language - no technical jargon

5. Use Case: Example 1A. Use Case Number: 9 1B. Use Case Title: Log in 2. Level: User-level 3. Primary Actor: Any user 4. Context of Use: The user logs in to authenticate his or her role in the system and to perform a task in the system. 5. Preconditions: A user account has been created for the user. 6. Success Guarantee: The user can successfully access the system and perform actions appropriate for his or her role. 7. Main Success Scenario (MSS): 1. The user connects to the system. 2. The user enters his/her username and password. 3. The system validates the username and password. 4. The system determines the user’s role. 5. The system displays a list of actions the user can perform based on the user’s role.

6. Use Case: Example 8. Extensions: 3a. The system determines that the password is incorrect for the username entered. 1. The system prompts the user to re-enter the password. 3a1. The system determines that the re-entered password is incorrect. 2. The system provides the option for the user to retrieve a forgotten password. 3b. The system determines that the username does not match a username for any account. 1. The system displays an error message. 4a. The system determines that the user has no role assigned in the system. 1. The system does not allow the user to access the system. 9. Notes/ Issues/ Reviewer Comments: This use case is the same for iHRIS Manage, Qualify and Plan. Completed by: Use case writer Date: October 25, 2008 Reviewed by: Use case reviewer Date: November 4, 2008

7. Examples: iHRIS iHRIS Manage http://www.capacityproject.org/hris/suite/UseCaseReport-iHRISManage.htm iHRIS Qualify http://www.capacityproject.org/hris/suite/UseCaseReport_iHRISQualify.htm iHRIS Plan http://www.capacityproject.org/hris/suite/UseCaseReport_iHRISPlan.htm

8. Benefits: Focused Goals Use cases should be co-written by stakeholders, users and developers. Ensures that the system includes the functions that are truly important to the people who will be using it Common understanding of the what will be implemented Use cases focus on action oriented goals: defines the scope of the system eliminates unnecessary requirements reduces costs and development time

9. Benefits: Guiding Development What should we build? There is a gap between the people who understand the problem and the people who understand how to build the solution. Use Cases bridge that gap. Use Cases describe functional requirements in a way that can be understood by stakeholders and users of the system and by the developers of the system

10. Benefits: Prioritize Development Several related use cases may be organized into modules, called packages. Development of each module can then be prioritized and scheduled Plan an iterative path for development: Core functions can be developed first Later by lower priority features are added Core system can be used even while new functions are being developed

11. Use Cases: Parts Minimal parts of a use case are: A goal to achieve The primary actor identified by a role in interacting with the system A set of action steps, the main success scenario Preconditions that must be true to start the scenario A triggering event that starts the scenario An end condition if the scenario is successfully achieved, called the success guarantee A possible set of extensions, or alternate scenarios, leading toward either the success or failure of the goal

12. Use Case: Parts 1A. Use Case Number: Assign a number to the use case for reference It is helpful to number use cases in order of implementation or priority Numbers can aslo indicate module 1B. Use Case Title: Assign a title to the use case, Generally a shortened form of the goal in action-verb- noun format.

13. Use Case: Parts 2. Level: user-level for a use case that describes one complete activity in the system subfunction for a use case that depends on a user-level use case but is too long to include in the user-level use case. sumary sequences multiple user goals 3. Primary Actor: The role of the user performing use case List of roles should be set before hand

14. Use Case: Parts 4. Brief Description/Goal: This statement describes the function that the primary actor wants to accomplish 5. Preconditions: List any preconditions for the use case. Preconditions specify what the system will ensure is true before letting the use case start. Generally, a precondition indicates that some other use case has been run to set it up 6. Success Guarantee: This statement describes the function that the primary actor wants to accomplish

15. Use Case: Parts 7. Main Success Scenario (MSS): The action steps of a typical scenario in which the goal is delivered. The first step is the trigger that initiates the use case Ideally, there should be 3-12 steps; number each step 8. Extensions: List the conditions that may cause the system behavior to branch from the steps that occur in the Main Success Scenario 9. Notes/Issues/Reviewer Comments: Good place to note any issues that have arisen regarding the use case or its implementation in the system

16. Use Cases: Stages Writing use cases is an iterative process that works well with iterative software development Stages of a Use Case: 1. Brief: The use case is summarized in brief narrative. The Description and Main Success Scenario fields are completed. Generate the Actors & Goals list. 2. Initial: The 1 st draft is written. Steps described only briefly. Used for grouping and prioritizing

17. Use Cases: Stages (continued) 3. Full: The 2nd draft of the use case is written. Includes all pre-conditions Detailed Steps Extensions and Explanations Can be used for development 4. Tested: A testing procedure is developed from use cases. Tested against developed product. Use Cases updated based on testing 5. Documented: Help text is generated from the use case Help tested against developed product. Use Cases updated slightly

18. Use Cases: Stages 6. Released: The Use Case is part of a release version of the software 7. Updated: A Use Case is revisde after a release Tips Once the Full version has been complete, document and date any changes in the Notes field Creating a revision history for the use case. New features of use cases in development should be added to the Project Control List

19. Use Case: Guidelines Guidelines for developing Use Cases List every possible human and non-human primary actor Brainstorm and exhaustively list all possible user goals for each actor. Write a short description of use case behavior for each goal, the use case brief, mentioning only the most significant activity and failures. Write user-level use cases for each goal using the use case template above. Use the Actors and Goals Templates to organize before writing full use cases Prioritize and assign goals to development teams and software releases. Write Summary-Level Use Cases Summary use cases tie together, and thus refer to, a number of user- level use cases but do not provide function requirements There are typically only four or five summary-level use cases for a system. Provide a helpful tool for quickly communicating with executives, stakeholders and customers the broad scope of what the system will do.