Chapter 3

Software Quality Factors

 The need for comprehensive software
quality requirements
 Our Sales IS seems v. good , but it is frequently fails, at least
twice a day for 20 minutes or more.( SW house claims no
responsibility….
 Local product contains a SW and every thing is ok, but, when we
began planning the development of a European version, almost
all the design and programming will be new.
 The need for comprehensive software
quality requirements
 There are some characteristic common to all these “but’s”:
■ All the software projects satisfactorily fulfilled the basic
requirements for correct calculations (correct inventory figures,
correct average class’s score, correct loan interest, etc.).
■ All the software projects suffered from poor performance in
important areas such as maintenance, reliability, software reuse,
or training.
■ The cause for the poor performance of the developed software
projects in these areas was the lack of predefined
requirements to cover these important aspects of the
software’s functionality.
The requirements document is one of the most important
elements for achieving software quality
The need for comprehensive software
quality requirements
 There is a need for a comprehensive definition
of requirements that will cover all attributes of
software and aspects of the use of software,
including usability aspects, reusability
aspects, maintainability aspects, and so
forth in order to assure the full satisfaction of
the users.
 Quality factors
The great variety of issues related to the various attributes
of software and its use and maintenance, as defined in
software requirements documents, can be classified into
groups called quality factors.
 The team responsible for defining the software
requirements of a software system is expected to
examine the need to define the requirements that
belong to each factor
 Classification of software requirements
.into software quality factors
McCall’s factor model classifies all software requirements into 11
software quality factors. The 11 factors are grouped into three
categories as follows:

1- Products operation factors: (daily operation of the software)

Correctness, Reliability, Efficiency, Integrity, Usability.
2- Product revision factors: (maintenance activates)
Maintainability, Flexibility, Testability.
3- Product transition factors: (software adaptation to other
environments and it’s interaction with other software systems)
Portability, Reusability, Interoperability.
Product operation software quality
factors
Deals with requirements that directly affect the
daily operation of the software.

Correctness:
 Correctness requirements are defined in a list of
the software system’s required outputs
 How many errors there are in the software?
 Correctness
Output specifications are usually multidimensional; some common
dimensions include:
 The output mission (e.g., sales invoice printout, and red alarms
when temperature rises above 250°F).
 The required accuracy of those outputs that can be adversely
affected by inaccurate data or inaccurate calculations.
 The completeness of the output information, which can be adversely
affected by incomplete data.
 The up-to-dateness of the information (defined as the time between
the event and its consideration by the software system).
 The availability of the information (the reaction time, defined as the
time needed to obtain the requested information or as the requested
reaction time).
Correctness Example
(club membership info system)
 1. Output mission: list of 11reports, 4 standard letters, 3
interactive queries.
 2. Required accuracy: prob of a non-accurate output <1%.
 3. Completeness: prob of missing data about a member,
attendance, payments etc < 1%.
 4. Up-to-dateness: no more than 2 days for info about
event participation to be valid
 5. Availability: reaction time to queries < 2 seconds, to
reports < 4 hours
 Product operation software quality
factors
 Reliability:
Reliability requirements deal with failures to provide
services. They determine the maximum allowed SW
system failure rate, and can refer to entire system or
one of its function.

E.g. The failure frequency of a heart-monitoring unit that will operate

in a hospital’s intensive care ward is required to be less than one in
20 years. Its heart attack detection function is required to have a
failure rate of less than one per million cases.
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 to all other
requirements.
Ex.
 Processing power (MIPS, MHz)
 Storage capacity (GBytes, TBytes)
 Data communication capabilities (MBPS, GBPS)
Product operation software quality
factors
Integrity:
Integrity requirements deal with the software
system security. That is requirements to
prevent unauthorized access.
Ex. “read only” permit
Product operation software quality
factors
 Usability:
Usability requirements deal with the scope
of staff needed to train a new employee
and to operate the software system.
 Eg Help Desk requirements
 Two days to train new staff
 One staff to handle 60 calls per day
 :Product revision software quality factors
Deal with those requirements that affect the complete
range of software maintenance activities:
Corrective maintenance: correction of software faults and
failures.
Adaptive maintenance: adapting the current software to
additional circumstances and customers without changing the
software.
Perfective maintenance: enhancement and improvement of
existing software with respect to locally limited issues.
:Product revision software quality factors
The three quality factors comprise the product
revision category are:
Maintainability:
Maintainability requirements determine the efforts
that will be needed by users and maintenance
personnel to identify the reasons for software
failures, to correct the failures, and to verify the
success of the corrections.
:Product revision software quality factors
This factor’s requirements refer to
1- The modular structure of software
2- The internal program documentation
3- The programmer’s manual.

Examples:
a- The size of a software module will not exceed 30
statements
b- The programmer will adhere to the company
coding standards and guidelines.
:Product revision software quality factors
Flexibility:
The capabilities and efforts required to support
adaptive maintenance activities are covered by the
flexibility requirements.
These include the resources (in man-days)
required to adapt a software to a varieties of
customers of the same trade and of various extents
of activities.
:Product revision software quality factors

The flexibility requirements also support

perfective maintenance activities, such as
changes and additions to the software in order
to improve its service and to adapt it to
changes in the technical or commercial
environment.
:Product revision software quality factors
As example TSS (teacher support SW.) calculation
of final grades, pupil achievements…etc

 The SW specifications of TSS include the following

flexibility requirements:
a) The SW should be suitable for all teachers of all
subjects and all school levels
b) Non-professionals should be able to create new
types of reports according to schoolteacher’s
requirements.
:Product revision software quality factors
Testability:
Testability requirements deal with the testing of an information
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, for
instance by providing predefined immediate results and log
files.
 Testability requirements related to software operation include
