Quality Assurance and

Requirements

Anas Bilal
 An Important Point
• We are discussing requirements with
reference to quality assurance and
management
• Every item we discuss, try to associate
issues of quality assurance with it
 Requirements
• IEEE Standard 729 defines it as “(1) a
condition or capability needed by a user to
solve a problem or achieve an objective; (2)
a condition or capability that must be met or
possessed by a system...to satisfy a contract,
standard, specification, or other formally
imposed document”
 Importance of Requirements
• The hardest single part of building a
software system is deciding what to
build...No other part of the work so cripples
the resulting system if done wrong. No
other part is difficult to rectify later
– Fred Brooks
 Requirements Engineering
• Requirements elicitation
• Requirements analysis and negotiation
• Requirements specification
• System modeling
• Requirements validation
• Requirements management
 Requirements Defects - 1
• All four categories of defects (errors of
commission, errors of omission, errors of
clarity and ambiguity, and errors of speed
and capacity) are found in requirements
• If not prevented, requirements defects
usually flow downstream into design, code,
and user manuals
 Requirements Defects - 2
• Historically, requirements defects are most
expensive and troublesome to eliminate
• Errors of omission are most common among
requirements defects
• Famous example is the Y2K problem
 Requirements Defects - 3
• Second most common errors are those of
clarity and ambiguity
• Primarily, because natural languages (like
English) are used to state requirements,
while such languages are themselves
ambiguous
• For example: object
 Requirements Defects - 4
• Errors of commission can also find their
way into the requirements documents
• Performance errors can also be found in
requirements documents
 Prevention Vs Removal
• For requirements errors, prevention is
usually mode effective than removal
• JAD, QFD, and prototyping are more
effective in defect prevention
• Requirements inspections and prototyping
play an important role defect removal
 Changing/Creeping
Requirements - 1
• Requirements will change, no matter what
• A major issue in requirements engineering
is the rate at which requirements change
once the requirements phase has “officially”
ended
• This rate is on average 3% per month in the
subsequent design phase, and will go down
after that
 Changing/Creeping
Requirements - 2
• This rate should come down to 1% per
month during coding
• Ideally, this should come down to no
changes in testing
 Defects and Creeping
Requirements
• Studies have shown that very significant
percentage of delivered defects can be
traced back to creeping user requirements
• This realization can only be made, if defect
tracking, requirements traceability, defect
removal efficiency, and defect rates are all
monitored for software projects
 Damage Control of Creeping
Requirements
• Following quality assurance mechanisms
can limit the damage done by creeping
requirements
– Formal change management procedures
– State-of-the-art configuration control tools
– Formal design and code inspections
 Tracing Requirements
• It is important to trace requirements both
ways
– origin of a requirement
– how is it implemented
• This is a continuous process
 Validating Requirements
• Requirements need to be validated for
– consistency
– testability
– performance issues
– conformance to local/national laws
– conformance to ethical issues
– conformance to company policies
– availability of technology
 Specifying Requirements
• Requirements are specified in a document
called Software Requirements
Specifications (SRS)
• SRS is used for communication among
customers, analysts, and designers
• Supporting system-testing activities
• Controlling the evolution of the system
 What Should be Included in
SRS? - 1
• Behavioral requirements
– They define what the system does. These
describe all the inputs and outputs to and from
the system as well as information concerning
how the inputs and outputs interrelate.
 What Should be Included in
SRS? - 2
• Nonbehavioral requirements
– They define the attributes of a the system as it
performs its job. They include system’s
required levels of efficiency, reliability,
security, maintainability, portability, visibility,
capacity, and standards compliance
– Some of these are quality attributes of a
software product
 What Should Not be Included in
SRS?
• Project requirements (for example, staffing,
schedules, costs, milestones, activities,
phases, reporting procedures)
• Designs
• Product assurance plans (for example,
configuration management plans,
verification and validation plans, test plans,
quality assurance plans)
Attributes of a Well-Written SRS
-1
• Correct
• Nonambiguous
• Complete
• Verifiable
• Consistent
• Understandable by non-computer specialists
• Modifiable
Attributes of a Well-Written SRS
-2
• Traceable
• Annotated
• ....
 Correct
• An SRS is correct if and only if every
requirement stated therein represents
something required of the system to be built
 Nonambiguous
• An SRS is nonambiguous if and only if
every requirement stated therein has only
one interpretation
• At a minimum all terms with multiple
meanings must appear in a glossary
• All natural languages invite ambiguity
 Example of Ambiguity
• “Aircraft that are nonfriendly and have an
unknown mission or the potential to enter
restricted airspace within 5 minutes shall
raise an alert”
• Combination of “and” and “or” make this
an ambiguous requirement
 Complete - 1
• An SRS is complete if it possesses the
following four qualities
– Everything that the software is supposed to do
is included in the SRS
– Definitions of the responses of the software to
all realizable classes of input data in all
realizable classes of situations is included
 Complete - 2
– All pages are numbered; all figures and tables
are numbered, named, and referenced; all terms
and units of measure are provided; and all
referenced material and sections are present
– No sections are marked “To Be Determined
(TBD)
 Verifiable
• An SRS is verifiable if and only if every
requirement stated therein is verifiable. A
requirement is verifiable if and only if there
exists some finite cost effective process
with which a person or machine can check
that the actual as-built software product
meets the requirement
 Consistent
• An SRS is consistent if and only if no
subset of individual requirements stated
therein conflict. Conflicts can be any of the
following
– conflicting terms
– conflicting characteristics
– temporal inconsistency
Understandable by Non-
Computer Specialists
 Modifiable
• An SRS is modifiable if its structure and
style are such that any necessary changes to
the requirements can be made easily,
completely, and consistently
 Traceable
• An SRS is traceable if the origin of each of
its requirements is clear and if it fascilitates
the referencing of each requirement in
future development or enhancement
documentation
• There are four types of traceability
 Traceability - 1
• Backward-from-requirements traceability
implies that we know why every
requirement in the SRS exists.
• Forward-from-requirements traceability
implies that we understand which
components of the software satisfy each
requirement
 Traceability - 2
• Backward-to-requirements traceability
implies that every software component
explicitly references those requirements that
it helps to satisfy
• Forward-to-requirements traceability
implies that all documents that preceded the
SRS can reference the SRS
 Annotated
• The purpose of annotating requirements
contained in an SRS is to provide guidance
to the development organization
• Relative Necessity
• Relative Stability
 The Balancing Act
• Achieving all the preceding attributes in an
SRS is impossible
• Once you become involved in writing an
SRS, you will gain insight and experience
necessary to do the balancing act
• There is no such thing as a perfect SRS
 How to Organize an SRS?
• Clients/developers may have there own way
of organizing an SRS
• US Department of Defense
• NASA
• IEEE/ANSI Standard
 Conclusion
• Requirements engineering and software quality
are tightly-coupled
• Requirements engineering must be performed in a
way that results in the development of high quality
software
• Requirements defects can have devastating impact
on the software project/product
• Defect prevention works better than removal
 References
• Software Quality: Analysis and Guidelines
for Success by Capers Jones
• Requirements Analysis and Specification by
Alan M. Davis
• A Practitioner’s Approach to Software
Engineering by Roger Pressman