Page 223 - Software and Systems Requirements Engineering in Practice
P. 223
189
t
s
n
m
e
g
i
n
E
R
e
:
6
r
e
i
q
u
n
a
t
l
P
m
s
r
f
o
i
n
r
e
e
o
r
f
g
h
a
C h a p t e r 6 : R e q u i r e m e n t s E n g i n e e r i n g f o r P l a t f o r m s 189
C
e
r
p
t
unusually large number, to ensure the performance need was for
similar load and deployment configuration situations. It was possible
that one stakeholder had some special application situations that led
to a very wide range of data in the stakeholder input.
The examples provided in Tables 6.2, 6.3, and 6.4 are a very small
part of what we develop in practice. Each of the stakeholders’ inputs
on the NFRs or the reconciliation sheet had hundreds of spreadsheet
cells that captured the stakeholders’ inputs for a variety of situations;
e.g., loading conditions, system deployment conditions. The inputs
from one stakeholder often were a set of collective/combined inputs
within one Siemens business division that planned to use the platform
to develop their products. Such semiautomated analysis was very
useful and greatly improved our productivity for both creating and
maintaining the NFRs.
Large
Stakeholder A . . . Configuration . . .
Alarm processed
per second (APS) 50 100
. . .
TABLE 6.2 Stakeholder A’s Inputs
Large
Stakeholder B . . . Configuration . . .
Alarm processed
per second (APS) 40 120
. . .
TABLE 6.3 Stakeholder B’s Inputs
All Stakeholders . . . Large Configuration . . .
APS for
stakeholder A 50 100
APS for
stakeholder B 40 120
. . . . . . . . .
Combined range 40 120
Reconciled range 40 120
NFR <120
TABLE 6.4 Example Reconciliation Worksheet