� � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

Abstract — Assessment of reliability using characteristics

of software development process phases is one of thediscussions which has been attracting more and moreattentions during the recent three decades. Most of thetechniques and models use the result of design,implementation and test phases; there are only a few modelsthat are employed at the early phase of software development.Assessment of software reliability in the early phases ofsoftware development process, however, is very important forbetter prognosis and management of risks. In this paper wepropose an approach for early software reliability assessment,based on software behavioral requirements. The majordifference between our approach and those of others is thefact that we use a formal method, called Viewcharts, tospecify the behavior of software systems.

Keywords — Software reliability models, Formal methods,Requirements specification.

I. INTRODUCTION

ELIABILITY is one of the major factors of softwarequality and is defined as the “probability of failure-

free software operation for a specified period of time in aspecified environment” [1]. Based on this definition, ifQ(t) is the probability of failures during time (0,t], thensoftware reliability is measured as follows:

Q(t)-1=R(t) (1)

Using this definition, for an accurate software reliabilitymeasurement, the behavior of software (at the failureoccurrence viewpoint) must be studied. Some of thesoftware reliability models of this kind, look at a system asa complete and functioning entity and study the behaviorof it; this is called the black box models, such as most ofthe approaches that are based on NHPP [3], [4]. Someother models try to take into account the softwarecomponents interaction to its reliability measurement;these are called whit box models [6], [7], [12], [13]. Mostof the models in both categories need test data andtherefore, cannot be employed at the early phases ofsoftware development (i.e., requirement phase).

In large-scale and complex systems, validation andverification of software requirements are important issues.Statistically speaking, 80% of all the defects in software

systems are inserted during the requirements phase [1]; anymodification and change in user requirements may causemanipulation of up to 95% of the system at themaintenance phase. It is necessary, therefore, to asses andimprove the reliability of software systems at therequirement phase. On the other hand, there exist only afew research activities on the reliability assessment andimprovement at the requirement stage. For earlymeasurement of software reliability we need to specify thesystem using some formal description technique and studythe probability of its failure states [5].

In this paper we use a formal method, called Viewcharts[1], for software system behavioral description. Viewchartsis designed for specifying the behavior of a system atrequirement phase and, therefore, it can be used as astarting point for early software reliability assessment. Wedescribe this method with two examples, demonstrating itsapplicability for assessment of software reliability. First,we make some minor modifications to Viewcharts, makingit suitable for our purpose. Then we show the way in whichsoftware reliability can be measured, using Viewcharts, atthe requirements specification phase of software systems.

A. Terminology

We use the term software behavior (or system behavior)to describe the interaction of a system and its environment.This interaction may get triggered by either external eventsor internal actions. In our model the software behavior isrepresented by states which are active at the specialmoment. The notation early software reliabilityassessment, in this paper it is equal to measurement ofreliability at the requirement phase. The state notationhave different concepts in the several models (e.g., some ofthe system components which active at the specific pointof time [6]). In our model a state is a high level conceptand it shows a specific operation of system. Note that astate may have sub-states, forming a hierarchy of states, asit is the case for views at the higher levels.

B. The Problem and Solution Characteristics

The problem we address in this paper is to discoverwhether there can be a practical and useful approach toearly analysis and assessment of software reliability. Asolution to this problem is to pick (and if necessarymodify) an existing software reliability model, or introducea new one, with the following specific characteristics:

1. Applicability at the requirement phase: The model

Software Reliability Assessment Based on aFormal Requirements Specification

R

Hooshmand Alipour†, and Ayaz Isazadeh‡†Islamic Azad University-Pars abad Moghan, Pars abad, Iran

halipour@iaupmogan.ac.ir,‡Department of Computer science, Tabriz University, Tabriz, Iran

Isazadeh@TabrizU.AC.Ir

1-4244-1543-8/08/$25.00 ©2008 IEEE

must work and produce result at the requirementphase of the software development life cycle toprovide early reliability assessment.

2. Independency from real failure data: This data isobtained at the test phase, whereas our goal isassessment of software reliability at the requirementstage. Our model should be real failure dataindependent. The later papers make use of errorstatistics obtained during the technical review ofrequirements to software reliability early prediction.

