Integrating Safety Analysis and Requirements Engineering

Gerald Kotonya and Ian SommervilleCooperative Systems Engineering GroupTechnical Report Ref: CSEG/18/1997

http://www.comp.lancs.ac.uk/computing/research/cseg/97_rep.html

ABSTRACT

Some systems failures are due to defects in manufacturing and design, however that there are a significant number ofsystem failures which result from errors, omissions and inconsistencies in the system requirements. We thus needmethods to support a ‘safe’ requirements engineering process whose objectives are to specify system requirementssuch that system states which compromise safety are avoided and to include, along with the requirements, ajustification or safety case which explains why the specified system is indeed safe. This paper describes the extensionof a viewpoint-based requirements method to incorporate safety analysis.

CSEG, Computing Department, Lancaster University, Lancaster, LA1 4YR, UK

Tel: +44-1524-65201 Ext 93799; Fax: +44-1524-593608; E-Mail: julie@comp.lancs.ac.uk

http://www.comp.lancs.ac.uk/computing/research/cseg/

Integrating Safety Analysis and Requirements Engineering

Gerald Kotonya and Ian Sommerville

Computing DepartmentLancaster University,Lancaster LA1 4YR. UK

(Proceeding of ICSC’97/APSEC’97, pp.259-270)

Abstract

Some systems failures are due to defects in manufacturingand design, however that there are a significant number ofsystem failures which result from errors, omissions andinconsistencies in the system requirements. We thus needmethods to support a ‘safe’ requirements engineeringprocess whose objectives are to specify systemrequirements such that system states which compromisesafety are avoided and to include, along with therequirements, a justification or safety case which explainswhy the specified system is indeed safe. This paperdescribes the extension of a viewpoint-based requirementsmethod to incorporate safety analysis.

1. Introduction

The incorporation of computer-based control systems intoa wide range of industrial and domestic products means thatthe associated software systems are safety-related. Thismeans that a software system failure can compromise theoverall safety of the system and thus may harm systemoperators, the environment where the system is installed,customers of the organisation using the system and thegeneral public. Engineers who are responsible for developingthese safety-related systems must be aware of the associatedproblems and must use a development process which aims tominimise the possibility of dangerous system failures.

Existing methods which support the requirements analysisprocess irrespective of whether they are based on functionalanalysis or object-oriented analysis are inherently deficient asfar as safety is concerned. There are two fundamentalproblems with these methods:1.

They are intended for the analysis of software systems.Safety is a whole-system consideration and not justconfined to software systems. Safety-related softwaresystems cannot be considered in isolation.

2.

They are intended to produce analysable system modelswhich set out what the system must do. This impliesthat we have already developed an understanding of the

system requirements and methods have been (in ourview) rightly criticised [1,2] because they do not addressthe difficult problem of requirements discovery asdistinct from requirements analysis. This is particularlyimportant for safety-related systems where the safetyanalysis is concerned with discovering what the systemmust not do rather than what services it should provide.We have addressed this problem by extending a viewpoint-oriented method for software requirements analysis so that itcan cover broader systems issues and by incorporatingsupport for safety analysis with this method. This methodfocuses on the processes of requirements discovery andanalysis rather than the development of detailed systemmodels.

In the remainder of this paper, we firstly discuss thenotion of viewpoints which we use and follow this with anoverview of the VORD (Viewpoint-Oriented RequirementsDefinition) method. We briefly discuss the process of safety-analysis and introduce a simple example which is used toillustrate our approach. The bulk of the paper concentrates onillustrating the integration of safety analysis andrequirements analysis using our approach and the supporttools which we have developed. Finally, we reflect on theeffectiveness of this method and its possible development.

2.Viewpoints

The notion of viewpoints as a means of organising andstructuring the requirements engineering activity is nowwell-known. Viewpoints are implicitly present in SADT [3]and were first made explicit in the CORE method [4]. Sincethen there have been various other viewpoint-basedapproaches and proposals [5,6,7,8]. We have summarisedthese methods and described our own work on viewpoints forinteractive system design elsewhere [9,10]VORD defines two classes of viewpoints:1.

