Page 220 - Software and Systems Requirements Engineering in Practice

186 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

NFRs more specific so that they will be satisfied only under certain
conditions. For example, the deployment constraints might be
modified to use a more powerful computing infrastructure to support
high performance requirements. This can certainly lead to architectural
changes or the use of other implementation technologies.
Complete NFRs
This activity completes the NFR definitions and makes them ready
for external review by the stakeholders. This activity should include
conducting an internal review of the NFRs by the requirement
engineers, software architects, software testing lead, and project lead.
In particular, this activity should check if each NFR has a trace to
some original stakeholder’s inputs and if the traces are documented
in the NFRs.
Formal Review by Stakeholders
This activity aims to collect feedback comments and get approvals
from the stakeholders. The review results may either lead to
modifications of the NFRs or generate new questionnaires for the
stakeholders. For example, if a stakeholder’s comment is that some
NFR might be missing, a questionnaire about this potentially missing
NFR could be defined and sent to all the stakeholders in the next
iteration of the NFR definition process. From our experience, we
expect that at least three iterations that involve external reviewers are
needed for completing an NFR document.

6.4 Experience
We have applied the PND process for developing a software platform
that supports the running and implementation of diverse industrial
software systems (e.g., factory control, automation, transportation).
For this example, each of the stakeholders represented either a
Siemens company or a division of such a company. In the following
sections, we describe our experiences in carrying out the activities of
the PND process.
Define Questionnaires and Elicit the Stakeholders’ Inputs
Defining the questionnaires for the NFR elicitation is very much an
iterative activity, since multiple elicitations are often needed. At the
beginning of NFR development, the questionnaires can be drafted
based upon the standard quality attribute requirements as defined
by ISO-9126 or other standards in relation to the key business drivers
of the software platform to be developed. An example business driver
could be increasing software reusability to reduce the software
development cost. Based upon ISO-9126, the questionnaires could
include questions regarding software functionality (e.g., accuracy,