Page 165 - Software and Systems Requirements Engineering in Practice

:
u

5
a
t
y
l
i
t
h
n
s
a
e
r
p
t

e
q

R
u
e
m
i
r
t
r
A
t
i
t
e
b
u
e
C C h a p t e r 5 : Q Q u a l i t y A t t r i b u t e R e q u i r e m e n t s 131 131
Document Dependency Diagrams
In the methodology framework diagrammed in Figure 5.1, great
attention has been paid to how artifacts (documents) depend on one
another. Each arrow represents a uses dependency: Artifact X uses
Artifact Y (X → Y) if and only if the correctness of X depends on the
presence of a correct version of Y. For example, it is possible to agree
upon a set of architectural principles before the product architecture is
complete, but it makes no sense to approve the product architecture
before the architectural principles have been signed off. In the case of
subclass and composition relations, the subclass depends on the parent
class and the component depends on the composite. The arrows do not
necessarily represent time sequences for the activities to develop the
artifacts. The only way that they represent time sequences is in the
sense already defined: a document cannot achieve a sufficient degree
of completeness and quality until the relevant parts of the documents
it depends on have sufficient completeness and quality. We call this
notation a document dependency diagram for specifying the overall
structure of a software process, whether it is a generic process, like this
one, or tailored for a specific project. Describing the overview without
control information turns out to make it easy to tailor, even after the
project is under way, because the state of the process is captured
primarily in the state of the artifacts and does not depend on the control
sequence used to reach that state. When you start a new project, you
can copy and modify this diagram to suit the needs of your project.
attribute scenario is not a use case scenario in the usual sense, but we
often formalize quality attribute scenarios by writing corresponding
use case scenarios, which can then be annotated with requirements
and tested in the usual way.
Quality Attribute Scenarios
Quality attribute scenarios (QASs) [Bass et al. 2003] are a special kind of
structured natural language description of a behavior. They are used
for capturing stakeholder concerns, by illustrating each concern with
a concrete example. A QAS may have a corresponding use case
scenario that formalizes it for the purpose of attaching requirements
and testing them.
Quality Attribute Requirements
A quality attribute requirement (QAR) is a special kind of requirement
that deals with measurable properties (quality attributes), such as
capacity, price, and responsiveness, related to stakeholders’
expectations.