Direct viewpoints These correspond directly to clientsin that they receive services from the system and sendcontrol information and data to the system. Directviewpoints are either system operators/users or other

1

sub-systems which are interfaced to the system beinganalysed.2.

Indirect viewpoints Indirect viewpoints have an‘interest’ in some or all of the services which areAbstract viewpoints andabstract requirementsdelivered by the system but do not interact directly withit. Indirect viewpoints may generate requirements whichconstrain the services delivered to direct viewpoints.

IdentifyviewpointsDocumentviewpointsAnalyserequirementsSpecifyrequirementsRequirements informationspaceFigure 1 VORD process modelWhile the concept of a direct viewpoint is fairly clear, thenotion of indirect viewpoints is necessarily diffuse. Indirectviewpoints vary radically from engineering viewpoints (i.e.those concerned with the system design and implementation)through organisational viewpoints (those concerned with thesystems influence on the organisation) to externalviewpoints (those concerned with the systems influence onthe outside environment).

Indirect viewpoints are very important as they often havesignificant influence within an organisation. If theirrequirements go unrecognised, they can often decide that thesystem should be abandoned or significantly changed afterdelivery. This is particularly true for some classes of safety-related systems which must be certified by an externalregulator. If certification requirements are not met, thesystem will not be allowed to go into service.

3.Viewpoint requirements analysis and specificationFigure 1 shows the VORD process model. The first step,viewpoint identification and structuring, is concerned withidentifying relevant viewpoints in problem domain andstructuring them. The starting point for viewpointidentification are abstract statements of organisational needsand abstract viewpoint classes. This step is described inSection 6.1.

The second step is concerned with documenting theviewpoints identified in step 1. Viewpoint documentationconsists of documenting the viewpoint name, requirements,constraints on its requirements and its source. Viewpointrequirements include a set of required services, controlrequirements and set of non-functional requirements. Thisstep is described in Section 6.2.

The last step is concerned with analysing, and specifyingthe functional and non-functional viewpoint requirements inan appropriate form. The notation used depends on theviewpoint, the requirement and the requirements sourcesassociated with the viewpoint. Appropriate notations rangefrom natural language (if the requirements source isconcerned with non-technical requirements), throughequations (if the requirements source is a physicist, say) tosystem models expressed in formal or structured notations.Viewpoints and their requirements are collected into acentral repository that serves as input to the requirementsanalysis process. The objective of the analysis process toestablish the correctness of the documentation and to exposeconflicting requirements across all viewpoints. The use oftools is an integral part of the VORD method and is intended

3. Viewpoints oriented requirements definition

Based on this notion of viewpoints, we have developed amethod for requirements engineering called VORD(Viewpoint-Oriented Requirements Definition) which coversthe requirements engineering process from initialrequirements discovery through to detailed system modelling.For the purposes of this paper, the later system modellingstages of the method are not important. The discussion heretherefore concentrates on the first three iterative steps inVORD namely:

1.Viewpoint identification and structuring2.Viewpoint documentation

2

to provide support from initial requirements formulationthrough to detailed specification.the system critical systems life cycle [11] as shown inFigure 2, identifies two stages in the safety analysis process:1.Safety requirements discovery. The establishment ofglobal safety requirements or constraints which thesystem must satisfy. This involves hazard identificationand analysis, risk assessment and the formulation ofsystem safety requirements. This stage may be carried outin some generic way (e.g. for all

4. Safety analysis

System safety analysis is concerned with ensuring and

certifying that a delivered system does not pose anunacceptable danger to its end-users or to the environment inwhich the system is installed. The widely accepted model ofHazardanalysisRiskassessmentSafety Requirements specificationFunctionalrequirementsspecificationSafety-integrityrequirementsspecificationDesignation of safety-criticalsystemsValidationPlanningDesign andImplementationVerificationSafetyValidationOperation andMaintenanceFigure 2 The safety-critical systems life cycle

aircraft) and the generic requirements are then instantiatedfor a specific system.

