College of Engineering
Department of Computer Engineering
SWE 401 – Software Quality Assurance
Dr. Khaled Almakadmeh
© Khaled Almakadmeh 1
Chapter 2
Software Quality Factors
© Khaled Almakadmeh 2
Agenda
Complaints from the City Computer Club members – A Case Study
Comprehensive Software Quality Requirements
McCall’s Model for Software Quality Factors
ISO/IEC 25010 Quality Model
Software Compliance with Quality Factors
© Khaled Almakadmeh 3
The City Computer Club – A Case Study
The City Computer Club was established by municipal corporations
and public IT department managers. The discussion topic of the club
meeting was implementation experiences in their organizations.
“Our new sales information system seems okay. The invoices and
inventory records are correct, the discounts granted to our clients
follow our very complicated discount policy precisely, but our new
sales information system frequently fails”. Recently, it has been
failing at least twice a day, and each time for at least twenty minutes.
Yesterday, it took an hour and half for us to get back to work.
© Khaled Almakadmeh 4
The City Computer Club – A Case Study
“Just a year ago, we launched our successful new product – RD-1, a
police radar detector. The RD-1 firmware embedded in the product
seemed to be the reason for its success.
But, when we began planning the development of the European
version of the product, RD-E1, we found out that the RD-1 firmware
had only been partially documented, and the code, mostly written
with no adherence to the company’s work instructions.
© Khaled Almakadmeh 5
The City Computer Club – A Case Study
“Our software package for schoolteachers' “Blackboard”, launched
just three months ago, is already installed in 187 schools. The
development team just returned from a week in Hawaii - their
vacation bonus. But we have suddenly started to receive daily
complaints from the “Blackboard” maintenance team.
They claim that the lack of failure detection features in the software,
in addition to the poor programmer’s manual, have caused them to
invest more time to deal with bugs and minor software changes,
than that agreed upon in the purchasing contracts with clients.”
© Khaled Almakadmeh 6
The City Computer Club – A Case Study
“The new version of our loan contract software is really accurate.
We have already processed 1,200 customer requests, and checked
each of the output contracts - no errors were found.
But we did face a severe unexpected problem – training a new staff
member to use this software takes about three weeks. This is a real
problem in customer departments suffering from high employee
turnover.
© Khaled Almakadmeh 7
The City Computer Club – A Case Study
There are several characteristics common to all these “buts”:
1. Software projects satisfactorily fulfilled basic requirements to
perform the correct calculations (correct inventory figures,
correct average class scores, correct loan interests, etc.).
2. Software projects suffered from poor performance in important
areas such as software maintenance, software reliability,
software reuse and user training.
3. The common cause, for poor performance of software projects
developed in these areas, was a lack in essential parts of the
project requirements. These parts should have been designated
to cover important aspects of software functionality.
© Khaled Almakadmeh 8
Comprehensive Software Quality Requirements
The previous examples already shown represent difficulties faced by
users, developers, and maintenance staff. All of which could have
been avoided if the relevant requirement had been included in the
requirement document.
There is a need for a comprehensive requirements set that covers
all attributes of software and aspects of its use needed throughout
the software life cycle.
Software that fulfill these requirements including usability, reusability,
maintainability are expected to achieve increased user satisfaction
and higher efficiency of development and maintenance teams.
© Khaled Almakadmeh 9
Comprehensive Software Quality Requirements
The great variety of attributes of software quality defined in software
requirement documents can be classified into content groups; these
groups are termed software quality factors.
Software requirement documents are expected to differ in degree of
emphasis placed on various quality factors, hence the differences
between software projects and the expectation that not all factors
are universally included in all requirement documents.
© Khaled Almakadmeh 10
Comprehensive Software Quality Requirements
Over the last four decades, groups of software quality factors have
been presented in several software quality models.
Several criteria (subfactors/sub-characteristics) for each of these
factors have been suggested.
These criteria/subfactors are expected to be measurable, and to
support the reviewing, testing, and quality measurement of software
products with respect to these factors:
o McCall’s classic model for software quality factors
o The ISO/IEC 25010 model and other alternative models
o Software compliance with quality factors
© Khaled Almakadmeh 11
McCall’s Model for Software Quality Factors
The classic model of software quality factors, suggested by McCall,
consists of 11 factors (McCall et al. 1977).
The McCall factor model, despite decades of “maturation,” continues
to provide a practical, up-to-date method for classifying software
quality requirements.
McCall’s factor model classifies all software requirements into (11)
software quality factors. These are grouped into three categories:
product operation, product revision, and product transition.
© Khaled Almakadmeh 12
McCall’s Model for Software Quality Factors
© Khaled Almakadmeh 13
McCall’s Model for Software Quality Factors
© Khaled Almakadmeh 14
McCall’s product operation software quality
factors: Correctness
Correctness requirements are related to the outputs of software
systems, such as a query display of a customer’s balance in the
sales accounting information system.
A specification is required for each system function which is usually
multidimensional:
o Required accuracy of the output
o Required completeness of the output information
o Required up-to-datedness of information
o Required response time
o Standards for coding and documenting the software system
© Khaled Almakadmeh 15
McCall’s product operation software quality
factors: Reliability
Reliability requirements deal with failures to provide service. They
determine the maximum allowed software system failure rate, the
maximum allowed percentage of a software system’s downtime, and
the maximum allowed recovery times.
The requirements can refer to the entire system or to one or more of
its separate functions.
© Khaled Almakadmeh 16
McCall’s product operation software quality
factors: Efficiency
Efficiency requirements deal with the hardware resources needed to
perform all the functions of the software system in conformance with
all other requirements such as computer’s processing capabilities.
Another type of efficiency requirement deals with the time lapse
between recharging the system’s portable units such as information
system units located in portable computers and meteorological units
placed outdoors.
© Khaled Almakadmeh 17
McCall’s product operation software quality
factors: Integrity
Integrity requirements deal with the software system security,
requirements to prevent unauthorized access to distinguish between
most personnel only allowed to see the information (read only
permit), and a limited group who will be allowed to add and change
data (write permit), and so forth.
Integrity requirements are defined to cope with risks of “nonfriendly”
unauthorized attempts to damage the software system and its
performance.
© Khaled Almakadmeh 18
McCall’s product operation software quality
factors: Usability
Usability requirements deal with the scope of staff resources needed
to train a new employee and to operate the software system.
The usability requirements relate to the (a) operation usability, the
productivity of the user, that is, the average number of transactions
performed per hour, and (b) training usability, the average time spent
training a new employee.
© Khaled Almakadmeh 19
McCall’s product revision software quality
factors: Maintainability
Maintainability requirements determine the efforts needed by users
and maintenance personnel to identify the reasons of a software
failure, correct the failure, and verify the success of the correction.
This factor’s requirements refer to the modular structure of software,
the internal program documentation, and the programmer’s manual,
among other items.
© Khaled Almakadmeh 20
McCall’s product revision software quality
factors: Flexibility
The flexibility factor deals with the capabilities and efforts required to
support adaptive maintenance activities.
These capabilities include the resources (i.e., in employee/days)
required to adapt a software package to a variety of customers, with
a variating extent of activities, and a different range of products.
This factor’s requirements also support perfective maintenance
activities, such as changes and additions to the software to improve
its service, and to adapt it to changes in the firm’s technical or
commercial environment.
© Khaled Almakadmeh 21
McCall’s product revision software quality
factors: Testability
Testability requirements deal with the testing process of a software
system, as well as with its operation. Testability requirements for the
ease of testing are related to special features in the programs that
help the tester by providing pre-defined intermediate results and log
files.
Testability requirements related to software operation include
automatic diagnostics performed by the software system prior to
operating the system.
Another type of these requirements deals with automatic diagnostic
checks to be applied by the maintenance technicians to detect the
causes of software failures.
© Khaled Almakadmeh 22
McCall’s product Transition software quality
factors: Portability
Portability requirements relate to adaptation of a software system to
other environments consisting of different hardware and operating
systems.
These requirements make it possible to widen the market for the
software product and enable using the same basic software in
diverse situations: in different hardware and operating systems.
© Khaled Almakadmeh 23
McCall’s product Transition software quality
factors: Reusability
Reusability requirements deal with “two-directional” requirements.
One direction is the use of a software module, or an entire
application, taken from an existing software product in a new
software project currently being developed.
Reused software is expected to be tested by its developers and
already corrected according to failures experienced by former users.
The reuse of software is expected to save development resources,
shorten development schedule and provide higher quality software
modules.
© Khaled Almakadmeh 24
McCall’s product Transition software quality
factors: Interoperability
Interoperability requirements focus on creating interfaces with other
software systems or equipment firmware (for example, the firmware
of the production machinery and testing equipment interfaces with
the production control software).
Interoperability requirements sometimes specify the name(s) of the
software or firmware to which an interface is required.
They may also specify the accepted standard output structure in a
specific industry or application area.
© Khaled Almakadmeh 25
The ISO/IEC 25010 Quality Model
Several software quality factor models, alternatives to the classic
McCall’s model, have been developed during the last four decades
such as Boehm’s model and ISO/IEC 25010:2023.
The ISO/IEC 25010:2023 model is significant as it was developed
by a joint ISO/IEC international professional team.
The ISO/IEC 25010:2023 product quality model is composed of
eight (8) factors, and shows a substantial similarity to McCall’s
model, as four out of its eight factors are included in McCall’s model.
© Khaled Almakadmeh 26
The ISO/IEC 25010 Quality Model
© Khaled Almakadmeh 27
The ISO/IEC 25010 Quality Model
Functional suitability is the capability to fulfill the functions needed
by the customer, stated or implied (not necessarily the specified
requirement).
It covers a wide variety of aspects of software use, including the
accurate and complete production of needed results.
A significant similarity exists between the functionality factor and the
correctness, integrity and interoperability factors of McCall’s model.
© Khaled Almakadmeh 28
The ISO/IEC 25010 Quality Model
Performance: software performance efficiency relates to the amount
of hardware resources required to fulfill the software system tasks.
Compatibility: refers to the capability of a software system or
component to (a) exchange information with other software systems
or components and (b) per form other system required functions,
sharing its hardware system and software environment.
Security: relates to capability of a system product to protect software
system, data stores, and information produced from the reading,
modification, or destruction by unauthorized persons or systems.
© Khaled Almakadmeh 29
Software Compliance with Quality Factors
The software quality models call for implementation for evaluation of
the quality of software development and maintenance processes,
and of software products.
The extent to which the software development and maintenance
processes comply with the requirements of the various quality
factors to be examined in technical reviews, software inspections,
software tests, and evaluated by software quality metrics.
© Khaled Almakadmeh 30
Software Compliance with Quality Factors
© Khaled Almakadmeh 31
Software Compliance with Quality Factors
© Khaled Almakadmeh 32
Exercise
Correctness
• Employees salaries should not be late (Wrong)
• Employees salaries should be calculated accurately and must be
ready five days before the end of the month (Correct)
Reliability
• The system should be working as much time as possible (Wrong)
• The system should not be in failure status during working hours (9 to
4). Total time of failure status should not exceed 20 minutes per
month. (Correct)
© Khaled Almakadmeh 33
Exercise
Efficiency
The GPS application should use as little as possible of mobile
phone battery. (Wrong)
The GPS application should not use more than 10% of battery
power in two hours time. (Correct)
Integrity
Students should be allowed to access their final marks. (Wrong)
Students should be allowed to view their final marks. They should
not be able to make any changes. (Correct)
© Khaled Almakadmeh 34
Exercise
Usability
The billing system should be easy to use. (Wrong)
Billing staff should be able to learn the most important five functions
of the billing system in 3 working hours. (Correct)
© Khaled Almakadmeh 35