3. Flexibility with respect to requirement changes:When the software requirement is changed, thereliability model should recalculate the reliabilitywith minimum cost.

4. Formality: The model should be based on a formalsoftware behavioral specification method. If thereliability model has formal foundation forrepresentation and analysis of software behavior,then the measured reliability value is realistic.

5. Clarity with respect to reasoning and deduction:The model must follow a white box approach, as it isthe case with most of ongoing work on softwarereliability modeling.

First two characteristics are necessary for such modeland next characteristics powered it. We claim that such asolution does exist. And in this paper, we will present aformal software reliability model, satisfying thecharacteristics sated above.

C. Paper Outline

This paper is organized in four sections. In this sectionwe stated the problem and provided a list of specificcharacteristics of our solution. Section2 presents therelated work on the problem. In this section we present anoverview of the Viewcharts, as the basis of our work.Section3 describes our approach, the way in which thebehavior of a system is represented using Markov chainand a modified version of Viewcharts and analyzed toassess software reliability. An example is also provideddemonstrating the approach. Section4 concludes the paperwith the results and some topics of future work.

II. RELATED WORK

As we mentioned earlier, because of lack of failure datain the early phases of software development, it is a difficultwork to predict the software reliability in the early stages.So there are just a few attempts, addressing the concept ofearly software reliability assessment or prediction. Gaffneyand Davis [9] developed the phase-based model. It makesuse of error statistics obtained during the technical reviewof requirements, design and the implementation to predictthe reliability during test and operation. This modelexpects that fault densities will be expressed in terms ofthe number of faults per thousand lines of source code(KSLOC), which means that faults found during therequirements analysis and software design will have to benormalized by the code size estimates. Another wellknown work in this field initiated by RADC [10]. Toprediction of software reliability in the early phases of

software lifecycle, the researchers applied some softwaredevelopment metrics which they felt affect to the reliabilityto obtain the initial fault density, which could then betransformed into other reliability measures. These metricsconsist of application type (e.g., scientific, real-timecontrol system), development environment (includedevelopment methodology and available tools),requirement and design representation metrics (includeanomaly management, traceability and incorporation ofquality results into the software) and implementationmetrics (e.g., language type, program size, modularity andso on). On the other hand there are some researches whichuse the output of design (directly or indirectly) toreliability assessment. Both of architecture-based [6], [7],[12], [13] and structure-based [14], [15] models are asmentioned models. Architecture-based and structure-basedmodels are similar. These models seek to assess tobehavior of software application taking into considerationthe behavior of its parts (components) and the interactionbetween its parts. Most of these models are dependent tothe real failure data obtained in the test phase. Since ourmodel assesses the software reliability by taking intoconsideration the software behavior, it is like to thearchitecture and structure based models. But our modeltries to assess the software reliability in the requirementphase. We believe that our model is more accurate than thesimilar models (used in the requirement phase), because itstudies the software behavior based on a formal softwarerequirement specification language.

A. Representation of a System States Using MarkovChain

In this section we describe Markov chain, a method usedfor architecture based reliability assessment [6], but wewill use it to assessment of software reliability in the earlyphase of its life cycle. A Markov chain is defined asfollows:

1. A finite set of n states S = {s1, . . . ,sn} that si denote astate of the system.

2. ji ,λ is the transition average rate of state si, to sj.

Showing system with Markov chain for older andhomogeneous systems is a simple task. But today most ofthe systems are complicated and heterogeneous (like clientserver systems). So, showing the behavior of these systemswith traditional method is very difficult and if we makesome modification in system then updating those modelswill be difficult. Another Markov chain's constraint is thatthe next component to be executed will only depend on thepresent component [7]. For decreasing these difficultiesand for showing the behavior of complicated systems witha simple method we decided to use a model, calledViewcharts. Viewcharts try to specify a system in terms ofthe different views of the system. Composition of theseviews forms the behavioral specification of the wholesystem. In the next section we provide a description ofViewcharts briefly. For more details refer to [1].

B. Representation of a system behavior using Viewcharts