2.Safety validation. The analysis of the systemrequirements against these global safety constraints toensure that these requirements either individually or inconjunction do not contradict the identified safetyconstraints. This process continues, of course, throughthe design and implementation of the system.As part of the process of safety analysis, there are variousactivities such as hazard identification and analysis whichrequire inputs and lateral thinking from different groups ofpeople. In essence, these groups represent different

viewpoints and it may be useful to formalise this processusing the notion of viewpoints discussed here. In this case,rather than a set of system requirements, the outcome of theprocess is a set of hazards which may arise. We are currentlyinvestigating the use of viewpoints in this context in anotherproject but, in this paper, we focus on safety validationrather than on initial safety requirements formulation.

Various methods such as fault-tree analysis and Petri netanalysis [13,14] have been developed for safety validation.Our approach has involved integrating these methods withVORD and providing integrated tool support for requirementsand safety analysis.

5. Example - A paper guillotine

3

We use a simple example of a paper cutting machine toillustrate our approach. This guillotine consists of a cuttingtable where the paper is positioned and a vertical blade whichdrops to trim the paper. The operation of the guillotine iscontrolled by embedded software that interfaces with the bladecontroller motor and a sensor which detects the completionof the cutting operation. Various other sensors are includedin the system to ensure its safe operation.

The guillotine is operated by a single operator under thesupervision of an operations supervisor. The paper cuttingoperation is initiated by the operator pressing a start buttonand interrupted by the operator pressing a stop button. Whenthe guillotine detects \"cutting done\" signal, the controllerautomatically resets the blade to its starting position andwaits until new paper is positioned on the table beforerestarting the cutting operation sequence.

The starting point for specifying this system is a set ofabstract organisational needs and constraints:

1.The organisation buying the system requires that it shouldoperate safely and reliably without causing injury to itsoperator. Safety in the organisation is the responsibilityof a safety officer. He or she requires the machinemanufacturer to take a systematic approach to safetyissues. These include:a.Identifying hazards, risks and risk criteria

b.Identifying the necessary risk reduction to meet therisk criteria.

c.Defining the overall Safety RequirementsSpecification for the safeguards necessary to achievethe required risk reduction.2.A working system must be operational within 8 monthsfrom the date of ordering the system.3.Guillotine operators are concerned about the safety of thesystem and would like to see as many safeguards aspossible incorporated into the system which wouldprevent an accident in the event of operational errors orsystem failures.4.The operations supervisor requires that the paper-cuttingservice operates with a failure rate of no more than 1 in1000 operations.

5. It is required that the system produce an accounting/auditreport every 2 days. The report should include the date andamount of paper cut up to that time.6.The Safety Officer recommends that regular maintenanceof the guillotine be carried out every two weeks.a.Identifying hazards, risks and risk criteria

b.Identifying the necessary risk reduction to meet therisk criteria

c.Defining the overall Safety RequirementsSpecification for the safeguards necessary to achievethe required risk reduction.

7.The production manager requires that the system providecontinuous operation for periods of up to 1 month.8.Because of its safety-related nature, it is recommendedthat the system be developed using standards defined in“System Quality Plan xxx”We use this example to show how the notion ofviewpoints can be used formulate and structure the systemrequirements. We also demonstrate how integrating safetyanalysis with the requirements engineering process can leadto the ‘discovery’ of requirements conflicts and proposals forimproving the initially proposed requirements. In this paperwe are more concerned with how safety analysis can beintegrated with the requirements process without going intothe detailed of specification of the complete system.

6. Deriving safe system requirements

The VORD process, shown in Figure 1, has beenextended to incorporate an explicit safety analysis activitywhose results are used to modify (where necessary) suggestedsystem requirements. This is illustrated in Figure 3 (shownin grey). The safety analysis process is based on viewpointinformation drawn from the requirements information spaceand a set of abstract safety requirements that serve as areference model for identifying initial safety considerations orconcerns relating to each viewpoint.

