FMEA for UML-based Software

Wang Wentao Zhang Hong

Dept. of System Engineering of Engineering Technology

Beihang University, Beijing, P. R. China

wwtjun@gmail.com zh@buaa.edu.cn

Abstract- As one of the most important methods used to

improve the software reliability and safety, Software

Failure Modes and Effects Analysis (SFMEA) has

increasingly been applied to many areas. Meanwhile, the

Unified Modeling Language (UML) has become the main

language for Object-Oriented software design. Therefore,

the method of UML-based SFMEA is of importance to

Object-Oriented software. In this paper, this research

takes advantage of the characteristics of the UML

diagrams used in different software development phases

such as requirement analysis phase and architectural

design phase, builds the relationships respectively

between SFMEA and use case diagram, activity diagram,

and lastly establishes the corresponding analysis methods

illustrated with an example.

Keywords- SFMEA, UML, OO

1. Introduction

With wide application of computer software in

many areas, the reliability and safety are also

increasingly becoming prominent. As a general method

of software reliability and safety analysis, Software

Failure Modes and Effects Analysis (SFMEA) has

been playing an important role in enhancing the

software reliability and safety. Currently, Object-

Oriented (OO) method has become the mainstream of

software development, while UML has also been the

unified modeling language in software industry [1].

Since the modeling language draws the blueprint of

software construction, apparently it is the source for

reliability analysis. Therefore, the research on SFMEA

based on UML makes actual sense to the reliability

analysis of Object-Oriented software.

So far, the researches on this topic are somewhat

few in software reliability area. The article [2] presented

by Professor Nathaniel Ozarin in 2004 stated the

relationships among software development stages,

UML diagrams and FMEA levels (method, class,

module and package), but not focused on the concrete

process when performing FMEA with UML diagrams.

In the same year, Professor Herbert Hecht in his

article [3] described respectively the application of UML

to SFMEA during the concept phase (the requirement

analysis stage in OO process) and the implementation

phase (the coding stage in OO process), while he only

took advantage of the use case diagram and class

diagram, lacking dynamic diagrams such as activity

diagram and sequence diagram, etc.

Therefore, in this paper some fresh researches on

FMEA for UML-based software will be described in

two development phases of OO software.

2. The Features of UML

The advent of OO technique and particularly of

the UML has motivated us to take a fresh look at

overcoming the previous difficulties in generating

SFMEA. The key to this fresh look is that objects are

uniquely characterized by their methods (sometimes

called behaviors) [3]. If all methods of an object are

executing in accordance with their specification the

object has not failed. Conversely, the object will fail.

The failure effect will depend on the mode in which

the method failed.

Now we will demonstrate orderly how these

characteristics can be used to generate a FMEA from

the UML diagrams available during the requirement

analysis phase and architectural design phase.

3. SFMEA in Requirement Analysis Phase

Requirement analysis is the first and also

important phase in OO software development process,

identifying the user’s functional requirements which

could be described with use case diagram. And it could

also use activity diagram to establish the order of

requirements as auxiliary artifacts. In this early phase

performing SFMEA could help the analyst find

potential weaknesses in system level, and

communicate to all project participants that special

attention to reliability or safety critical aspects is

required. Also, applying SFMEA in the early phase

needs comparatively little effort but great benefit [4].

World Congress on Software Engineering

978-0-7695-3570-8/09 $25.00 © 2009 IEEE

DOI 10.1109/WCSE.2009.342

457

World Congress on Software Engineering

978-0-7695-3570-8/09 $25.00 © 2009 IEEE

DOI 10.1109/WCSE.2009.342

457

World Congress on Software Engineering

978-0-7695-3570-8/09 $25.00 © 2009 IEEE

DOI 10.1109/WCSE.2009.342

456

World Congress on Software Engineering

978-0-7695-3570-8/09 $25.00 © 2009 IEEE

DOI 10.1109/WCSE.2009.342

456

World Congress on Software Engineering

978-0-7695-3570-8/09 $25.00 © 2009 IEEE

