Dependability Reqmts

7/29/2019 Dependability Reqmts

1/7

Issues in Defining, Analyzing, Refining, and Specifying System

Dependability Requirements

Bonnie Melhart Stephanie WhiteTexas Christian University Long Island Universityemail: [email protected] email: [email protected]

Abstract

Requirements specification has long been acknowledgedas an area for further research in the development ofsystems, particularly for those that are computer based. Inaddition, an IEEE White Paper by Tripp and Keaneindicates that current practice regarding SystemDependability is in large part based on tricks of thetrade, and that there is a need to codify best practices.This paper attempts to codify the practice for specifyingdependability requirements, by classifying and describingthe process and product requirements needed for suchspecification.

1. Introduction

A dependable system is one that does not fail in anunexpected or catastrophic way. This simple, intuitivedefinition belies the difficulty with specifying exactlywhat properties such a system must have and how thesecan be ensured. Often the dependability of the ultimatesystem is determined by the quality of the analysisperformed at the requirements stage. To improverequirements engineering, a taxonomy was developed fordefining, analyzing, refining, and specifying requirements[1]. The taxonomy consists of a structure, definitions,templates, examples, and keywords for requirementsretrieval. The purpose of the taxonomy is to increase theintegrity of requirements: their consistency, completeness,

and correctness. This paper extends the taxonomy, whichheretofore addressed only functional requirements, toinclude dependability requirements

1.

Dependability is a system property. Acceptablethresholds for system dependability are defined in therequirements (for example, acceptable mean time torepair). So is the required functionality (for example,

5 H V H D U F K Z D V I X Q G H G E \ 1 D Y D O 6 X U I D F H : D U I D U H & H Q W H U D Q G W K H 2 I I L F H

R I 1 D Y D O 5 H V H D U F K

recovery functions) that ensures the desired dependabilityin the final product. Process requirements are alsospecified, either in the requirements document, thestatement of work, or a dependability plan. Such a plan

addresses the use of dependability techniques throughoutsystem development, such as (1) fault removal, (2) datacollection, and (3) measuring the level of dependability.Developers must collect data for such measurementsthroughout the system life cycle. For example, earlypredictions of the number of faults that remain in thesystem are based on data about fault removal duringdevelopment. Such predictions allow systems engineeringtradeoffs concerning technologies for later development.

Required dependability levels are actually measurednear the end of or after development. That is a primarygoal of testing, which consumes a large part of thedevelopment and maintenance budget. When the systemis not dependable, test, repair and retest become

exorbitant. The direct costs of software unreliability, inparticular, are substantial, let alone the indirect costs [2].Information that defines what should be measured isdefined in the requirements. Thus, if requirementsspecification is improved, costs should be significantly

reduced.

2. Dependability Terms

Many terms are related to or a part of dependabilitydiscussions. Some definitions are given here.

Dependability measures the degree to which a systemis operable at any random time during a specified missionprofile, given that its services are available at the start ofthe mission [3]. Tripp and Keene have called this fitnessfor use [4]. Dependability is not one measure, but acollection of related measures that includes reliability andavailability, and often safety and security. It may includemaintainability, usability, and extendibility [5].


2/7

Survivability from information warfare2

is a recentaddition to the list of dependability measures. Table 1identifies facets commonly associated with the most

commonly used dependability measures.

Table 1. Dependability measures and related

facets

Reliability Avail-

ability

Security Safety Surviv-

ability

MTBF

Probabilityof failure

Probabilityof Success

Zerodefects

MTTR

Probabilityof beingoperational

Down time

Mainten-ance

Informationintegrity

Confident-iality

Authentica-tion

AccessControl

Unsafestates

Fail safe

Life critical

Propertycritical

Vulnerabil-ity

Protection

Intrusiondetection

React toattack

Reliability, R, is the probability that the systemperforms its required functions under specifiedenvironmental conditions for a specified period of time, t[2]

3. Reliability is concerned with departures of any kind

