Types of Requirements Requirements Analysis and Use Cases

Chapter 2 • Object-Oriented Software Engineering 61 • Landlord represents the property management personnel • Devices, such as lock-mechanism and light-switch, that are controlled by our system • Other potential actors: Maintenance, Police, etc., see below. When deciding about the introducing new actors, the key question is: “Does the system provide different services to the new actor?” Likewise, our system may receive help from another system in the course of fulfilling the actor’s goal. In this case, the other systems will become different actors if they offer different type of service to our SuD. Examples will be seen below. It is important to keep in mind that an actor is associated with a role rather than with a person. Hence, a single actor should be created per role, but a person can have multiple roles, which means that a single person can appear as different actors. Also, multiple persons can play the same role, i.e., appear as a single actor, perhaps at different times. The following table summarizes preliminary use cases for our case-study example. Table 2-1: Actors, goals, and the associated use cases for the home access control system. Actor Actor’s Goal Use Case Name Landlord To open the door’s lock and enter get space lighted up. Unlock UC-1 Landlord To lock the door shut the lights sometimes?. Lock UC-2 Landlord To manage user accounts and maintain the database of residents up to date. ManageUsers UC-3 Landlord To find out who accessed the home in a given interval of time. ShowAccessHistory UC-4 Tenant To open the door’s lock and enter get space lighted up. Unlock UC-1 Tenant To lock the door shut the lights sometimes?. Lock UC-2 LockDevice To control the physical lock mechanism. UC-1, UC-2 LightSwitch To control the lightbulb. UC-1, UC-2 ActorX ? To auto-lock the door after an interval of time, if person forgot to lock. Lock UC-2 Since the Tenant and Landlord actors have different responsibilities and goals, they will utilize different use cases and thus they should be seen differently by the system. The new actor can use more or less, subset or different ones use cases than the existing actors, as seen in Table 2-1. We could distinguish the Maintenance actor who can do everything as the Landlord, except to manage users. If we want to include the Maintenance but the same use cases apply for this actor as for the Tenant, this means that there is no reason to distinguish them—we just must come up with an actor name that covers both. Notice that the last row contains an unidentified actor, “ActorX,” whose goal is to automatically close the lock after a certain period of time expires, to account for forgetful persons. Obviously, this is not a person’s goal, but neither is it the SuD’s goal because SuD does nothing on its own— it must receive an external stimulus to take action. We will see below how this is solved. Generally, the system under development has five key stakeholders: customers, systems and business analysts, systems architects and developers, software testing and quality assurance Ivan Marsic • Rutgers University 62 engineers, and project managers. We will be mainly concerned with the actors that interact directly with the SuD, but any of the stakeholders has certain goals for the SuD and occasionally it may be appropriate to list those goals. Table 2-1 implies that a software system is developed with a purposeresponsibility—this purpose is helping its users actors to achieve their goals. Use cases are usage scenarios and therefore there must be an actor intentionally using this system. The issue of developer’s intentions vs. possible usage scenarios is an important one and can be tricky to resolve. There is a tacit but important assumption made by individual developers and large organizations alike, and that is that they are able to control the types of applications in which their products will ultimately be used. Even a very focused tool is designed not without potential to do other things—a clever user may come up with unintended uses, whether serendipitously or intentionally. Use Cases