A Behavioral view of a software system is the behavior

312

of the system observable from a specific point of view. Aclient's view of a server, for example, is the behavior thatthe client expects from the server. This behavior, ofcourse, may differ from the behavior that the serverexhibits to another client. A server, therefore, may haveseveral behavioral views. The caller view of a telephoneset and the telephone set's view of a switching system arealso examples of behavioral views. The Viewchartsnotation is based on Statecharts [8]. Statecharts, however,has no concept of behavioral views. Viewcharts extendsStatecharts to include views and their compositions.Statecharts is often criticized for not being practical forlarge-scale systems specifications. Specifically, the issue ofscale in Statecharts leads to the following problems:

1. Explosion of States: In conventional finite statemachines the number of states grows exponentially asthe scale of the system grows linearly. Statechartsreduces this blow-up, but for a large-scale system thisis still a problem.

2. Global Name Space: All names, in Statecharts, aredefined globally. A given event, for example, can besensed throughout the system and, therefore, it musthave a unique name. Managing the name space isdifficult in large-scale systems.

Viewcharts attempts to eliminate these problems.A viewchart consists of composition of views. The

leaves of the hierarchy, described by independentstatecharts, represent the behavioral views of the system orits components. The higher levels of the hierarchy arecomposed of the lower level views. Views are representedjust like states, except that the arc-boxes representingviews have thicker borders than those of states.

Notice that the statecharts describing views, in aviewchart, are independent. In other words, the scope ofbroadcast communications of Statecharts is limited to theviews and does not cover the entire viewchart.

Notice also that a statechart describing a view, in aviewchart, describes only a behavioral view of the systemor, more importantly, its component. In other words, thenumber of states and the size of such a statechart areaffected only by the scale of the behavioral view.Consequently, considering that a large-scale systembehavior can be described in terms of simple behavioralviews, Viewcharts is expected to eliminate the issue ofscale.1) Ownership of Elements

The Viewcharts notation limits the scope of broadcastcommunications. In other words, the scope of an element(event, action, or variable) in a given view is limited to theview. On the other hand, composition of views may requirecommunication between the composing views; the scope ofan event in one view, for example, may be extended tocover other views. In a given view, therefore, Viewchartsmust distinguish two different types of events:

1. Events that belong to the view: These are the eventsthat the view can trigger. They must be declared bythe view.

2. Events that do not belong to the view: The viewcannot trigger these events. An event of this type can

occur only if it is triggered elsewhere and if the viewis covered by the scope of the event.

An event may have multiple owners; in other words anevent can be triggered by more than one view. An eventmay also have no owner, in which case the event can neveroccur. The Viewcharts notation allows this case, becauseof the possibility of further composition of the viewchartwith additional views, which may affect the event. This isexactly analogous to the notion of free variables inprogram fragments, which can be bound in a largercontext.

The notion of ownership for events is a naturalconsequence of composing views, while the scopes ofevents are limited. This notion also applies for actions.However, actions are implicitly declared: an action belongsto the view (or views) that generates (or generate) theaction. There is no need, therefore, for explicit declarationof actions. However, an action may also be owned as anevent by some other views, in which case it must bedeclared accordingly. Viewcharts determines the affect ofeach event occurrence based on the ownership and scopingrules. However, an event occurrence may still be specifiedby its full name, provided that it does not violate theserules. Consequently, unlike events and actions, variablescannot have multiple owners. On the other hand, if avariable is used in a view, but not declared by the view orany of its superviews (i.e., it has no owner), then thevariable, by default, belongs to the top view of thecorresponding viewchart.

In a viewchart, if the triggering view of an element isobvious and there is no ambiguity in the ownership of theelement, then there is no need for explicit declaration ofthe element.2) Composing Behavioral ViewsViews can be composed in three ways: SEPARATE, OR,and AND compositions.

1. SEPARATE Composition of Views: In aSEPARATE composition of views, all the views areactive (A view is active if, and for a period of timeduring which, the system is in a state of the view); notransition between the views is allowed, the scopes ofall the elements are unaffected; and any subview orstate in one view is hidden from (i.e., cannot bereferenced by) the other views. No view is, in fact,aware of any other view in the composition. Visually,the views involved in a SEPARATE composition aredrawn on the top of each other. Fig. 1 illustratesSEPARATE composition of V1 and V2.