Abstract viewpointsand abstract requirementsIdentifyviewpointsDocumentviewpointsAnalyserequirementsSpecifyrequirements4

Requirements information spaceSuggested safetyrequirementsIdentify viewpointssafety considerationsIdentifyhazardsAnalysehazardsAbstract safetyrequirementsRiskassessmentFigure 3 Process model for integrating safety analysis and requirements formulationAn operator viewpoint, for example, has obvious safetyWe have generalised problem domain experts and potentialconcerns relating to the operation of the paper guillotine.requirement sources into a set of abstract viewpoint classes,The output from the safety analysis process is a set ofthat can be used as a starting point for finding viewpointssuggestions and improvements that are fed back into thespecific to the problem domain. Each organisation shouldmain requirements process.define a hierarchy of these viewpoint classes which areThe safety analysis process includes the identification ofappropriate to the organisational needs and applicationsafety considerations, hazard identification hazard analysis,domain of the systems which are being developed. The toprisk analysis and derivation of safety requirements. Thehalf of Figure 4 shows the abstract viewpoint classes.hazard and risk analysis stages use any appropriate hazard andNormally, the indirect viewpoints would be decomposed torisk analysis techniques and are not tied to any particulargreater depth than shown here.method. In our example, we have chosen to use fault-treesThe root of the tree represents the general notion of afor hazard analysis and a risk analysis scheme based onviewpoint. Information can be inherited by viewpoint sub-accident severity-probability categorisation.classes so global requirements are represented in the moreThe integration of requirements definition and safetyabstract classes and inherited by sub-classes. In the directanalysis is an iterative process. The output from any oneviewpoint class, the sub-system viewpoint represents thestage may be fed back to its preceding stage for review andabstract class of systems within the organisation that mayimprovement. The output from the safety analysis, forinteract directly with the proposed system. These includeexample, informs the requirements definition process, theshared databases and other sub-systems. The operator classresult of which acts as the input to the safety analysisrepresents the abstract class of people who interact with theprocess.system directly. Under the indirect viewpoint class, theWe believe this approach provides a sound framework forcustomer viewpoint represents the requirements and concernsensuring that safety is built into the system right from itsof the organisation purchasing the system, the regulatoryinitial formulation, and a powerful facility for tracing safetyviewpoint represents legal and other regulatory requirementsrelated issues and decisions. In the next sections we willassociated with system, the engineering viewpoint representsdescribe the components of this process model using thethe engineering requirements for the system and theguillotine example discussed above.environmental viewpoint represents environmental issues

affecting the system development.

6.1 Viewpoint identificationThe method of viewpoint identification which we propose

involves:

All structured methods must address the basic difficulty of

1.Pruning the viewpoint class hierarchy to eliminateidentifying the relevant entities for the system which is

viewpoint classes which are not relevant for the systembeing specified or designed. The majority of methods provide

being specified. In the guillotine example, let us assumelittle or no active guidance in this and rely on the method

that there is no external certification authority for theuser’s judgement and experience in this entity identification

system and that it has no environmental effects. Weprocess. While we cannot claim that we have solved the

therefore do not need to look for viewpoints under theseidentification problem, we do provide some help to the

headings.analyst in the critical step of viewpoint identification.

5

2.Using a model of the system architecture, to identify sub-system viewpoints. This model may either be derivedfrom existing system models or may have to bedeveloped as part of the RE process. In the example ofthe paper guillotine we can identify two main sub-systems, the controller and sensor sub-systems.3.Identifying system operators who use the system on aregular basis, who use the system on an occasional basisand who request others to use the system for them. All ofthese are potential viewpoints. We can identify twoinstances of direct viewpoint in this example namely theguillotine operator (regular) and the guillotine supervisor(occasional).