from the specifically required service. It is assumed thatthe system is functioning at the start of the time interval,

R(0) = 1, and that the system will fail sometime, R(B ) =0. The expected environmental conditions may bespecified in a mission or operational profile.

Availability addresses the ability of the system toprovide service at any given time. It is the probability ofbeing operational, under given use conditions, at a giveninstant in time [5].

Safety is the ability of a system to deliver serviceunder given conditions with no catastrophic affect. Thisabsolute definition implies no grace period or marginfor safety; the requirements specify how close the systemmust come to this ideal [7]. Safety attributes mean thesystem will include requirements to detect and avoidcatastrophic failures. Security is the ability of a system todeliver its required service under given conditions for agiven time without unauthorized disclosure or alterationof sensitive information, or denial of service to legitimateusers by unauthorized persons [5]. The security attributeadds requirements to the system to detect and avoidintentional faults. Survivability is the capability of asystem to accomplish its mission despite a man-made

hostile environment; i.e., the power of the system to detectand withstand an attack. Survivability of Computer BasedSystems (CBSs) is gaining attention because of recent

3 D Q G D D Q G * L R U G D Q R G H I L Q H , Q I R U P D W L R Q : D U I D U H W R E H D Q \ P D O L F L R X V

D W W D F N D J D L Q V W D Q R U J D Q L ] D W L R Q V L Q I R U P D W L R Q E D V H W K U R X J K H O H F W U R Q L F

P H D Q V > @

$ V S R L Q W H G R X W E \ 0 H O O R U W K L V W U D G L W L R Q D O G H I L Q L W L R Q H [ F O X G H V W K H F O D V V

R I I D L O X U H V L Q Z K L F K W K H V S H F L I L F D W L R Q L V Z U R Q J R U G R H V Q R W H [ L V W > @

attacks on computers and communications channels andconcern about Information Warfare. Though often relatedto dependability, these last three measures are not directlyincluded in the dependability discussion here. A completetreatment of requirements for these three attributes isbeyond the scope of this work.

Measures used for dependability incorporate the

terms, fault, error, and failure. From a systemsperspective, afaultis a condition that is thought to be thecause of an error. An erroris that part of a system statewhich is liable to lead to a failure for the system. Afailure is any deviation from the specified behavior [8].

The Mean Time to Failure (MTTF) measure isfrequently used for system reliability. The MTTF alongwith the maintenance time, Mean Time to Repair (MTTR)can be used to calculate availability as

0775077)

077)

.

Note that this simple model makes assumptions about shutdown and constant failure and repair rates that may beinappropriate. In particular, software components usuallyhave negligible MTTR, since repairs do not require theprogram to be idle unless the failure is critical to life orproperty. For software systems, the MTTR may beweighted by the failure intensity for a more realistic andusable measure of availability.

Failure intensity measures the frequency at whichfailures occur. It is the number of failures per some unitof measure [9,10]. The measurement unit is usuallyexecution time, but may be something else like thenumber of transactions, number of runs, etc. This failurerate must address all system failures: those due to primarydefects, manufacturing defects, operator errors, wear-out,

along with dependent failure, maintenance inducedfailure, and equipment damage rates. The number offaults in the system and the evaluation environment affectfailure intensity; i.e., the measurement must reflect properuse so it gives a fair indication of the actual reliability ofthe system. The failure intensity, i, at time, t, is related to

the reliability:R(t) = e-it

.Robustness and fault-tolerance are important

properties that affect system dependability. Robustnessimplies that frequently occurring errors have little effecton the system. A fault-tolerantsystem is desirable whenthe system must recognize a potential failure and takeaction to avoid it. This implies at least some redundancybuilt into the system to check results [2].

3. Types of Dependability Requirements

Dependability requirements address measurement andaccompanying performance thresholds for the product,and the process by which those measurements areaccomplished. It is important to specify what process willbe used to increase confidence in the product, including


3/7

the collection of data, and then to collect relevant datathroughout development. The latter enhances the abilityto assess dependability in the product.