DOI 10.1109/WCSE.2009.342

456

Take the common ATM system for instance. We

apply our approach in the software part of this system,

whose use case diagram is shown in Figure 1 as below,

including “deposit”, “withdraw”, “query balance” ,

“login” and “print receipt” five use cases. Then we

discuss the steps of performing SFMEA [5].

Figure 1 ATM Use Case Diagram

(1) System defining and partitioning. As a

bottom-up analysis method, SFMEA requires firstly

the system under analysis to be hierarchically divided

into components in such a way that the failure modes

of the components at the bottom level can be

identified [6].

As is shown in Figure 1, the three main use cases,

also the three main components should be the first

level for analysis. “Login” belongs to the included use

case, which means it must be a necessary part of other

use cases (symbolized with <<uses>>), and it should

be allocated to the second level. The “print receipt”

belongs to the extended use case, which means it is a

supplementary but not necessary part of other use

cases (symbolized with<<extends>>). And also these

two special use cases are independent of each other.

The correlations among use cases could help us

acquaint with the system and components.

(2) Identify analysis level and analysis item. It is important to make sure which level we start

analyzing from. Generally, the lower level chosen, the

more components concerned, and the higher cost. The

basic factors influencing the selection of the proper

lowest level of system decomposition are the purpose

of the analysis and the availability of system design

information [7]. Once analysis level is identified, each

component at this level could be considered as the

analysis item. According to Figure 1, we choose the case level

as the analysis level and each use case is regarded as

an item. For each item, we start to bottom-up analyze.

(3) Identify failure modes. A failure mode is

defined to be “the physical or functional manifestation

of a failure” [8]. As one of the components which

perform an independent function from others, its

failure modes could be regarded as function failure

modes and performance failure modes. The former

often includes “unable to initialize”, “could not

perform correctly”, “correct operation but bad result”

and so on; the latter often pays attention to time and

memory such as “perform delays”, “memory leaks”

and so on.

In this example our discussion concentrates on the

“login” item. In accordance with its functional

requirement, the most common failure modes are

“unable to login” and “illegal login”. Besides,

considering the time factor, “login delays” is another

failure mode. In order to identify more failure modes,

except for experiences, the analyst also need to refer to

other development documents and communicate with

experts in related domain.

(4) Trace the failure effect. Failure effect,

which is the consequence that a software failure causes,

could propagate from the lower level to the higher one.

The failure effects of the lower level components

constitute the failure modes of the upper level

components. Failure effect is generally composed of

the local effect, the next higher level (NHL) effect and

system effect. In this example, solely on the basis of

Figure 1, we could not trace the local failure effect of

“login” item, thus we need the activity diagram to

show the relationship between items.

Figure 2 The System Activity Diagram

As is shown in Figure 2, the system activity

diagram contains a sequence of activities displaying

how a customer uses the ATM system. Thus, we can

judge that the local effect caused by the failure mode

“illegal login” will influence the next activity

(“withdraw”/ “deposit”/ “query balance”) and will

458458457457457

cause specifically withdraw, deposit, and query

balance illegally. The NHL effect and system effect are

the same one in this example, which indicates that the

system operates abnormally and personal account will

be stolen, which is a high severity failure.

If another failure mode “login delays” happens,

despite local effect or system effect, it may only cause

the system’s performance degradation but not

influence its normal operation and personal safety, and

we define this kind of failure effect as “moderate”. So

a FMEA worksheet for the “login” use case based on

Figure 1 and Figure 2 is shown in Table 1. Finally,

performing FMEA for the rest items could follow the

rules as above.

To sum up, the method based on UML to generate

software FMEA during the requirement analysis phase

is that:

� Analysis basis: use case diagram, activity

diagram;

� Analysis item: use case;

� Analysis step: make use of use case diagram

to identify analysis level and items, activity diagram to

trace the local effect, and use case diagram to trace the

system effect.

Table 1 Worksheet in Requirement Analysis Phase

ID Item/

Function

Failure

Modes