4.For each indirect viewpoint class which has beenidentified, consider the roles of the principal individualwho might be associated with that class. For example,under the viewpoint class ‘customer, we might beinterested in the roles of ‘safety officer’, ‘maintenancemanager’, ‘production manager’, etc. There are oftenviewpoints associated with these roles. In this example,there are many possible indirect viewpoints but we willconfine our analysis to a safety officer, a productionmanager and a development standard viewpoint.We will limit our analysis to these seven identifiedviewpoints. Figure 4 shows the viewpoint structure for thepaper guillotine. Indirect viewpoints are shown in the darkershading.

6

Figure 4 Viewpoints for a paper guillotine system

6.2 Documenting viewpoint requirements

Viewpoints have an associated a set of requirements,sources and constraints. Viewpoint requirements are made upof a set of services (functional requirements), a set of non-functional requirements and control requirements. Controlrequirements describe the sequence of events involved in theinterchange of information between a direct viewpoint andthe intended system. Constraints describe how a viewpoint'srequirements are affected by non-functional requirementsdefined by other viewpoints.

We do not have space to look at the detailed requirementsof each viewpoint here. However, Figure 5 shows the initialviewpoint requirements which have been distilled from thenarrative text of the system described in section 4. Viewpointspecialisations inherit the requirements of their more abstractparents. The controller sub-system and sensor sub-systemviewpoints do not appear in the table as they are essentially

Viewpoint ReferenceReferenceLabel1Guillotine Operator1.11.2

Regular Operator

Operations Supervisor

Source311.21.2

2

Safety Officer

2

concerned with providing control information to the proposedsystem. Using the VORD toolset, each viewpoint isdocumented using a template form, described in detailelsewhere [10], which includes:1. 2.3. 4. 5.6.

Viewpoint identifier and descriptionViewpoint type

Viewpoint attributesViewpoint requirementsViewpoint event scenariosViewpoint history

Figure 6 shows this requirements template for theGUILLOTINE OPERATOR viewpoint. Each viewpointrequirement is accompanied by a rationale and requirementsource. The requirements are specified on a separate formwhich is not shown here.

Requirement

Description

1. Requires the system provide paper cutting service2. Guillotine operators require that system operate safely

1. The operations supervisor requires that the paper cutting service

operates with a failure rate of no more than 1 in 1000 operations.2. Operations supervisor is required that system produce an

accounting/audit report every 2 days. The report should include thedate and amount of paper cut up to that time.

1. The Safety Officer recommends that regular maintenance of theguillotine be carried out every two weeks.a.Identifying hazards, risks and risk criteria

b.Identifying the necessary risk reduction to meet the risk criteriac.Defining the overall Safety Requirements Specification for thesafeguards necessary to achieve the required risk reduction.

1. The system should be continuously available for periods of up to 1month

2. The organisation buying the system requires that it should operatesafely and reliably without causing injury to its operator.

3. A working system must be operational within 8 months from the dateof ordering the system.

4. The system should produce an audit/accounting report every 2 days1. It is recommended that safety-critical systems be developed usingstandards defined in “System Quality Plan xxx”

3Production Manager3

4DevelopmentStandards

4Figure 5 Viewpoint documentation for paper guillotine

form includes built-in facilities for the quantitative

Non-functional requirements are documented by selectingspecification of reliability.the appropriate requirement button shown at the bottom ofNon-functional requirements identified in one viewpointthe form. In this case, the cutting operation must be safe.may constrain the requirements associated with otherNon-functional requirements are specified in more detail on aviewpoints. When a non-functional requirement has beenseparate form either qualitatively or, wherever possible,defined, it may be categorised as follows:quantitatively. For example, the non-functional requirements

7

1.As a system constraint. This means that the requirementis a constraint on all services on all viewpoints.Examples of systems constraints are safety andmaintainability requirements.2.As a constraint on a specified set of viewpoints or aspecified set of system services. Therefore, usabilityrequirements may be constraints on all operatorviewpoints but not on viewpoints associated with sub-systems. Different sets of services may have differentreliability requirements - for example, services which aresafety-related must normally be more reliable thanreporting services.3.As a local constraint. This means that the non-functionalrequirement applies only to the local viewpoint or aservice associated with that viewpoint.When the non-functional requirement has beencategorised, the VORD support toolset then propagates it toall relevant viewpoints and services so that it may be takeninto account during analysis or requirements discovery. Wesee an example of this on the right side of Figure 6 which

