Page 221 - Software and Systems Requirements Engineering in Practice

n
t
m
e
s
n
g

E
e
C h a p t e r 6 :
R
m
s
e
i
r
q
u
i
P
l
r

a
o
r
t
f
o
e
r
n
e
i

f
n
g
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 187 187
interoperability, compliance, and security), reliability, usability,
efficiency, maintainability, and portability. The questionnaires
organized around those attributes should help elicit the first set of the
stakeholders’ inputs. Analyzing the answers to those questionnaires
often helps identify the needs that are beyond the scope covered by
the questionnaires. In addition, some answers may be incomplete
when providing insufficient details such as those that describe the
related operating environments. This often needs to be corrected by
carrying out the next round of stakeholder elicitation. During this
elicitation, the NFR Questionnaire Table as illustrated in Table 6.1 will
most likely be used. This table is precise and structured with built-in
mathematical formulas to automatically calculate (derive) the
stakeholders’ inputs.
Some quality attributes that were not covered by the standards
will be added into the questionnaires as well. For example, the ISO
standard does not have the safety and localizability (i.e., defines how
easily the software can be localized) attributes. For a real-time,
embedded system that controls physical equipment, safety is often
very important and thus needs to be added. For a large software
system company, its products often need to be localized to the regional
markets all over the world. Thus, localizability-related questions
could be added to the questionnaires.
Note that although our experience reported herein emphasizes
using the NFR Questionnaire Table, it cannot take the place of the
face-to-face elicitation meetings we have described in Chapter 3.
Complete understanding of functional and nonfunctional
requirements requires much discussion and communication between
stakeholders and requirements engineers.
Unify Terminology
This activity is particularly important for developing NFRs for a
software platform that is potentially applied in multiple application
domains. For example, a software platform may support the
applications in multiple application domains or different applications
(e.g., image analysis for different purposes) in the same application
domain (e.g., the medical imaging domain). Not unifying and
differentiating those key terms in the stakeholders’ inputs will make
many NFR-related discussions very difficult.
Our experience indicates that carrying out this activity is actually
not very difficult if it is well supported by the stakeholders. In our
practice, we used only two to five structured tables that modeled the
relationships among the similar terms. The table can be used to
indicate the relations among the terms and list the differences and
commonalities. Some of those tables were documented into the NFR
requirements as the term definitions. However, during the NFR
documentation development, we must be very disciplined at using