Page 215 - Software and Systems Requirements Engineering in Practice

m
e
r
e
n

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

f

a
t
P
l
g
i
n
n
g
e
i
n
e
r
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 181 181
category that defines a set of rows (bolded text indicates a category).
Our experience indicates that such a table in practice could have well
over 200 rows related to NFRs (e.g., reliability, availability). Thus, the
ISO standards [ISO 2001, 2007] for quality attributes are a good source
to start to define the questionnaires, but many more details need to be
added for collecting the stakeholders’ inputs.
Elicit Stakeholders’ Inputs
This activity collects inputs from the stakeholders. Requirements
engineers will organize workshops with the stakeholders from each
of the organizations that will use the future software platform for
their products. The goal is to complete the answers to the
questionnaires and avoid any misunderstandings by having
discussions during the on-site workshops. Table 6.1 does not include
any explanations for each row, so it is most important for the
requirements engineers to collect the stakeholders’ inputs when
they are together on site.
Unify Terminology
This activity aims to unify the terms used in the stakeholders’ inputs.
After this, only the unified terms will be used in the NFRs to replace
a set of similar terms. Since a software platform may aim to support
the users of different application situations and organizations,
stakeholders may use varying terms in describing their business
applications. For example, terms such as alarms, telegrams, events,
requests, messages, change of value (COV) events, etc., may have
similar meanings, depending on the application. Thus, we may just
use a unified term “message” to represent all these terms for all
applications of the product platform.
For this activity, the Language Extended Lexicon (LEL)–based
requirement analysis approach [Cysneiros et al. 2004], [Boehm et al.
1996] should be very useful for identifying the terms. Requirement
engineers can effectively unify/conceptualize terms by analyzing
their relationships (e.g., a-type-of, a-part-of, etc.). Depending on how
complex the analysis is, users can choose to use simple modeling
notations (e.g., Structured Table) and visual modeling notations (e.g.,
Entity-Relation).
Normalize Stakeholders’ Inputs
This activity aims to make the stakeholders’ inputs comparable with
each other on the same scale and operating conditions. For example, for
performance requirements, one stakeholder’s input might be
50 alarms per 10 seconds while another stakeholder’s input might
be 20 alarms per 1 second. Such differences are often caused by the
different nature (e.g., how frequently an alarm would usually come and
how quickly the system must respond to it) of their application