Page 326 - Software and Systems Requirements Engineering in Practice

288 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

equirements engineering (RE) is only one part of a project’s
effort, and it can never be done in a vacuum. Life-cycle
Ractivities such as project management, quality assurance,
validation, configuration management, system architecture, design,
implementation, and maintenance are all important activities. RE is
cross-cutting, and it helps enable each of these project areas.
The goal of this book is to discuss and share experiences from
many requirements engineering projects (of different sizes,
technologies, business domains, application areas) with practitioners
in the field. All of the authors of this text have had significant
experience in their various domains outside and within Siemens, and
they have presented techniques they have personally used and are
appropriate for large, real-world projects. But, also through
collaborations with universities and “RE best practices sharing
events,” the individual experiences were checked and benchmarked
against both RE theory and industrial practice. Furthermore, this
book is not just about requirements engineering. Rather, it looks at
how RE relates to other software and systems engineering disciplines
such as architecture, testing, and validation.
In Chapter 1, we introduced some basic terminology and
concepts, as well as exploring some common myths of requirements
engineering. We hope that the discussion of terminology will lead to,
at least within the reader’s organization, a better understanding of
the different types of requirements and a more uniform set of terms.
In Chapter 2, we provided the architectural foundation of
requirements engineering, that is, the artifacts on which the field is
based and how they can be represented with Requirements
Engineering Artifact Models (REAMs). Furthermore, we also
highlighted how taxonomies can be used to define and clarify the
relationships between various types of requirements. In our
experience, taxonomies and artifact models have proven to help
support building domain-specific, useful, and scalable RE
approaches.
Chapter 3 is all about eliciting and accurately capturing
requirements. Some of the key takeaways are tips on how to
gather requirements most effectively, how to define the right level
of requirements granularity, and how to train staff members to be
effective communicators when they are involved in the elicitation
process.
Model-Driven Requirements Engineering (MDRE) techniques
are explored in Chapter 4. These techniques, while challenging and
requiring some skill on the part of the participants, offer significant
benefits over the traditional textual approach. Model-driven
approaches utilize graphical structures, based on syntactical and
more or less formally defined semantic rules for model creation. It is
possible to perform verification and validation on such models to a
level that is not feasible with natural language text descriptions.