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.
Good, but where will the passwords be stored? Will, the users be able to modify there own passwords? (That is if passwords will be part of the security system.) Also, what kind of information is going to be stored about each user? At a minimum, a login name, a password, and a list of groups the user is a member of are necessary. However it would be nice if full names and phone numbers (in case of emergency) were stored as well.
The following features need to be supported.
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:
| 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.