Functional models describe business processes and interaction of an information system with its environment. On the other hand, use cases are used to describe the basic functions of the information system. It can be used to describe the current as-is system and to-be system being developed. As an analyst, we can implement use cases and the use case diagram to better understand the functionality of a system. Use case diagram provides a simple, straightforward way of communicating to the users of what the system will do, and also disseminate different kinds of users that will interact with each functionality system.

There are five steps that we can use to define the major use cases, that we call it as the functional requirements:

• As the first step, we gather requirement from the users and review the requirements definition. In this step, we aim for a complete overview of our business process. For example, a health clinic wants to change their manual operational activities, into a new system. From this case, we can gather all requirements that we need, such as managing appointments, producing schedule, and also recording doctor schedule availability. For managing appointments, we may require the system can record every cancelled or new appointment that the patient makes. We may also require that the system can update the doctor availability schedule. As the conclusion for this first step, we only state what kind of important requirements that we want from the new system.
• The second step is to identify the subject’s boundaries. This helps us to identify the scope of the system, because through the subject’s boundaries, we can define which subject can interact with the system. For this step example, we can look up from the system requirements that we made. We stated that we need a requirement for the patients and also the doctors. We can conclude that through this second step, we know which subjects will interact with our system boundaries.
• The third step is to identify the primary actors and goals, which are involved with the system, and usually comes from a list of stakeholders and users. Actor is a role that a stakeholder or user plays, which involves stakeholder who is a person, group, or organization that can effect, or will be effected by the system. The goal is the functionality of the system that must be provided to the actor or other stakeholders. For example, the actor can do create, read, update, delete, or execute (CRUDE). For this step example, we may also use the business process from the previous steps. In this third step, we should do the checking for which actors and its stakeholders will get an impact from our previous system requirements. For example, when the patient wants to change or make new appointment in our clinic, obviously the actor is the one who directly jumped into the action, which is the patient itself. From this case, we can think of another part of our business who can get the impact. The office manager who checks and prints daily schedule for patient’s appointment. We can connect both of them as actor and stakeholders, because they both effected by the goals of our new system.
• The fourth step is to identify the business processes and major use cases. Major use cases mean that we should identify all key business processes and also explain to the users about our overall set of business processes, so the users can know about which key activities that they responsible with. From previous steps, we finally can conclude which major use cases of our clinic business process. The first one is managing appointment, second one is producing schedule, and the third one is record doctor availability.
• The fifth step is to review the current set of use cases that we already identified from the previous steps, because it may be necessary to split or merge those use cases. In identifying use case, we may find new use cases because it may be necessary to split or merge those use cases. In this step, there is one more way to disseminate use cases, so we can keep it easy to read and understood. We should group it into packages to keep the level of complexity reasonable. For this last step for defining major use cases, we may find other important use cases that we can implement on use case diagram. For example, we can find three important points, such as patient makes new appointment, patient changes appointment, and also patient cancels appointment, but we can merge them into one main use case, which is manage appointments. For producing schedule, we can also state that office manager can checks and prints daily schedule, but those use case can we merge into one, which is produce schedule by office manager.

References

Tegarden, D., Dennis, A., & Wixom, B. H. (2013). Systems Analysis and Design with UML. Singapore: John Wiley & Sons, Inc.