Page 216 - Software and Systems Requirements Engineering in Practice

182 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

domains or the existing (legacy) products from which the performance
requirements are derived. Sometimes, such performance needs are
based upon competitors’ product specifications to ensure an edge over
the competitors (e.g., so that the inputs are comparable to the competitors’
quality attribute requirements values). In order to make those
stakeholders’ inputs directly comparable for an NFR for the platform,
requirements engineers must convert them into the same scale (e.g.,
number of alarms per second). Sometimes, this normalization changes
the stakeholder’s original intent. For example, “Processing 50 alarms
per 10 seconds” as a performance need for certain applications reflects
more precisely the stakeholder’s real need than an alarm processing
rate (alarms/second). Normalizing the need to “Processing 5 alarms per
second” would make a more specific and demanding requirement than
the original stakeholder’s need. However, in order to reconcile the
stakeholders’ inputs, such normalization is necessary.

Reconcile Stakeholders’ Inputs
This activity identifies and groups the similar stakeholders’ inputs,
and then requirements engineers can define a single NFR to address
this group of similar stakeholders’ inputs. By doing this, requirements
engineers can also identify a range of variations on the similar
requirements. Depending on how much they vary, some constraints
might be added to ensure the NFRs are feasible to implement. For
example, the performance requirements within a narrow latency
range might be grouped together. If one stakeholder requests less
than 2 seconds for transmitting an alarm while another stakeholder
requests less than 4 seconds (assuming they are easily achievable
with low-end hardware), then the requirements engineers can define
that a low-end, small deployment of the system shall support an
alarm latency that is less than 2 seconds. However, if another
stakeholder requests a 0.5-second alarm latency that is far more
demanding, a constraint might be added to ensure that such a short
latency can be implemented and acceptable for the targeted application
situation. For example, the constraint might be that some high-speed
networking device should be used when achieving this short alarm
latency. By doing this, we can address the stakeholders’ needs with
similar NFRs by specifying different constraints.
Define the NFRs for the Platform
This activity defines the NFRs for the platform from the stakeholders’
inputs that address the end-user needs. The reconciled stakeholders’
inputs will be used for specifying the NFRs. The NFRs will use the
specific values from the reconciliation. The worksheets used in the
reconciliation should be put into the NFR specification, possibly as an
appendix, referred from the main context of the NFR specification.