Page 219 - Software and Systems Requirements Engineering in Practice

185
m
e
e
r
n

E
t
s
s
m
r
o
C h a p t e r 6 :
u
i
e
q
o
r

f

a
t
P
l
g
i
n
n
g
e
i
n
e
r
f
C h a p t e r 6 : R 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 185
level are concerned about the quality of the services that can be
directly used by the end users to provide the product functionalities
(e.g., those for handling alarms in a monitoring product) or the quality
of the platform as a whole (e.g., ease of installing the platform). The
NFRs at the component level are for those services that can only be
used as a part of the implementation for the product functionalities.
For example, an alarm forwarding latency requirement must be
consistent with the performance of the low-level messaging system,
since the latency of alarm forwarding (as a platform-level function)
depends on the performance of the messaging system (e.g., message
transmit latency).
Check for Testability
This activity checks if the NFRs that have been developed are
generally testable or not. The requirements engineers would play the
role of a tester and examine if the NFRs provide sufficient information
that the test procedures (including the testing environment) can be
specified to test the NFRs. This activity is integrated with feature
release management to focus on the features that are to be released
soon (e.g., the next major platform delivery time). That is, for the
features to be released, the related NFRs must be clearly testable. This
strategy avoids requiring all NFRs to be testable, since some of them
may still be unstable and may not be implemented at all. Such an
incremental approach can be integrated well with agile development
methods [Schwaber 2004].
Complete the Constraints
This activity identifies the missing constraints (e.g., operating
conditions, deployment conditions, prerequisite software systems)
under which the NFRs should be defined. The activity “check for
testability” will provide inputs for completing the constraints, since it
helps identify the unspecified conditions under which the tests
should be performed. For example, for testing the platform startup
latency, a necessary condition is whether the operating system has
been started or not. Without this condition specified, the platform
startup latency cannot be tested to verify whether the latency
requirement has been fulfilled or not.
Tune the NFRs for Feasibility
This activity aims to ensure that the NFRs are implementable; i.e., the
NFRs can likely be satisfied with the technologies that the platform
will be based upon. For example, this activity examines whether the
performance requirements are achievable by analyzing the available
results from testing the platform prototypes or finished components.
If the analysis shows that the NFRs may not be achievable,
the constraints might have to be added or modified to make the