![]() |
![]() |
![]() |
![]() |
![]() |
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:
- Moderate real-time demands
- Mostly signal oriented
- Simple data representation
- Simple interface to the environment (hardware)
- A non-distributed system
- Adding new features to the system can be achieved in an easy way by adding new program logic, while the interface to the environment remains the same
- The system can be simulated in the host environment by using a graphical user interface (see Figure 1).
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:
- An 8751 microcontroller
- 64 kilobytes of program memory (RAM or ROM)
- 64 kilobytes of data memory (RAM)
- A card reader for credit cards
The card reader reads track 2. Data is stored as 40 five-bit words according to the most common standard.- A keypad
The keys are organized according to normal telephone standard. Valid keys are the digits 0-9. In the basic version, the function keys "*" and "#" are not recognized.- A display unit
The display unit can display 2 lines each consisting of 16 characters.- 4 LEDs
Four light emitting diodes will indicate the status of the controlled doors. Off = closed, on = open.The system should be able to fulfill the following tasks for a user:
- Reading the code on the back of a standard credit card.
- Reading a personal code, consisting of 4 digits, typed from the keypad.
- Validate that the card and the personal code are registered.
- If the system is configured to control more than one door, give the user the possibility to choose which door to open after the card and code have been validated.
The system should be able to fulfill the following tasks for a system administrator/supervisor:
- Registration of a user card and a personal code. Only one code is allowed for each user card.
- Registration of the supervisor card at system startup time. Only one supervisor card is allowed for each system.
- The system must be designed in such a way that it is easy, at system generation time, to configure the system to handle from one to four doors.
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:
- Stopping the opening of one door (only the supervisor can open the door after this).
- Stopping the opening of all doors (only the supervisor can open a door after this).
- Removing the blocking of one or all the doors.
- Allowing free access through one or several doors.
- Specifying different categories of cards permitting different access possibilities during a 24-hour period
- Displaying the time.
- Setting of the current time.
- Blocking a user card.
- Remove the blocking of a user card.
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 user functions are the services available for all users, such as reading the card code, reading the four digit personal code, etc.
- The supervisor functions are only available for suitable privileged personnel (e.g. a supervisor) and perform services such as registration of a new card and code.
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.
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.
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 |
![]() |
![]() |
![]() |
![]() |