Software Quality Engineering
BS(SE)-VI
Dr. Assad Abbas
Department of Computer Science
Topics
n Quality in requirements specification
n Defects in requirements specification
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)
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
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 –
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.
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
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
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%
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.
nNecessary
– 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.
Writing Example #1
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?
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.
Writing Example #2
n
“The product shall switch between displaying and
hiding nonprinting characters instantaneously."
n
Incomplete
– conditions which trigger state switch
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.”
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?
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
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
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
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
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.
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:
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
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
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
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.
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
Verifiable
n A Requirement that cannot be tested, is not a Requirement.
n TIP: Take a tip from the Agile/XP/Scrum people: create
Traceable
n Traceability is required for Change Management.
n TIP: Use a software tool or at least number each paragraph in
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
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.
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
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.
