1.0 Goals and Trade-offs

1.1 Design Goals

Facilities Management systems, such as OWL, are used to monitor workplaces and similar locations to ensure maximum comfort and productivity for the workers. The primary goal of OWL is to design a Facilities Management system for Intel's Intelligent Workplace (IW) project. Current Facilities Management systems are not built to handle a dynamic environment such as the IW; therefore, OWL will increase the functionality of existing systems. As this project only spans the timeframe of a single college project course, the expectation that a fully functional system would be delivered by the end of the project (December 5, 1996) is unrealistic; therefore, the focus for this stage of the project is to create a prototype of the OWL system that can be expanded on by future contributors.

There are some overarcing goals to the OWL system, which are to be implemented in the prototype and continued to the final system. These include:

A user interface that can handle mouse, keyboard, and speech input;
A central database repository will store inputs from the IW's varied types of sensors (light, temperature, air flow);
Automated systems will respond to some sensor readings independent of user input in order to comply with certain efficiency guidelines;
New code for the OWL system will be written in Java in order to ease portability to multiple platforms.

1.2 Design Priorities

No piece of software is perfect. However, every piece of software has certain goals that should be attempted. Even these various goals, however, cannot all be realized, especially not in one semester. Therefore, it is necessary to prioritize the various design goals for the OWL project. The prioritization that has been settled on is as follows:

1.2.1 Highest Priority Item

Design a prototype facilities management software system for Intel's Intelligent Workplace project.

1.2.2 High Priority Items

Location Transparency: In order to facilitate portability and ease of use, the actual locations of the servers on which the "core" of OWL is running should be transparent to clients.
Fault Tolerance: The system should be resilient to individual server and client failures.
Ease of use and learning: No software is practical if users are unwilling or unable to learn how to use it. Therefore, the system should be relatively self-explanatory so that the amount of time required to become familiar with it is minimized.
Efficiency: If a product responds slowly to user input, or does not facilitate efficient solutions to problems, then it will inevitably be replaced by a superior product. In order to maximize OWL's effective lifespan, the product should be efficient.
Correct functionality: OWL, as should any good product, should be as bug-free as possible.

1.2.3 Medium Priority Items

Portability: The client system should be usable on multiple platforms, and should be easily ported to a new architecture, should the need arise.
Reuse of Components: The individual subsystems of OWL should be easily extractable and applicable to other systems if similar functionality is required.
Rapid development: The prototype should be developed, as complete as possible, by the end of the time period (the end of the semester).
Extensibility: At the end of the semester, the prototype will be capable of handling only one small section of the IW, and only one type of sensor (light sensors). The workplace control engine should be extensible enough that it will eventually be able to handle all the different aspects of the IW.

1.2.4 Low Priority Items

While goals such as readability, user-friendliness and adaptability are priorities for any software project, they are not given above-average treatment by the OWL development teams.

1.3 Design Trade-offs

When developing a software system, sometimes established design goals can lead to an impass: a situation will arise where one design goal must be sacrificed in order to acheive another. When problems of this nature present themselves, the system's (or subsystem's) development team must make a trade-off, and decide which goal is more important.

1.3.1 System-Level Design Tradeoffs

Some trade-offs arise at the System level, and are shared by most software projects. For instance, a software project has a defined delivery date, requiring that all functionality be completed by that date. However, sometimes all the required functionality cannot be completed by the specified delivery date. The trade-off in this scenario is between required functionality and required schedule: is the system on-time but not complete, or complete but late? Other trade-offs encountered by the system as a whole are functionality vs. effeciency (the client's requests should be handled completely, but they should also be handled quickly) and specificity vs. generality (the system should run efficiently and according to the user's wishes, but should also be portable to multiple platforms).

1.3.2 Subsystem-Level Design Tradeoffs

Some of the subteams of OWL have also come across trade-off situations that are specific to that subsystem's functionality.

The User Interface subteam, for instance, has discovered that speech input, which is a stated requirement of the product, is not supported by Java, which was specified as the language in which all new code should be written. This problem has been solved by specifying that clients will only be available on systems that have established speech input drivers.

The Control subteam has discovered that the efficiency guidelines given may conflict with the wishes of the user. For instance, in summer, efficiency guidelines dictate that natural light should be minimized in favor of artificial light to save resources that would be spent on cooling. However, if a user prefers to work in natural light even in the summer, the system should accede to the user's wishes. At the time of this writing, the subteam has not determined a solution to this problem.

The Facilities Management subteam has found that MicroStation, the chosen Site Editor package, has more functionality than they need, and although the Simulation subteam requires some of the extra functionality, the package is complex enough that the Facility Manager's required learning time will be significantly increased if they have to learn MicroStation. At the time of this writing, the subteam has not determined a solution to this problem.

1.4 Contributing Documents

The information in the following documents was used in the development of this section of the System Design Document:

Return to the main System Document Page