Page 222 - Software and Systems Requirements Engineering in Practice

188 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

the unified terms to ensure the use is appropriate. This requires that
the NFR writer clearly understands the differences among the terms
and decides if it is appropriate to use the unified terms rather than
the terms that came directly from the stakeholders. Though the
different terms used by the stakeholders were very similar, they could
indeed be different, depending on where those terms are used in the
NFRs. For example, for an NFR that defines the rate of transmitting
data, a value change as data that is being transmitted is the same as
an alarm. However, for an NFR that defines the limit on the specific
data size, the two terms are different and the unified term (e.g.,
message) would not be used. When NFRs are bound to specific
platform services, more service-oriented terms (e.g., alarm), and not
the unified term (e.g., message), would be used, since this would
make the NFR more readable and specific.

Normalizing and Reconciling Stakeholders’ Inputs
It is essential to normalize the stakeholders’ inputs before we can
reconcile their requests. Our practice indicates that normalizing (hence,
changing) the original stakeholder’s input is usually acceptable to the
stakeholder as long as a clear trace to the original stakeholder’s request
is maintained. Such traces helped answer the stakeholders’ questions
concerning the origins of the normalized stakeholders’ inputs. Without
such traces, there could be a great deal of confusion when the
stakeholders review the NFRs.
In our practice, Excel spreadsheets are used to perform the
normalization and reconciliation, since the spreadsheets help build
the links and enable automated computations from the original
stakeholders’ inputs to the normalized results. Furthermore, the
spreadsheets help to identify and manage the value ranges
represented in the stakeholders’ inputs. For example, a performance
requirement “alarms processed per 10 seconds” from one stakeholder
was normalized to alarms processed per second (APS). Then, the
APS needs that were collected from all the stakeholders were listed
in the spreadsheet. More specifically, each stakeholder provided the
APS range for different deployment configurations (i.e., those
defined earlier also through the normalizing and reconciling process).
The spreadsheet automatically calculated the combined range (see
Table 6.3: 40–120 alarms per second). In most cases, such simple,
automated calculations can work well, for example, when the ranges
are not too wide to provide specific enough information for design
decision making. However, it is necessary to review the automated
calculations results. Sometimes, in our practice, we did override the
results to make sure that the range was not too wide. If the values of
the combined range were acceptable (e.g., approved by the architects),
we manually put them into the reconciled range, which was further
turned into a NFR. Sometimes, in our practice, we checked with the
stakeholders as to why they provided either an unusually small or