Chapter 2:

SOFTWARE
QUALITY FACTORS

Bộ môn Công Nghệ Phần Mềm

Khoa CNTT – Trường ĐH Ngoại Ngữ Tin Học TP.HCM
Contents

• The need for comprehensive sof tware quality requirements

• Classify sof tware requirements into sof tware quality factors

• Quality factors of product operating sof tware

• Alternative models of sof tware quality factors

• Sof tware complies with quality factors

 The need for a comprehensive software
quality requirements

There are some characteristic common :

□ All the software projects satisfactory fulfilled the basic requirements for
correct calculations

□ 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 functionally.
 The need for a comprehensive
definition of requirements

■ There is a need for a comprehensive definition of requirements

that will cover all attributes of software and aspects of the usability
aspects, reusability aspects, maintainability aspects, and so forth in
order to assure the full satisfaction of the users.

■ Software industry groups the long list of related attributes into

what we call quality factors. (non-functional requirements )

■ Requirement documentation (specification) is one of the most

important elements for achieving good software quality
 The Facts…

■ Seems like in Sof tware Engineering we concentrate on capturing,

designing, implementing, and deploying with emphasis on functional
requirements.

■ Little (not none!) emphasis on the nonfunctional requirements

(quality factors). •More and more emphasis now placed on quality
factors •Can be a critical factor in satisfying overall requirements.
The Facts…

■ In the RUP, non-functional requirements are captured in

the Software Requirements Specification (SRS); functional
requirement usually captured in Use Case stories.
 Classification of software requirements
into software quality factors

The classic model of software quality factors suggest by :

o McCall (consist of 11 factors, 1977)

o Deutsch and Willis (consist of 12 to 15 factors, 1988)

o Evans and Marciniak (1987)

 McCall’s Factor Model

Classifies all software requirement into

11 software quality factors, grouped into
three categories:

1) Product operation factors : Correctness,

Reliability, Efficiency, Integrity, Usability.

2) 2. Product revision factors :

Maintainability, Flexibility, Testability.

3) 3. Product transition factors : Portability,

Reusability, Interoperability.
Product Operation Factors

How well does it run

and ease of use ?
 Product Operation - Correctness

• Correctness requirements are def ined in a list of the sof tware system’s
required outputs.

• Output specif ications are usually multidimensional; some common dimensions

include :

✓ The output mission

✓ The required accuracy of output o The completeness of the output information

✓ The up-to-dateness of the information

✓ The availability of the information

✓ The standards for coding and documenting the sof tware system.
 Product Operation - Reliability

❑ Reliability requirements deal with failures to provide service.

❑ Determine the maximum allowed sof tware system failures rate and can
refer to the entire system or to one or more of its separate functions.

❑ Use MT TF, MTBF and MT TR calculation

❑ Examples :
1. The failures frequency of a hear t -monitoring unit that will operate in a hospital’s
intensive care ward is required to be less than one in 20 years. Its hear t attack
detection function is required to have a failure rate of less than one per million cases.

2. One requirement of the new sof tware system to be installed in the main branch of
Independence Bank, which operates 120 branches, is that it will not fail, on average,
more than 10 minutes per month during the bank’s off ice hours.
 Product Operation - Efficiency

❑ Eff iciency requirements deal with the hardware resources needed to

perform all the functions of the sof tware system in conformance to all other
requirements.

❑ Here we consider MIPS, MHz (cycles per second); data storage capabilities
measured in MB or TB or communication lines (usually measured in KBPS,
MBPS, or GBPS).

❑ Examples :

1. A chain stores is considering two alternative bids for a sof tware system.

2. Ver y slow communications

 Product Operation - Integrity

■Integrity requirements deal with the sof tware system security, that is
requirements to present access to an authorize person,

[to distinguish between the majority of personnel allowed to see the

information (“read permit”) and a limited group who will be allowed to
add and change data (“write permit”), and so for th.]

■ Example : GIS SW allowed citizens access to its GIS through Internet

only for viewing and copying data but not to insert changes.
 Product Operation - Usability

❑ Usability deals with learnability, utility, usability, and more

❑ Usability requirements deal with the scope of staff resources

needed to train a new employee and to operate the sof tware
system.

❑ Example : The sof tware usability requirements document for the

new help desk system initiated by a home appliance service
company lists the following specif ications :
a. A staf f member should be able to handle at least 60 ser vice calls a day

b. Training a new employee will take no more than two days, immediately at
the end of which the trainee will be able to handle 45 ser vice calls a day.
Product Revision Factors

Can I fix it easily,

retest, version it, and
deploy it easily ?
Product Revision software Quality
Factors

■ According to the McCall model of software quality

factors, three quality factors comprise the product revision
category. These factors deal with those requirements that
affect the complete range of software maintenance
activities :

✓ Corrective maintenance

✓ Adaptive maintenance

✓ Perfective maintenance
 Product Revision – Maintainability

❑ Maintainability requirements determine the ef forts that will be needed by