There are four types of dependability requirements,which address the means for achieving dependability:fault tolerance, fault removal, fault prevention, and faultprediction [8]. Their combined utilization provides the

desired coverage of dependability concerns for both theproduct and the development process. The objectives andmeans for these are often part of a reliability programplan. Table 2 identifies facets associated with these fourcategories of dependability requirements. We addressfault tolerance in the section on Product Requirements,and we address fault prediction, fault prevention, and faultremoval in the section on the Dependability Process.

Table 2. Four categories of dependabilityrequirements, and related facets

Fault

Prediction

Fault

Prevention

Fault

Tolerance

Fault Removal

FMEA/FMECA

Models Redundancy Fault detection

Fault treeanalysis

Prototypes Failuredetection

Inspection

Hazardanalysis

Simulations Failureavoidance

Reviews

Models Informationhiding

Fault recovery Walkthroughs

Measures Low coupling Gracefuldegradation

Failurereporting

Tolerablethreshold

High cohesion Reconfigura-tion

Proof ofcorrectness

Fault/Error/Failure

Reuse Rollback Dynamicanalyses

DataCollection

Traceability N-versionsoftware

Test/Debug/Repair

OperationalProfile

Formalverification

Hot shadow Latent faults

4. Dependability Process

Process requirements describe how dependabilitymust be achieved, and include the means for datacollection and analysis to verify its achievement.

4.1 Fault Removal

Fault removal requirements are process requirements.Such requirements imply the need for fault detection. Inaddition to dynamic analyses of the system such astesting, the required process should include statictechniques such as inspections, reviews, walkthroughs,proofs-of-correctness.

4.2 Fault Prevention

Fault prevention requirements are also processrequirements. In a sense, every good developmentpractice is a fault prevention technique. A constructiveapproach to developing a dependable system dictates thatit be designed and built according to a more dependabledevelopment process. All the process requirements havefault prevention as a goal or sub-goal.

4.3 Fault Prediction

Fault prediction implies process requirements for datacollection so that adequate information is available, andproduct requirements regarding level of achievement. Theinformation to measure the dependability and thus predictnumbers of failures in the future is based on failures andtheir history of occurrence. Requirements indicate whatquantitative measurements will be taken (availability,reliability, etc.); the specific data needed is determined by

the chosen model used for evaluation. To measurereliability the number of observed failures over ameasured period of time, usually execution time (i.e.,actual time that the system is operational) must berecorded.

Failure modes and effects analysis or criticalityanalysis (FMEA/FMECA), fault-tree analysis, and othertechniques may be used to determine the relevant failureevents. Analysis includes determining what faults mayarise in dependent components due to failures of anothercomponent, and what faults within a component may leadto an eventual error state and failure of that componentitself. For example,

) 0 ( $ L G H Q W L I L H V W K H Z D \ V L Q Z K L F K

I D L O X U H V F D Q R F F X U W K H H I I H F W V R I H D F K I D L O X U H R Q W K H V \ V W H P

H O H P H Q W L Q Z K L F K L W R F F X U V S U R E D E O H R Y H U D O O F R Q V H T X H Q F H V

V H Y H U L W \ R I H D F K I D L O X U H P R G H R Q W K H V X F F H V V R I W K H

V \ V W H P D Q G V D I H W \ R I X V L Q J S H U V R Q Q H O D Q G W K H

U H F R P P H Q G H G F R U U H F W L Y H D F W L R Q V S U R F H G X U H V W R U H G X F H W K H

R F F X U U H Q F H R I W K H S R W H Q W L D O I D L O X U H P R G H

Dependability objectives for the given time period ofoperation must be specified. The operational profile thatwill be used to make the measurement must be described., I W K H F R P S O H W H R S H U D W L R Q D O S U R I L O H L V Q R W H V W D E O L V K H G D W W K H

W L P H R I W K H U H T X L U H P H Q W V V S H F L I L F D W L R Q D S U R F H V V

U H T X L U H P H Q W W R G H Y H O R S R Q H P X V W E H L Q F O X G H G 0 X V D L Q

I D F W V X J J H V W V D V H U L H V R I S U R I L O H V O H D G L Q J W R W K H I L Q D O

R S H U D W L R Q D O S U R I L O H & X V W R P H U S U R I L O H 8 V H S U R I L O H 6 \ V W H P

P R G H S U R I L O H ) X Q F W L R Q D O S U R I L O H D Q G 2 S H U D W L R Q D O S U R I L O H

