Page 198 - Software and Systems Requirements Engineering in Practice

164 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

Starting with a monolithic system in Figure 5.7(a), ADD applies
the modifiability tactics to limit the impact of change and minimize
the number of dependencies on the part of the system responsible for
integrating new hardware devices. This is shown in Figure 5.7(b),
where an adapter is introduced for each field system (anticipation of
changes tactic) with each adapter exposing a standard interface
(maintain existing interface tactic) and a virtual field system is
introduced to further limit the ripple effect when removing or adding
field systems (hiding information tactic).
The performance tactic (concurrency), shown in Figure 5.7(c), is
applied next to add support for critical systems so that they operate
within specific latency constraints and can handle specified load
conditions. The parts responsible for evaluating rules and generating
alarms for life-threatening situations are separated out into an alarms
module. This module can now be moved to a dedicated execution
node, reducing latency, and its performance can be further enhanced
by introducing multithreading within the module. We can also add
execution nodes for horizontal scalability.
The modifiability tactic (anticipation of changes) is applied in
Figure 5.7(d), and a separate presentation module is created to
support several international languages.
It should be noted that the only driver from Table 5.8 that does
not appear to be addressed is the one dealing with conversion of
nonstandard units used by various devices. We use the adapters
shown in Figure 5.7(b) to do the conversions into standard units
(intermediary modifiability tactic).

Modeling the Domain
Figure 5.8 shows a domain model for the building automation system.
In describing various artifacts related to the system, the use of a
standard vocabulary of the domain plays a significant role in making
the descriptions less ambiguous. The closer the standard vocabulary
is to the problem domain, the smaller is the representation gap
between how the stakeholders of the system perceive their world and
how the software engineers describe the system under design.
Performance Modeling
In the event that data from the field systems begins to indicate the
possibility of an alarm, the facilities manager (and possibly, the public
safety officials) needs to know about this possibility within one
minute of its occurrence. Under normal operating conditions, a single
field system generates ten data samples/second in the worst case.
Sample size is approximately ten bytes. A typical building in the
worst case may have 100 field systems.
This section creates a performance model for the proposed
architecture for the building automation system based on the end-to-end