Ivan Marsic • Rutgers
University 60
• Fault-tolerance
• Usability
• Reliability
• Performance
• Security
Although it may appear easy at first, the distinction between functional and non-functional requirements is often difficult to make. More often than not, these requirements are intertwined
and satisfying a non-functional requirement usually necessitates modifications in the system function. The reader should be cautioned against regarding non-functional requirements
secondary in importance relative to functional requirements. The satisfaction of non-functional requirements must be as thoroughly and rigorously ensured as is the case for functional
requirements. In any case, satisfaction of a requirement comes down to observable effects in the world.
A popular technique for elicitation of functional requirements is the use case analysis, which is described next.
2.2.2 Use Cases
Actors, Responsibilities, Goals
The consideration of system requirements starts with identifying the entities that will be related to the system under discussion SuD, the so-called
actors
. An actor is any entity human, physical object, or another system external to the SuD that interacts with the SuD. The actors have their
responsibilities
and seek the system’s help in managing those responsibilities. In our case-study example, resident’s responsibilities are to maintain the apartment secured and in proper order as
well as seek comfortable living. The property manager’s responsibilities include keeping track of current and departed residents. Maintenance personnel’s responsibilities include checks and
repairs. There are also some physical devices depicted in Figure 1-4 that are not part of the SuD but interact with it. They also count as actors for our system, as will be seen below.
To carry out its responsibility, an actor sets some
goals
, which are context-dependent. For example, if the resident is leaving the apartment for work has a goal of locking the door; when
coming back from work, the resident’s goal is to open the door and enter the apartment. To achieve its goals, an actor performs some actions. An action is the triggering of an interaction
with another actor, calling upon one of the responsibilities of the other actor. If the other actor delivers, then the initiating actor is closer to reaching its goal. For example, the actor may initiate
interaction with the system, so the system can help achieving those goals. The SuD itself is an actor and its responsibility is to help the actors achieve their goals. In this process, SuD may seek
help from other systems or actors.
To this point we have identified the following actors: •
Tenant represents the apartment residents
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