> @

( D U O \ S U R I L O H V P D \ E H G H Y H O R S H G D V S D U W R I W K H

U H T X L U H P H Q W V V S H F L I L F D W L R Q Z L W K D U H T X L U H P H Q W W R F R P S O H W H

W K H I L Q D O S U R I L O H G X U L Q J G H Y H O R S P H Q W $ & X V W R P H U 3 U R I L O H

V S H F L I L H V D O O W K H J U R X S V W K D W Z L O O X V H W K H V \ V W H P D O R Q J Z L W K

W K H S U R S R U W L R Q R I X V H W K H \ U H S U H V H Q W 7 K H 8 V H 3 U R I L O H

U H I L Q H V W K H S U H Y L R X V S U R I L O H L Q W R J U R X S V R I X V H U V Z K H U H

X V H U V L Q W K H V D P H J U R X S H P S O R \ W K H V \ V W H P L Q D V L P L O D U


4/7

Z D \ 7 K H U D W L R R I D J U R X S V X V H U V W R W R W D O X V H U V F D Q E H

X V H G D V W K H S U R E D E L O L W \ R U D S U R S R U W L R Q R I D F W X D O X V H F D Q

E H R E W D L Q H G 6 H F W L R Q K D V P R U H W R V D \ F R Q F H U Q L Q J

R S H U D W L R Q D O S U R I L O H V

3URGXFW'HSHQGDELOLW\5HTXLUHPHQWV

$ S U R G X F W U H T X L U H P H Q W L V D V W D W H P H Q W L Q V R P H Q R W D W L R Q

W K D W G H V F U L E H V R Q H R U P R U H F K D U D F W H U L V W L F V R U S U R S H U W L H V D

V \ V W H P P X V W K D Y H 3 U R G X F W U H T X L U H P H Q W V D U H Q R U P D O O \

F O D V V L I L H G D V F D S D E L O L W L H V R U F R Q V W U D L Q W V , W L V F R P P R Q W R

V X E F O D V V L I \ F R Q V W U D L Q W V D V I R U H [ D P S O H S H U I R U P D Q F H

V H F X U L W \ U H O L D E L O L W \ P D L Q W D L Q D E L O L W \ H W F U H T X L U H P H Q W V

> @ 7 R I X O O \ G H V F U L E H D V \ V W H P V G H S H Q G D E L O L W \

F R Q V W U D L Q W V R Q H P X V W L Q F O X G H G H S H Q G D E L O L W \ R E M H F W L Y H V I R U

W K H V \ V W H P D Q G L W V F R P S R Q H Q W V R S H U D W L R Q D O S U R I L O H V I R U W K H

D E R Y H P H D V X U H P H Q W V S H F L I L F D W L R Q R I I D L O X U H P R G H V D Q G

U H T X L U H P H Q W V D G G U H V V L Q J I D X O W W R O H U D Q F H L Q F O X G L Q J

U H G X Q G D Q W F R P S R Q H Q W V S H F L I L F D W L R Q V D Q G U H F R Y H U \

W H F K Q L T X H V W R E H H P S O R \ H G

' H S H Q G D E L O L W \ 2 E M H F W L Y H V

7 K H S U R G X F W G H S H Q G D E L O L W \ R E M H F W L Y H L V W K H W K U H V K R O G

R I D F F H S W D E L O L W \ D Q G L V G H W H U P L Q H G I U R P W K H G H V L U H I R U

U H O L D E L O L W \ V D I H W \ R U R W K H U G H S H Q G D E L O L W \ D W W U L E X W H W K H

X U J H Q F \ Z L W K Z K L F K W K H S U R G X F W L V Q H H G H G D Q G W K H S U L F H

W K H F X V W R P H U L V Z L O O L Q J W R S D \ 7 K H V H U H T X L U H P H Q W V D U H

L Q L W L D O O \ G H I L Q H G D V S D U W R I W K H F R Q F H S W X D O G H V L J Q Z K L F K L V

X V X D O O \ D Q R X W F R P H R I D G Y D Q F H G G H Y H O R S P H Q W

' H S H Q G D E L O L W \ U H O L D E L O L W \ R E M H F W L Y H V I R U W K H J L Y H Q W L P H

S H U L R G R I R S H U D W L R Q P X V W E H V S H F L I L H G 7 K H R S H U D W L R Q D O

S U R I L O H W K D W Z L O O E H X V H G W R P D N H W K H P H D V X U H P H Q W P X V W E H

G H V F U L E H G

2 S H U D W L R Q D O 3 U R I L O H V

' H S H Q G D E L O L W \ R I W K H S U R G X F W L V P H D V X U H G G X U L Q J

R S H U D W L R Q L Q D G H I L Q H G H Q Y L U R Q P H Q W 6 R W K H G H S H Q G D E L O L W \

U H T X L U H P H Q W V P X V W Q R W R Q O \ V S H F L I \ W K H P H D V X U H P H Q W

S U R F H V V D Q G W R O H U D E O H W K U H V K R O G E X W D O V R V W D W H W K H H [ S H F W H G

R S H U D W L R Q D O F R Q G L W L R Q V 7 K H V H F R Q G L W L R Q V L Q F O X G H

H Q Y L U R Q P H Q W D O I D F W R U V H J W H P S H U D W X U H F \ F O H V K X P L G L W \

Y L E U D W L R Q V K R F N V D Q G K H D W J H R J U D S K L F D O O R F D W L R Q D Q G

H [ S H F W H G L Q W H U D F W L R Q Z L W K H [ W H U Q D O V \ V W H P V D Q G K X P D Q V

2 S H U D W L R Q D O S U R I L O H V V K R X O G D G G U H V V W L P H V W K H V \ V W H P L V

R S H U D W L Q J D Q G W L P H V L W L V V W R U H G R U E H L Q J W U D Q V S R U W H G

7 K H V H O D W W H U F R Q G L W L R Q V D U H V R P H W L P H V P R U H F U L W L F D O W K D Q

W K H R S H U D W L Q J F R Q G L W L R Q V > @

7 K H R S H U D W L R Q D O S U R I L O H L V D W R R O I R U V S H F L I \ L Q J W K H X V H

H Q Y L U R Q P H Q W , W L V D T X D Q W L I L H G O L V W R I W K H H O H P H Q W V D Q G

I D F W R U V U H O D W H G W R H [ S H F W H G S U R G X F W X V H D Q G K R Z R I W H Q W K H \

Z L O O R F F X U , W V K R X O G E H G H Y H O R S H G W K U R X J K

F R P P X Q L F D W L R Q E H W Z H H Q W K H F X V W R P H U D Q G W K H G H Y H O R S H U V

7 K H R S H U D W L R Q D O S U R I L O H S U R Y L G H V L Q I R U P D W L R Q D E R X W Z K L F K

F D S D E L O L W L H V Z L O O E H X V H G W K H P R V W D Q G Z K L F K F D S D E L O L W L H V

Z L O O E H Q H H G H G I L U V W L I W K H V \ V W H P Z L O O E H G H O L Y H U H G L Q

V W D J H V

6 \ V W H P 0 R G H V

6 \ V W H P P R G H V P D \ E H G H W H U P L Q H G E \ S D U W L W L R Q L Q J W K H

V \ V W H P L Q S X W V S D F H L Q W R H T X L Y D O H Q F H F O D V V H V E D V H G R Q V R P H

F R Q G L W L R Q V V X F K D V V \ V W H P W U D I I L F O H Y H O S U H G R P L Q D Q W

I X Q F W L R Q X V H U H [ S H U L H Q F H H W F $ V \ V W H P P D \ K D Y H D I D L O

V D I H P R G H I R U H [ D P S O H R I U H G X F H G R U E D V L F I X Q F W L R Q D O L W \

W K D W K D V D Y H U \ G L I I H U H Q W S U R I L O H I U R P W K H Q R U P D O P R G H R I

R S H U D W L R Q 0 R G H V D O O R Z X V W R F R Q V L G H U I H Z H U S R V V L E L O L W L H V

W K D Q F R Q V L G H U L Q J H Y H U \ I X Q F W L R Q $ O V R X V L Q J P R G H V L V

P R U H D S S U R S U L D W H I R U W K H U H T X L U H P H Q W V S K D V H V L Q F H Z H P D \

Q R W N Q R Z D O O W K H I X Q F W L R Q V 7 K H 6 \ V W H P 0 R G H 3 U R I L O H

V K R Z V W K H P R G H V D Q G W K H L U S U R S R U W L R Q D O R F F X U U H Q F H

7 K H V H S U R I L O H V P D \ E H X V H G W R S U H G L F W L Q L W L D O

G H S H Q G D E L O L W \ O H Y H O V I R U W K H V \ V W H P D Q G W R G H Y H O R S W H V W V

O D W H U R Q 7 K H \ D O V R D V V L V W L Q D V V X U L Q J W K H F R P S O H W H Q H V V R I

W K H U H O L D E L O L W \ U H T X L U H P H Q W V D V W K H \ L Q F U H D V H

F R P P X Q L F D W L R Q R S S R U W X Q L W L H V I R U F X V W R P H U V D Q G

G H Y H O R S H U V

5.4 Failure Modes

Functional requirements are a positive specificationof what the system must do. A specification of what itmust not do, a negative specification, is also important,and should include information concerning failure modesfor the system. Failures are defined from the product userperspective (e.g. loss or degraded capability of a functionor feature) and grouped into categories by cost/impact on

the product user. Each of these categories affects the userto the same degree and is called a severity class. Somesystems, fault tolerant systems for example, will need todetect and count run-time failures in distinct categories.

5.5 Fault Tolerance

Fault tolerance requirements imply the system mustinclude redundancy for error detection and/or it mustavoid the consequent failure state. That is, the fault atissue shall not become active. Systems that include suchsafety, security, and survivability requirements specify thestates and conditions that the system must detect andavoid. It is usually necessary to include recovery

techniques, though specific components will employdifferent means for this. Example recovery alternativesare reconfiguration with a new component, and reducedfunctionality to avoid exercising the fault in the currentcomponent (graceful degradation). Reconfiguration isgenerally supported with redundant computers. Thesystem design may employ extra general-purposecomputers, or each computer may have a Hot Standbywhich shadows the active computer and executes the same


5/7

software. The operating system must support systemrequirements for redundancy and hardwarereconfiguration. Requirements for error recovery mayinclude exception handling and recovery blocks in theapplication software.

An alternative to error recovery is fault masking (alsocalled error compensation). Classically this is achieved by

modular redundancy, in which several componentsperform each computation independently, and the finalresult is selected by majority voting [13].

Fault tolerance affects reliability as it reduces thelikelihood that faults will be manifested as failures andtherefore also affects the availability at a specific time. Itmay be used to increase safety and security attributes iftheir relevant classes of failures are addressed. Systemfailures that may result in loss of human life or criticalproperty are a special concern. With fault tolerance, thesystem may be able to withstand a sequence of failuresand fail in a safe state (e.g. fail operational, on firstfailure, fail operational on second failure, fail in a safe

state on the third failure).

5.6 Software and Hardware Differences Affect

Measurement

Dependability attributes are emergent properties ofthe system. That is, they are a measure of the system as awhole and not just a sum of measures for the componentparts. Hardware and software dependability must bemanaged as a system measure. However, there arerecognized differences between these characteristicsubsystems. The differences affect the overall evaluationof the integrated system. The American Institute ofAeronautics and Astronautics has summarized theimportant hardware to software contrasts.

First, changes to hardware require time consumingsteps including fabrication and assembly, so requirementsnormally call for replacement or repair, rather thanchange. Repairs generally restore the hardware to itsprevious state. Changing software is frequently morefeasible, though not always effective. Therefore,maintainability requirements address modularity and othergood design techniques that support fixing bugs andimproving the software. Changing the software alwayschanges the software state. A high rate of change is likelyto decrease the software reliability.

Software developments have traditionally made little

use of existing components; hardware is oftenmanufactured from standard parts, and requirements callfor use of common parts, which supports maintenance.Manufacturing tolerances affect hardware, andrequirements call for specific tolerances. Exact copies ofsoftware can be easily produced, so tolerance is not anissue. However computation accuracy is important.

Software does not experience physical wear-out.Rather, failures from software faults come without

advance warning, often with little indication of theiroccurrence. Hardware on the other hand, often provides aperiod of graceful degradation and is susceptible to wear-out. Both hardware and software reliability measures arein operational time. For hardware, this is expressed inwall-clock time. For software, execution time is used[14].

5.7 Example: Air Traffic Control System

The following example illustrates the concepts ofdependability objective, operational profile, system mode,failure mode, and fault tolerance.

Assume that the customer for an Air Traffic Control(ATC) system requires that the system be down at mostsix hours per year. This is an availability requirement thatrequires very high reliability and very fast repair. Thecustomer defines operational profiles that include aircraftmanagement, and limited time on duty for controllers dueto fatigue and stress. Controllers manage aircraft flying

through their sector, taking off, and landing. Whenrunways are not available for landing, controllers assignthe aircraft a flight pattern and altitude, and may bring theaircraft to successively lower altitudes prior to landing.Eventually they assign aircraft a runway, manage aircraftas they approach the runway and land, and assign aircrafta gate. Such high level use profiles (or scenarios) arefurther detailed and are used with other profiles to designthe system and verify that it meets the dependabilityobjectives. The customer and users also define failuremodes, such as (1) one (or more) radars out of operation,(2) understaffed operation, and (3) insufficient computerresources. System and subsystem designers use therequirements, operational profiles and mode definition,

and working together, they identify potential designs,perform tradeoffs, and select the best design. They definesystem modes, which may include (1) test modes, and (2)operational modes. The latter may include (2a) sectorcontrol (controls aircraft flying through the sector); (2b)approach control (controls multiple aircraft landing onmultiple runways; and (2c) aircraft emergency mode (e.g.aircraft must land immediately due to passenger illness oraircraft failure). System modes should be consistent withoperational profiles, for user understanding andmaintainability.

Based on the system architecture, contractors andsubcontractors allocate requirements for reliability(MTTF) and repair (MTTR), or allocate requirements forfailure intensity, as appropriate, to subsystems. They thendefine subsystem requirements, including those forhumans, communication links, hardware, andinfrastructure and application software. Subsystems mustoperate in unison to meet the ATC system objective of atmost six hours down time, so a fault tolerant architecturemust be part of the overall system architecture. Allocatedfault tolerance requirements for the communication


6/7

subsystem may include redundant broadcast on multiplechannels, data backup, and rebroadcast when data iscorrupted. There are a number of basic concepts for faulttolerant computing that could be used in the ATC system.All may be used. The fault tolerance requirements for thehardware normally specify the need for redundantcomputers.

6. Summary

Dependability requirements are related to bothprocess and product. The product part is concerned withspecified quantitative measures related to functions,behavior, and data. These measures may differ byscenario, mode, or operational profile. The process partspecifies required practices that the contractor shallperform during the system life cycle, to ensure thatdependability requirements will be met and can beverified.

The requirements specification may require a

dependability program plan as part of the systemengineering management plan. A typical reliability planshould address these product requirements issues:- Quantified dependability requirements for the

system as related to system operational requirementsand operating conditions, including the operationalprofile and the maintenance concept.

- Allocation or apportionment of dependabilityrequirements to the subsystem components, hardwareor software.

- Effects of maintenance.It should address these process requirements issues:- Failure Modes and Effects (Criticality) Analysis

(FMEA/FMECA).- Design techniques and practices.- Formal reviews.- Analysis of behavioral and mathematical models,

worst case analysis, vulnerability analysis.- Data collection, analysis and corrective actions.- Dependability prediction and assessment.

Dependability testing and other evaluations.7. Future Work

The following open problems are recommended asresearch topics to improve specification of dependabilityrequirements.- Examination of requirements documents and

plans for ultra-reliable systems may provideimproved insight for ultra-reliable and normallyreliable systems, as concepts used for ultra-reliablesystems can be applied in a relaxed form to systemsthat are not safety or mission critical.

- Corrective changes result in dependabilitygrowth; all types of maintenance (change) can lead to

dependability decay. Can change/maintainability bespecified at the requirements stage, and how does thisimpact the requirements for dependability?

- Testability is important and has an affect ondependability [15]. Is it possible to require thathardware and software be more controllable orobservable? How are requirements for this stated?

- Different information is available and recordedfor defects discovered at different phases ofdevelopment. What are appropriate lists of thisinformation for each phase?

8. References

[1] White, S.,A Faceted Structure for Capturing and AnalyzingSystem Requirements, Report for Engineering of ComplexSystems Technology Project, Naval Surface Warfare Center,Dahlgren Division. Research performed under contract N60921-94-C-0073, February 1997.

[2] Kopetz, H., Software Reliability, Springer-Verlag New York

Inc., 1976.

[3] Department of Defense, Glossary, Defense AcquisitionAcronyms and Terms, Fifth Edition, Defense SystemsManagement College, Fort Belvoir, Virginia, Sept. 1991.

[4] Tripp, L. and S. Keene, System Dependability White Paper,unpublished paper, sponsored by IEEE Computer Society andIEEE Reliability Society, 1999.

[5] Mellor, P., Failures, Faults and Changes in DependabilityMeasurement,Information and Software Technology, 34 (10),October 1992, 640-654.

[6] Panda, B. and J. Giordano, Defensive Information Warfare,Communications of the ACM, July 1999, 31-32.

[7] Leveson, N. G., Safeware: System Safety and Computers,Addison-Wesley, Reading, MA, 1995.

[8] Laprie, J. (ed.), Dependability: Basic Concepts andTerminology, Springer-Verlag New York, 1992.

[9] Blanchard, B.S. and W. Fabrycky,Systems Engineering andAnalysis, Prentice Hall, Englewood Cliffs, N.J., 1990.

[10] Musa, J., A. Iannino, and K. Okumoto, SoftwareReliability: Measurement, Prediction, Application, McGraw-HillBook Company, New York, 1987.

[11] Musa, J., Operational Profiles in Software-Reliability

Engineering,IEEE Software, 10(2), March 1993, 14-32.

[12] Sawyer, P. and G. Katonya, SWEBOK: SoftwareRequirements Engineering Knowledge Area Description,Version 0.5, IEEE and ACM Project on Software EngineeringBody of Knowledge, July 1999.


7/7

[13] Rushby, J., Critical System Properties: Survey andTaxonomy, Computer Science Laboratory Technical Report SRI-CSL-93-01 written for NASA Langley Research Center underContract NAS1-18969, SRI International, May 1993.

[14] AIAA Space-based Observation Systems Committee onStandards, Software Reliability Working group, "Recommended

Practice for Software Reliability" R-013-1992, Draft, April1992.

[15] Kapur R., T. Williams, and E. Miller, System Test andReliability: Techniques for Avoiding Failure,IEEE Computer,November 1996, 28-30.

Documents

Dependability Reqmts