Quality Requirement

The body of knowledge regarding quality management is vast. This article is

intended to give the project manager, and other key project stakeholders,
preliminary insights to the importance of Quality Management in its
relationship with Project Management. Readers are encouraged to
reference, A Guide to the Project Management Body of Knowledge (4th ed.,
The Project Management Institute) for further information.

Quality requirement is a common term in project management. It is defined as

the condition used to assess the conformance of the project by validating the
acceptability of an attribute or characteristic for the quality of a particular
result.

In a nutshell, the quality requirement defines the expectations of the customer

for quality, the internal processes as well as the attributes of products that
indicate whether the quality factors are satisfied or not.

The quality requirements in project management are defined in terms of the

quality criteria, quality factors, and quality metrics. The quality criteria
document the internal process and attributes of the product that will be
monitored all throughout the project life cycle. The quality factors document
the perceived aspects of the user regarding the deliverables of the project to
determine if the project satisfies the expectations from customers. Lastly,
the quality metrics document the indicators used to measure the quality of
the product.

The quality requirement is used by different project management processes

particularly the Quality Management Plan to create the risk register,
requirements documentation, and cost-benefit analysis.

Adherence to requirements is the responsibility of the project manager. The

act of proving whether requirements have, or have not, been met is called
validation; and it is typically accomplished via observation and measurement.
When requirements are correctly defined, validation can be achieved
regardless of who performs the validation activities, or how many times they
are repeated. Conversely, when requirements are not well defined,
inconsistent test results, arguments, misaligned expectations, dissatisfied
stakeholders and perceptions of failure are more likely to result.

Quality Requirements
Quality planning involves ensuring requirements are defined in a manner that
facilitates objective validation, rather subjective opinion. Reliably defined
requirements are said to be SMART when they share the attributes of being:
Specific, Measureable, Agreed upon, Realistic, and Time bound.

Specific
Terms like fast, user friendly, and intuitive are examples of nonspecific
requirements’ attributes. These are called "fuzzy" requirements because
they are unclear and therefore open to interpretation (Read: subjective).
Specific attributes objectively define what constitutes fast, friendly and
intuitive in an unambiguous manner.
Measureable
This speaks not only to the ability to measure, but also to how we
interpret the results of the measurements we make. In other words,
“measurable” implies the application of metrics. If measurements will be
made in non-standard units (or there is more than one standard!) the
quality plan must define the units of measure and how results are to be
interpreted (meaning). An example might be Transactions per Second.
This requirement should specify exactly what constitutes a transaction
(beginning, end, size, contents), how the rate of processing will be
measured and the thresholds for acceptance.
Agreed upon
A requirement is of little use if key stakeholders do not agree if indeed it
is a requirement, or whether it has been properly defined. This is why
requirement documents require signature approval from at least the
sponsor and project manager.
Realistic
This is perhaps the most contentious of the five criteria. Sponsors
and/or customers may know what they want, but they may also lack an
adequate appreciation of what is involved to produce what they want. It
 is up to the project manager to determine what can be accomplished
within well defined constraints (Time, money, resources, etc.).
Estimating methods, negotiation and compromise are tools for defining
realistic requirements. If there is a requirement for something too
uncertain to reliably estimate, consider adding a feasibility phase to the
project’s lifecycle to determine the viability of such requirement(s).
Time bound
This requirement attribute addresses when the requirement will be
satisfied, and is documented in the project schedule.

Quality Standards, Quality Assurance and Quality Control

A customer requirement becomes a Quality Standard when it has been
SMART-ly defined, documented, and placed under formal change control.
After Quality Standards are baselined in this manner, the next step is to define
the Quality Control (QC) and Quality Assurance (QA) activities used to meet
the Quality Standards. We will use the following definition for QC and QA:

QC measures performance against quality standards and may lead to

corrective actions based on the findings.
QA ensures the efficacy of QC by examining if we are measuring the right
things, properly and interpreting the results accurately.

Use the following checklist of questions as a basis for designing Quality

Control activities:

 Does each Quality Standard have a QC activity assigned to it?

 For each QC activity:
o What will be measured?
o How will it be measured?
o Who will perform the measurement activity (project team, customer, third party
…)?
o How many times will the activity be performed (once, in batches, periodically)
o Where will the activity be performed (location, environment ...)?
o When will the activity be performed (upon delivery, event triggered, project
end …)?
o Under what environmental conditions?

Use the following checklist as a basis for designing Quality Assurance

activities:
 Who will observe / verify the activity results?
 How will the test environment be configured, and who will create and validate
the environment?
 If sampling, how do we know the samples accurately represent the
population?
 What constitutes “accurate”, and how will we know if the data meet this
criterion?
 Who will sign the technical and/or managerial acceptance documents?
 How do we determine if a QC (or QA) initiated actions are producing desired
results?