Page 23 - Software and Systems Requirements Engineering in Practice

xxii 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

Background
The Software and Systems Engineering Department of Siemens
Corporate Research is involved with many software development
projects with Siemens organizations working across a broad spectrum
of application domains in the business sectors of industrial, health
care, and energy. In our dual role of an industrial research and
development laboratory, we have many opportunities for observing
how requirements engineers do their work. Over time we can classify
certain requirements engineering practices as “best practices,” and
we also learn from the not-so-best practices that were not as effective
in achieving project goals.
This book was written to summarize our requirements engineering
experiences, and to describe them in a form that would be useful
to software and systems engineering practitioners; i.e., methods,
processes, and rules of thumb that can be applied to new development
projects. We are not so naïve as to believe that engineers who follow
what is described in this book will work only on successful projects.
We know too well that a practice that worked well in Princeton may
not work so well in Poland, and much like our children, engineers
sometimes learn best from their own mistakes. But, if software and
systems engineers can learn from our experiences and increase the
probability of a successful project outcome, our efforts will be
worthwhile.
Requirements engineering is most critically applied in the early
phases of a systems development project, but it is a decision-making
process that is applied across the entire product development life
cycle. Thus, the requirements engineer must work effectively with
software and systems engineers working on other tasks such as
architecture design and test procedures. Indeed, our research in
requirements engineering was initiated based on the observation that
the first task for an architect on a new project is to understand the
product requirements.
We have worked on projects for a broad range of application
domains; e.g., medical equipment, factory automation, transportation,
communications, automotive. The number of requirements that must
be defined, analyzed, and managed in the projects may range from a
few thousand to one hundred thousand. Many of our projects are
distributed over multiple development sites, involving engineers
living in many different countries. These software and systems
engineers are often working under great pressure to deliver the
product quickly, with good quality and a rich feature set. Most of the
products contain both hardware and embedded software; thus, there
are dependencies on electrical and mechanical characteristics,
reliability, usability engineering, and requirements that must be
considered by many different stakeholders. We often work within
regulated domains such as medical devices where requirements must