Page 31 - Software and Systems Requirements Engineering in Practice

4 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

Misconception 1: Any Subject Matter Expert Can Become
a Requirements Engineer after a Week or Two of Training
Requirements engineers need strong communication and knowledge
of engineering skills, the ability to organize and manage a data set of
requirements, high-quality written and visual presentation skills,
and the ability to extract and model business processes using both
text and graphical (e.g., Integration DEFinition [IDEF], Unified
Modeling Language [UML]) techniques. First and foremost, to elicit
requirements from stakeholders requires the ability to interact with
a variety of roles and skill levels, from subject matter experts (detailed
product requirements) to corporate officers (elicitation of business
goals).
Moreover, people have to be trained to write good specifications.
High school and university training tends to teach a style of writing
that is antithetical to the techniques needed to create unambiguous
and complete documents. Requirements analysts typically need
significant training, both classroom and on the job, before they can
create high-quality specifications.
Misconception 2: Nonfunctional and Functional Requirements
Can Be Elicited Using Separate Teams and Processes
The subject domains for nonfunctional and functional requirements
are related, may impact each other, and may result in iterative changes
as work progresses (see Chapter 5). Team isolation may do more
harm than good.

Misconception 3: Processes That Work for a Small Number
of Requirements Will Scale
Requirements engineering processes do not scale well unless crafted
carefully. For example, a trace matrix is an N × N matrix, where N is
the number of requirements of interest. In each cell, a mark or arrow
indicates that there is a trace from requirement R (row i) to requirement
i
R (column j). It is relatively easy to inspect, say, a 50-requirement
j
matrix, but what happens when five to ten thousand requirements
are needed to define a product? Filtering and prioritization become
important in order to retrieve results that can be better understood,
but the requirement annotations necessary to provide such filtering
are often neglected up front because the database is initially small.

1.3 Industrial Challenges in Requirements Engineering
Over the last few years, the requirements engineering R&D focus
program at Siemens Corporate Research has been involved with a
substantial number of requirements engineering (RE) projects with
Siemens development organizations. Many RE challenges have been
identified as potentially impacting project performance. We have