Software Quality Engineering

BS(SE)-VI

Dr. Assad Abbas

Department of Computer Science

COMSATS University Islamabad, Islamabad Campus
assadabbas@comsats.edu.pk
Topics

n Quality in requirements specification

n Defects in requirements specification

n Writing quality requirements

5/13/20 2
What is a Requirement?
n A “ requirement” is a set of measurable user needs and wants negotiated
for incorporation into a project or application.
5 It is an essential condition; something needed or necessary.
5 A requirement describes a condition or capability to which a system must
conform; either derived directly from user needs, or stated in a contract,
standard, specification, or other formal agreement.ƒ
5 As a system is being developed, it is evaluated according to how well it
meets its requirements.
n Requirement types
5 Business or functional
5 User interface and usability (functional)
5 Hardware (functional)
5 Software (functional)
5 Performance (non-functional)
5 Security (non-functional) ƒ

5/13/20 3
Why is Developing Software Hard?
n “The hardest single part of building a software system is
deciding what to build. No other part of the conceptual
work is as difficult as establishing the detailed technical
requirements, including all the interfaces to people, to
machines, and to other software systems. No other part
of the work so cripples the resulting system if done
wrong. No other part is more difficult to rectify later.”

n Frederick Brooks. “No Silver Bullet: Essence and Accidents of Software

Engineering.” Computer (April,1987)

5/13/20 4
Requirement Pitfalls
n Assume requirements are stated by the user.
n Customers are confused with users, and vice versa.
n Dialog (communication) between users and
developers is weak.
n Process lacking for managing changes to
requirements.
n Developers allowed to fill in the gaps.
n Rush to get through requirements –
“Let’s get to the good stuff…”

5/13/20 5
Why can’t we get requirements right?
n Mistaking “stated requirements” with the “real requirements.”
n Ambiguous requirements which cannot be validated in the
final product.
n Inability to transfer domain expertise.
n Getting requirements from the wrong source(s).
n The users do not always know what they want!
n Not change, but the inability to effectively manage change.
n Commitment from all parties to be responsible for the success
of a project.
n Politics

5/13/20 6
Obstacle to Successful Business Solution Delivery:
Business-IT Gap
n Sobering Statistics:ƒ
5 7 out of 10 projects fail ƒ
5 Of those that fail, 70% failures are due to problems in
the early stages of deciding on the business
requirements, project scope and planning.
n How to “bridge the Gap?”

Successful Solutions depend upon a precise translation

from Customer Needs to Business Requirements to
Software Engineering Capabilities

5/13/20 7
Overcoming Communication Breakdowns During
Solution Design

5/13/20 8
What is Requirements Engineering About?
n Effectively generating High
Quality Requirements:
5 Correct
5 Consistent
5 Complete
5 Modifiable
5 Traceable
5 Verifiable
5 Non-ambiguous
5 Understandable
5 Annotated

5/13/20 9
Project Success Factors (Chaos report)
n User Involvement 15.9%
n Executive Management Support 13.9%
n Clear Statement of Requirements 13.0%
n Proper Planning 9.6%
n Realistic Expectations 8.2%
n Smaller Project Milestones 7.7%
n Competent Staff 7.2%
n Ownership 5.3%
n Clear Vision & Objectives 2.9%
n Hard-Working, Focused Staff 2.4%
n Other 13.9%
5/13/20 10
Types of Requirements

5/13/20 11
Spiral Model of RE

5/13/20 12
Quality Requirements
n ƒCorrect – only user representative can determine. ƒ
n Feasible – get reality check on what can or cannot
be done technically or within given cost constraints. ƒ
n Necessary – trace each requirement back to its
origin. ƒ
n Unambiguous – one interpretation. ƒ
n Verifiable – how do you know if the requirement was
implemented properly? ƒ
n Prioritized – function of value provided to the
customer.

(from “Writing Quality Requirements” 5/13/20

– Karl Wiegers) 13
Writing Example #1

n “The product shall provide status messages

at regular intervals not less than every 60
seconds.”

5/13/20 14
Writing Example #1
n “The product shall provide status messages at regular
intervals not less than every 60 seconds.”

n Incomplete – What are the status messages and

how are they supposed to be displayed?
n Ambiguous – What part of the product? Regular

interval?
n Not verifiable

5/13/20 15
Alternative #1
n 1. Status Messages.
5 1.1. The Background Task Manager shall display
status messages in a designated area of the user
interface at intervals of 60 plus or minus 10 seconds.
5 1.2. If background task processing is progressing
normally, the percentage of the background task
processing that has been completed shall be
displayed.
5 1.3. A message shall be displayed when the
background task is completed.
5 1.4. An error message shall be displayed if the
background task has stalled.

5/13/20 16
Writing Example #2
n “The product shall switch between displaying and
hiding nonprinting characters instantaneously."
n Incomplete – conditions which trigger state switch

n Ambiguous – “non-printing character”

5/13/20 17
Alternative #2
n “The user shall be able to toggle between displaying and
hiding all HTML markup tags in the document being edited
with the activation of a specific triggering condition.” ƒ

n Note that “triggering condition” is left for design

5/13/20 18
Validating Requirements (1/2)
n Is each requirement consistent with the overall objective for
the system/product?
n Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?
n Is the requirement really necessary or does it represent an
add-on feature that may not be essential to the objective of
the system?
n Is each requirement bounded and unambiguous?
n Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?
n Do any requirements conflict with other requirements?

5/13/20 19
Validating Requirements (2/2)
n Is each requirement achievable in the technical
environment that will house the system or product?
n Is each requirement testable, once implemented?

