This document is well designed and gives a general feel for how the security sub-system will work. However, certain details are lacking within the document. It neglects to mention how the security will be enforced. Will the users be required to log in and out of the system? Additionally, although the document does mention the addition of User Groups (something we find very attractive), it provides no information as to how the User Group data will be accessed or changed. Finally, the document does stray from our Informal Requirements Specification in that it does not separate access of the sub-systems into read access and write access.
The Security Information module is the category on the main menu to access any or change information regarding security.
A menu will be displayed with the following choices:
Add_user - Add a new user to the system
Change_status - Change the security level for user
List_Users - Lists users of the system and their different
security clearances.
The user is required to select one of these options by clicking on it with
the left hand button of the mouse.
Group Name Can Access? Systems Admin X
Plane Admin
Flight Admin
Booking Agents
These tables are quite helpful. However, this
is where it becomes clear that no provisions are made for write access
and read access. This is necessary, as flight information will have to
be read by a number of staff members. However, those same staff members
must not be able to modify the flight information (ie. cancelling a flight).
The security of Dairy-Air's UDDERS is a key issue for the development
team. However it would be neither economical nor secure enough for Mootronix
to independantly develope a security system. Instead the required featues
of the security system will be outlined, and a development platform will
be chosen which either supports these directly, or for which third party
security software already exists. This paragragh leaves many questions unanswered.
Will the security system be implemented in the prototype? If it will be
implemented, when will the required features of the security system be
outlined? Overall this paragraph leaves us very confused. The following information needs to be stored. Within UDDERS, individual subsystems will be accessable only to those
users who require access. This will prevent sensitive information from
being accessed by unqualified people. The following user groups have been
identified at this stage:
Data Requirements
Required Storage
User Groups
| User Group | Perceived Duties |
| Systems Admin |
Administration of the whole database. Producing backups of the data. Administrering the security database, adding/deleting of users from the system. |
| Plane Admin |
Adding/deleting/modifying airplanes in the database. |
| Flight Admin |
Setting up route information in the database, scheduling of flights along routes. Tracking plane locations and usage. Cancelling Flights rom the scedule. Processing past flight records (generatig passenger list, freeing seats on plane for next flight, etc.) |
| Booking Agents |
Dealing with passengers. Selling tickets, issuing boarding passes, and rebooking of passengers who have been bumped due to overbooking or a cancelled flight. |
Well thought out seperation of our staff into groups. All that is lacking is what operations can be carried out on groups. Will the system have the capacity to add/delete/modify groups? This would be a valuable feature.