users and maintenance personnel to identify the reasons for sof tware
failures, to correct the failures, and to verify the success of the corrections.

❑ This factor ’s requirements determine refer to the modular structure of

sof tware, the internal program documentation, and the programmer ’s
manual, architectural and detail design and corresponding documentation.

❑ Example typical maintainability requirements :

a. The size of a sof tware module will not exceed 30 statements.

b. The programming will adhere to the company coding standards and

guidelines.
 Product Revision - Flexibility

❑ The capabilities and efforts required to support adaptive

maintenance activities are covered by the f lexibility requirements.
❑ These include the resources (in man -days) required to adapt a
sof tware package to a variety of customers of the same trade, of
various extents of activities, of different ranges of products, and so
on.
❑ This factor ’s requirements also support perfective maintenance
activities.
– May also involve a little per fective maintenance to perhaps do a little
better due to the customer ’s perhaps slightly more robust environment.
– Dif ferent clients exercise sof tware dif ferently and this is big !
 Product Revision - 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 intermediate results and log files.
– Are intermediate results of computations predefined to assist testing?

– Are log files created? Backup?

– Does the sof tware diagnose itself prior to and perhaps during
operations?
 Product Transition Factors

Can I …

a. move the app to different hardware ?

b. interface easily with different hardware / software

systems ?

c. reuse major portions of the code with little

modification to develop new apps ?
Product Transition - Portability

■ Portability requirements tend to the adaptation of

software system to other environments consisting of
different hardware, different operating systems, and so
forth
 Product Transition - Reusability

Reusability requirements deal with the use of software modules

originally designed for one project currently being developed.

– Can save immense development costs due to errors found / tested.

– Certainly higher quality software and development more quickly

results.

– Very big deal nowadays.

 Product Transition - Interoperability

❑ Interoperability requirements focus on creating interfaces with

other software systems or with other equipment firmware.

❑ Interoperability requirements can specify the name of the software

or firmware for which interface is required.
✓ Frequently these will be known ahead of time and plans can be made to
provide for this requirement during design time.
• Sometimes these systems can be quite differ ent; differ ent platforms , differ ent
database s, and more

✓ Also, industry or standard application structures in areas can be specified

as requirements.
Alternative Models of Software Quality Factors

Formal comparison of the alternative models

(Evans M 1987, Deutsch & Willis 1988)
□ Comparison of the factors models -content analysis
(verifiability, expandability, safety, manageability, survivability)

□ Structure of the alternative factor models

Models Comparison of Software Quality Factors
 Alternative Factors

Alternative – Verifiability: requirements addresses design

and programming features that allow for efficient verification of
design and programming

■ This does not refer to outputs; rather, structure of code, such

as design elements and their dependencies, coupling, cohesion;
patterns…

■ apply to modularity, simplicity, adherence to documentation

and programming guidelines, etc.

■ Look at the UML for dependencies, cohesion, coupling…

Alternative Factors

Alternative - Expandability :Expandability

requirements really refers to scalability and extensibility to
provide more usability.

■ Essentially this is McCall’s flexibility

 Alternative Factors

Alternative – Safety:
■ Safety requirements address conditions that could bring the
equipment or application down especially for controlling software, as
in setting alarms or sounding warnings.
■ Safety is clearly important as computers control more and more of
what we do especially in both hardware and in software.
• Especially important to process control / real time sof tware such as that
running conveyor belts or instrumentation for ordinance
• New cars will now sound an alarm as we back up; sof tware will sound
when power is interrupted.
Alternative Factors

Alternative – Survivability : Survivability requirements

refer to MTBF, or continuity of service, as well as MTTR
(mean time to recover).

■ Appears to be quite similar to Reliability in McCall’s

model
Alternative Factors

Alternative – Manageability : Manageability

requirements refer to tools primarily administrative to
control versions, configurations and change management /
tracking.

■ We must have tools to manage versions and various

configurations that may vary from customer to customer
 Who is interested in the definition of
quality requirements?

■ Some quality factors not included in the typical client’s

requirements document may, in many cases, interest the
developer.

■ The following lists of quality factors usually interest the

developer whereas they may raise very little interest on the part
of the client:

✓ Portability

✓ Reusability

✓ Verifiability
Requirements Documents

A project will be carried out to according to two

requirements documents :

✓ The client’s requirements document

✓ The developer’s additional requirements document

Software Compliance with Quality
Factors

❑ The software’s product compliance to the requirements

belonging to the various quality factors is measured by
software quality metrics, measures that quantify the
degree of compliance.

❑ In order to allow for valid measurements of compliance,

sub-factors have been defined for those quality factors
that represent a wide range of attributes and aspects of
software use.
Factors and sub-factors
Factors and sub-factors
Factors and sub-factors
Summary

1. The need for a comprehensive requirements documents

and their contents.

2. The structure (categories and factors) of McCall’s classic

factor model.

3. The additional factors suggested by alternatives factor

models.

4. Those interested in defining software quality

requirements.