Page 36 - Software and Systems Requirements Engineering in Practice

:
n
1
n

t
p
r
t
e
o
r
o
C
a
h
t
i
c
d
u
C h a p t e r 1 : I I n t r o d u c t i o n 9 9
1.7 Characteristics of a Good Requirement
Requirements characteristics are sometimes overlooked when defining
requirements processes. They can be an excellent source of metrics for
gauging project progress and quality. One question we typically ask
organizations when discussing their quality processes is, “Given two
requirements specifications, how would you quantitatively determine
that one is better than the other?” This question may be answered by
looking at the IEEE 830 Standard [IEEE 1998]. The characteristics of
a good requirement, as defined by the IEEE, are listed next, with
several additional useful ones.
It is important to distinguish between the characteristics of a
requirement and the characteristics of a requirements specification (a set
of related requirements). In some cases a characteristic can apply to a
single requirement, in some cases to a requirements specification, and in
other cases to the relationship of two or more requirements. Furthermore,
the meaning may be slightly different when referring to a requirement
or a specification. Care must be taken, therefore, when discussing the
characteristics described here to define the context of the attributes.
Feasible
A requirement is feasible if an implementation of it on the planned
platform is possible within the constraints of the program or project.
For example, the requirement to handle 10,000 transactions per second
might be feasible given current technologies, but it might not be feasible
with the selected platform or database manager. So a requirement is
feasible if and only if it can be accomplished given the resources,
budget, skills, schedule, and technology available to the project team.
Valid
A requirement is valid if and only if the requirement is one that the
system shall (must) meet. Determination of validity is normally
accomplished by review with the stakeholders who will be directly
responsible for the success or failure of the product in the marketplace.
There can be a fine line between “must” and “nice to have.” Because
the staff of a development team may be mainly focused on technology,
it is important to differentiate between stakeholder requests that are
wishful thinking and those that are actually needed to make the project
or product a success. The inclusion of requirements that are nice but
not valid is called “gold plating.” As the name implies, having
requirements on a project that are not valid will almost certainly add
cost without adding value, possibly delaying project completion.