shows a list of constraints associated with the viewpointtogether with the constraint sources. By picking the safetyregulations constraint, the constraints which are derivedfrom these non-functional requirements and which influencewith the paper cutting service may be viewed.

As well as functional and non-functional requirements,VORD also allows for the specification of system controlrequirements. These are associated with viewpoint servicesand describe the interchange of information between a directviewpoint and the system being specified. We have defined asimple event-based language for control specification. Asthis is not critical to the example here, we will not discussthis further.

6.3 Support for safety analysis

The process of safety analysis which we have incorporatedinto VORD includes the following stages:

1.Safety consideration identification What are the safetyconsiderations of each system viewpoint?

2.Hazard identification What hazards may occur whichmight lead to an accident.

Figure 6 Documentation for the operator viewpoint

3.Hazard analysis What are the causes of these hazards?4.Risk classification and analysis What is the risk of ahazardous situation occurring and causing an accidentwhich results in injury.6.3.1

Identifying safety considerations

The first step in the safety analysis process involvesidentifying key safety considerations or concerns associatedwith viewpoints. A safety consideration is a hazardclassification which depends on the system which is beinganalysed. For the guillotine safety considerations might beoperational considerations (i.e. what hazards are associatedwith the machine operation) and electrical considerations.

8

For other types of system, such as an X-ray machine,radiation considerations would also be identified. Each safetyconsideration has an associated set of hazards which must beanalysed.

Identifying safety considerations serves to limit thenumber of hazards that can be considered at one time and toplace the hazards in context. To help in the process ofidentifying safety considerations, a set of global safetyrequirements are used as a starting point. Global safetyrequirements are derived from general organisational concernson safety and the need to ensure that safety regulations aremet.6.3.2

Hazard identification and analysis

For each identified safety consideration, we identify a listof possible hazards. We then go on to analyse each of thesehazards to discover their possible causes. This process ofhazard identification largely relies on the judgement andexperience of those involved in the process.

The method of hazard analysis which we support inVORD is fault-tree analysis. Fault-tree analysis is concernedwith discovering the system states which are potentiallyhazardous. For each identified hazard (condition withpotential for causing an accident), a fault-tree is producedwhich traces back to all possible situations which might

cause that hazard. Fault-tree analysis can be applied atdifferent levels from a requirements level through to ananalysis of the code of a software system. Fault-trees includeand/or operators which allow hazardous conditions to becombined.

We have incorporated a syntax driven graphics editor forfault-trees with the VORD support tools. Figure 7 shows afault-tree analysis of an operational hazard associated with theoperator viewpoint, ‘guillotine crushes operator’s hand’.The top right of the form shows the viewpoint associatedwith the safety consideration and the identified hazard. Thetop left shows the viewpoint requirements. The lower halfshows the hazard analysis which reveals that the operatorshand can be crushed if there is some controller failure, if theblade locking mechanisms fails or if there are some externalenvironmental hazards (e.g. an earthquake) which mightoccur. These are then decomposed into their possible causes.6.3.3 Risk classification

Risk classification is concerned with devising a schemewhere the risks associated with a system failure can beclassified with a view to deciding on whether or not theserisks are acceptable. It involves a consideration of theseverity of accidents and the probability that a hazard will

9

Figure 7 Hazard analysis for the hazard ‘guillotine crushes operator’s hand’

arise. Note that these will vary depending on the systembeing developed and on the organisation developing asystem. Some organisations may be willing to tolerate agreater level of risk than others because they make aneconomic judgement that it is cheaper to pay for theconsequences of an accident rather than engineer the systemso that it will never occur.

We have developed a set of user-definable severity and riskschemes based on the UK Ministry of Defence Standard 00-56 [12] . The tables comprise a set of accident-severitycategories, probability categories and an accident riskclassification scheme. Figure 8 illustrates how theseclassifications may be defined. This information is used toassist with the later risk analysis activity.