2. OR Composition of Views: The OR andSEPARATE compositions are similar, except that inan OR composition, only one view can be active andthere can be transitions between the views. Fig. 2consist of OR composition of V1 and V2.

3. AND composition of Views: In an AND compositionof views, all the views are active; the scopes of allthe elements owned by each view are extended to theother views. All the subviews and states in one vieware visible to (i.e., can be referenced by) the otherviews; variables, however, must be referenced by

313

their full names. The view V1 of Fig. 3 is anded withview V2.

Fig. 1. SEPARATE composition

Fig. 2. OR composition

Fig. 3. AND composition

3) E-Commerce system, an example for Application ofViewcharts

Now, for showing of Viewcharts applicability, we try tospecify a simple e-commerce system by Viewcharts. Whena user goes to the e-commerce site the system exhibits theproducts. By this system a user can select some productsand submit his or her order. The system checks the orderof user to validate existing of selected products. If the userorder is valid then server sends an ok message to the client;otherwise, server sends the respective problem messageand client shows it. When the user order is valid then he orshe gives his or her credit card specifications and submitthem. The server side of system checks the user bankaccount and if there is no problem then sends an okmessage to the client side; otherwise, the client shows theproblem message to the user. Finally the purchasedproducts are showed. The server contains two parts (views)which are dependent together. V1 checks the order validityand V2 checks the user bank account. Fig. 4 illustrates theViewcharts specification of this system.

III. ASSESSMENT OF SOFTWARE RELIABILITY USING

VIEWCHARTS

In this section we present our approach to softwarereliability assessment using formal software behavioralrequirements specification represented by Viewcharts. But,

first we need to make a modification to Viewcharts.

A. Modified Viewcharts

Basically, Viewcharts is a model for description ofsystem in early phases of development. For using itsbenefits for showing states of system and then assessmentof software reliability we need to add the concepts ofMarkov chain to it. Therefore, in each view instead ofstatechart we use Markov chain.

For applying these modifications, we first drawViewcharts specification of system and then add rate ofeach transition on its arc. Fig. 5 illustrates the modifiedViewcharts for e-commerce system.

In this model, for each view we fined probable eventswhich if they occur then the system configuration will befalse (fault will occur). According to these events one ormore state(s) is (are) specified to each view. These statesare called fault states. So if a faulty event occurs in thespecific view then the fault states will be active. Anotherissue in this model is finding the rate of system statestransition. For this purpose we defined a method andapplied it to our model. According to this method, aprototype of system is made based on its viewchartspecification. The second step is drawing the system usecase diagram and determining its operational profile. Atthe next step, according to the use cases, and the systemoperational profile some system inputs (include values andexternal events) is selected randomly and the systemprototype is ran with these inputs. When the system'sprototype is executing, its states should be determine in theviewchart specification. Finally the rate of all transitionsmust record during the system's prototype execution.

B. Reliability of system

According to description in previous section, supposeFig.6 is the modified Viewcharts for e-commerce system.The Client Fault State(CFS), Server Fault State1(SFS1)and Server Fault State2(SFS2) are three fault states whichare considered for the Client, V1 and V2 views. If we canobtain probability of fault states then reliability of systemcould be calculated as follow:

( ) ( ) ( )( )SFS2SFS1CFS1 probprobprobR ∪∪−= (2)

For computation of system fault states probability wemust use Markov chain conservation low for each view.For example in V1, suppose P1= prob(CF), P2=prob(Readyto Receive Request), P3=prob(Receiving),P4=prob(Processing Order Validation), P5=prob(Wait) andP6=prob(Sending Problem Message) then the conservationlow is as follows:

( )( )

( )����

�

����

�

�

=+=

=++=+

++=++=

46687

4559

334654

21331

110685921

674432110

pp

pp

pp

pp

pppp

pppp

µµµµµ

µµµµµµµ

µµµµµµµµ

(3)

A B M

V1 V2

a

b

m

