Page 217 - Software and Systems Requirements Engineering in Practice

183
n
t
e
m
E
n
s

e
s
e
o
m
i
r
q
u
o
r

f

a
t
P
l
n
e
g
i
e
n
g
r
i
f
r
C h a p t e r 6 :
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 183
Derive the NFRs for the Components
This activity allocates the NFRs to the related functional
requirements, which are often defined in terms of services in a
service-oriented platform. The stakeholders’ inputs usually describe
the functions they need in their products. The software platform
would have to provide either a program-callable service or an end
user–level (application-level) service to support the implementation
of such functions. This activity derives what NFRs certain services
must satisfy. For example, a NFR might be that the service for
subscribing a value change event must have a latency that is less
than 0.1 seconds. Such NFRs may depend on the high-level
architectural design to some degree. However, since the development
of NFRs will be performed in parallel or intertwined with the
architecture design, the NFRs can be adjusted according to the
architectural design changes.
This activity should document the NFRs’ traces to the original
stakeholders’ inputs so that the NFR reviewers (often a stakeholder)
can understand from which inputs the NFRs are derived.
The NFRs resulting from the two preceding activities are grouped
into NFR categories. For each category, the following structure is
used to define its NFRs.
NFR Category (e.g., Performance)
We give an example of how a platform-level NFR model can identify
lower-level NFRs.
• The platform-level NFR model
• Platform-level NFRs
• [Perf-PLATFORM-1]
• [Perf-PLATFORM-2]
• . . .
• [Perf-PLATFORM-N]
• Component-level NFRs for component 1
• The component-level NFR model
• [Perf-COMP1-1]
• [Perf-COMP1-2]
• . . .
• Component-level NFRs for component 2
• The component-level NFR model
• [Perf-COMP2-1]
• . . .