111
Establish quality criteria for requirements and documentation
Purpose: To define requirements and requirements documentation quality criteria in case not available or
update requirements quality criteria as per project requirements.
Stakeholders: Domain SME, Implementation SME, Project manager, Implementation SME.
Inputs
1. Requirements
engineering approach
2. Organizational policies
and processes
Elements
1. Review and update organizational
requirements and documentation quality
criteria as per project requirements.
2. Define requirements and documentation
quality criteria in case not available..
Outputs
1. Requirements and
documentation quality
criteria.
Tools and Techniques: Structured walkthrough
Quality Criteria for Requirements
Formal criteria as per to IEEE Std. 830 as well as criteria that increase the readers’ acceptance of the
requirements are briefly explained below:
Criteria
Agreed
Ranked
Unambiguous
Explanation
A requirement is agreed upon if it is
correct in the opinion of all stakeholders
and all stakeholders accept it as valid.
When the complexity or
comprehensiveness of a system reaches a
certain threshold, it is important to rate
the requirements, for example, according
to their importance, legal obligation, or
priority. This is especially the case if not
all functions of a system can be
implemented right away in a particular
system release. In that case, stakeholders
must rate the requirements.
A requirement that is unambiguously
documented can be understood in only
one way. It must not be possible to
interpret the requirement in a different
way. All readers of the requirement must
arrive at the same understanding of the
requirement.
Draft prepared by Laxminarayan Mishra
Example
1. System shall calculate time taken to
complete a service request as Date of
completion of the service request
minus Date of arrival of the service
request. One stakeholder may interpret
as Calendar days (Elapsed days)
where as another stakeholder may
Page 1
111
interpret as Number of working days
elapsed between arrival and departure.
2. The system shall have ability to
support multiple browsers. Which
browsers?
3. Another example – The application
shall be usable in off-line condition as
well i.e. users should be able to use
the system when they are not
connected to internet.
Valid and up-todate
Correct
Documented requirements must represent
the facts and conditions of the system
context that is valid with regard to the
actualities of the system context. These
actualities may be the different
stakeholders’ ideas, relevant standards, or
interfaces to external systems.
A requirement is correct if it adequately
represents the idea of the stakeholder.
This also means that the requirement may
not express more than what the
stakeholder was trying to say. In order to
verify that, it is necessary for the
stakeholders to be able to read and
understand the requirements
documentation. Therefore, correctness of
the specification can only be verified if
the criterion of understandability is met.
1. The actual end of a service request is
always greater than the start date of the
actual start date of the service request.
On face of it, it seems to a correct
requirement, but it is not. The correct
requirement is, the actual end of a
service request is always equal to or
greater than the start date of the actual
start date of the service request.
Consistent
Requirements must be consistent with
regard to all other requirements, i.e., the
requirements must not contradict one
another, regardless of their level of detail
or documentation type. In addition, a
requirement must be formulated in a way
that allows for consistency with itself,
i.e., the requirement may not contradict
itself.
1. An employee must log-in 6 hours of
effort to be considered as a full day of
working.
2. An employee must login 40 hours of
effort in a week.
3.
Verifiable
A requirement must be described in a
1. The system should have extremely high
Draft prepared by Laxminarayan Mishra
Page 2
111
Realizable
Traceable
Complete
way that allows for verification. That
means that tests or measurements can be
carried out that provide evidence of the
functionality demanded by the
requirement.
It must be possible to implement each
requirement given the organizational,
legal, technical, or financial constraints.
This means that a member of the
development team ought to be involved
in rating the goals and requirements so
that he can show the technical limits of
the implementation of a particular
requirement. In addition, the costs for the
implementation must be incorporated into
the rating. Occasionally, stakeholders
withdraw a requirement if the costs for its
realization become apparent.
A requirement is traceable if its origin as
well as realization and its relation to other
documents can be traced. This can be
done by means of unique requirement
identifiers. Using these unique identifiers,
requirements that are derived from other
requirements on a different level of the
specification can be connected. For
example, a system goal can be traced
through all levels of abstraction, from
design to implementation and test. Details
can be found in Traceability of
requirements.
Each individual requirement must
completely describe the functionality it
specifies. Requirements that are yet
incomplete must be specially marked, for
example by inserting “TBD” (“ to be
determined”) into the respective text field
or by setting a corresponding status.
These markings can then be
Draft prepared by Laxminarayan Mishra
through-put.
2.
3.
4.
Page 3
111
systematically searched for and missing
information can be amended accordingly.
Understandability Requirements must be comprehensible to
each stakeholder. Therefore, the type of
requirements documentation (see Types
of Documentation) can vary significantly,
depending on the development phase
(and therefore, depending on the involved
staff). In requirements engineering, it is
important to strictly define the terms
used.
Fundamental principles of
understandability
Along with quality criteria for
requirements, there are two fundamental
rules that enhance the readability of
requirements:
5.
1. Short sentences and short
paragraphs:
As human short-term memory is very
limited, circumstances that belong
together should be described in no
more than seven sentences.
2. Formulate only one requirement per
sentence:
Formulate requirements using active
voice and use only one process verb.
Avoid long, complicated interlaced
sentences.
Quality criteria for requirements documents
To become a basis for the subsequent development processes, the requirements document must meet certain
quality criteria.
IEEE Standard 830 provides following requirements criteria.
Draft prepared by Laxminarayan Mishra
Page 4
111
1.
2.
3.
4.
5.
Consistency (IEEE Std. 830)
Modifiability
Extendibility (IEEE Std. 830)
Completeness (IEEE Std. 830)
Traceability (IEEE Std. 830)
Other very useful criteria are:
1. Unambiguity
2. Clear structure
Unambiguity
and
Consistency
Quality of individual requirements is a prerequisite.
Requirements documents can be consistent and unambiguous only when the individual
requirements are consistent and unambiguous. In addition, it must be guaranteed that
individual requirements do not contradict one another. To achieve this, it is advisable to
make use of conceptual models.
Another aspect of unambiguity pertains to the unique identification of a requirements
document or a requirement among the set of all requirements documents or requirements
in a development project (see Versioning of Requirements).
Clear structure
Modifiability
and
extendibility
Allows for selective reading
In order to guarantee that the requirements document is readable by any stakeholder, it
should be appropriately comprehensive and clearly structured. Unfortunately, no clearcut suggestions can be made regarding the appropriate comprehensiveness of a
requirements document. A very comprehensive requirements document with a good
structure can be just as appropriate as a less comprehensive document because a clear
structure will allow the reader to skip parts that are not relevant to him.
An unstructured or badly structured requirements document of the same high level of
comprehensiveness would not be appropriate because the document must be read in its
entirety in order for a stakeholder to be able to identify parts that are relevant to her.
A good starting point is the standard structures described in Standardized Document
Structures.
Content and structure should support changeability. Requirements documents must be
easy to extend. There are always requirements that are changed, altered, added, or
removed as a project progresses.
Completeness
Two types of completeness in requirements documents
1. Requirements documents must be complete, i.e., they must contain all relevant
requirements (and required additional information), and each requirement must
be documented completely.
Draft prepared by Laxminarayan Mishra
Page 5
111
2. All possible inputs, influential factors, and required reactions, error and
exception cases, quality requirements of the system must be described for each
desired system function.
Evidence,
reference, and
sources are
formal
necessities.
Formal factors contribute to completeness. Label graphs, diagrams, and tables
appropriately. Another important aspect is that consistent reference and index directories
must exist. Also, definitions and norm reference that denote specific terms must be
included in any requirements document.
Comprehensiveness of a requirements document is a challenge during requirements
engineering. Often, a compromise must be found between the time resources available
and the completeness of the requirements documents.
Traceability
Relationship to other development documents (e.g., business process model, test plans, or
design plans). These documents could have been created in previous development
phases, in subsequent development phases, or concurrently with the requirements
documents.
Draft prepared by Laxminarayan Mishra
Page 6