n

c

c

V1, V2

V1A B

a

b

A Ba

bV2

N

314

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�������

���� �

������

������

����� �

�������

�������

���������

���� �����

����� ���� � ����������

���������

������

�������

�������

��� ���

��������� ���

������

��� ���

��������� ���

�������

�������

���������

������

�������

�������

�������

���� �!

�������

���������

��� ���

��������� ���

������

������ �

� �

"� ���

������

�������

��������

������ ���

������

������ �

����� ��

� � ����������

����� ��

� � ����������

������

������ �

����� ��

� � ����������

���������

������ ���

������

������ �

#$��

"������

���� ���� ������

����� �

�������

������

���������

������

%��

������

������

�������

���������

#�

&���� ���

� �

���������

���������

������ ���������

������ �#$

���������� �

"� ����������

�������

"������

������

������ �

����� �

�������

������

���������

��� ���

��������� ���

� ���'�

������

������

�������

���������

��� ���

&���� ���

� �

��������

���������

������ ���

#$

���������� �

���������

��������������

#(

������

������ �

������

������ �

����� )������ ����� *������ *�������������� �*

� � �"� ������������������*�#$*�� � ����������*����� ���� ������� ����

&+)�� � ����������*����������������� �*�#$*�������*�"������*

������������� �

,-��������

�����

����

&.)�� � ����������*����������������� �*�#$*�������*�������

������ �*�#(

,-��������)������ �/(0������������������)�&+��,�/�/�,�&.

#$��

#(

� �

���������

������

�������

Fig. 4. Viewchart specification of e-commerce system

1λ2λ

3λ4λ

5λ

6λ

7λ

8λ

9λ

10λ

11λ

12λ13λ

14λ15λ

1µ

2µ3µ

4µ

5µ

6µ7µ

8µ9µ

2ρ3ρ

4ρ

5ρ

6ρ7ρ

8ρ

9ρ

1ρ

17λ 18λ

19λ

20λ

10µ

10ρ

16λ

Fig. 5. Modified viewchart for e-commerce system

ServerFault

State 2ShowingProblem andCredit CardSpecification

315

After solving of Eq. 3, p1 will be obtained. For obtainingprob(CFS) and prob(SFS2) we can use the conservationlow for Client and V2 views. Finally the system reliabilitywill be measured by Eq. 2.

IV. CONCLUSION

We have introduced a new approach for representing thebehavior of software systems and using it for earlysoftware reliability assessment. Our approach combinestwo methods, Markov chain and Viewcharts, and showsthe states of system. The Viewcharts method has the abilityto specify heterogeneous and complex systems easily. Onthe other hand, for adding the rate of system's transition,from a state to another one, we have used Markov chain.We also predicated some states for showing systemfailures and added these states to our model. Consequently,we have provided an early assessment of the softwaresystem reliability as the union of failure states probability.

A. Demonstration of the claim

We now return to Section I.B, where we defined theproblem addressed by this paper. Recall that our proposedsolution is characterized as an approach, satisfying a list ofsome specific characteristics.

1. Regarding the first characteristic of the solution, ourapproach is design to work and produce result at therequirement phase of the software development.

2. We used only the software requirement specification,represented by Viewcharts, for early softwarereliability assessment and real failure data are notneeded. This satisfies the second characteristic of thesolution.

3. Viewcharts uses divide and conquer approach tospecify system requirement. Limitation of eventsscope in the Viewcharts methodology provides theflexibility we require. Requirement changes andmodification, therefore do not affect all of thesystem, and so the third characteristic is satisfied.

4. Viewchart is a formal method and provides theformality we need, satisfying the fourthcharacteristic.

5. Our model studies the system behavior internally and,therefore, it is a white box approach, satisfying thefifth characteristic of the solution.

B. Discussion and Comparison

Since our model assesses the software reliability bytaking into consideration the software behavior, it is like tothe architecture and structure based models. But our modeltries to predict the software reliability in the requirementphase. Our model is more accurate than similar models,this accuracy emanate from Viewcharts. The similar workssuch as [9] and [10] do not use software requirementspecification to reliability prediction. Some of the softwarerequirements and design representation metrics used in[10] consist of anomaly management, traceability andincorporation of quality results into the software. Unlikeour work, these metrics are not obtained formally and the