Cause Local

Effect

NHL

Effect

System

Effect

Severity Compensation

1.1.1 Login Illegal

login

Login part

lacks fault

tolerance

design in

hardware and

software;

Withdraw,

deposit,

and query

balance

illegally.

N/A The system

operates

abnormally,

or personal

account is

stolen

High Implement fault

tolerance design in

hardware and

software part.

1.1.2 Login Unable

to login

Hardware

fails; defect

in software

design

Unable to

withdraw,

deposit,

and query

balance.

N/A The system

operates

abnormally

High Make sure hardware

is all right before

operation or could

reject card if does not

work; Add another

validation process

1.1.3 Login Login

delays

Lack of

explanation on

login time in

requirement

Accessing

operation

interface

delays.

N/A The system

operation

delays

Moderate Add clear explanation

on login time in

requirement

… … … … … … … … …

4. SFMEA in Architectural Design Phase

The architectural design phase, which is based on

requirement, describes the system architecture and

functions how to operate. In this phase, activity

diagram or sequence diagram need to be used for

depicting the main use cases, so that the definement of

system structure is clearer and concreter than the

former phase. And performing SFMEA will detect

more potential failure modes so that it could reduce

more risk. Now our approach will be illustrated by

means of the activity diagram for “login” use case.

As is shown in Figure 3, the “login” use case has

been divided into a sequence of activities, such as

“insert card”, ”validate card”, ”input password”,

“validate password”, etc, and all of them are in the

same level. So the activity level could be the analysis

level, and each activity can be regarded as an analysis

item since it represents an individual function.

Figure 3 “Login” Activity Diagram

459459458458458

The parts of logical decision and concurrent in

software, which are represented by the symbols

“branch” and “fork” in activity diagrams, are usually

easy to fail. Hence more attentions should be paid to

these two parts in generating SFMEA. In addition, the

failure modes at this level concern about not only each

item’s behavior, but also the relationships between

behavior and its inputs and outputs, and relationships

with other items, mainly generated from the analyst’s

experiences and acquaintance with the object under

analysis.

Take the item “validate card” related to a branch

symbol for example. Considering the behavior process

itself, it has three common failure modes like “unable

to validate card”, ” validate card illegally”, and

“validation delays”, similar to the ones in requirement

analysis phase; With regard to input, there are such

failure modes as “receive a wrong card”, “the valid

card is swallowed abnormally”, etc; Similarly, in terms

of output, there are such failure modes as “validate

successfully but cannot access the password interface”,

“the invalid card cannot exit after validation”, etc. It is

really difficult to cover all failure modes, but the more

we detect, the less risk the system will confront with.

The local failure effect could be identified by the

direction to the arrowhead points. The NHL effect and

system effect could be established from the use case

diagram, which is very similar to the method used in

former phase. Finally, a FMEA worksheet for the

“validate card” activity based on Figure 3 and Figure 1

is shown in Table 2.

Table 2 Worksheet in Architectural Design Phase

ID Item/

Function

Failure

Modes

Cause Local

Effect

NHL

Effect

System

Effect

Severity Compensation

2.1.1 validate

card

Unable to

validate card

Lack of fault

tolerance

design in

hardware and

software;

network fault

Access the

password

validation

interface

illegally.

Login

illegally

Refer to

ID1.1.1

High

Implement fault

tolerance design in

hardware and

software part of

card validation;

check network

transmission

normal

2.1.2 validate

card

Validate

card

illegally

Hardware

fails; defect

in software

design

Unable to

access the

password

validation

interface

Unable

to login

Refer to

ID1.1.2

High

Refer to ID 1.1.2

2.1.3 validate

card

Validation

delays

Network fault;

the amount of

visiting goes

beyond the

limits

Delay to

access the

password

validation

interface

Login

delays

Refer to

ID1.1.3

Moderate Check network

transmission

normal; Add clear

explanation on the

amount of visiting

in design

2.1.4 validate

card

Receive a

wrong card

Lack of

another

verifying

process before

