IBM
Contents Index Previous Next



Requirements on the Access Control System


This section should only be viewed as a background for the design of the system and not as a description of a complete requirements analysis phase.

Description of the System to be Built

This application is chosen because it is a good example of an embedded system, with features that make it very suitable to be specified using SDL and the object oriented extensions (introduced in the 1992 version of the language).

The Access Control system is a system to control the access to a building. To enter the building, a user must have a registered card and a personal code (four digits). The device used for entering the card and personal code consists of a card reader, a keypad and a display.

The main characteristics of the system are:

Figure 1 : Graphical interface to the Access Control system

Textual Requirements

This description serves as an initial set of requirements. These requirements are normally collected and refined to a standardized form to make the requirements analysis easier to deal with and each requirement easier to refer to. Only the initial set of requirements will be shown for this simple example.

We will also focus only on the functional requirements and leave out the non-functional requirements (like performance, reliability, availability, etc.).

Basic Requirements

The hardware devices consists of the following components:

The system should be able to fulfill the following tasks for a user:

The system should be able to fulfill the following tasks for a system administrator/supervisor:

General requirements:

Additional Requirements

The system should be able to fulfill the following tasks for a user:

The system should be able to fulfill the following tasks for a system administrator/supervisor:

Use Cases

The most interesting functional requirements are described by a number of use cases. These use cases describe the interaction between the system and its environment and formalizes (to some extent) the functional requirements.

The outside entities that communicate with the system are usually called the actors of the use cases. Actors are often

There are two different actors of the Access Control system that are relevant (the hardware is not taken into account in this simple example): user and supervisor.

The use cases could be described either textually or by MSCs or by a combination of the two notations. An example of a use case with the user actor is the Open Door use case (described by the MSC OpenDoor in Figure 2). The use case ends with the fulfillment of the goal of the use case: the opening of the door.

Figure 2 : Requirements use case OpenDoor

Use cases that describe requirements usually show only the interaction between the actors and the system. When the use cases are refined in later activities, they can also express the inner behavior of the system.

Object Model

The requirements object model is a simple object model that relates the known domain entities of an access control system and its environment. The environment of the system could be anything that is related to the system as long as it is relevant for understanding the problem, typically the actors of the use cases that describe the wanted behavior of the system. The objective of the model is to give a simple picture of the problem without going into details.

Figure 3 : Requirements object model

When elaborating the requirements object model into an analysis object model, concern about the system properties rather than the real world properties will affect the model. In the requirements activity, it is not known what a certain class will result in or if it should be modeled at all. When analyzing the requirements and the system to be built, classes can be mapped to software entities, hardware entities or not mapped at all.


http://www.ibm.com/rational
Contents Index Previous Next