Page 32 - Software and Systems Requirements Engineering in Practice

d
u
c
o
i
o
I
n
t
t
n
C h a p t e r 1 :
r
C h a p t e r 1 : I n t r o d u c t i o n 5 5
observed that problems tend to be exacerbated by three critical
factors, the first being a decision to outsource the implementation, the
second being a significant change in technology, and the third being
the introduction of new products (e.g., entering a market where the
company has minimal prior experience).
When a decision is made to outsource, changes must take place in
all processes, especially in the area of requirements engineering. The
implementation may be done by staff with minimal domain
knowledge and, because of customs, logistics, time, or distance, with
limited access to subject matter experts. Attempts to use the same
processes and techniques used for in-house development for the
development of specifications for subcontracting or outsourcing may
lead to significant delays in delivery, sometimes even resulting in
project cancellation.
When technology changes rapidly, domain experts may no longer
be “experts.” Techniques and solutions that worked for many years
may become obsolete or irrelevant. Such technological discontinuities
may require substantial new training, or the experts in the older
technologies may make poor decisions for new product designs. A set
of key success factors for identifying potential requirements
engineering problems early has been developed at SCR and is
described in the next section.

1.4 Key Success Factors in Requirements Engineering
This section contains a checklist describing key factors for success in
requirements engineering. Most of the factors can be evaluated prior
to project initiation. Although project success cannot be guaranteed,
it is likely that if several of the success factors are not in place there
may be significant project difficulties.

The Project Has a Full-Time, Qualified Chief Architect
On many large projects the only senior technical role that spans the
requirements process through delivery is that of the chief architect.
He provides technical continuity and vision, and is responsible for
the management of the nonfunctional requirements (e.g., scalability,
quality, performance, environmental, etc.) and for the implementation
of the functional requirements. In our experience having an
experienced, full-time architect on a project contributes significantly
to its success [Hofmeister et al. 1999], [Paulish 2002].
A Qualified Full-Time Architect Manages
Nonfunctional Requirements
The architect is responsible for managing nonfunctional requirements
and the relationships among requirements analysis, development,
and management.