Page 224 - Software and Systems Requirements Engineering in Practice

190 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

Derive the NFRs for the Software Platform
The derivation is to identify and conceptualize the NFRs for the
platform services based on the stakeholders’ inputs. For example, one
stakeholder’s input could be, “If an unauthorized user attempts
to access the X product, the platform should detect the attempt and cut
off the accessing PC from the network.” Another input might be,
“If an unauthorized user attempts to access the Y product, the
software should detect the attempt and raise an alarm.” The platform
requirement could be, “The software shall provide a service(s) for
detecting the unauthorized access, and upon the detection, execute a
predefined handling action.” Our experience indicates that this activity
actually performs two tasks: one is to identify a required service (e.g., a
platform security service) to support this platform-level security
requirement; another one is to reconcile/combine the stakeholders’
inputs. Such activities have an impact on the software architecture and
services the software platform should provide (e.g., functional
requirements).

Check for Testability and Complete the Constraints
These two activities are highly related in developing software systems.
As the products we develop often support a variety of application
situations (e.g., loading conditions and deployment configurations),
without sufficient description of those situations, the NFRs would not
be testable. The testers would not know how to set up the testing
environment to perform the NFR testing. The tester review of the NFRs
often provides many inputs for completing the NFR constraints.
Using structured templates is a way to ensure the constraints are
more complete. For example, we could enter certain attributes (e.g.,
loading conditions, deployment configurations, redundancy status)
for each requirement. Our experience, however, was that this is too
much work for defining the NFRs for all of the attribute combinations.
Stakeholders would not likely provide all the inputs for all of the
combinations. This is because some of those combinations are rare in
the intended applications (e.g., small deployment configurations
with redundancy). Thus, it was not necessary to provide NFRs for all
combinations.

6.5 Tips for RE for Platforms
The following tips may be useful when developing and analyzing
platform requirements.
• Use a standard set of quality attribute requirements to
structure the first version of the NFR questionnaire.
• Unify the terminology used by different stakeholders for
defining platform requirements.