validate; the

hardware part

fails

Might access

the password

validation

interface

illegally;

Refer to

ID2.1.1

Refer to

ID1.1.1

Moderate Add another

verifying process

for initial check;

Implement fault

tolerance design in

hardware.

2.1.5 validate

card

The valid

card is

swallowed

abnormally

Defect in

validation part

design such as

lacking the

times of input,

or logic

confusion

Unable to

access the

password

validation

interface

Refer to

ID2.1.2

Refer to

ID1.1.2

High

Modify the

weakness, enhance

validation part

design

460460459459459

2.1.6 validate

card

Validate

successfully

but cannot

access the

password

interface

Defect in GUI

part design;

the display

screen fault

Unable to

access the

password

validation

interface

Unable

to login

or login

delays

Refer to

ID1.1.2/

ID1.1.3

Moderate Enhance GUI part

design; check

display screen to

work normally

2.1.7 validate

card

The invalid

card cannot

exit after

validation

Logic

confusion in

validation part

design; the

“reject card”

hardware fault

Might access

the password

validation

interface

illegally

Refer to

ID2.1.1

Refer to

ID1.1.1

Moderate Enhance validation

part design; check

“reject card”

hardware to work

normally

… … … … … … … … …

Therefore, the method based on UML to generate

software FMEA during the architectural design phase

is that:

� Analysis basis: activity diagram, use case

diagram;

� Analysis item: activity;

� Analysis step: make use of activity diagram to

identify analysis level, items and to trace the local

effect; make use of use case diagram to trace the NHL

effect and system effect.

It must be admitted that completing an accurate,

complete and effective SFMEA worksheet does not

only depend on how sufficient experiences an analyst

has, but also needs the analyst to communicate

necessarily with the developers and experts, repeatly

modify and confirm the result.

5. Conclusion and Prospect

Via the application of our method to OO software

requirement analysis phase and architectural design

phase, we could make more affirmations about the

benefits brought by UML-based SFMEA:

� Convenient — the analyst don’t need to

partition the program into functions, since the analysis

items are defined by the use case diagram in

requirement analysis phase and the activity diagram in

architectural design phase;

� Unique — the dynamic diagrams such as

activity diagrams and sequence diagrams (although not

be introduced yet) could reveal the sequence or other

relationships among items, which aid the analysts to

trace the failure effects;

� Complete — the requirements are covered

with use case diagrams and the use case diagrams are

divided into activity diagrams, which assure the

analysis results complete.

There is still much work to do in the future,

although our researches seem to be encouraging. We

are continuing with this research by applying SFMEA

to the sequence diagrams and class diagrams in the

detail design phase and the implementation phase. Of

course our ultimate goal is to establish a set of

comprehensive and in-depth SFMEA approaches

applicable to the whole OO software development

process.

References [1] Song Bo, Liu Jie, UML based OO Technology and

Practice [M], Science Press, 2005,10

[2] Nathaniel Ozarin. Failure Modes and Effects Analysis

during Design of Computer Software [J]. IEEE, 2004:

201-206

[3] Herbert Hecht, Xuegao An, Myron Hecht. Computer

Aided Software FMEA for Unified Modeling Language

Based Software [J]. IEEE, 2004: 243-248

[4] Bowles, J.B., The new SAE FMECA standard.

Proceedings Annual Reliability and Maintainability

Symposium [C], 1998: 48–53.

[5] Li Fang, Huang Xizi, Software Failure Modes and

Effect Analysis Method [J], UESTC, 1998

[6] Haapanen Pentti, Helminen Atte, Failure modes and

effects analysis of software based automation systems

[C], STUK-YTO-TR 190, 2002.8

[7] Peter L.Goddard. Software FMEA Techniques [J].

Reliability and Maintainability Symposium. Jan.2000:

118-123

[8] Lutz, R.R., Woodhouse, R.M. Contributions of SFMEA

to Requirements Analysis [J]. Proceedings of the

Second International Conference. April 1996: 44 – 51

461461460460460