The top left of the form shows four possible classes ofaccident severity ranging from catastrophic to minor. To theright of this classification, we define hazard probabilityclasses which reflect how likely it is that a hazard will arise.These classes have associated numeric probabilities which arearbitrarily assigned and which depend on engineeringjudgement. We make the worst case assumption that hazardswill always result in an accident although, of course, this isnot always the case. The hazard probabilities may be adjustedto take this into account.

In the bottom right of the form, the tolerability of risks isset out. We have identified three classes of risk namelyintolerable i.e. it must never happen, undesirable whichmeans that it can only be accepted if no risk reduction is

practical or acceptable with endorsement which means thatrisk is acceptable given that some safety authority hasagreed.

Finally, the bottom left of the form sets the severityclasses against the hazard probabilities and, for each pair,defines its tolerability. Therefore, in the classificationscheme used here, we can see that hazards which are likely toarise frequently and have catastrophic, fatal or severeconsequences are intolerable. This means that the systemmust be specified and designed so that these hazards areeliminated or by ensuring that there is an extremely lowprobability that these hazards result in an accident.6.3.4 Risk analysis

The accident risk classification scheme can be used toanalyse the risks of hazards in the fault-tree. VORD allowsthe user to select an event within the fault-tree and to open arisk analysis form on that event. Figure 9 shows riskanalysis forms for the top level hazard of operator injury,blade lock failure and software specification error.

For the top-level hazard, the safety analyst fills in theseverity of the event from a menu of possibilities derivedfrom the risk classification. For lower-level events, theanalyst makes an estimate of the probability of the event andproposes risk reduction strategies which would reduce thatprobability if they were applied. The VORD toolset

Figure 8 Accident risk classification scheme

10

Figure 9 Risk analysis forms for hazard events associated with ‘guillotine crushes operator’s hand’

uses the probability of the lower level events to compute theoverall hazard probability at the top-level using the eventrelationships as specified in the fault-tree and fills this inautomatically in the risk analysis form.

In Figure 9, the top-level hazard probability has beencomputed as approximately 0.01 so is considered as aprobable event. As probable events with severe consequencesare intolerable, this implies that some risk reductionstrategies must be applied to reduce the likelihood of thishazard occurring or, alternatively, to ensure that theoccurrence of the hazard can never result in an accident. Thiswould be documented separately in a system safety case.

The proposed risk reduction strategies for each event arealso propagated to the top-level hazard form so that acollected list is available (Figure 10) as an input to therequirements analysis process. Each proposed changeincorporates a source annotation for traceability. Suggestedchanges form the basis for further decisions, in the case ofsafety analysis they can be used derive more safetyrequirements. This system may be used as a spreadsheet for

safety analysis. Various event probabilities can be proposedand the effect on the overall hazard probability isimmediately displayed. Therefore, some acceptableprobability for an event can be discovered and systemengineering strategies proposed which will ensure that thisevent probability can be achieved.

7. Conflict analysis

After the safety analysis process has been completed, weare now in a position to analyse requirements to discovererrors, omissions and conflicts. Viewpoints are the key tolinking the requirements analysis and the safety analysisprocesses. Viewpoints have differing stakes in andinteractions with the intended system and will haveperceptions of safety closely aligned with these interests.They have a set of associated requirements which must beanalysed in the context of safety issues.

The VORD toolset does not incorporate automaticconflict analysis, as viewpoint requirements need not be

11

expressed in any particular formal notation. The modeladopted by VORD is based on ensuring that information canbe presented in a way that manual analysis is simplified.Because the toolset automatically propagates relevantinformation across viewpoints, conflicting requirements canbe exposed by comparing the requirements across allviewpoints. Requirements have associated rationale andpriorities to aid in the analysis process. Conflicts areidentified and negotiated, and the results added to a proposedchanges report.Figure 11 shows the result of a three-way analysis of theSAFETY OFFICER requirements, PRODUCTION MANAGERrequirements and global system requirements. ThePRODUCTION MANAGER requirement for a continuallyavailable paper cutting service for periods of up to 1 monthis clearly in conflict with the safety requirement that theguillotine should be checked every day to prevent its lockingmechanism failing and causing accidents. The requirement isalso in conflict with the SAFETY OFFICER requirement thatmaintenance be done every two weeks.

