Page 29 - Software and Systems Requirements Engineering in Practice

2 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

tudies such as the CHAOS report [Johnson 2000] indicate that
about half of the factors associated with project or product
Ssuccess are requirements related. Recently, researchers have
reported on studies showing that project success is directly tied to
requirements quality [Kamata et al. 2007]. With such overwhelming
evidence that requirements engineering is a cornerstone of software
systems engineering, one could ask, why is it still a relatively neglected
topic in university training? It is quite rare, for example, that a new
Computer Science (CS) university graduate might be asked to
participate in the development of a compiler or operating system, yet
nearly every graduate working in the industry will, sooner or later,
be asked to participate in creating the requirements specifications for
a product or service.

1.1 Why Has Requirements Engineering
Become So Important?
For years, many products were successfully created without the
participation of professionals who specialized in requirements
creation or management. So, why is requirements engineering (RE)
so important today? The answer lies in the changing nature of
industry and society in general. First, the pace of product development
has picked up drastically. Whereas just a few decades ago, product
improvements would be a slow process, today customers often
demand new versions of a product in less than one year. For example,
Siemens estimates that approximately 20 years ago, 55 percent
of sales were from products that were less than 5 years old. Today,
75 percent of sales are from products that were developed less than
5 years ago (Figure 1.1). Second, turnover and technology change
have impacted the experience levels of professionals engaged in the
development of products. Just a few short years ago, engineers might
expect to spend their entire careers with a single company, whereas
today job change is more common. Finally, outsourcing and offshoring
have dramatically changed the product life cycle. Specifications must
now be created for implementation or manufacturing by organizations
with potentially limited or no domain expertise. Imagine, for example,
having to create a product specification for a washing machine,
dishwasher, or luxury automobile to be built by staff who may have
never even seen one! Under such circumstances specifications must
be exact and detailed.
Software development is highly coupled to the domain; e.g., cell
phone software and avionics software tend to be designed, built,
and managed with processes that are heavily domain specific.
Furthermore, industries have begun to use software as product
differentiators. Product innovations can be more easily implemented
in software than hardware because of the lower engineering