accuracy of them is not tenable.

C. Future Topics of Research

The method we presented in this paper sets the stageready for the following topics of future research: (1)Entering the time parameter to the software reliabilityassessment in the requirement phase. As we mentionedearlier we want to perform this work by using theModchart notation [16] in stead of Viewcharts. Modchartis designed to the real-time systems, but we believe that itcan be useful for reliability assessment of all softwaresystems. (2) Implementation of Viewchart to obtain therate of transition between states of system automatically.

REFERENCES

[1] A. Isazadeh, D. A. Lamb, and T. Shepard, “Behavioral views forsoftware requirements engineering,” Requirements EngineeringJournal, Vol. 4, No. 1, pp. 19–37, 1999.

[2] Standard Glossary of Software Engineering Terminology, STD-729-1991, 1991; ANSI/IEEE.

[3] S. Yamada, M. Ohba, and S. Osaki, “S-shaped reliability growthmodeling for software error detection,” IEEE Trans.on Reliability,R-32(5), pp. 475–485, December 1983.

[4] H. Pham and X. Zhang, “An NHPP software reliability model andits comparison,” Int. J. Reliability, Quality Safety Eng., vol. 4, no.3, pp. 269–282, 1997.

[5] Meng-Lai Yin, Craig L. Hyde and Larry E. James, “A Petri-Netapproach for earl-Stage system-Level software reliabilityestimation,” proceedings Annual reliability and maintainabilitySymposium, IEEE 2000.

[6] Wen-Li Wang, Dai Pan and Mei-Hwa Chen, “Architecture-basedsoftware reliability modeling,” The Journal of Systems andSoftware 79 (2006) pp. 132–146, 2006

[7] Wen-Li Wang and Mei-Hwa Chen, “Heterogeneous softwarereliability modeling,” Proceedings of the 13th InternationalSymposium on Software Reliability Engineering (ISSRE’02) IEEE2002.

[8] D. Harel, “Statecharts: A visual formalism for complex systems,”Science of Computer Programming, pp. 231-274, 1987.

[9] J. E. Gaffney Jr., and C. F. Davis, “An approach to estimatingsoftware errors and availability,” SPC-TR-88–007, version 1.0,March 1988a. Proceedings of the 11th Minnowbrook Workshop onSoftware Reliability, July 1988.

[10] McCall J., Rome Laboratory (RL), “Methodology for softwarereliability prediction and assessment,” Technical Report RL-TR-pp.92-52, volumes 1 and2. 1992.

[11] Somo Banerjee, Leslie Cheung, Leana Golubchik NenadMedvidovic, Roshanak Roshandel and Gaurav Sukhatme,“Engineering reliability into hybrid systems via rich design Models:Recent results and current directions,” In Proceedings of the NSFNext Generation Software Program (NSFNGS) Workshop, RhodesIsland, Greece April 25-26, 2006.

[12] Gokhale S. S., Wong W. E., Trivedi K. S., and Horgan J.R., “Ananalytical approach to architecture-based software reliabilityprediction,” In Proceedings of IEEE International ComputerPerformance and Dependability Symposium (IPDS), Durham,North Carolina, September 1998.

[13] Wen-Li Wang and Dan Scannell, “An architecture- based softwarereliability modeling tool and its support for teaching,” Proceedingsof the 35th ASEE/IEEE Frontiers in Education Conference,October 2005.

[14] Gokhale SS and Lyu MR, “A simulation approach to structure-based software reliability analysis,” IEEE Trans Software Eng, vol31, no 8, pp. 643–656, 2005.

[15] S. Gokhale and K. Trivedi, “Structure-based software reliabilityprediction,” In Proceedings of the Fifth International Conference onAdvanced Computing (ADCOMP’97), pp. 447–452, 1997.

[16] F. Jahanian and A. K. Mok, “Modechart: A specification languagefor real-time systems,” IEEE Transactions on SoftwareEngineering, 20(12), pp. 933-947, December1994.

316