Documentation: Use Case Development Tool and iHRIS Use Cases

Objective

With the SLG and the implementation team, collaboratively develop the system requirements and document them using a standard methodology.

If you decide to document the system requirements for customizing iHRIS using the use case methodology, we have included a template for writing use cases. We have also included all of the original use cases developed for iHRIS Common, Manage, and Qualify, which you may adapt as needed.

Use Cases: Concepts

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.

You may find that some goals cannot be accomplished in iHRIS as it is installed. In that case, a programmer will need to customize iHRIS 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. At the end of this document is a template to use when writing use cases.

Benefits of 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 co-written 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:

• Describe a work process
• Focus discussion about system actions
• Be the functional requirements for a system
• Document the design of a system
• Serve as a mechanism for managing and tracking software development
• Generate procedures for testing a system
• Write instructional, help and training materials for end users.

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 Parts of a Use Case

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:

• A goal to achieve
• The actor who is attempting to achieve the goal; the actor should be identified by a role in interacting with the system, not by a name or the name of a group
• A condition under which the use case runs; this may include any preconditions that must be true before the scenario can start and a triggering event that starts the scenario
• A set of action steps called the main success scenario
• A possible set of extensions, or alternate scenarios, leading toward either the success or failure of the goal.