automatic diagnostics performed by the software system prior
to starting the system, to find out whether all components of the
software system are in working order and to obtain a report
about the detected faults.
:Product revision software quality factors
 Example
An industrial computerized control unit is programmed to
calculate various measures of production status, report
the performance level of the machinery, and operate a
warning signal in predefined situations.
One testability requirement demanded was to develop a
set of standard test data with known system expected
correct reactions in each stage. This standard test data
is to be run every morning, before production begins, to
check whether the computerized unit reacts properly.
 :Product Transition software quality factors
Factors that deals with the adaptation of software to other
environments and it’s interaction with other software systems
Portability:
Portability requirements tend to the adaptation of a software
system to other environments consisting of different
hardware, different operating systems, and so forth. It make
possible to use the software in different SW and HW
simultaneously.
Example :A software package which designed and programmed to
operate in a Windows 7 environment is required to allow low-cost
transfer to Linux and Windows NT environments.
 :Product Transition software quality factors
Reusability:
Reusability requirements deal with the use of software
modules originally designed for one project in a new
software project currently being developed.
 The reuse of SW is expected to save development
resources, shorten the development period and provide
higher quality modules. These benefits based on the
assumption that the most of the SW faults have already
been detected and solved
 :Product Transition software quality factors
Interoperability:
Interoperability requirements focus on creating interfaces
with other software systems or with other equipment
firmware. Interoperability requirements can specify the
names of the software or firmware for which interface is
required. The can also specify the output structure
accepted as standard in a specific industry or
applications area.
 Example: The firmware of a medical laboratory’s equipment is
required to process its results (output) according to a standard
data structure that can then serve as input for a number of
standard laboratory information systems.
Example
 The software requirement document for the
tender for development of “Super-lab,” a
software system for managing a hospital
laboratory, consists of chapters according
to the required quality factors as follows:
correctness, reliability, efficiency, integrity,
usability, maintainability, flexibility,
testability, portability, reusability and
interoperability
No. Section taken from the software requirement document The requirements
factor

1 The probability that the “Super-lab” software system will be found in a state of failure during peak
hours (9 am to 4 pm) is required to be below 0.5%.

2 The “Super-lab” software system will enable direct transfer of laboratory results to those files of
hospitalized patients managed by the “MD-File” software package.

3 The “Super-lab” software system will include a module that prepares a detailed report of the patient’s
laboratory test results during his current hospitalization. (This report will serve as an appendix
to the family physician’s file.) The time required to obtain this printed report will be less than
60 seconds; the level of accuracy and completeness will be at least 99%.

4 The “Super-lab” software to be developed for hospital laboratory use may be adapted later for private
laboratory use.

5 The training of a laboratory technician, requiring no more than 3 days,will enable the technician to
reach level C of “Super-lab” software usage. This means that he or she will be able to manage
reception of 20 patients per hour.

6 The “Super-lab” software system will record a detailed users’ log. In addition, the system will report
attempts by unauthorized persons to obtain medical information from the laboratory test
results database. The report will include the following information: the network identification
of the applying terminal, the system code of the employee who requested that information, the
day and time of attempt and the type of attempt.

7 The “Super-lab” subsystem that deals with billing patients for their tests may be eventually used as a
subsystem in the “Physiotherapy Center” software package.

8 The “Super-lab” software system will process all the monthly reports for the hospital departments’
management, the hospital management, and the hospital controller according to development
contract.

9 The software system should be able to serve 12 workstations and 8 automatic testing machines with a
single model AS20 server and a CS25 communication server that will be able to serve 25
communication lines. This hardware system should conform to all availability requirements
listed in development contract.

10 The “Super-lab” software package developed for the Linux operating system should be compatible
for applications in a Windows NT environment.