| Requirements
Document |
 |
RWL |
Introduction:
Lockheed Martin of Moorestown, NJ requested the services of the RWL
to design a flexible and robust information system for the management of
mechanical devices. The intent of this project is to provide an information
system for the data collected from these devices. The system will be flexible,
allowing for many types of devices. The system will also be modular; new
devices can be added at any time. Furthermore, the system will provide
an interface to the data. The interface presents instantaneous status information
and historical data for each device. The parameters of the system, such
as user access, device properties, and device reporting intervals, will
be configurable. Finally, the system will be redundant.
Project Advisor:
The project advisor for the Lockheed Martin group is David Smith. <rwlmgr@cc.gatech.edu>
We communicate with Professor Smith through weekly status emails and meetings
when necessary. The primary concern for our project advisor is to
guide our team and to keep us on the right track.
Project Sponsor:
The main project sponsor for the Lockheed Martin group is Scott Hoyle
<scott.b.hoyle@lmco.com>, manager of Advanced Control System Programs
of the Naval Electronics and Surveillance Systems division in Moorestown,
NJ. Two other key players within Scott's team includes Shane Mueller
<shane.p.mueller@lmco.com> and David Morgan. <david.c.morgan@lmco.com>
We communicate with Scott and his team through weekly conference calls
on Fridays as well as through e-mail messages. Scott Hoyle's office
number: 856-608-4029
Overall Requirements:
-
1.1 Requirement: User is able to add a new device to the system (Modularity)
Test: The device the user added is added to the database in the proper tables
-
1.2 Requirement: User is able to Add New Types of Devices to the system (Flexibility)
Test: The new device type is added to the database with the new tables made and the proper linking estabilished to the correct tables involved
-
1.3 Requirement: User is able to view instantaneous info about device(s)
Test: Status information about device(s) is displayed to the user from the information in the database
-
1.4 Requirement: User is able to view historical information about device(s)
Test: Historical information about device(s) are displayed to the user from the information in the database
-
1.5 Requirement: Redundancy In Case of Disaster
Test: Database is implemented in standard DBMS software
-
1.5 Requirement: Configurable Parameters (User Access/Securty, etc.)
1.5.1 Test1: Superuser is able to add user(s) with normal or mangerial security access
1.5.2 Test2: Superuser is able to remove user(s) with normal or managerial security access
1.5.3 Test3: Normal users are unable to remove, modify, or add other users to the database
-
1.6 Requirement: Implement a front end user interface for user to access database commands
Test: User is able to access the given database commands through some sort of interface; be it a console, JSP page, java applet or any other type of user interface
Database Information Requirements:
Device Information
2.1 Requirement: All devices have a usable (easily discernable) device name, an
identifier, a location and a description.
Test: Database contains name, id, location and description fields.
2.2. Requirement: They each belong to a subsystem within a system.
Test: All devices have a subsytem, or system, field which is filled out.
2.3 Requirement: Each device has a physical installation and software updates that are
done. We want to be able to record the time and date of each of these events as
well as who did that task.
Test: Database contains fields for each device which allow for dates and
usernames for each of the tasks.
2.4 Requirement: Various device types have various state data that they need to record
(with a time stamp)
Test: State data is stored for each device along with a corresponding time
stamp for last update
2.5 Requirement: A device can be standalone which means it does not have to be in a zone or contained in any system
Test: Add a device without linking it to anything and make sure it's not linked to anything.
2.6 Requirement: A device can be added to one or more systems.
Test: Add the device to 1 system and then add it to another system and check for device being in both systems.
2.7 Requirement: A device can be a member of a zone without being a member of a system.
Test: Add device to a zone but not a system, make sure device is part of the zone and of no systems.
2.8 Requirement: Behavior set is only able to be removed if and only if no devices reference it.
Test: Try removing a behavior set that a device is referencing and removing with no devices referencing.
2.9 Requirement: Behaviors are only able to be removed if and only if no behavior sets reference it.
Test: Try removing a behavior that a behavior set references and removing with no behavior sets referencing it.
Examples of devices:
Heat pumps and water pumps need to record their status of On/Standby/Off and an alarm state.
Valves need to record their status of Open/Closed and an alarm state.
Air temperature sensors record only one thing - air temperature.
Flow meters record water temperature, flow rate and water pressure.
Subsystem Information
-
3.1 Requirement: A subsystem is a hierarchical grouping of devices. An overall
status needs to be maintained for each subsystem which will be
Red, Yellow, Green, or Blue.
Test: Each subsystem in the database has a correct status.
System Information
-
4.1 Requirement: A system is a hierarchical grouping of subsystems. An overall
status needs to be maintained for each system. That status will be Red,
Yellow, Green, or Blue.
Test: Each system in the database has a correct status.
-
4.2 Requirement: A system shall not be removed if it contains devices or other systems.
Test: Each system containing anything under it should not be removed, only systems that are empty are able to be removed.
-
4.3 Requirement: A system snapshot should be able to be viewed.
Test: List contains listing of devices and all their statuses and readings.
Subsystems within Systems Information
-
5.1 Requirement: Each system can contain one or more of each type of
subsystem. A status must be maintained for each subsystem within each
system. That status will be Red, Yellow, Green, or Blue.
Test: Each system in the database which contains a subsystem contains a
correct status for each subsystem
Context Information
-
6.1 Requirement: Context is a discrete combination of various states. Some states
are mutually exclusive. In Port, Underway, and At Anchor are all mutually exclusive. The
Underway category has subsets - Offense, Defense, Efficient, Quiet, and
Restricted Maneuvering (Some of these may occur simultaneously).
Test: Verify states are updated when a change of state is issued.
Historical Snapshot of Entire System
-
7.1 Requirement: Must have the ability to record all state values for all objects at an
instant of time.
Test: Application returns all state values for all objects in the database for any given timeframe.
Readiness Information
-
8.1 Requirement: Readiness information for various warfare areas must be maintained.
The status will be Red, Yellow, Green, or Blue.
Test: Various warfare areas maintain a correct status.
Zone Information
-
9.1 Requirement: Zones contain systems and stand alone devices.
Test: No zone should be empty and contain only systems and standalone devices.
DB Language for Implementation
-
10.1 Requirement: Use SQL Server 2000 as the database language
Test: Server laptop has SQL Server 2000 installed and database is running on
it.
-
10.2 Requirement: The server laptop will be setup for implementation and testing
purposes of the db.
Test: Server is running with database server.
User Interface Information Requirements:
UI Needs
-
11.1 Requirement: Able to display a web-based interface for specific users defined
in the use cases.
Test: UI is accessed over a network of some sort via a web browser
Back
to Main Page