Figure 10 Risk analysis proposals

The direct implication of this, is that the PRODUCTION

1.A project concerned with developing a safe requirementsMANAGER requirement is also in conflict with the global

specification for an autonomous mobile robot excavator.organisational requirement that the system should not cause

2.A project concerned with improving the requirementsinjury to its users. The result of the negotiated trade-off is

engineering process for the development of safety-relatedadded to proposed requirements changes and fed back into the

systems.requirements process.

8. Conclusions

We have described a requirements analysis method

(VORD), based on viewpoints, which incorporates safetyanalysis as part of the system requirements engineeringprocess. VORD has a comprehensive toolset which allowsviewpoint requirements to be collected, collated and analysedin the context of the associated system safety analysis.

VORD and its associated toolset are currently being usedin two collaborative research projects in the area of safety-related systems:

Our experience so far is that the integration ofrequirements analysis and safety analysis brings safety-relatedrequirements conflicts to light early in the process thusreducing the rework required during the RE process. As weuse the method to develop the excavator specification, weanticipate evolving the approach to include other approachesto safety analysis and improved facilities for navigating andviewing the viewpoint requirements.

12

Figure 11 Conflict analysis forms

Proc. 6th Int. Workshop on Software Specification andDesign, Como, Italy, pp.14-21, 1991.

Leite, J. C. S. P., “Viewpoint analysis: a case study.”Software Eng. Notes 14(3), pp.111-9, 19.

Finkelstein, A., Kramer, J., Nuseibeh, B., and Goedicke, M.,“Viewpoints: A Framework for Integrating MultiplePerspectives in System Development.” Int. J. of SoftwareEngineering and Knowledge Engineering 2(1), pp.31-58,1992.

Finkelstein, A., Kramer, J., and Goedicke, M., “Viewpointoriented software development”. 3rd Int. Workshop onSoftware Engineering and its Applications, Toulouse,France, pp.337-351, 1990.

Kotonya, G. and Sommerville, I., “Viewpoints ForRequirements Definition”. Software Eng. Journal 7(6),pp.375-387, 1992.

References

1. Bansler, J. P. and Bødker, K., “A Reappraisal of Structured

Analysis: Design in an Organisational Context.” ACMTrans. on Information Systems 11(2), 1993, pp.165-93.2.Gause, D. C. and Weinberg, G., Exploring Requirements:

Quality before Design. New York: Dorset House, 19.3.Schoman, K. and Ross, D.T., “Structured Analysis for

Requirements Definition.” IEEE Trans. on SoftwareEngineering. SE -3(1), pp.6-15, 1977.

4.Mullery, G., “CORE - A Method for Controlled Requirements

Specification.” Proc. 4th Int. Conf. on Software EngineeringMunich, pp.126-135, 1979.

5. Fickas, S., Van Lamsweerde, A., and Dardenne, A., “Goal-directed concept acquisition in requirements elicitation”.

6.7.

8.

9.

10.Kotonya, G. and Sommerville, I., “Requirements

Engineering with Viewpoints”. Software Eng. Journal11(1), pp.5-18, 1996.

11.IEE, Software in Safety-Related System. Joint BCS/IEE

Report, London: Institute of Electrical Engineers, 19.12.MOD, Safety Management Requirements for Defence

Systems Containing Programmable Electronics. Ministry ofDefence, 1993.

13.Leveson, N.G., “Software Safety: Why, What, How”. ACM

Computing Surveys 18(2), pp.125-163, 1986.

14.Leveson, N.G., Heimdahl, M., and Melhart, B.,

“Requirements Analysis for Real-Time Process-ControlSystems”. IEEE Trans. Software Engineering 18(2), pp.241-257, 1991.

14