n Does the requirements model properly reflect the

information, function and behavior of the system to be

built.
n Has the requirements model been “partitioned” in a

way that exposes progressively more detailed

information about the system.
n Have requirements patterns been used to simplify the

requirements model. Have all patterns been properly

validated? Are all patterns consistent with customer
requirements?
5/13/20 20
What to look out for (1/3)
n Incomplete lists, typically ending with "etc.", "and/or", and
"TBD".
n Vague words and phrases, such as "generally", "normally", "to
the greatest extent", and "where practicable".
n Imprecise verbs, such as "supported", "handled", "processed",
or "rejected".
n Implied certainty, such as "always", "never", "all", or "every“.
n Passive voice, such as "the counter is set." (by whom?)
n Every pronoun, particularly "it" or "its" should have an explicit
and unmistakable reference.

5/13/20 21
What to look out for (2/3)
n Comparatives/superlatives, such as "earliest", "latest", "highest". Words
ending in "est" or "er" should be suspect.
n Words whose meanings are subject to different interpretations between

the customer and contractor such as:

5 Instantaneous
5 Simultaneous
5 Achievable
5 Complete
5 Finish
5 Degraded
5 A minimum number of
5 Nominal/normal/average
5 Peak/minimum/steady state
5 As required/specified/indicated
5 Coincident/adjacent/synchronous with

5/13/20 22
What to look out for (3/3)
n Non-quantifiable measures, such as
5 Flexible
5 Modular
5 Efficient
5 Adequate
5 Accomplish
5 Possible (possibly/correct(ly))
5 Minimum required/acceptable/reasonable
5 Better/higher/faster/less/slower/infrequent
5 Some/worst
5 Usually/often
5 To the extent specified
5 To the extent required
5 To be compatible/associated with

5/13/20 23
Verification vs. validation
n Requirements verification works with raw requirements as
elicited from the system stakeholders.
5 “Have we got the requirements right?” is the key question
to be answered at this stage.
n Requirements validation works with a final draft of the
requirements document.
5 “Have we got the right requirements?” is the key question
to be answered at this stage

5/13/20 24
The Problem
n The problem with doing Requirements is that it is difficult to measure their
quality, so you can't get feedback.

n As a result:
You don't know how well you are doing. You don't know when to stop

5/13/20 25
1: Correctness
n Correctness can be only identified using domain and
context understanding
n ‘Correct' is too broad a term to be useful.
n Instead we will look at:
5 Complete
5 Clear
5 Feasible

5/13/20 26
Complete
n Completeness means that nothing is missing.
n TIP: Use a Requirements Development tool or the suggested
format in IEEE 830, to remind you of what should be in the
specification.
n TIP: Wrong information is better than no information because
it motivates people to correct it. So be complete by entering
wrong information.

5/13/20 27
Clear
n Not ambiguous.
n TIP: You are the worst person to determine if your
specification is ambiguous. Get some one else to read and
explain it.
n TIP: Never put the same information in two places. Instead
use references, or better yet, hypertext format.

5/13/20 28
Feasible
n Vendors love a non-feasible project because they can make
more money working on it.
n TIP: Create a working model or simulation, if possible.
n TIP: It never hurts to call the first version, a Feasibility model.
There is no upside risk and less downside risk.

5/13/20 29
2. Compatibility
n Definition: Software Requirements must be compatible, that is
interrelate within the other parts of the software development
project.
n Compatibility implies: ƒ
5 Verifiable ƒ
5 Traceable ƒ
5 Modifiable ƒ
5 Ranked for importance

5/13/20 30
Verifiable
n A Requirement that cannot be tested, is not a Requirement.
n TIP: Take a tip from the Agile/XP/Scrum people: create
requirements that are in fact the tests that an acceptable
system should be able to pass.

5/13/20 31
Traceable
n Traceability is required for Change Management.
n TIP: Use a software tool or at least number each paragraph in
the requirements specification. Then carry that number
forward through the remainder of the development. Never
change these numbers.

5/13/20 32
Modifiable
n “Software projects change as rapidly as any project ever
conceived by the human mind.”
n “Requirements change 2% per month” T. Capers Jones
n TIP: Remember software has diseconomy of scale. Design and
build the system in parts (GUI, DBM, etc.).
n TIP: Because the requirements will change, design and build the
system, a portion at a time: Incremental or Spiral development.
n TIP: Guarantee there is some success within every budget year.
n TIP: This is a big help when requirements change; It is always
easier to say ‘later’ than to say ‘no’.

5/13/20 33
Ranked for Importance
n TIP: Decide what is the most important aspect of the
system: ƒ
5 Get to market fast ƒ
5 Ease of use ƒ
5 Run in real time ƒ

n TIP: Attach an importance number to every

requirement, if only 1...5, or HM-L. Build just the
most important subset of requirements first.
n TIP: Remember that risky requirements are, by
definition, important.

5/13/20 34
Other Things to Remember
n TIP: Do not put too much into the Requirements specification,
i.e. Project information or Design information.
n TIP: Remember that the Requirements specification will be
used to size the project.
n TIP: Alternatives that are almost equally good, will generate
the most argument.

5/13/20 35
References

1. Software Requirements. Karl. E. Weigers,

Chapter 14, Microsoft, 2013.
2. Mastering the Requirements Process.
Suzanne Robertson & James Robertson,
Addison-Wesley 1999.
3. Estimating Software Costs. T. Capers Jones,
McGrawHill 1998.
4. Software Engineering Body of Knowledge.
IEEE Press.

5/13/20 36