Before choosing or programming an HRIS, it is important to identify the functions that the system will perform and document them. Think of these functions as goals. What goals do you want to achieve with your HRIS? The policy and management questions that the Stakeholder Leadership Group (SLG) developed should provide a list of these goals. Once the list of goals is developed, prioritizing the goals may help when selecting an HRIS. You should look for a system that achieves as many of the goals as possible and supports all of the high-priority goals.
However, you may find that some goals cannot be accomplished in the system as it is installed. In that case, a programmer or administrator will need to customize the system to achieve those goals. For example, you may need to build a new report or add a new field to capture additional data.
A simple way to document these needed customizations is to write use cases. A use case describes how to achieve a specific goal or function using the system. The iHRIS documentation includes a full set of use cases for the three systems to help you understand the functions that each HRIS supports when it is installed. You may modify these use cases to document the customizations needed to achieve your goals, or you may use the template that follows this introduction to write use cases.
One of the most difficult aspects of system development is figuring out exactly what to build. There is often a gap between the people who understand the problem and the people who understand how to build the solution. Use cases are one of the most effective means of bridging that gap. Written in plain language, without technical jargon, use cases describe system goals in a way that can be understood by the stakeholders and users of the system and by the developers of the system. The set of use cases serves as a roadmap for the developer to achieve what is desired by the stakeholders.
Use cases are usually cowritten by stakeholders, users and developers. This ensures that the system includes the functions that are truly important to the people who will be using it. Use cases should focus on the goals that users want to achieve. Focusing on action-oriented goals defines the scope of the system and eliminates unnecessary requirements, reducing costs and development time.
Several related use cases may be organized into modules, called packages. Development of each module can then be prioritized and scheduled. This helps plan a path for development where core functions can be developed first and enhanced later by lower priority features. The core system can be used even while new functions are being developed.
However, use cases should not serve as all of the system specifications. For instance, use cases do not specify the user interface design. They don't capture nonfunctional requirements, such as performance, security and auditing requirements. Also, use cases do not describe database fields or their relationships to one another. Use cases are just one part of the full system specifications, but they are still a valuable communications tool.
Use cases should be living documents. Stakeholders, users and developers should constantly review, revise and expand the use cases during the development or customization of a system. At different stages, use cases can be used to:
Not all requirements have to be known before starting development. Use cases may be edited during development to capture additional goals, and new use cases may be written as needs for the system arise.
The use case enumerates all of the steps describing the interaction of one user—called the actor—with the system to achieve a goal. The use case begins at a triggering event and continues until the goal is either successfully achieved or abandoned. It collects all the possible scenarios for how the goal can be achieved and how it may fail.
At minimum, each use case should contain the following information:
Use these guidelines to complete the blank use case template. Write a use case for each goal that has been identified for your system. A completed example is given following the guidelines.
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.
1b. Use Case Title: Assign a title to the use case, generally a shortened form of the goal in action-verb-noun format.
2. Level: Select summary for a use case that summarizes a number of activities or is outside the scope of the system; user-level for a use case that describes one complete activity in the system; or 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.
3. Actor: Write the role of the user performing the use case. It is often helpful to brainstorm and list all the possible actors on a system before beginning to write use cases.
4. Goal: Write a goal statement that is longer and more detailed than the use case title. 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: State the successful result that the primary actor wants. It should satisfy the stated goal and ensure that the stakeholders' interests are met.
7. Main Success Scenario (MSS): Write the action steps of a typical scenario in which the goal is delivered. The first step is the trigger that initiates the use case. Each following step describes an action that the user or the system takes in reaction to the previous step to accomplish the use case goal. Ideally, there should be three to 12 steps; number each step.
8. Extensions: Brainstorm and list the conditions that may cause the system behavior to branch from the steps that occur in the MSS. An extension must be detectable by the system, and the system must take some action to handle it. Number each extension to link to the MSS step in this format: 1a, 1b… If the extension can happen at any time, precede it with an asterisk (*) and list it first: *a, *b… Indent extensions to extensions and restart numbering: 1a1, 1b1… Under each extension, indent and write how the system responds, the extension-handling steps. Each extension-handling step should end back in the main success scenario, at an alternative successful exit or in failure (a system error) that stops the use case before the goal is accomplished.
9. Notes/Issues/Reviewer Comments: Add any comments on the use case or explanatory notes needed. This is also a good place to note any issues that have arisen regarding the use case or its implementation in the system.
Completed use case example for reference, suitable for printing. PDF
Suitable for printing. PDF
Suitable for modifying or completing on the computer. Microsoft Word