Page 192 - Software and Systems Requirements Engineering in Practice

158 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

supported in the new system. This may require innovative ways of
displaying information in the user interface and providing fine-
grained access control over who is allowed to interact with what part
of the system. Supporting international languages implies
personalization capabilities. Regulatory policies for safety-critical
parts of the system would require alarm-handling capabilities for
situations that could cause loss of life. Supporting hardware devices
from different manufacturers would require dynamic configuration
capabilities. Table 5.5 shows a mapping of business goals to the
features of the building automation system.
These features can be refined into specific use cases based on how
the external actors shown in the context diagram in Figure 5.5 intend to
use the system. For instance, the field engineer intends to manage field
systems and dynamically reconfigure them. The facilities manager
intends to manage alarms generated by field systems that monitor a
building. Alarms related to events that could cause loss of life also result
in notifications to the public safety system. The system administrator
intends to manage the users of the building automation system.

Goal Refinement Features
Integrate existing applications into a single User Management
unified software package: the building Access Control
automation system
Field Device Management
Event Management
Alarm Management
Support international languages Internationalization and
Localization
Comply with regulations covering life-critical Alarm Management
systems, such as fire alarms, to operate
within specific latency constraints
Support hardware devices from different Dynamic Reconfiguration
manufacturers
Support conversions of nonstandard units Dynamic Reconfiguration
used by the different hardware devices

TABLE 5.5 Features Derived from Business Goals