Page 35 - Software and Systems Requirements Engineering in Practice

8 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

1.5 Definition of Requirements Engineering
“Requirements engineering [DoD 1991] involves all lifecycle activities
devoted to identification of user requirements, analysis of the
requirements to derive additional requirements, documentation of
the requirements as a specification, and validation of the documented
requirements against user needs, as well as processes that support
these activities.” Note that requirements engineering is a domain-
neutral discipline; e.g., it can be used for software, hardware, and
electromechanical systems. As an engineering discipline, it
incorporates the use of quantitative methods, some of which will be
described in later chapters of this book.
Whereas requirements analysis deals with the elicitation and
examination of requirements, requirements engineering deals with all
phases of a project or product life cycle from innovation to obsolescence.
Because of the rapid product life cycle (i.e., innovation→development→
release→maintenance→obsolescence) that software has enabled,
requirements engineering has further specializations for software.
Thayer and Dorfman [Thayer et al. 1997], for example, define software
requirements engineering as “the science and discipline concerned
with establishing and documenting software requirements.”

1.6 Requirements Engineering’s Relationship
to Traditional Business Processes
It is extremely important to tie requirements activities and artifacts to
business goals. For example, two competing goals are “high quality”
and “low cost.” While these goals are not mutually exclusive, higher
quality often means higher cost. Customers would generally accept
the higher cost associated with a car, known for luxury and high
quality, but would likely balk at paying luxury car prices for a car
expected to compete in the low-cost automotive market.
Unfortunately, some organizations may tend to decouple business
and requirements activities. For example, business goals may drive
marketing activities that result in the definition of a new product and
its features. However, the business goals may have no clearly defined
relationship to the artifacts used and produced during requirements
analysis and definition. RE activities start at the very beginning of
product definition with business goals and innovation. Requirements
engineering techniques can add an element of formality to product
definition that can improve communication and reduce the
downstream implementation effort.