Page 204 - Software and Systems Requirements Engineering in Practice

170 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

others such as accuracy and stability during overload conditions.
However, several concerns in the FURPS+ taxonomy, such as
configurability, testability, and maintainability under the
supportability category, or availability under the reliability category,
appear at the quality attribute level in our data.
A conclusion from these mismatches is that there is clearly a gap
between the vocabulary used by stakeholders and practitioners in
specifying quality attributes and those that are used in commonly
referred-to reference material and taxonomies. Our observation using
the integrated approach is when it comes to specifying quality attributes,
eliciting the concern supported by the description of the quality attribute
scenario is more expressive than going down a list of classifications,
which may not give a complete coverage of quality issues.

Integration of Functional Requirements,
Quality Attributes, and Architecture
Of the mainstream design methodologies, object-oriented analysis and
design (OOAD) has taken a center stage since the early 1980s, and
almost all programming languages developed since the 1990s have
object-oriented features [Budgen 2003]. OOAD makes use cases and
domain modeling its starting point and primarily uses functional
decomposition to drive the architecture of a system. There is, however,
a need for integrating these activities with the architecture-centric
approaches to gain an understanding of the quality attribute
requirements used in the elaboration of the architecture for a software-
intensive system [Sangwan et al. 2008]. Our experience with the
integrated approach is that such a synergy between the OOAD and
architecture-centric approaches also provides a linkage from high-level
design models to detailed design models that is important for
preserving the integrity of the architectural design as the system evolves.

5.9 Tips for Quality Attribute Requirements

Tips for effectively handling quality attribute requirements are given
below.
• Empower the chief architect to be the technical leader and
decision maker for the project team.
• Establish traceability from soft goals through ASRs and use
cases to test cases, so that testing the architecture can become
a relatively routine part of the software development process.
• Write a stakeholder analysis document and periodically
update it to identify the key stakeholders. Give preference to
the stakeholders for whom the project is most important
and/or urgent.
• Be careful not to bloat your requirements database with every
conceivable quality attribute, but you might want to keep a