Requirements Engineering

433-641 E. Kazmierczak

Course-work Masters The University of Melbourne First Semester, 2003

Aims and Administration

Aims
Requirements are a critical factor in the success or failure of software engineering projects. A large proportion of errors detected in released software can be traced back to faulty requirements or a poor understanding of the problem domain. The aim of this course is to explore the development of requirements, to provide you with a deeper understanding of Requirements Engineering, the role and impact of requirements on software engineering projects and the techniques and tools for improving problem understanding, requirements analysis and requirements specication. While this course focuses on the early parts of the software life-cycle we cannot really understand requirements unless we also understand something about software engineering, processes and the context in which requirements engineering occurs. Our path through the subject will therefore not necessarily be the shortest, nor the straightest. We dont believe that the shortest and straightest of paths is necessarily the most educational or the most interesting.

Topics Covered
The range of topics that we will be exploring1 follows. Topic 1 An Introduction to Requirements: where we will explore the textbook understanding of requirements and the role that they play in the software engineering process, the impact that they have and the goals of requirements engineering. Topic 2 Software Engineering Processes: where we will explore the role that requirements play in software engineering processes, and to how requirements engineering processes and software engineering processes are inter-related. Topic 3 Requirements Elicitation: where we will classify requirements, study elicitation techniques for requirements, and (qualitatively) evaluate their effectiveness. We will also seek some experience of elicitation methods but this will depend on the projects available. We will also look at Use Cases and other notations as a vehicle for problem understanding.
Please note that the word exploring is used and not the word studying. We will be hopefully be taking a more exploratory and questioning approach and doing some of our own research in this subject, and not just being lectured!
1

Topic 4 Requirements Analysis: where we will explore ways of deepening our understanding of the problem domain, the clients needs and way of making trade-offs. In particular we will be using UML as a notation for structuring and modelling the problem domain. Topic 5 Requirements Specication and Validation: where we will look at specication techniques for requirements and particularly what makes a good requirements specication. Topic 6 Measurement and Metrics for Requirements: where we will investigate some of the metrics, or measurements, that can be applied to requirements and their applications. Topic 7 Special Requirements - USABILITY: here we will explore a special set of requirements for usability. Usability is vital for many applications but needs special analyses and approaches specic to understanding the ways that people interact with computer systems. Topic 8 Special Requirements SAFETY: here we will explore the special topic of requirements analysis in safety engineering. The reason for exploring safety is that it is a good example of requirements engineering for a special domain where the standard approaches must be augmented in order to meet the stringent safety standards required in most safety critical applications.

Contact Details
Ed. Kazmierczak Email Room 3.20, 111 Barry Street ed@cs.mu.oz.au

Background Material
This course assumes a familiarity with the aims, methods and processes used in software engineering. Students who do not have this background material are urged to read the following texts in order to gain an understanding of software engineering basics.

Chapter 1, 2, 3 and 4 of Pressman [16]. Chapter 1 and 2 of Peeger [14].

Generic Skills
As part of this subject you will be required to understand both technical and people related problems and to derive solutions to them. You will be required to present your ndings and to work in small teams on project work. The subject aims to impart general communication, teamwork and problem solving skills and to deepen your skills in analysis and critical evaluation of your solutions. 4

Chapter 1 An Introduction to Requirements Engineering

1.1 Introduction
Software engineering has arisen as a discipline because of the very real need to deliver quality software on time (or at least in reasonable time) and on budget. This has not always happened in the past! Software engineering seeks to address the problem of ensuring that quality software gets delivered on time and on budget by setting out a systematic and disciplined approach to the development of software. We may say that current software engineering ideas are based on the following principles. (1) A sound understanding of development processes, project management and the ability to measure, monitor and control software development; (2) A sound understanding of the problem to be solved, the design methods required to solve it and the platforms used to implement the solution; and (3) A sound understanding of the range of tools and techniques required to support the processes and how they are to be used effectively to support problems. If we adopt the engineering approach to developing software and this comes from an engineering perspective then there are essentially three phases in the development of an artifact, such as a computer program: (1) Analysis, in which we must understand exactly what it is that we must build and how it should work in order to be t for purpose, (2) Synthesis, in which we must take our analysis and derive designs for building a concrete artifact, and (3) Realisation in which we must make our product a reality, that is, we must somehow build it and test that what we have built is t for purpose and meets the needs of our clients! In the study of requirements analysis we focus on the rst of these activities, that is, how to analyse a clients problem and their problem domain so that an understanding can be gained of exactly what software needs to be created in order to solve this problem. Such Requirements Analysis requires that we determine all of the functions, constraints, qualications, and other information relevant to 6

the system, and organise all of the information in a clear and unambiguous manner. Requirements analysis may occur repeatedly during the course of the development of a piece of software. There are many possible paths to understanding requirements engineering but time prohibits us from exploring them all. Our path in this subject will be to view requirements engineering as a problem understanding and domain analysis exercise. The set of requirements for the software come from this analyses.

1.2 What is Requirements Engineering?

Opinion (unsurprisingly for a relatively new discipline) differs as to the exact denition of requirements engineering. In these notes we will begin with two related denitions and will add to them as the subject progresses. Our rst task, however, is to understand what we mean by a requirement. We will use the following denition for concreteness, but again, it will be added to as the subject progresses. Denition 1.1 A requirement mandates that something be accomplished, transformed, produced or provided. If we adopt this denition then the aim of requirements engineering is to uncover what the system must accomplish, transform, produce or provide in order to meet a clients needs. As we have already stated above, our view is that this means developing an in depth understanding of a clients problem domain. An obvious denition of requirements engineering now follows. Denition 1.2 Requirements engineering is the discipline concerned with understanding and documenting software requirements. Another denition of a requirement is given in IEEE Std 610.12-1990. Denition 1.3 (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or processed by a system or system component to satisfy a contract, standard, specication, or other formally imposed documents. This denition has a much greater breadth and takes into account the fact that software may be part of a much larger system, or that a software engineering project may be part of a much larger project. Here, the aim of requirements engineering is to determine the external conditions that the system is required to meet, that is, the standards, specications, contracts or other formally imposed documents, and what capabilities the proposed computer system must possess in order to satisfy the external conditions. Requirements engineering now becomes: Denition 1.4 Requirements engineering is the discipline concerned with understanding the externally imposed conditions on a proposed computer system, determining what capabilities will meet these imposed conditions and and documenting those capabilities as the software requirements for the computer system. 7

1.3 The Importance of Requirements

Software engineering projects are all too often undertaken without a good understanding of the needs or wants of the client, or their problem domain. Developers lapse into making design decisions too early and without an understanding of all the constraints on the system to be developed. As a consequence unnecessary and (more typically) incorrect assumptions are built into the system and the result is all too often a system which fails to meet customers expectations! One way to understand the importance of requirements is to look at the costs of correcting errors. As an example, the typical relative costs of correcting an error at a particular stage of software development is given in gure 1.1 [5]. As an example, an error detected in the requirements phase is 0.2 Phase Requirements Design Coding Unit Testing Acceptance Testing Maintenance Relative Cost 0.1-0.2 0.5 1 2 5 20

Figure 1.1: The relative costs of correcting errors made at the requirements stage of a project. times as costly to x as an error detected in the coding stage. An error detected in the maintenance phase is 20 times as costly to x as an error detected in the coding stage. Figure 1.1 gives the cost of detecting and repairing an error in the coding phase relative to the cost of detecting and repairing errors in other phases . To understand better the reasons for the multiplying factor Figure 1.2 shows the cumulative effects of errors made at the various stages. Other studies, such as the one reported in Sallis et.al. [19] estimate that the percentage of errors in released software due to specically to requirements to be in excess of 50% of all errors detected. Similar evidence suggests that concentrating effort earlier in software development processes can have a dramatic effect1 .

1.4 Approaches to Requirements Engineering

A number of approaches to requirements engineering have been established over the last three decades. For example, more orthodox approaches [16, 21] tend to break up the requirements engineering phase into a set of activities which can be performed iteratively, while object oriented analysis

The Orthodox View

Perhaps the most generic viewpoint is to look at the principle activities underlying requirements gathering and problem domain understanding.
But be cautioned! What we are talking about here are principles that have been used effectively over time and are not absolute!
1

The real problem

Correct Spec.

Erroneous Spec.

Correct Design

Erroneous Design

Design based on erroneous spec.

Correct Programming Programs based Programs based Programs Errors on erroneous on erroneous design spec.

Correct Correctable Function Errors

Uncorrectable Errors

Hidden Errors

Figure 1.2: The cumulative effects of error!

Requirements Elicitation The process through which clients and developers review, articulate and understand the needs of the clients and the constraints on the software. Requirements elicitation requires involvement with the client, domain experts, and end-users (at least!) in order to establish an the clients needs and the constraints on the computer system must have. Here we use techniques such as: (1) Interviews, (2) Questionnaires, (3) Focus groups, (4) Apprenticing, and (5) modelling. Requirements Analysis The process of analysing the needs of the clients in order to arrive at a denition of the requirements. If elicitation activities are intended to gather constraints then analysis aims to deepen our understanding of the constraints and client needs. Typically, modelling of the requirements is involved and is done while also eliciting requirements. Requirements Specication The process by which a document is developed which clearly communicates the requirements. The viewpoint that we want to develop in these notes is that the requirements exists independently of their specication2 The requirements are captured, or expressed, or articulated, in a software requirements specication. The IEEE has put down eight criteria for an SRS to be considered acceptable and these are: (1) correctness of the requirements, (2) completeness of the requirements, (3) consistency of the requirements, (4) trace-ability of the requirements, (5) Prioritorisation of the requirements, (6) that the requirements be unambiguous, (7) that the requirements be testable, and (8) that the requirements be modiable. Requirements Validation The process of ensuring that the requirements and the Software Requirements Specication are in compliance with the needs of the clients and the system. Validating the requirements is not an easy task as the clients, end-users or domain experts may not even know what correct ought to be. A good example of this was th early days of the A3420 Airbus project where design and problem understanding evolved almost together. Some techniques here include (1) reviews, inspections and walkthroughs of requirements, and (2) prototyping. Requirements Management The planning and controlling of the requirements engineering processes. Typically, requirements management also means being able to track the dependencies between requirements. Good requirements management often requires good requirements management tools. Requirements are divided into four chief classes. Functional Requirements: Functional requirements determine what the system must do. The key functions of the system determine what must be transformed, accomplished, produced or provided by the system. For example, the software for an A320 Airbus must provide: a safer ying envelope by maintaining the aircraft between its maximum climb angle and maximum angle of descent3 .
Then we can talk about the logic consistency of the requirements and their groupings independently of how they are actually set out on paper. 3 The maximum angle of climb is called the ceiling and the maximum angle of descent is called the oor.
2

10

 ight alleviation functions such as stability during turbulence. Functional requirements are not concerned with how these functions are to be achieved, just what is to be achieved. The Underlying Information Model: The information model for the problem domain consists of a logical representation of what information resides in the system, who needs the information and where does it come from, what processing of the information occurs and who processes it, what transformations of the information take place.

The Intended Behaviour of the System: The behaviour of the system is how it responds to external events, for example, if we click the right mouse button when viewing a window, how should the system respond. More importantly, if an Automated Braking System detects a vehicle within a specic distance what should the behaviour of the vehicle be? Should it slow? Should it apply brakes fully? We must answer these questions if we are to determine the behaviour of the system. Non-functional Requirements: This category deals with attributes, or properties, of the software rather than functions. We include here aspects of the software such as its performance, its usability, its reliability, any safety aspects and a range of other attributes. The context of the system, and this includes the needs and aspirations of the client, the potential user community, regulatory bodies and other stake-holders, must also be taken into account. This include here the environmental and physical factors as well as the developers risks, available technologies, expertise and costs.

A Problem Solving Approach to Requirements Engineering

Davis [5] provides a renement on the more process centred view given above. He starts by observing that a problem analysis is about understanding the problem domain. Ultimately, however, we will be required to produce a software requirements specication that will delineate the range of possible, or acceptable, solutions to the problem and this range of solutions needs to be clearly dened. Initially, however, we typically know very little about the problem domain, but as the elicitation process continues the solution spaces becomes more dened; in effect as each new set of requirements is added the range of possible solutions is reduced. Several factors can inuence the set of requirements as the problem understanding process continues [5]. The clients needs will form part of the requirements. Clients will often say what it is that they want, but as engineers we must also determine what is needed in the situation. The client, as far as these notes are concerned, is the individual or organisation commissioning the software project. Typical client concerns include, functionality, development time, maintenance, cost, modiability, reliability, and performance. The client should also be concerned with the legal and ethical environment in which the software will operate.

11

ok ok

(a) Client needs

(b) Users needs

ok

ok

(e) The product space (c) Developers perspective (d) Technological risks

Figure 1.3: Dening the solution space [5].

12

 Potential users too may be able to express their wants quickly and effectively, but again it is the engineers task to determine what is actually needed. Users are typically also concerned with functionality, reliability and performance but are also concerned with their interaction with the system, that is, its usability and interface, as well as the impact that the system will have on them and their tasks. The developer also has a perspective on the system. In addition to delivery of a product which satises the customers requirements the developer is often concerned with legal issues, market share, time-to-market, protability, relationship to existing products and in-house expertise to do the job. The legal and ethical framework in which the software is to operate will certainly inuence requirements. This is especially relevant to safety critical systems where the cost of a mistake can be catastrophic. Technology has a major impact on the product space, and the possibility of completing a project in the required time-frame may depend critically on the choice of technology. Questions include the following: What are the risks of using existing technology? What are the risks of using yetto-be-developed technology? What technology will give us the best chance of success and will it be available in time? During problem analysis all aspects of the problem domain need to be investigated, that is, investigate the needs of the clients, investigate the needs of the current users, investigate the functions performed by these people, and investigate the physical, intellectual, legal and ethical environment that people must work in. Davis makes the point that a problem analysis usually involves people. In the case of most software projects it will involve the client or their duly appointed representatives, the potential users of the system, technical and domain experts and perhaps even representatives from regulatory bodies. Such people have an enormous amount of knowledge about the problem domain in their heads and it is the job of the analyst to extract as much of that knowledge as possible. Typically, interviews, formal meetings with chairman and secretary, questionnaires and direct observation are methods used to determine what information is present. The process of gathering information is however, iterative. Once we have established certain facts we may know better what further questions need to be answered. Remark 1.1 There is a tendency to start solving the problem and do design work during problem analysis. The two activities are very different. Analysis traditionally focuses on understanding what the clients needs are and what the system should do to meet those needs. Design is focused on how to achieve those needs. Ideally, we would like a clean separation between requirements and design but in practice this is difcult. The nal requirements specication must take into account the feasibility and cost of requirements and so a technical assessment of the system must have been made. Some very recent thinking has suggested that architectural design and the requirements specication should be done at the same time. 13

Object Oriented Analysis

1.5 A Final Note on Requirements

Requirememts come from a number of sources but most often it involves clients and end-users. This makes requirements engineering a remarkably social process 4 [13]. There is a great deal of domain knowledge within the people who act as stake-holders for the system and it is an unfortunate observation [13] that much of that knowledge remains locked away, even after the requirements specication has been written and the system built. The result is that many key facets of the problem are only discovered during the system development, or worse, after a system has been released. Ideally, analysts must try to uncover as much of this information as possible and provide it in a convenient form for the development team. Requirements engineering can also be a very difcult activity to get right since typically even the clients and domain experts may not understand what is really needed in the early phases of the project and analysts must determine what they really need rather than what they say they want.

Oestereich, in his book Developing Software with UML is actually talking about more specically about creating object-oriented analysis and design models but his comments are accurate in the more general context of requirements engineering.

14

15

16

Chapter 2 Requirements Analysis in Software Engineering

The purpose of this chapter is to understand the role of requirements engineering in the context of software engineering. Indeed, requirements analysis (in some form) is an integral part of all of the software engineering development processes used to today.

2.1 What is Software Engineering?

There is no denitive answer to this question and there are almost as many answers as there are textbooks. Our perspective, which also dominates our approach to requirements, can best be summed up as follows [9]. What distinguishes engineering, and consequently software engineering, from ad hoc development is the ability to exert control over the quality and outcomes of the products developed within the project. In this way, software engineering is the study of the processes, methods, tools and techniques for achieving such control over the quality and outcomes in software development. The control over the quality and the outcomes of the project that we are talking about in the denition above means that software developers are able to: repeatedly determine and achieve the desired level of quality for their products; measure and improve the quality of their software products; and predict, plan and manage the development of their software products. Our view is that in software engineering we exercise this control at a number of different levels which are depicted in Figure 2.1. The choices made at each of these levels can signicantly affect the quality and outcomes of a project. As a contrast, below are two more denitions from popular works in the eld of software engineering. A traditional denition goes which is still referred to is that of Bauers [16]. 17

Software Engineering Processes Engineering Methods Development Tools and Environments Implementation Platforms

Lifecylce Processes e.g. Waterfall, Iterative or Evolutionary processes Methods for "building-in" desired properties of the software e.g. performance, reliability or usability; or methods for requirements engineering or design. Case tools, debuggers, documentation tools, version control and configuration management tools. Hardware, operating systems and implementation languages.

Figure 2.1: The layers at which control can be exercised in a software engineering project. Denition 2.1 Software engineering is the establishment and use of sound engineering principles in order to obtain economically, software that is reliable and works efciently on real machines. The IEEE standard [8] renes this denition and puts it in the following form. Denition 2.2 Software Engineering: (1) The application of a systematic, disciplined, quantiable approach to the development, operation and maintenance of software, that is, the application of engineering to software. (2) The study of approaches as in (1). Another denition appears in Peegers book [14], although it is not so much a denition as a perspective, much like ours, to software engineering. Denition 2.3 Software engineering is about using our knowledge of computers and computer related systems to solve problems.

2.2 Software Quality Assurance A First Pass

Quality is a ubiquitous concern in software engineering. Achieving quality pervades software engineering processes, methods and tools and is one of the chief foci of project management. Quality products can increase market share and long term protability for companies and poor quality can certainly have the opposite effect. Yet, in spite of the focus on quality in software engineering, it can be remarkably elusive in actual software engineering projects. Another driver for quality is that the sheer complexity of many modern systems, the number of changes to requirements and to designs during development and the diversity of platforms and users requires constant assessment of the quality of the product just to make sure that our nal product is satisfactory. To build software according to engineering principle we must be able to identify what characteristics the nal system must have and then to choose tools, techniques and processes ensure that the

18

required characteristics are achieved in the nal product. In this context, quality is a set of characteristics that we want to build into any piece of software, and our job as requirements engineers is to identify the key quality drivers and attributes for the software project. What is Software Quality? Ask ten different individuals what software quality means and you are likely to get ten different answers. Here is a sample of the possible viewpoints on software quality. 1. End-user Perspective: Typically, end-users judge the quality of a product by their interaction with it. For users a system has quality if it is t for purpose, reliable and has reasonable performance, is easy to learn and use and helps the users in achieving their goals. Sometimes, if the functionality is hard to learn but is extremely important and worth the trouble of learning, then users will still judge the system to have high quality. 2. Developers Perspective: The developers perspective typically also includes the number of faults that the system has, ease of changing the system, ease of testing the system, the nature of the design, the re-usability of components, conformance to requirements, and resource usage and performance of the systems to judge quality. 3. Maintainers Perspective: The maintainers perspective certainly includes many of the developers perspectives on quality but also includes the simplicity and modularity of the system, the documentation produced by the developers and the ease of understanding the implementation. Ideally, the job of the software engineer is to choose processes tools and techniques to monitor and control the quality of the products being developed or the quality of the processes being used to develop the product. Monitoring the quality of a product or a process often involves the measurement or assessment products or processes to see if they meet the right level of quality. But, how do we determine the right level of quality? How can we measure or evaluate quality? There are a number of facets to quality. Adherence to Standards It is generally accepted that quality software is developed according to standards. Such standards may be formal external standards such as the IEEE or the IOS/IEC software engineering standards (see chapter 3 below) or indeed standards developed by the project team. Certainly, safety critical or high integrity software must be developed according to very rigid standards. Ensuring that software is developed according to standards is aimed at ensuring that the each component of the nal product undergoes exactly the same analysis, design, verication and documentation processes as every other component. Consequently the standard of the nal product is uniform and meets the expectations of the organisation and our community; even if it has been developed by a team. As an example, a requirements specication can be developed according to the Standard IEEEStd. 830-1998 and reviewed to ensure that it meets the criteria in IEEE 830-1998 as the quality gate. Satisfy the Clients Needs The software must be t for purpose and must meet the clients needs. The emphasis here is on establishing quality gates that ensure that the clients needs are met and that the software being developed is t for purpose at every stage of the development.

19

 Satisfy Explicit Requirements The nal product must satisfy the requirements of the project. The emphasis here is on proper design and trace-ability of requirements through to code, as well as quality gates which will ensure that the code meets its requirements. However, ensuring that the product is correct with respect to its requirements is only one aspect of the quality of a product and we will also need to ensure that the product meets other quality attributes, or nonfunctional requirements. Satisfy Implicit Requirements Even though explicit requirements are met by the software there are still a host of implicit requirements that characterise good software and these obviously include the quality attributes. There is a trade-off here! Typically, there is not enough time or money in a project to engineer everything to the highest level of quality. We must decide on what quality attributes, or implicit (non-functional) requirements are important and expend effort in assuring these. Quality cannot be measured or assessed directly except perhaps by having someone inspect artifacts for quality. The problem with inspection alone is that it relies heavily on an individuals understanding and interpretation of quality. Ideally, we would like to remove such biases where-ever possible and seek more objective measures of software quality. For this reason software engineers often build models that break quality down into a number of attributes. An early model of quality and its attributes was given in the ISO standard ISO-9126 and part of it is shown in Table 2.1 below.

2.3 Software Engineering Processes

One of the key ways of controlling the quality built into a product is to apply software engineering processes and software engineering methods to control the characteristics of quality (as sketched in section 2.2 above). Indeed, here we nd one of the key premises underlying software engineering processes: The quality of the product depends on the quality of the process! Furthermore, this process can be dened, managed, measured and improved and that by doing so we improve the quality of our products. One of the key observation about process is due to Royce [17] (but see also [16, 21]) that regardless of the actual process used to develop a piece of software, a process will always contain the following generic activities. Requirements Analysis is an activity which may occur repeatedly during the course of the development of a piece of software. Requirements analysis requires that we determine all of the functions, constraints, qualications, and other information relevant to the system, and organise all of the information in a clear and unambiguous manner. This is the real analysis part of an engineering activity. Design is an activity by which we synthesise a (logical) structure for the system which satises all of the requirements. In essence, the design activity transforms requirements into a representation of the system which can be assessed for quality and suitability before coding begins. Designs 20

Characteristics Functionality

Sub-characteristics Suitability Accuracy Interoperability Security Maturity Fault Tolerance Recoverability Understandability Learnability Operability Attractiveness Time Behaviour Resource Utilisation Analysability Changeability Stability Testability Adaptability Installability Co-existence Replace-ability

Reliability

Usability

Efciency

Maintainability

Portability

Table 2.1: ISO 9126 quality attributes and their sub-attributes.

21

themselves may be multi-faceted, for example, we may have architectural views of a system, detailed, or algorithmic, views of program modules, a control hierarchy for the system and data ow. Coding is the activity by which designs, or design elements, are translated into machine readable form. This, and testing, are the real realisation activities of an engineering process. Testing is actually a set of activities which are aimed at uncovering errors in the system. Testing can be conducted at several different levels: unit testing, integration testing, system testing and acceptance testing. Maintenance is the process by which the system is extended, corrected and enhanced. Maintenance activities can encompass requirements, that is new requirements for the system, design, coding and testing as well as correcting errors. In general, a processes consist of a number of phases, each of which can consist of a number of other activities. In general, a phase has a number of inputs, a number of outputs and typically requires a quality check, as in Figure 2.3.

Quality Test

Inputs

Process

Outputs

Figure 2.2: A diagrammatic representation of a typical software engineering process phase. Example 2.1 The software engineering standard IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specications species eight properties of a good Software Requirements Specication: (1) Correctness, (2) Completeness, (3) Consistency, (4) Trace-ability, (5) Veriability, (6) Modiability, (7) Clarity and conciseness of specication, and (8) prioritorised requirements. To determine if the software requirements specication is acceptable an SRS review can be held. If an SRS review is to be the quality gate for the requirements phase then the SRS must be reviewed against the eight criteria above if we are to assure ourselves that the SRS satises IEEE std. 830-1998. In general, the ordering of the phases, the choice of quality checks and the activities making up a phase constitutes a process (or process model). A number of such process models have been proposed in the literature (see, for example, [16, 21]) in order to cope with various kinds of project circumstances. These include: Variants of the linear sequential, or waterfall, model; 22

Interviews Questionnaires User Interface Prototypes External Documents Quality Gate: SRS Review Requirements Phase Software Requirements Specification

Figure 2.3: A possible requirements phase in a waterfall development process. Prototyping models; The Rapid Applications Development (RAD) model; Evolutionary models The Incremental model; The Spiral Model model; and The Concurrent Development model. Agile Processes. The Rational Unied Process. Each process has its own peculiarities, for example, the Spiral model [2] combines prototyping with aspects of the waterfall model to minimise the risk of missing or misunderstood requirements.

2.4 Requirements Engineering in Software Life-cycles

Most software engineering processes involve a requirements analysis, or problem analysis, stage. Understanding software engineering processes and the role that requirements plays in these processes is the subject of this section.

The Waterfall Model

The waterfall model is a venerable process template whose history goes back to the paper by Royce [17]. Royce did not actually advocate that the life-cycle phases in his paper should be a process for software development but rather, that whatever process be used should at least include a requirements analysis, design, coding, testing and maintenance phase. The collection of phases (see section 2.1) later became the basis of a process and, together with its variations, has been much used since. Variations include providing processes for the results of one phase to feedback into a previous phase as in Figure 2.4, or to include internal iteration within a phase as in Baseline management approaches.

23

Requirements

Design

Coding

Testing

Maintenance

Figure 2.4: The Waterfall Model Baseline management is a variation on the waterfall model which allows for iteration within a phase and stringent conguration management procedures for base-lining the results of a phase. As the name implies, in the pure waterfall model each phase should ideally be completed before the next one is commenced. In practice, however, this is not always true, for example, architectural design may be started before requirements analysis is complete. Supporters of the waterfall model claim that is provides good support for projects which are relatively well understood and provides a good model for estimating project costs and tracking progress (see for example, [4, 21]). To make the waterfall model more effective, feedback from later phases may feed-back into earlier phases, for example, an unforeseen technical constraint may force additional investigation of the problem domain. Also, prototyping at the requirements and design phases may be added in order to improve the developers condence in the outcomes of these phases (see Figure 2.5). Detractors of the waterfall model assert that it does not take into account the technological and domain directed risks inherent in software projects [2, 14], nor does it allow for the iterations that are required as understanding of a project evolves during the course of a project [14]. Further, for large and complex processes there is not enough feedback provided to client and it may be months (or years) between commissioning a system and seeing some part of it working. This implies that requirements for a waterfall development should remain relatively stable throughout the project. Unless the project is in a well understood domain where iteration over artifacts is not necessary then the waterfall is not suitable. Note that each major phase within the waterfall model is concerned with the production of an artifact in the very way as depicted in Figure 2.3. The early phases are consequently, not only concerned with developing a complete description of what needs to be done but also of what can be feasibly implemented. Another version of the waterfall is the V model (see Figure 2.6) which is used in projects where safety, correctness and high levels of assurance need to be given. Its is easier to see from Figure 2.6 that requirements do not only have an impact on the development but also on the systems verication 24

Requirements

Design

Coding Exploratory Prototyping Experimental Prototyping Testing Maintenance

Figure 2.5: The Waterfall Model

Feasability Study

Corrections

Review

Requirements

Corrections

Acceptance Testing System Testing

System Design

Corrections

Program Design

Corrections

Program Testing

Code

Figure 2.6: The V model of software development which matches up development stages with assurance activities.

25

and acceptance. However the model is presented, the emphasis on understanding the problem domain and eliciting a stable set of requirements is shifted to the early phases of the project. A corresponding increase in effort should therefore be made to elicit, specify and validate requirements early in the development process.

Incremental Development Models

Incremental development splits the development into a number of increments based on either functionality or some other criteria. Typically, each increment is delivered to the client after it is nished. The model calls for a single requirements phase, followed by a number of increments, each consisting
Requirements Design Code Test Integrate Maintain

Design

Code

Test

Integrate Maintain

Figure 2.7: Incremental development of design, coding, testing and maintenance phases. In principle requirements analysis must be done at the start of the project, as in the waterfall model, but in practice feedback from users can inuence both the requirements of latter increments and the design of latter increments. While incremental delivery offers more exibility than a waterfall and reduces some of the risks of a changing environment, the process needs to well managed. If requirements are changing then we must at least keep an accurate record of which requirements pertain to which increment. Typically we would want to ensure good conguration management procedures before commencing incremental development.

The Spiral Model

Many projects are risk driven. The process model proposed by Boehm [2] aims to control and manage project risks during the course of development as well as provide opportunities for understanding the problem domain throughout the development and for building the system incrementally. The spiral model begins with an initial plan for development, evaluate risks, perhaps do some prototyping to evaluate alternatives at the system level, and produces a concept of operations document which describes how the system should work at a high level. From the concept of operations, a set of requirements for the system is extracted and this should be as complete as possible. The spiral model then uses to iteration to complete the development. Unlike the incremental approach however, each iteration typically involves risk analysis, prototyping to determine the feasibility and desirability of various alternatives and then design, coding and testing.

26

Risk Analysis Risk Analysis Risk Analysis Prototype Req. Plan Concept Phase Development Plan Integration and Test Plan Plan Next Phase

Operational Prototype Prototype

Concept of Operation Software Requirements

Software Req. Validation

Detailed Design

Figure 2.8: The Spiral Model The spiral model (see Figure 2.8) allows for a complete re-evaluation of the project direction after each spiral, and this of course means that requirements can be re-evaluated. Again, there is an issue with managing the spiral model and requirements need to be managed carefully. In particular, we need to ensure that new insights, which lead to new requirements are consistent with prior requirements and with the what has been built thus far. The purpose of this chapter is to understand the role of requirements engineering in the context of software engineering. Indeed, requirements analysis (in some form) is an integral part of all of the software engineering development processes used to today.

27

28

29

Chapter 3 Eliciting Requirements

3.1 Trawling for Requirements
Starting the Elicitation Process
Eliciting requirements is about determining all of the sources of requirements and then using these to understand, to the best of our ability, the problem to be solved and the characteristics of the solution. The process of eliciting requirements is itself often iterative, with each meeting nding out more about the project and rening our understanding of the problem to be solved. Early in the requirements process it is good to determine the following four elements of the project: (A) the purpose, aims and a basic understanding of the problem that requires a computer solution; (B) an understanding of the context and the environment in which the project will take place; (C) an understanding of the impact that the client expects the system to have; (D) an understanding of the motivation and expectations of the client. We have already met many of these properties during our discussion of quality, but it may not be apparent to the client which of these properties are essential to the success of their system. After the initial interview the next step is to understand the problem domain and determine exactly what part of the problem the new system will automate or solve.

3.2 Stake-holders and Their Cousins!

Software engineering Projects are typically the result of somebodys need, somebodys idea, or an opportunity that someone has seen. Before a project can begin, however, the initial idea must be turned into something more concrete. Funding must be found for the project. If the software is to be used within an established organisation then funding must be sought from the organisation and the project must get approval. If 30

Pressman suggests some questions which are aimed at uncovering context and client expectations, that is, points (B), (C) and (D) above. Pressman suggests that these questions should be asked rst but in practice they can end up being asked at anytime. 1. What is the new system intended to achieve? What is it intended to replace? What sort of system would you like? 2. Who will the users be? Who will the operators and maintainers of the system be? 3. Is there an existing system which is similar? What is wrong with it? How can it be improved? Is there are manual or paper system in place? Where can it be improved? Why have you decided to automate? What savings or economies do you expect? 4. What will the real benet of the new system be to you? 5. What sort of environment will the system be used in? We can then follow-up the questions in Figure 3.1 with questions designed to to understand point (A). 6. What should the system achieve? 7. Can you provide examples of inputs and outputs for the system? Can you provide samples of reports or data for the existing manuals system? 8. What standards does your company use? What standards would effect this project? 9. What special properties do you expect this system to have? Should it be: safe, reliable, high performance or real-time, secure, have high levels of usability.

Figure 3.1: Some suggested questions for starting the requirements process in an interview.

31

the software is to be sold on the free market then other forms of funding, such as venture capital, corporate sponsorship or government assistance, must be found. The point of all this is that by the time we are actually ready to plan and launch our project there has already been a signicant amount of activity with a potentially large cast of characters. It is important to understand who has been involved in establishing a project and what their stake is. Answers to the following questions contribute to project risk, requirements and ultimately choice of development model.

Identifying Stake-holders
Identifying all of the stake-holders early in the project is important for the project management, nding all sources requirements and for understanding the constraints on the project. Stake-holders in a project are those people, groups or organisations that have an interest, or a stake, in the software or will, in some way, be affected by the software. The key stake-holders in a project are usually the client for the project, the sponsor of the project, customers, end-users, and the developers of the software. Other potential stake-holders include the technical experts, developers of interconnected systems, regulatory bodies, other professional bodies. There are important reasons for identifying all of the stake-holders in a project, what each of them controls in the project, and their motives. Identifying the stake-holders for a project is important for requirements analysis. If all of the relevant stake-holders are not included in the requirements analysis process then there is a danger that some potentially critical requirements will be missed. A good understanding of who controls what in the project can help to resolve conicts and inconsistencies in requirements, and knowing who controls your project is certainly important if you need to negotiate for more time or money. Understanding the area of control and the motives of stake-holders such as any independent auditors and reviewers involved in your project can help you to prepare and meet their concerns without delay to the project. Understanding the motives of your stake-holders also lets you determine the best ways of approaching stake-holders during the project and perhaps anticipating how they will react in different circumstances. Some of these points are tied to project risk.

3.3 Requirements Elicitation Techniques

Several techniques may be employed in order to gain such an understanding, for example, we may use Interviewing, 32

 Questionnaires, Focus Groups, Direct Observation, Apprenticing, Brainstorming, Joint Applications Development; Prototyping, and Use Case Modelling. Interviewing, focus groups, apprenticing and brainstorming uncover information in the form of business rules and processes, standards, legal and ethical constraints, users likes and dislikes and their working habits, as well as what needs to be transformed, provided, accomplished or produced. Models in the from of formal methods or in the form of Object Oriented models can a key aid for organising all of this information and uncovering inconsistencies, incompleteness and ambiguities in the gathered information. Finally, good modelling methods and notations allow us to systematically understand how each piece of information ts into the workings of the whole. Use case modelling we will deal with in Chapter 4 and prototyping we will deal with in Chapter ??.

Interviewing
Interviews can be conducted with clients, end-users, technical experts, or indeed any of the stakeholders associated with the project. Interviews provide a good form of Data Collection about the problem requiring a computer solution as perceived by the interviewee. Note, that capturing expert information is often critical but also often overlooked. Ideally, information gathered during an interview should be veried from other sources or crosschecked. This reduces some of the potential biases in interviewees. Interviewing is exible and encourages participation of the stake-holders in the project but interviewing requires expertise and much practice to get procient. There can, however, be a tendency to gather Soft information that is too vague to use. Poor or inexperienced interviewers may leading the interviewee or develop Selective hearing of interviewee. An interviewers opinion may be inuenced by stereotyping of interviewee. There is also the danger that the information gathered may not grounded in fact.

Questionnaires
Questionnaires have the potential to gather large amount of data quickly, can be precisely targeted and are relatively inexpensive to run. They can be conducted with large numbers of people audience by using mail or email and often do not require much time for staff to ll in. More importantly, questionnaires permit anonymity in requirements elicitation and can be supported by technology. 33

The problem with questionnaires however, is that designing them can be difcult, questions can be ambiguous and the lack of direct contact prevents clarication of issues. More typical is a poor response rate and the data can remain untested unless good follow-up methods are employed. There is also a danger that the respondents may be careless in lling in questionnaires or may feel antagonised at having to ll them in.

Focus Groups
A focus group is a relatively informal meeting of a small group of people (some sources recommend keeping the number above ve but under ten people) who represent one or more aspects of the requirements. For example, we can have a focus group on the user interface design in which a representative selection of the people who must use the system are present. Focus groups are excellent for bringing out spontaneous reactions and are a good way of getting from people what they actually want from the system. The group atmosphere may stimulate ideas and may help to bring issues in the requirements into the open. Focus groups can be problematic in actually resolving the issues and for making decisions about requirements. Focus groups will not generally provide requirements detail or know what the constraints on a system should be.

Direct Observation
Direct observation means observing users conducting the tasks (not necessarily all of the tasks) that they will be carrying out with the new system, but using an existing or manual system. It is widely accepted in the HCI community that direct observation is essential for understanding tasks in a situation. Direct observation is a good starting point prior to more extensive observation and can be inexpensive. It is also a valuable information-gathering tool where the requirements engineer gains insight about what is actually done, not just what is documented or explained. Users, however, can get resentful at being under constant observation and the th e presence of an observer may affect what is observed (Hawthorne effect). Further, decisions must be made about what is important to record and since these decisions must usually be made quickly, there is a possibility of missing important events. A renement of this technique is the technique of apprenticing where the requirements engineer actually conducts the tasks that users of the system will be carrying out. This has the added benet that the requirements analyst gains critical insight into the tasks required of the new system. There can, of course, be difculty communicating and capturing some of this insight but if the analyst is an integral part of the development team then apprenticing can be a powerful tool for understanding what tasks a system must support.

Brainstorming
Brainstorming can be an effective way to generate lots of ideas in a short space of time. It works by having a number of people in a relaxed informal environment. The statement or problem for which 34

ideas are sought is stated and then the people in the session simply shout out ideas until the time limit is reached. All of the ideas are captured and after the meeting these ideas are sifted to determine which idea(s) best solves the problem. There are rules to a brainstorming session, for example, no criticism of ideas is allowed and no discussion of ideas is allowed. Brainstorming is good for creative input into a requirements session, perhaps when something new is being sought or there is a difcult problem to overcome. Brainstorming is not appropriate for any kind of analysis or for decision making.

Inspecting Documents
Inspecting documents is a good means of gathering requirements where existing systems have been formalised. The information gathered is usually qualitative but the data is also usually reliable. Documents are a good source of information for checking facts from other sources as they do not rely on staff cooperation. Informal systems and processes, or those systems and processes that are not documented are typically missed. Further, there is a problem with documents eventually becoming dated and so there is a need for the requirements analyst to ensure that documents are current and live! Document inspection can be time consuming so there is often a need to be selective. Also, data may not be in an immediately usable form and there is usually no information on attitudes or opinions.

Joint Applications Development

A JAD session is a structured session in which customers, designers and other experts come together to plan, understand and in aspects start designing the system to be built. JAD sessions require a clear statement of the purpose of the session and its goals. JAD sessions are usually run by a facilitator who keeps the participants focussed. It can have observers, but observers must remain silent according to the rules of JAD. JAD ensures users get involved early in project and facilitates gathering user requirements and can help the design process. It gains user commitment to project and helps resolve issues. The use of an external facilitator who is open and impartial to the requirements can help the process. Projects can run better with group decisions and JAD sessions make sure that users from different areas of business or stake-holders are brought together. The problems are however, as with any workshop, that the JAD session may not reach a consensus on critical issues and can be very can be time-consuming. Experience suggests that there is a need for a good facilitator to involve best user participants. Individual user participants may dominate workshop and other users may feel threatened by project or may feel excluded from decision-making process.

35

36

37

Chapter 4 Use Cases

4.1 Introducing Use Cases
Use cases are a notation for specifying the intended behaviour of a system and how it interacts with users and other systems at a high level of abstraction. Use case are the generic activities, or tasks, that a system is to carry out if it is to meet its clients needs. Use cases are very general in that each use case can cover a number of different scenarios and these scenarios make up the behaviour of the system as far as external entities are concernede. In this way, use cases determine: 1. The boundary of the proposed system; 2. how other entities interact with the system; and 3. what tasks the new system needs to accomplish. In the language of use cases the other entities are called Actors and can be people; other external devices; and other computer systems. Each actor plays a role in the use case diagram and it is these generic, or sufciently general, kinds of roles that we wish to capture using actors. Example 4.1 John Smith and Mary Bloggs both borrow books from the library. The use case (task) that we want to capture is Borrow a copy of a book and we identify an actor Book Borrower whose instances are John Smith and Mary Bloggs. The actor plays the role of a generic somebody who wants to borrow a book. Use cases are represented by ovals and actors by (stick) gures. A simple use case diagram is given in Figure 4.1. We may also have Mary Bloggs playing the role of librarian which introduces another actor, the Librarian actor, who interacts with the use cases Borrow a copy of a book and Update Catalogue. 38

Borrow a copy of a book Book Borrower Update Catalogue Librarian

Figure 4.1: A simple use case diagram for the book borrower example. Note that it is the role that is important and the actor exemplies that role. A further aspect of analysis is that not all actors will necessarily gain benet from the use case even though they may be involved. An actor who gains value from a use case will be referred to as a Beneciary [15]. Identifying the beneciaries of a use case is valuable for motivating the need for a specic set of functions or behaviours, for if the system has no beneciaries then we are likely to be in a situation where somebody believes that it is good to automate something but nobody really wants the system. Actors can be human, but they can also be devices or external computer systems. In this case we must determine use cases at the right level of abstraction, for example, it may not be appropriate to treat the mouse and keyboard as external devices in many contexts. Including irrelevant detail will often complicate the model. Ultimately the decision on what detail to include is pragmatic, but some guidelines are offered in [15] who suggests that there are three choices of when to show interactions when dealing with external devices: always, when the other device or system initiates the contact, and when the other device or system is the beneciary. In this course we will use use cases, and UML models, to rene our requirements, integrate new requirements and to informally check the consistency and completeness of our requirements. Of course, there is still the problem of elicitation to deal with before any real modelling can occur. Returning to our library example we may have the following set of scenarios. 1. Mary Bloggs borrows the third copy of War and Peace when she has no other books on loan. The loan is allowed and the catalogue is updated accordingly. 2. John Smith attempts to borrow the rst copy of Anna Karenina but he already has the maximum number of books on loan and so is refused the loan. 3. Alan Alder attempts to borrow the second copy of Crime and Punishment but must get authorisation from the librarian Mary Bloggs because he has an overdue book. Mary Bloggs authorises the loan and the catalogue is updated accordingly. 39

The rst two scenarios are instances of the use case diagram shown in Figure 4.2 but the third scenario is not because it involves the Librarian actor which is not part of this diagram. To capture the third
Borrow a Copy of a Book Book Borrower

Figure 4.2: scenarios we would need a diagram as in Figure 4.3.

Borrow a Copy of a Book Book Borrower Librarian

Figure 4.3: Observe that these scenarios can get quite complex, that there are variations in the use cases, and that they can be structured. Thus, use cases can embody complex requirements for the system. Thus we need to: provide detailed scenarios for each use case, and specify the circumstances under which each scenario applies. This information can be provided either textually, perhaps using the template for specifying ow of events as shown in Figure 4.4 [13], or using UML activity diagrams. Modelling requirements via use cases requires two simple steps; 1. Identify actors and beneciaries, 2. For each actor, what they need from the system, that is, what use cases have value for them, and any other interactions they expect to have with the system, that is, which use cases would they participate in for somebody elses benet. Use cases are a scenario based elicitation and modelling technique. A group of related scenarios relating to the tasks that the user wants or needs to accomplish are collected into a Use Case. The library use case diagram may appear as follows. The beneciary of the use case is the borrower while the librarian is required in order for the borrower to derive benet from the Borrow use case. The supervisor and librarian are required for the library to complete the Fine task. 40

Use Case 2.2 Name Actors List the actors Trigger List the circumstances under which this use case is activated. Process Specify the steps in carrying out the use case. Variations List the variations to the steps above and specify the points at which they occur. Dialogs A specication of the dialogue that the actors have with the system while carrying out this use case. It can include screen shots to show layout or diagrams to show the path through a set of screens. Open Issues List the open problems and unresolved issues. Figure 4.4: A template for specifying use cases.

Borrow Librarian Borrower Order Title

Fine

Superivsor

Figure 4.5: A Possible Use Case diagram for a simple library system.

41

Names
Large systems involve large numbers of objects. In UML the key tool for organising large numbers of modelling elements are packages, but we may think of packages as subsystems of the whole as well. Use cases are not specically tied to UML and so they are applicable in any analysis situation. The names of use cases may reect the structure of subsystems. Thus names can be Simple names consisting of a single text string, or path names which is a use case prexed by a UML package to which it belongs, or a subsystem to which it belongs.

Generalisation Between Actors

We say that the actor A generalises the actor B if every behaviour performed by A can also be performed by B, for example, the actor customer generalises loan customer because every behaviour performed by a customer can be performed by a loan customer. A loan customer however, is capaGeneralisation

Loan Customer Customer

Figure 4.6: Generalisation between actors. ble of performing other behaviours which extend or vary in specic places from the behaviours of a customer. Use cases can be structured in much the same way as class diagrams, for example, we have generalisation, inclusion and extension as the basic means of structuring use cases.

Generalisation
Generalisation between use cases is very similar to generalisation between classes in Object Oriented Analysis; the child use case inherits all of the behaviour of the parent use case. The child may, however, extend and override the parent and so alter its meaning. The notation appears as in Figure 4.8 where the arrow always points back to the parent. Perhaps more importantly, the child use case can be substituted anywhere the parent use case appears. As an example, the use cases Check Password and Retinal Scan generalise the use case Validate User. In this case Check Password and Retinal Scan are the children of Validate User, have the same behaviour as Validate User, and can can be used anywhere that Validate User can be used. 42

Place Order Extension Point Set Point <<include>> Inclusion Validate User <<include>> Track Order

<<extend>> (Set point) Place Rush Order Extension Check Password Generalisation Retinal Scan

Figure 4.7: Structuring use cases.

Parent

Child

Figure 4.8: Structuring use cases through generalisation.

43

Inclusion
Inclusion between use cases signies that the base use case explicitly incorporates the behaviour of the use case at the tip of the arrow at a specic location in the base. An include use case is used to avoid describing the same ow of events numerous times by allowing common behaviour to be put into another use case and then included where necessary. As an example, in Figure 4.7 the use cases Place Order and Track Order include the use case Validate User. The use case for Track Order may contain the following ow of events. 1. Obtain and verify order number. 2. include (Validate User). 3. For each part in the order, query its status and then report back to the user.

Extension
Extension relationships are used to model the parts of the use case that the user sees as optional. The base case may stand alone, but under certain conditions its behaviour can be extended by another use case. For example, we may have the following in place order. 1. include (Validate User). 2. Collect the users items for the order. 3. extend (Set Priority). 4. Submit the order for processing.

4.2 Examples of Requirements Elicitation Using Use Cases

The Much Overused ATM Example
A consortium of banks wishes to create a computerised banking network including both human cashiers and automatic telling machines (ATMs). The cost ad planning of the network is to be shared by the consortium of banks. (i) Each bank provides its own computer to maintain its own accounts and process transactions against them. (ii) To carry out a transaction on an automatic teller machine, it rst accepts a cash card, interacts with the user to determine the transaction type, then communicates with the central bank system to determine which bank computers are required, validates the transaction with the bank computers and if the transaction is valid, it dispenses cash, and prints out receipts. (iii) Cashier stations are owned by the individual banks and communicate directly with their own bank computers and not via the central bank system. Human cashiers enter account and transaction data as customers arrive at teller windows. 44

(iv) The system requires the appropriate record-keeping and security provisions. (v) The system must handle concurrent access to the same account correctly. (vi) The banks will provide their own software for their computers; you are to design the software for the ATMs and the network. (vii) The cost of the shared system will be apportioned to the banks according to the number of customers with cash cards. (viii) The system must be administered by administrators who are responsible for generating reports. A possible use case diagram for the bank system appears in Figure 4.9.

ATM Customer

<< extension invalid user>> Reject

ATM Transaction <<include>> Authenticate <<include>> Check Accounts Bank Computer

<<include>>

Withdrawal

Create Report Administrator ATM System Bank Computer

Figure 4.9: The bank system use case diagram There are two chief main use cases in Figure 4.9, ATM Transaction and Create Report. We have assumed that part of the ATM Transaction use case is to Validate the ATM customer. We have also assumed that there are two types of transactions possible: (1) Withdrawal and (2) an Account Check. The Reject use case rejects the ATM Customer if they cannot be validated.

45

Exercise - Point of Sale System

Consider the use cases for a mobile point of sale and inventory control system with the following description. (i) Sales staff can walk around the store with mobile POS terminals. The sales staff can complete sales of items without the need to go to a register or sales station provided that customers have credit cards or store cards. (ii) To complete a sale the customer provides a card, is validated by the system, either for their credit card against the credit card agency or for their store card against the system. Once validated the money is charged to the card, the item is scanned and deducted from the store inventory and the customer may leave with the item. (iii) The staff can also perform stock taking activites by using the mobile data terminal to scan stock numbers or enter stock numbers by hand if no bar-code exists on the stock item. Once an item is scanned the inventory is checked and updated. (iv) Suypervisors can used the mobile data terminals to check sales for a specic sales consultant, or to determine x the price of an item if there is a discounting period. Model these tasks as a set of use cases.

Example - Auctions
Bfeore an auctions sellers submit items to be sold to the auction. A valuer and the auctioneer looks over the item with the seller and discusses the value and the price of the item with the seller. They decide on an acceptable (or reserve) price for the item. The auction of an item involves a collection of bidders making increasingly higher offers (or bids) for the item. Initially nothing has been offered, and any bidder can make a bid provided it exceeds the previous bid (though it would make no sense for the same bidder to bid twice in a row). The auctioneer, who conducts the auction, can start counting-out by saying going once, and if no further bids are received, going twice, and if again no further bids are received, the item is declared sold to the highest bidder, ending the auction. Whenever a new bid is received, the auctioneer needs to start the counting-out from the beginning again. If the highest bid does not reach the reserve price then the item is passed in and the next item is brough out. Model this situation as a set of use cases.

4.3 Sketching, Filling Rening and Completing Use Cases

An interesting use-case driven approach has been proposed by Kulak and Guiney [10]. The authors identify a number of key problems with orthodox approaches and advocate an iterative approach based on use cases and four iterations below. (1) Facade Identify and outline use cases and provide very high-level descriptions of uses cases.

46

(2) Filled Broaden and deepen the facades. (3) Focused Narrow and prune use cases. (4) Finished Touched up and ne-tuned use cases. These iterations are not intended to be a process, but rather and as before, set of activities to be conducted as part of a process.

The Facade
The goal of the Facade iteration is to create place-holders for for each major task that that you expect users to have with the proposed system. A Facade use case contains only the minimum of information that is needed as a place-holder, including names, actors and a short description of each interaction. The Facade iteration has the following key steps. 1. Create a problem statement. 2. Identify and review existing documentation and existing intellectual capital. 3. Identify users, the user group management, the stake-holders, the customers being served by the user group, and the owners of any data. 4. Interview the stake-holders. 5. Find the actors. 6. Create the Facade use cases. 7. Start the business rules catalogue. 8. Create a risk analysis. 9. Create a statement of work. 10. Get informal approval from the executive sponsor. The chief output of a Facade iteration is a set of improperly dened use cases, but a set that can be used to dene the scope of the project, its key purpose and tasks. Any more detail and (it is claimed) that you will be hurting the iterative nature of this use-case development method. Example 4.2 An example of a Facade is given in Figure 4.10.

The Filled Use Case

The lled iteration is the place where most of the hard labour gets done. The objective of the lled iteration is to create a comprehensive set of use cases and business rules that describe the application. Although these requirements may be rough and unpolished the intention is that contain a lot of detail and include the functional and non-functional requirements for the system. The key steps in the Filled iteration are the following. 1. Break down general facades if necessary to create more detailed use cases. 47

Use Case Name: Iteration: Summary:

Track Costume Sales Facade System Context Use Case. This system needs to track the information related to customers, appointments, designs, orders, and sales. The purpose of the system is to provide historical sales data that allows the owner to visualise trends.

Basic Course of Events: Alternative Paths: Exception Paths: Extension Points: Trigger: Assumptions: Pre-conditions: Post-conditions: Related Business Rules: Author: Date: John Pea Em. January 1, 2002Facade

Figure 4.10: A Facade for tracking costume sales [10].

48

2. Create lled use cases. 3. Collect and document the non-functional requirements. 4. Add business rules. 5. Test the lled use cases. 6. Put some things off. . . ! Example 4.3 An example of a Filled use case is given in Figure 4.11 where the processing steps for a Process Loan use case can be added to create a lled use case. Use Case Name: Iteration: Summary: Process Load Filled The loan provider and the buyer work out the terms of the loan, if the buyer requires one. Terms include the interest rate, points, term, escrow, insurance, and so forth. 1. The use case begins when the buyer and the seller have agreed to terms. 2. The buyer indicates that a loan is required. 3. The system responds by contacting the loan provider with the details of the buyers loan requirement. 4. The loan provider uses the buyers loan requirement as input to create a loan proposal. 5. The system responds by sending the loan proposal to the buyer and the buyers agent. 6. The buyer makes a counter-offer to the loan provider. 7. The system responds by sending the counter-offer to the loan provider. 8. The loan provider accepts the counter-offer. 9. The system responds by sending notication of the loan providers acceptance to the buyer and the buyers agent. 10. The buyer indicates acceptance of the loan. 11. The system responds by recording the buyers acceptance of the loan and les approved loan application with the loan provider.

Basic Course of Events:

Figure 4.11: A Filled use case for processing loans [10]. Where applicable a glossary of terms should also be included with use case in order to ground readers of the use case in the domain. 49

The Focused Iteration

The main objective of the focussed iteration is to lter the probably large collection of use cases that you now have and select the best and most appropriate for your system. The aim is to create a clear, consistent set of requirements that will dene your system and allow you to build a successful application. The focussed iteration is about making the difcult choices about the current project, deciding on the feature set, the scope and the eliminating redundancy and duplication where it doesnt add anything to the project. The idea is that you understand the problem well enough to remove contradictory requirements and how use cases share functionality to support each other in reaching their goals. Example 4.4 The focused use case shown in Figures 4.12 and 4.13 shows that part of the system requirements that deal with coming to agreed terms on the sale of a property. There are some notes to make here. The use case has been developed from a facade and a lled use case by going back to the sources of requirements and determining the processing steps. Nonfunctional requirements are dealt with in the next iteration. In the focussed iteration your aim is to bring each use case into focus and then to ensure that it is relevant for your system and to provide sufcient information to make it as accurate, informative and concise as possible but without being vague. Terms in the use case that are related to the domian need to be dened along with the use case and actors in the use case need to be accurately dened as well. Consider [10]: Interfaces to other systems; The relationships between the interfaces and the use case For example, can the telecom CLI interface provide the correct services to each of the use cases that depend on it? Improving the process There is an opportunity to walk through each of the processes in the use case from the point of view of the user. What does it tell you about the process? Has the manual system inadvertantly been retained? Can this task accomodate the future business plans? Can this use case accomodate the future of the system? Prioritorising use cases Are the use cases ranked in order of imortance and urgency for te users? This helps identify which use cases should be designed and delivered early and can be the basis for incremental or iterative development models. Dening inputs and outputs Ensure that all of the information required by the use case is supplied to the use case throug one of its interfaces.

The Finished Iteration

The aim of the Finished iteration is to add in the non-functional requirements, user interface requirements and package up the use cases so that they can be used by the designers of the system. The basic steps in the Finished iteration are: 1. Add user interface requirements to the use case model. 2. Abstract and combine the non-functional requirements and associate them with use cases. 50

Use Case Name: Iteration: Summary:

Agree to Terms Focused The buyer and seller agree to the terms of the sale, including changes to the existing property that are required, the items included in property, the date of possession, the nancing arrangements, and any other conditions of the sale. The agents help their respective customers by offering advice, caution and recommendations.

Basic Course of Events: 1. This use case begins when the buyer and the seller both indicate that an agreement is possible. 2. The system responds by notifying the buyer, the buyers agent, the seller, the sellers agent, the legal analyst and the nancial analyst that the agreement process is ready to begin. 3. The buyer or the seller submits a proposal of terms. 4. The system responds by allowing all actors to view the proposal of terms and make their changes. 5. The actors make their changes. 6. The system responds by making the actors changes public to all. 7. The actors discuss the changes and come to an agreement on each proposed change, item by item. 8. The system responds by consolidating agreed-to changes and again making the proposal of terms public. 9. The actors indicate their agreemnet. 10. This use case ends when the system indicates that the proposal of terms is nal.

Figure 4.12: Selling a Property Agreed to Terms Focused Use Case [10].

51

Alternative Paths:

In step 3, the buyers agent may submit a proposal of terms to the buyer, who may then submit it as his own. In step 3, the seller may also be the one to submit a proposal of terms. In step 3, the sellers agent may submit a proposal of terms to the the seller, who may then submit it as his own. In step 9, if the buyer or the seller does not agree to the proposal of the terms as it stands, the objecting party enters his issue; then the objecting party modies the proposal, and processing returns to step 4. None. One of the actors indicates that the agreement to terms can begin. None An offer has been made and accepted. Terms are agreed to by the buyer and the seller. None John Pea Em. Januray 1, 2002Facade, February 1, 2002Filled, March 1, 2002Focused

Exception Paths:

Extension Points: Trigger:

Assumptions: Pre-conditions: Post-conditions: Related Business Rules: Author: Date:

Figure 4.13: Selling a Property Agreed to Terms Focused Use Case Part 2 [10].

52

3. Make nal scope decisions and get the sign-off. 4. Baseline the requirements.

53

54

55

Chapter 5 Analysis, Modelling and UML

A model of the requirements can be used to analyse the requirements and to provide feedback and guide the requirements elicitation process.
Sources of Requirements Requirements Specification

Elicit Requirements

Analysis of the Requirements

Figure 5.1: Using analysis models to feedback into requirements elicitation. There are a number of possibilities for evaluating and analysing sets of requirements as they are being developed. Model building is one of the most popular and accepted methods of analysing requirements.

5.1 Modelling
A model of the requirements can be used to: test the feasibility of the requirements, help to understand aspects of the problem domain, clarify misunderstandings and act as a laboratory for the imagination [22]. A good model can be modied, extended, reduced or transformed in order to explore requirements. We can argue about the threads of logic and see if they knit together consistently and test the models strengths and limitations. Finally, a good model can be used to guide the requirements elicitation and to gain a better understanding of the problem domain. Some popular modelling approaches are listed below. Formal Methods Here we create mathematical models of the system requirements. Popular methods include 56

 Z and B Both are formalisms for writing specications using logic and set theory. Models are usually created by giving an explicit model of the system state, identifying the actions that the system must undertake and specifying exactly how each action affects the system state. The affect on the system state is modelled in terms of the actions preconditions and its postconditions. VDM (The Vienna Development Method) Another formalism using logic and set theory and explicitly designed for modelling states and transitions (or actions) using preconditions and post-conditions. Petri Nets A very mature and surprisingly general formalism and used in numerous engineering disciplines based on the mathematical theory of graphs. Systems are modelled as a set of places representing conditions or assertions about the system, transitions, representing changes in conditions, and tokens. Tokens occupy places. When a token occupies a place the assertion about the system holds (see Figure 5.2). Petri-nets are most often used for understanding problems with resource sharing in multi-

Producer Producing Waiting

Channel Full Empty

Consumer Waiting Consuming

Figure 5.2: An example of a Petri Net process environments. Process Algebra Process algebras have their origins in the mathematical theory of automata. Common process algebras include CCS and CSP but there are others. Systems are modelled as a collection of agents that interact and communicate to achieve a common goal. Each agent engages in a series of actions that can synchronise with the actions of other agents. UML The Unied Modelling Language consists of a number of different sub-languages. UML does not rigorously dene all of its sub-languages although some, like state-charts, do have a rm mathematical basis. More is given on UML in Section 5.2 below. 57

Prototyping Prototyping is where we create executable models of the [1, 7, 11]. Prototypes can be a good way for the development team to gain an understanding of the system and its environment. Prototyping is iterative in nature and the production of prototype can show-up vague or uncertain requirements. Prototyping has the distinct advantage that the client, or even the end users of the system, can be shown how the system might behave in a given situation.

5.2 The Unied Modelling Language

In these notes UML [3] will be used for modelling and analysis. UML is a large language which can be used for most phases of the software life-cycle including Requirements Analysis through use cases and analysis models, through to the design, coding and testing phases of the project. We will not be looking at the whole language but only at the ve key areas that are most useful in analysing the problem domain. Use Cases: Use cases, we have already looked at in Chapter 4.1. Use cases are used for requirements elicitation while the analysis of the use cases in Object Oriented Analysis and Design methods is typically undertaken using Class Diagrams, Interaction Diagrams and State-charts. Class Diagrams: Object oriented analysis is done in terms of Objects, Object Classes, Object Functions, and Associations between objects. This sort of analysis imposes a structure on the problem domain that we can use to test the feasibility and accuracy of existing requirements and to assess the impact of new requirements. Interaction Diagrams: Interaction diagrams show how objects and actors communicate with each other via their methods. In particular, sequence diagrams show the temporal ordering of messages between objects and actors. In particular, the collaboration diagrams can show exactly how the objects, actors and associations in the class diagram collaborate to achieve the tasks and processing steps specied in the use cases. Doing this also provides us with a cross-check on the feasibility and consistency of the use cases. State Charts: State charts also capture the behaviour of objects in terms of states, state transitions and events. State charts can be used to capture the behaviour of event-based systems and aspects of concurrency. Activity Diagrams: Activity diagrams are used to show activities, object states, state transitions and events as well as which activities can occur concurrently. Activity diagrams provide another diagrammatic means of capturing a process or a sequence of processing steps. We will be omitting packages, component diagrams, extensions and many of the annotations at least.

58

59

60

5.3 Class Diagrams

Use cases provide us with the basis for identifying the objects and their responsibilities and the associations in our system. Once we have the objects and the associations then we can determine the attributes of those objects and the operations that they can perform. The objects and the relationships between them are captured in UML in Class Diagrams. Once objects and their relationships are identied then we can collect those objects with common attributes into object classes. Classes and the relationships between them form the basis of our Analysis Model. The analysis model in these notes is the UML model of the proposed system and its environment that we will use to determine the completeness, correctness and consistency of our requirements, and which we will use to help us rene our use cases. Before continuing, note that class diagrams capture structure or static information about the system. Specically, they support a functional requirements and data viewpoint of the problem domain. To understand system behaviour, you will need to use collaboration diagrams, state-charts or activity diagrams. First, some denitions, Objects are entities that have well dened boundaries and have their own identity. Objects can encapsulate both state and behaviour. Objects possess attributes and operations: attributes capture the state of an object and operations model state changes. Classes are collections of objects with identical attributes and operations. Each object is an instance of a class and each class is a collection of objects. Classes are drawn in boxes with four compartments: (1) a class name at the top, (2) a set of attributes, (3) a set of operations, and (4) a set of responsibilities1 An example of two classes are given in Figure 5.3.
Shape Origin move() resize() display() Point x,y:Real newP() ChangeX() ChangeY()

Figure 5.3: Two classes. Relationships hold between objects and relationships hold between classes. There are three basic kinds of relationships in UML. 1. Generalisation, or sometimes inheritance, relationships exist between a general thing and a more specic or specialised thing. A child inherits all of the properties of its parent but child classes may override operations in the parent and extend the parent by adding
1

We deal with responsibilities later.

61

Shape

Point x,y:Real newP() ChangeX() ChangeY()

Parent

Origin move() resize() display()

Children

Rectangle TopLeft:Point BottomRight:Point

Circle Radius:Real

Polygon Vertices:List Point

Square

Figure 5.4: Generalisation.

62

more attributes and operations. In particular, generalisation means that the objects of the child class can be used anywhere that the objects of the parent class can be used but not the converse! An example of a generalisation relationship is given in Figure 5.4. 2. Associations are another kind of structural relationship. Given an associations between classes, you can navigate from an object in one class in an associations to an object in another class in the association. Associations can be unary, binary or n-ary and can be named. Typically, association names are used to describe the nature of the association as in Figure 5.5. Associations may also have roles attached to them as in Figure 5.6.
Works for Person Employer

Association Association Name Direction

Figure 5.5: An association between Person and Employer classes. Associations may reect multiplicity, that is, an object at one end of a relationship may
Person Employee Employer Employer

Role Names

Figure 5.6: An association between with roles attached to the classes. be related to n objects at the other end of a relationship and vice-versa. Some possible multiplicities include, 1..* 0..* 1 (0..1) (0..1, 3..4, 6..*) One or more Zero or more Exactly one Zero or one Complex ranges Zero or more.

3. Aggregation is an association which relates parts to their whole. The other relationships are typically between peers but the the aggregation relationship is intended to introduce a strict hierarchy between the whole and its parts. An example of an aggregation is given in Figure 5.7.

63

Whole

Part *

Company

Department

Aggregation

Figure 5.7: An aggregation relationship: Company is the whole and Department is the part.

5.4 The ATM Example

Consider the system shown in Figure 5.8 which shows the conguration of the computing systems for a consortium of banks.
A/C Bank Comp. Central Computer Bank Comp. Bank Comp. A/C A/C

ATM

ATM

A/C

ATM

System

Figure 5.8: The ATM Network

The Problem Statement

The following problem statement is taken from [18]. Design the software to support a computerised banking network including both human cashiers and automatic telling machines (ATMs) to be shared by a consortium of banks. Each bank provides its own computer to maintain its own accounts and process transactions against them. Cashier stations are owned by the individual banks and communicate directly with their own bank computers. Human cashiers enter account and transaction data. Automatic teller machines communicate with a central computer which 64

clears transactions with the appropriate banks. An automatic teller machine accepts a cash card, interacts with the user, communicates with the central system to carry out the transaction, dispenses cash, and prints out receipts. The system requires the appropriate record-keeping and security provisions. The system must handle concurrent access to the same account correctly. The banks will provide their own software for their computers; you are to design the software for the ATMs and the network. The cost of the shared system will be apportioned to the banks according to the number of customers with cash cards.

Use Cases
Consider the use case in Figure 5.9. The processing steps all involve Objects and Associations between objects. Object oriented analysis is tries to capture these objects and associations to create a class model. The use cases and the problem statement provide a wealth of information about the objects and associations in the problem domain.

Choosing Objects
Here is a simple method for developing an object model from a use case or a problem description. Step 1 Select potential objects from the Use Case or problem description. Potential objects are usually things (well. . . , objects really!) and a described by nouns or noun-phrases. This list forms the set of potential objects, and object classes. Note, however, that not all items in this list will serve as classes. All objects Step 2 Remove all of the items in the following list. Vague If the object is not unambiguously dened then it should be rejected. Redundant that is, some sets of objects in the problem statement may refer to the same entity. We must ensure that the two object classes are actually distinct. Event or an Operation We must take care to ensure that our potential object does not actually refer to an event or an operation. Outside the Scope of the System We must ensure that the object class must be relevant to the system being specied. This can be hard and is to a greater extent a subjective decision. Attribute If the potential object refers to something simple with no interesting behaviour and which is part of another class then it ought to be an attribute and not an object. Meta-Language If we are using nouns to identify objects then we must ensure that the the noun is part of the language for dening things and not part of the language of the problem domain. What kind of things are we looking for to be good classes? (i) Tangible real world things, for example, ATM and ATM Card. (ii) Roles, for example, Customer and Cashier. 65

Use Case Name: Iteration: Summary:

ATM Transaction Filled The ATM customer inserts their card into one of the Consortiums ATMs. The ATM customer initiates a transaction and the bank consortiums network carries out the transaction, and delivers back to the ATM customer the results of that transaction.

Basic Course of Events: 1. The ATM customer inserts their consortium ATM card into an ATM. 2. The ATM customer enters their pin-number. 3. The ATM customer chooses their transaction type. 4. The ATM customer enters the details of their transaction into the the ATM. 5. The ATM sends the account details, customers pin number and transaction details to the Consortiums central computer. 6. The Consortiums central computer keeps a record of the transaction, and sends the transaction to the correct bank computer. 7. The bank computer validates the ATM customers pin number, and checks to see that the ATM customers account is in a state that will enable the transaction to be carried out. All ATM costumers must be a customer of one of the consortiums member banks. 8. The bank computer sends back an authorisation number to the central computer. 9. The central computer clears the transaction and sends a message to the ATM to allow the transaction to proceed.

Extension Points:

Step 7 If the ATM customers bank account is not able to support the transaction, or the customer has supplied an invalid pin number the apply the Invalid Transaction use case. The ATM customer inserts their ATM card into one of the Consortiums ATMs. Ed. Kazmierczak April 15, 2003.

Trigger:

Author: Date:

Figure 5.9: An ATM Transaction Use-Case for the Bank Consortium Problem. 66

(iii) Events, and (iv) Interactions. The categories listed above do overlap but this is not that important. What is important is to recall that the objects in the model dene the system and consequently a good choice now may save us a lot of rework later.

Choosing Associations
In general class A and class B are associated if, (v) an object of class A sends a message to an object of class B; (vi) an object of class A creates and object of class B; (vii) an object of class A has attributes whose values are objects of class B, or collections of objects of class B, and (viii) an object of class A receives a message whose argument is an object of class B.

A Class Model for the ATM System

With the rules above in mind we arrive at the list of potential classes in Figure 5.10.
Good Account ATM Bank Bank Computer Cash Card Cashier Central Computer Customer Consortium Account Transaction Cashier Station Vague System Security Provision Record Keeping Provision Banking Network Attribute Account Data Receipt Cash Account Data Transaction Data MetaEvents Language Redundant User Outside Scope Cost

Figure 5.10: The potential classes of the ATM consortium problem categorised . Remark 5.1 This is only one reading of the problem and other models will exist which are equally valid. The choice depends on the set of objects chosen to model the system.

67

Consortium 1 Owns

Consists of *

1 Bank 1 1 Holds Owns 1 * Account * Has 1 1 Customer

* Central 1 Bank Computer Computer * Communicates with Concerns Accesses

Issues

Has

Communicates with

ATM

Transaction Kind Date Time Amount

* * Authorised by

Cash Card passwd()

* *

Figure 5.11: One Object Model for the ATM Network.

68

Responsibilities
In class diagrams it is useful to add the responsibilities of each class, that is, the role that the class plays in the system as a whole. This can be added to a fourth division in the class box if required and is useful for deciding what the attributes and operations should for the class.

5.5 A Simple Surgical Training Example

The second example is a bit more complex where we need to perform the analysis of a simple surgical training system.

The Problem Statement

Blunt trauma to abdomen can result from a number of causes including car accidents, falls or ghts. Often it is difcult to determine if an intra-abdominal injury has occurred in a blunt trauma victim. In many cases, the decision about when to perform an exploratory surgery is not straightforward. One procedure used to determine whether blunt trauma victims require surgery is diagnostic peritoneal lavage (DPL). DPL helps determine whether an intra-abdominal injury exists and whether surgery is required. Surgeons require training in procedures such as DPL but cadavers are expensive and sedated animals are possible for a single use. It is proposed that a medical simulator be used to allow students to try the procedure numerous times. The DPL procedure involves several steps but broadly it requires the surgeon to locate the area of the suspected trauma, apply a local anaesthetic, make an incision, insert a drain into the incision, insert a catheter, aspirate some uid from the abdominal cavity and test for blood in the aspirated uid.

Use Cases
We can begin by determining that there are likely to be three main use cases for the simulator and these are given in Figure 5.12. The rst use case Create Virtual Patient is used by the the senior surgical educator or administrator to create a model patient with a specic trauma. The administrator takes a template patient and species the location and the parameters of the trauma and the simulator responds by creating and storing the new patient model. The second use case, Execute DPL Scenario is the main use case for the DPL simulator. It is given in detail in Figure 5.13 but, at this early stage, is still quite incomplete. The nal use case is the Assess DPL Scenario use case where the senior surgeon replays and examines the the actions of the student created in the Execute DPL Scenario and assesses the students performance.

69

Create Virtual Patient Administrator Trainee Surgeon Execute a DPL Scenario Teaching Surgeon

Assess the DPL Scenario

Figure 5.12: Use Cases for the DPL Simulator. Virtual Patient Incision Incision Tool Abdominal Fascia Guide-wire Syringe Tool Site Records of Actions Cannula Tool Bowel Catheter Tool Syringe Abdominal Wall Local Anaesthetic Cannula Guide-wire Tool Catheter Fluid

Table 5.1: Possible Objects for the DPL procedure.

Possible Objects, Classes and Associations

The use case is still really just a facade and so we will make some assumptions about the simulator and then verify these with the clients and end-users. By doing this, we can create a lled use case and get a good understanding of the details of the procedure. Our analysis starts with an object model that elaborates2 the use case in Figure 5.13. Possible objects are given in Table 5.1. Remark 5.2 1. From step 3 of the use case and from interaction with the surgeons we learn that a scalpel is used for making incisions. 2. We make the assumption3 that the tools in the use case, such as the cannula tool are design related and so are rejected from the analysis model.
The point here is not that we can determine the structure of the model once and for all, but that we can use the model to get at the important details of the use case. 3 Recall that all assumptions must be veried!
2

70

Use Case Name: Iteration: Summary: Basic Course of Events:

Execute Diagnostic Peritoneal Lavage Scenario Facade

1. The trainee surgeon or the teaching surgeon loads a virtual patient. 2. The trainee surgeon selects a site on the abdominal wall in the virtual patient in which to make an incision. The site is usually just below the umbilicus for lower abdominal injury but can be higher up the abdominal wall depending on the location of the trauma. 3. The simulator records the site chosen for later analysis of the procedure by the teaching surgeon. 4. The trainee surgeon must administer a local anaesthetic and waits for a small period of time for the anaesthetic to take effect. 5. The trainee surgeon makes an incision using an incision tool provided by the simulator. 6. The trainee surgeon selects a cannula tool and inserts the cannula into the incision. The trainee surgeon keeps inserting the cannula until they penetrate the abdominal fascia (a membrane behind the abdominal wall). The surgeon should feel a give or a pop when the cannula penetrates the fascia. Care must be taken not to insert the cannula too deeply and perforate the bowel. 7. The trainee surgeon selects a guide-wire tool and passes a guide-wire through the cannula. 8. The trainee surgeon removes the cannula from the virtual patient. 9. The trainee surgeon selects a catheter tool and threads a catheter over the guide-wire. 10. The trainee surgeon removes the guide-wire. 11. The trainee surgeon selects a syringe tool and inserts the syringe at the end of the catheter. 12. The trainee surgeon aspirates some uid from the abdominal cavity. Testing the uid for blood is not part of the scenario. Trigger: The surgeon suspects that blunt abdominal trauma has occurred and CT and ultrasound scans are not available. Trainee Surgeon Ed. Kazmierczak April 15, 2003.

Actors Author: Date:

Figure 5.13: The Execute Diagnostic Peritoneal Lavage use case. 71

3. We will include the virtual patient, and assume that Abdominal Wall is a part of the virtual patient. Further we will assume that the Fascia is a part of the abdominal wall. 4. We will assume that the associations between objects arise from the interaction between physical objects. The resulting object model is shown in Figure 5.14.

Record of Actions

History of

Virtual Patient

Administered

Local Anaesthetic

Scalpel 1Make

Incision

Abdominal m

Wall

CannulaInserted

Into 1

Incision
1

Fascia

Bowel Fluid

+Incision Length +Incision Depth Inserted Into

Inserted Into 1

Guidewire

Catheter

Attached To

Syringe

Figure 5.14: An Initial Model for the Diagnostic Peritoneal Lavage Simulator .

Responsibilities
Table 5.2 shows what responsibilities we have assigned to each of the objects based on our current understanding. We have not captured the responsibility for storing a specic students work on a specic patient model and the association between the Record of Actions and a Virtual Patient looks articial. Further, we also require an object to have the responsibility of stepping through the procedure and maintaining the current state of the procedure. We will add an object called Procedure that incorporates this information. We have made some further assumptions with respect to the models. Each of the objects must be able to display itself as well as carry out its intended function. Thus the cannula must be able to be visually rendered and to be inserted and removed into the abdomen. The rened object model is given in Figure 5.15.

72

Object/Class Virtual Patient

Local Anaesthetic

Abdominal Wall

Incision Fascia Bowel Scalpel Cannula Guide-wire Catheter Syringe Record of Actions

Fluid

Responsibility Responsibilities are: (1) hold the state of the patient, and (2) to provide an model of a patient for the scenario. Actions include being able to render key parts of the virtual patient. Responsibilities are to execute the anaesthetising procedure. Actions include being able to execute all of the steps in anaesthetising the patient. Responsibilities are: (1) to provide a physical model of the abdomen for the procedure, and (2) to maintain the location and state of the trauma including types of uid that may be retrieved from certain areas, and the site for the incision and the state of the patient. Responsibilities are to be a model of the incision. Responsibilities are to be a model of the fascia. Actions are to test if the fascia has been penetrated or not. Responsibilities are to be a model of the bowel. Actions are to test if the bowel has been penetrated or not. Responsibilities are to be a model of the scalpel. Responsibilities are to be a model of the cannula. Actions are to insert and remove the cannula. Responsibilities are to be a model of the guide-wire. Actions are to insert and remove the guide-wire. Responsibilities are to be a model of the catheter. Actions are to insert and remove the catheter. Responsibilities are to be a model of the syringe. Actions are to attach the syringe to the catheter, to extract uid and to remove the syringe. Responsibilities are: (1) to store signicant events and actions of the surgeon for later replay; and (2) to save the state of a procedure for resuming it later. Actions are to store events, store the state of the procedure and keep details of the current students performance. Responsibilities are unclear.

Table 5.2: Assigning responsibilities to objects as part of the analysis process.

73

+Event List +Operation State +Patient Model +Record Event() +Record Procedure State() +Record Patient Model()

Engaged in 1 Student Record of Actions History of 1Procedure m 1 +Name +Procedure State +Load Patient() 1 Uses

+Student Number +Number of Patients +Current Rating

Virtual Patient Administered Local Anaesthetic Event

+Event Type +Time +Patient State +Render Patient() +Volume of Anaesthetic +Select Syringe() +Fill Syringe() +Administer Anaesthetic() +Dispose of Syringe()

Scalpel
+Render Scalpel()

1 Make Incision m

Abdominal Wall

Cannula
+Insertion Depth +Insert Cannula(Length:Real) +Remove Cannula() +Render Cannula() 1

Inserted Into

+Incision Site +Render Abdominal Wall() +Render Incision() 1 +Render Trauma() 1 +Select Incision Site() +Make Incision()

Inserted Into

Guidewire
+Guide Wire State +Insert Guidewire(Length:Real) +Render Guidewire() +Remove Guidewire() Inserted Into 1

Incision
+Incision Length +Incision Depth

Fascia
+Render Fascia() +Fascia Penetrated(): Boolean

Bowel
+Render Bowel() +Bowel Penetrated(): Boolean

Catheter
+Render Catheter() +Insert Catheter(Length:Real) +Remove Catheter() Attached To

Syringe
+Volume of Fluid +Render Syringe() +Attach Syringe() +Extract Fluid() +Remove Syringe()

Figure 5.15: The renement of the object model in Figure 5.14.

Asking Questions!
Of course we are note nished yet! The Execute DPL Scenario needs to be lled and we are uncertain about a number of areas that our modelling has highlighted. 1. In recording events, and actions in the Recording phase, what tasks and actions are signicant? Are there standardised assessment tasks for medical students? 2. Our understanding of the Local Anaesthetic object is poor. What is the procedure for administering a local anaesthetic? 3. There is no closing procedure. What is the process for closing? 4. Is our model of the syringe correct or do we need another association? Where does the uid need to go in order to get tested? 5. The use case does not provide a good data model for students, administrators, or supervising /educating surgeons. What are their roles in th system and what information will they need? The act of trying to create a model, assign responsibilities and determine relationships can help immensely in understanding and clarifying situations. By going through each object and trying to verify it and its responsibilities against the use case we can derive at least the questions above and probably many more. Answers to such questions will ultimately help to create a lled use case.

74

75

76

5.6 Interaction Diagrams

Class diagrams are best used to express the structure of a model. To complete the analysis we will often be required to complement the structural model with a model of the system behaviour. By behaviour we will mean sequences of events or sequences of operations (actions) including: external events initiated by actors; internal events or messages initiated by objects; operations undertaken by objects or actors. The models of system behaviour are intended to capture its dynamic content, that is, the system as it evolves in time. The main elements in UML for capturing system behaviour are: Collaboration diagrams including sequence diagrams and interaction diagrams; Activity diagrams; and State charts. An example of a sequence diagram is given in Figure 5.16.

Customer accept_card() accept_pin()

:ATM

:Central Computer

Bank Computer

send_PC() determine_bank() send_PC() validate_PC() valid_user() Valid_user() accept_transact()

Figure 5.16: A sequence diagram for the ATM example. Sequence diagrams describe how objects and actors collaborate to achieve the tasks of the system. Sequence diagrams specically show a time-ordered sequence of events and messages that are sent between objects, and between objects and actors. Objects and actors are listed across the top of the diagram. We can include: actors, 77

 specic objects, for example, customerA : CUSTOMER, and an anonimous object which satises a type declaration : CUSTOMER. Messages and events are represented by the operation calls in the objects that are listed at the top of the diagram and the time ordering of messages is represented by the vertical placement down the page; later calls are further down the vertical line. The head of the arrow determines which object owns the operation and the tail of the object determines which object invokes the operation. For example, accept card() is an operation in the ATM class and is invoked by the Customer actor. A second form of diagram which expresses the ways in which objects interact to produce behaviours is the Collaboration Diagram. The collaboration diagram corresponding to the sequence diagram in Figure 5.16 is given in Figure 5.17. .
Customer Bank Computer

9. accept_trans()

1. accept_card() 2. accept_pin()

7. valid_user()

4. determine_bank() 5. send_PC() 6. validate_PC()

8. valid_user() atm:ATM 3. send_PC() :Central Computer

Figure 5.17: A Collaboration Diagram Collaboration diagrams are intended to emphasise the organisation and relationships between objects in a collaboration, while sequence diagrams are intended to emphasis the time-ordering of messages. In collaboration diagrams the time ordering of sequences of messages (modelling events and actions) are specied with sequence numbers with the direction of the message given by the arrows. To show nesting you use multi-level numbers. The lines represent relationships, or links, between object. Both the sequence diagram and the collaboration diagram derive the same information but the presentation emphasises different aspects of this information. The diagrams are, however, semantically equivalent and each diagram can be derived from the other.

Common Uses of Interaction Diagrams

In general there are a number of ways of using interaction diagrams, but essentially they can be used to model the dynamic aspects of: the system as a whole, subsystems, packages or components, a class, or even an operation. 78

The focus, or level of abstraction, will dictate the objects, actors and messages involved in the collaboration diagram. You will need to decide if it is more important to focus on the structure of the interaction and nested sequences of messages (in which case use a collaboration diagram) or the time ordering of messages (in which case use a sequence diagram).

Another Example of Sequence Diagrams

Sequence diagrams for the DPL example are given in Figures 5.18 and 5.19. Turning our attention to Figure 5.18 rst notice that in order to complete the interaction we have been forced to add in an operation Select Scalpel(). The operation is required because otherwise the actor has no means for invoking an incision procedure. Exploring the model in this way shows up the omission of an operation for invoking a procedure in the model (Figure 5.15) and in the use case. We can explore the interaction with the clients in order to better understand how all tools are invoked.

Trainee Surgeon

: Procedure

: Abdominal Wall

Select Scalpel() Select IncisionSite()

Make Incision()

Figure 5.18: A sequence diagram for making an incision. The second sequence diagram in Figure 5.19 shows up some problems with the model, but it is arguable if there is a problem with the use case. Again, the trainee surgeon must choose to insert a cannula (Select Cannula Insertion()), but in addition some information must pass between the Cannula and the Abdominal Wall objects. The state of the procedure must be altered to reect the fact that the cannula is being inserted. Inserting a cannula is, effectively, a continuous operation requiring that the simulation reect the visible and hidden parts of the cannula4 as it enters the abdominal wall.
If haptic interaction is being contemplated, then the forces acting against the cannula also need to be taken into account.
4

79

Trainee Surgeon

:Cannula

:Abdominal Wall

Select Cannula Insertion() Insert Cannula( length ) Update Abdominal Wall() Render Cannula()

Render Abdominal Wall()

Figure 5.19: A sequence diagram for inserting a cannula.

5.7 State Charts

We refer the reader to the paper by David Harel [6] for an exposition of the state chart formalism. As an example of the use of state-charts consider again the DPL simulator. We can analyse the requirements for the DPL use case in using state charts, and in fact, state-charts are ideal for analysing such procedures. Certain actions of the surgeon only make sense when the procedure has reached a specic stage. In general state-charts are ideal for describing and analysing systems where it is only possible (or sensible) to perform actions when the system is in a certain mode or in a certain state and this is exactly what is required in the DPL simulator. The modelling approach is to model events or activities by transitions. The conguration of the virtual patient after a specic sequence of actions by the surgeon is modelled by the state. For example, the virtual patient can be in a conguration where the cannula has been inserted and the guide-wire has been inserted into the cannula. It is not possible to attach a syringe to the cannula when in this state.

5.8 Activity Diagrams

Activity diagrams are typically used to specify the dynamic parts of the system. They are used for specifying the ow of control in systems and subsystems from activity to activity. This may involve sequential ow of control or concurrent ow of control of the computational process. The key difference between interaction diagrams and activity diagrams is that interaction diagrams show the ow of messages between objects, while activity diagrams show the ow of control between activities. Figure 5.21 contains an activity diagram for building a house (at a high level of abstraction, of course!).

80

Lost Control of Guidewire

Regain Control of Guidewrire

Loose Control of Guidewire Load a Patient Patient Loaded Insert Catheter Catheter Inserted Insert Catheter Insert Catheter

Regained Control of Guidewire

Making an Incision

Catheter at End of Guidewire

Choose a Site Choose a Site

Catheter at Correct Depth Remove Guidewire

Good Site Choosen Make Incision Patient with Incision Made

Cannula Removed Catheter Inserted Guidewrire Removed Remove Cannula Attach Syringe

Guidewire at End of Cannula Inert Cannula into Incision Cannula Inserted Penetrate Fascia Cannula Inserted to Correct Depth Insert Guidewire Guidewire Inserted Insert Guidewire Insert Guidewire Make Diagnosis Inert Cannula into Incision Syringe Attached

Inserting Guidewrire

Aspirate Blood

Sample Obtained Make Diagnosis Make Diagnosis Incorrect Diagnosis

Loose control of Guidewire Lost Control of Guidewrire Extract Guidewire Regain Control of Guidewrire

Correct Diagnosis

Make Diagnosis

Regained Control of Guidewire

Figure 5.20: A possible state chart for the Diagnostic Peritoneal Lavage procedure.

81

Start State

Select Site

Commission Architect Action States

Develop Plan

Guard for Expression

Bid Plan [Not Accepted] Concurrent Fork

[Else]

Do Site Work

Do Trade Work()

Activity State with Sub-machine

Finish Construction

Concurrent Join

Figure 5.21: The activity diagram for building a house.

82

Activity diagrams consist of Activities, which are non-atomic actions in some state machine. We can think of activities as representing an action made up of a sequence of atomic computations. Branches which consist of guards which allow ow of control to pass along the arc associated with the guard. Parallel sets of activities which are signied by the concurrent fork and the concurrent join. The concurrent fork enables a number of parallel threads of control to be initiated, while the concurrent join brings the parallel threads back together again into a single thread of control. When the sequence of steps corresponding to an activity nishes then the ow of control passes immediately to the next activity state (and the rst atomic action in that activity). Branching is possible as well (diamond box) where the ow of control has a choice of passing along a number of arcs. The arcs are guarded by expressions; if the expression is true then ow of control can pass along that arc. Finally, we can have concurrent threads of control signied by the fork/join lines. The ow of control is essentially split by a fork line and both sequences of activities execute in parallel until they are joined together again by a join line. Note a join line need not join together all the threads of control.

83

84

85

Chapter 6 Specifying and Validating Requirements

So far we have discussed elicitation, analysis and some UML modelling. The last phase that we will deal with in the requirements engineering process is the specication and validation phase. The task is to take the results of the elicitation and analysis process and to present them in a clear, succinct and unambiguous manner in a form suitable for further development. We will rst cover the presentation of requirements and then discuss the validation of requirements

6.1 The Software Requirements Specication

The Software Requirements Specication (SRS) is used to document and communicate the requirements among the various stake-holders. Ideally, the SRS should serve a variety of purposes. The SRS can serve as the basis for agreement between the the various stake-holders on what the software system will do. The system functions described in the SRS have the potential to help users to determine if the software specied meets their needs or how the software must be modied to meet their needs. The SRS can help reduce the development effort by being a reference point for questions and for detail about the problem to be solved and the motivation for the project. The preparation of the SRS forces the various stake-holders and groups in the project to consider rigorously all of the requirements before design begins. This reduces the need to redesign the project, rework the recode, and retest the code. Careful review of the requirements in the SRS can reveal omissions, misunderstandings, and inconsistencies early in the development cycle when these problems are easier to correct. Provide a basis for estimating costs and schedules. The description of the product to be developed as it is given in the SRS is a basis for estimating project costs and project schedules. It can and can be used to obtain approval for bids or price estimates. The SRS can provide a basis for developing review and audit plans, and more importantly for developing test plans. Teams can develop their test plans much more productively from a good SRS that describes requirements in an understandable and testable manner. 86

 A good SRS makes it easier to transfer the software product to new users or new machines. A good SRS serves as a basis for corrective maintenance and for enhancements to the software. A good SRS will discuss the product developed but not the processes or the project used to develop the software1 . The SRS serves as the basis for enhancing the nished product. In so doing the SRS may need to be altered but at least it provides a rm foundation for enhancement and maintenance as well as providing a good starting point.

SRS Templates
Requirements can be specied using natural language, diagrams or using formal methods. Ideally, the aim of the requirements document is to convey an understanding of the problem, the problem domain, and what the system needs to produce, provide, transform or accomplish in order to satisfy the clients needs in solving their problem. As a guide to the contents of an SRS we can look to the IEEE standard IEEE Std. 830-1998 [?]. Figure 6.1 and Figure 6.2, Figure 6.3, Figure 6.4 and Figure 6.5 give a series of suggested templates for setting out the Software Requirements Specication. Table of Contents 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Denitions, acronyms, and abbreviations 1.4 References 1.5 Overview 2. Overall Description of the Proposed System 2.1 System Context and Perspective 2.2 System Functions 2.3 User Characteristics 2.4 Constraints 2.5 Assumptions and Dependencies 3. Specic Requirements Appendixes Index

Figure 6.1: A Template for the Software Requirements Specication: Adapted from IEEE Std. 8301998

Properties of a Good SRS

The structure of requirements specications vary from project to project but as a rule the formats set out in [20] provide a good structure. Remember when working with standards, that standards often
1

Thats the job of the Project Management Plan!

87

3. Specic Requirements 3.1 External Interface Requirements 3.1.1 User Interfaces 3.1.2 Hardware Interfaces 3.1.3 Software Interfaces 3.1.4 Communications Interfaces 3.2 Functional Requirements 3.2.1 Functional Requirement 1 . . . 3.2.N Functional requirement N 3.3 Performance Requirements 3.4 Design Constraints 3.5 Software System Attributes 3.6 Other Requirements

Figure 6.2: Section 3 of the Software Requirements Specication Organised According to Requirements Class: Adapted from IEEE Std. 830-1998 3. Specic Requirements 3.1 External Interface Requirements 3.1.1 User Interfaces 3.1.2 Hardware Interfaces 3.1.3 Software interfaces 3.1.4 Communications Interfaces 3.2 Functional Requirements 3.2.1 Mode 1 3.2.1.1 Functional Requirement 1.1 . . . 3.2.1.N Functional Requirement 1.N 3.2.2 Mode 2 . . . 3.2.m Mode M 3.2.M.1 Functional Requirement M.1 . . . 3.2.M.N Functional requirement M.N 3.3 Performance Requirements 3.4 Design Constraints 3.5 Software System Attributes 3.6 Other requirements

Figure 6.3: Section 3 of the Software Requirements Specication Organised According to System Modes: Adapted from IEEE Std. 830-1998 88

3. Specic Requirements 3.1 External Interface Requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.2 Classes/Objects 3.2.1 Class/Object 1 3.2.1.1 Attributes (direct or inherited) 3.2.1.1.1 Attribute 1 . . . 3.2.1.1.N Attribute N 3.2.1.2 Functions (services, methods, direct or inherited) 3.2.1.2.1 Functional requirement 1.1 . . . 3.2.1.2.M Functional requirement 1.M 3.2.1.3 Messages (communications received or sent) 3.2.2 Class/Object 2 . . . 3.2.P Class/Object P 3.3 Performance Requirements 3.4 Design Constraints 3.5 Software System Attributes 3.6 Other Requirements

Figure 6.4: Section 3 of the Software Requirements Specication Organised According to Objects: Adapted from IEEE Std. 830-1998.

89

3. Specic Requirements 3.1 External Interface Requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.2 Use Cases 3.2.1 Use Case 1 3.2.2 Use Case 2 . . . 3.2.N Use case N 3.3 Performance Requirements 3.4 Design Constraints 3.5 Software System Attributes 3.6 Other Requirements

Figure 6.5: Section 3 of the Software Requirements Specication Organised According to Use Cases: Adapted from IEEE Std. 830-1998. need to be tailored to the individual project. Standard formats such as those in [20] are not suitable for all projects and you may well need to add extra sections or substitute sections in order to make a template relevant to your project. The key thing to remember is that at the start of the SRS you need to state clearly what deviations from the standard you have employed for your requirements document. Once the requirements are written according to the format in the IEEE Standard IEEE Recommended Practice for Software Requirements Specications (IEEE Std-830-1993) it recommends that the SRS exhibit the following eight properties. 1. Correctness The correctness of requirements typically refers to the accuracy of the requirements and whether or not, a system which implements these requirements will actually meet the clients needs (rather than just the clients desires). Each requirement needs to be checked that it is accurate, transforms, produces, accomplishes or provides exactly what is required for a solution to the clients problem and is feasible in terms of the ability to implement that requirement in the time given for the project. 2. Completeness Completeness in refers to (1) the completeness of the requirements, that is, do we have all of the requirements necessary to describe the solution to the clients problem; and (2) does the SRS contain all of the gures, tables and diagrams necessary to explain all of the requirements. 3. Consistency Consistency refers to (1) the logical consistency of the requirements, that is, no two requirements in the SRS are in conict over what the system must accomplish, transform, produce, or provide; and (2) that the terminology, diagrams, tables and gures are consistent, use the same terminology and provide a consistent view of the proposed system. 90

4. Veriability Veriability refers to the ability to write down a procedure to test the correctness of each requirement in the implementation. 5. Prioritorisation Each requirement should have a priority set on it so that there is a clear indication of which requirements should be tackled rst, and which requirements are less important. 6. Traceability Traceability refers to the ability to trace modules in the implementation back to requirements (Forwards Traceability) and to trace requirements back to their source (Backwards Traceability). Requirements ought to be numbered for ease of traceability. 7. Modiability The dependencies between requirements ought to be such that modifying the requirements is easy, and that tracking the effect of changes is easy. Note that tools such as requirements databases and conguration management tools help to track changes, but the key point is that a changes to requirements need to be carefully monitored and that the structure and layout of the SRS should make tracking the effects of changes more manageable. 8. Unambiguous Ideally, requirements should only be interpreted in one way and not be open to multiple interpretations. If multiple interpretations are possible then we open up the possibility of implementing the requirement in a faulty way. Requirements should be written clearly, concisely and as unambiguously as the language or notation will allow (see the list of phrases in the English language to avoid).

6.2 Specifying Requirements

Using Natural Language
It is important when using natural language that we try and give a clear precise and unambiguous statement of the requirement. You need to beging by ensuring that Requirements are numbered for traceability, and prioritorised so that the most important requirements are tackled rst. Some simple guidelines to follow for unambiguous and clear requirements and some simple guidelines for writing requirements in general [16]. 1. Are an persuasive connectors used, e.g. certainly, therefore, obviously or it follows that. If they are used then ask why? 2. Are any vague terms used, e.g. some, often, usually, most or ordinarily. Quantify these where possible and get clarication when needed. 3. Watch out for incomplete lists, e.g. lists ending with so forth etc. or and so on. Complete the lists where possible and make sure that all the items are clearly understood. 4. Make sure that any data ranges dont contain hidden assumptions, e.g inputs are from 10 up to 100 but are these integers or reals? 91

5. Beware of vague verbs, e.g. handled, rejected, processed, eliminated or skipped. These can be interpreted in a number of ways and should be replaced by more denite processes. 6. Beware of dangling pronouns, e.g. The I/O module communicates with the data validation module and its control ag is set. Whose control ag is set? 7. Look for statements that imply certainty, e.g. always, every, none, never. Check these and ask for proof if necessary. 8. When a term is explicitly dened try substituting the denition in a couple of places that the term is used. 9. When a structure or object is described in words draw a picture to aid in understanding it. 10. When a calculation is specied try at least two examples. Beware of writing requirements using vague terms and language. Here are some examples of requirements that use vague terms and language. The system must respond to user commands in a reasonable time. The application is to have a Motif style user interface. The server will be sufciently fast so that it is not the limiting factor in the speed of the system. The user interface should be intuitive. The system must be able to deal with other real world constraints. Also beware of writing ill dened requirements. Here are some examples of ill dened requirements. The system will be initialised by, 1. calibrating the subsystem A, and 2. calibrating the subsystem B. Assuming that we know what subsystem A and B are (from the SRS) then we still do not know what constitutes a calibration of the system. To ensure that this requirement is not ill dened then we need to state exactly what it means to calibrate each of the two subsystems. Another example of an ill-dened requirement is the following. The data-base will allow the user to access and alter parts of the data base. The database will contain parts. Associated with each part will be the data specic to this part. Assuming that we already know what parts will be stored in the database some indication is needed of what data associated with parts needs to be stored. A better way of writing this requirement may be the following. The database will contain parts. Associated with each part the database needs to store the part number in Company X format (see 5.3.2.1), the quantity and . . . 92

Formal Methods
Another way of specifying requirements is to use a very precise mathematical notation. Such notations are called Formal Methods and typically provide more than just a notation for writing down requirements. They often include tools of analysis, especially for concurrent systems and their behaviour. A short list of some of the more established formal methods is given in Figure 6.6. Model Based Z VDM B ACT I ACT II Extended ML CCS CSP LOTOS ESTELLE Petri Nets Figure 6.6: A short list of formal methods A mathematical notation provides a precise language, without the ambiguities of natural language. Essentially, there are three main groups of formal methods, which we class as model based, axiomatic and process algebra. In addition, for concurrency and resource usage, petri nets are an old reliable favourite in many engineering disciplines. While this subject is not about formal methods Figure 6.7 and Figure 6.8 give a brief idea of the kinds of notations and styles that are involved. Figure 6.7 shows the specication in Z of a simple dependency management system, or in other words a system to manage directed acyclic graphs. Each of the boxes is called a schema, and schemas contain both state variables and predicates specifying how the state variables change. The specication in Figure 6.7 is parameterised by a set of data (Given by [DATA] and the system state is given by the schema DepManSys. The system also has four operations AddNode, RemoveNode, AddDependency, and RemoveDependency. Notice that the style is to represent the state of all of the operations explicitly as sets, and all changes in state as predicates over the current state. Do we involve implementation bias in this case? Contrast the Z specication with the process algebra expression in Figure 6.8. CCS is a language for modelling concurrent systems where each expression denes a Process. All we know about processes are that you can observe a process engage in an action, and that the actions that are observable dene the process behaviour. In the example in Figure 6.8 the actions for the Producer process are pc 1 and pc2 . The bar over action signies that it is an output of the Producer process. Unbarred actions are inputs. In the case that a process has a barred action with the same name as an unbarred action in another process, then the two processes can synchronise and exchange data. 93

Axiomatic

Process Algebra

Concurrency

[DATA] DepManSys nodes : F DATA ddo, tc : DATA DATA ddo nodes nodes tc = ddo+ ( x : DATA (x, x) tc) AddNode DepManSys d? : DATA d? nodes / nodes = nodes {d?} ddo = ddo RemoveNode DepManSys d? : DATA d? nodes \ ran ddo nodes = nodes \ {d?} ddo = {d?} ddo

AddDependency DepManSys x?, y? : DATA {x?, y?} nodes x? = y? ddo = ddo {(x?, y?)} nodes = nodes

RemoveDependency DepManSys x?, y? : DATA (x?, y?) ddo ddo = ddo \ {(x?, y?)} nodes = nodes

Figure 6.7: A portion of a Z specication for a class/student data base.

Producer = pc1 .Producer + pc2 .Producer Consumer = cc1 .Consumer + cc2 .Consumer Channel = pc1 .pc2 .cc1 .cc2 .Channel Figure 6.8: A portion of a CCS specication for a producer/consumer system.

(6.1)

94

6.3 Validating Requirements

All software engineering projects should be able to provide a high level of assurancea high degree of condencethat the resulting system will meet the need for which it was engineered. The level of assurance depends on many factors including the kind of system under development, the overall process used, and, in particular, the verication and validation activities undertaken during development. We can partition the kinds of activities that are conducted for assurance into two classes [9]. Domain directed activities involve the client, users, domain experts or other persons who are the sources for the requirements and who can act as oracles in resolving questions that arise about the requirements model. Also included in this class are empirical activities that effectively use the intended operating environment as an oracle. Specication directed activities involve the requirements as an artifact. These activities include abstracting from use cases, scenarios, and empirical data, structuring of the requirements, and analysis of requirements to extract additional information, for example, to aid in structuring, and to determine if certain desirable properties hold. Note however, that required properties, such as specic performance targets, are part of the actual requirements. The main aim in validating the SRS is to assure ourselves and our clients that we have got a good SRS. Note that the concept of assurance is different to provide iron-clad guarantees - we typically cant do this in practice as we do not have enough time or the combinatorial complexity of the problem is such that it would take us thousands of years to cover all of the possibilities. Thus we must be content with a level of assurance that we are correct in our requirements.

Reviews, Inspections and Walkthroughs

The Software Requirements Specication (SRS) review is an evaluation of the SRS in order to ascertain if it is complete, consistent and correct and adheres to the eight properties of a good SRS listed in the section above. Reviews are conducted according to a formal process, that is, the review is conducted in a formal meeting with minutes taken. Informal technical reviews are really go with the ow style meetings. The objective is to evaluate the SRS and provide evidence that 1. the SRS satises the correctness, completeness and consistency criteria as well as the other eight aspects of a good SRS; 2. the SRS follows the guidelines and standards that are required by the organisation or the specic project; 3. changes to the SRS are properly implemented and impact only those areas identied in the change specication. While reviews are appropriate for validating the requirements specication, a more structured form of validation are Inspections. Inspections focuses on the following aspects of the SRS.

95

1. verify that the SRS satises the correctness, completeness and consistency criteria as well as the other eight aspects of a good SRS;verify that work products satisfy their specications; 2. verify that the SRS conforms to standards; 3. identify deviations from standards and the goals of a good SRS (these are identied as defects and are listed); 4. collect data, for example, the number of defects found; 5. inspections do not, however, examine alternatives or stylistic issues or seek to improve the SRS. Walkthroughs focus on objects; the main objective is to understand the work product in order to nd defects, omissions and contradictions as well as alternatives which improve the software product.

Modelling and Prototyping

We have already met one way of validating requirements and that is through UML modelling. Building up scenarios, use cases and interaction diagrams, with the aid of the client, is often critical in understanding the problem domain and, almost as a consequence of building up the model, we validate the requirements but this is informal. Another mechanism for validating the consistency, correctness and completeness of requirements is by building up a rapid prototypes. Rapid prototypes can be considered to be executable models of the requirements, as opposed to UML diagrams which must capture dynamic behaviour in a (rather static) diagram. The intended behaviour of the system can be demonstrated to the client using a prototype and quickly evaluated and changed if necessary. Prototyping can be seen as follows. The construction and analysis of an executable model that approximates a proposed system. Prototyping is often viewed as a risk reduction strategy although it is a very useful aid in helping to understand, rene and validate requirements. The main problem with prototyping is that the client may demand the prototype instead of the nal production version of the software and this is dangerous! If the limits of a prototyping are well understood then prototyping at the requirements phase can achieve the aims of (i) elicit requirements, (ii) analyse requirements and construct a model of the proposed system, and (iii) validate requirements. Typically such prototyping is referred to as Exploratory Prototyping. It is clearly a domain directed validation activity as prototypes can be shown to the various stakeholders and supported by interviews, questionnaires, focus groups, or observation to gather feedback on the requirements model thus far. 96

Prototyping Approaches
There are several approaches to prototyping that are commonly used. 1. Throw-away 2. Evolutionary 3. Incremental In throw-away prototyping we construct a prototype explicitly for the purpose of eliciting, understanding and validating requirements. A process for rening requirements using prototyping is given in Figure 6.9.

Requirements Analysis

Develop Prototype

Modify

Evaluation Successful

Unsuccessful

Figure 6.9: A throw-away prototyping process. We list the advantages and disadvantages of throw-away prototypes below. The advantages are: 1. The prototype can be exercised in order to uncover erroneous behaviour. 2. The prototype can be used as a common basis for communication between clients and developers in order to reduce the risk of misunderstandings. 3. Missing requirements may be detected. 4. Difcult or confusing services may be uncovered, especially if end-users are involved with the prototype. But beware prototypes are not always built with usability in mind! 97

5. Demonstrate feasibility of requirements and reuse useful design decisions. Remark 6.1 There is a key assumption here and that is that the prototype is a faithful implementation of the requirements. The disadvantages of throw-away prototypes are: 1. We must determine if a defect is a defect of the requirements or the prototype. In other words how far can we trust our assumption that the prototype faithfully implements the requirements. 2. Unless, carefully managed the prototyping process can consume the available time (and resources). 3. Clients, after seeing many of the features that they want, may insist on the prototype rather than the production version and may not want to pay for the production version! Remember: A prototype is not a production version of the software! There are some very good reasons for this. The prototype often does not encompass all of the functionality that the production version needs to have. Prototypes, because of the speed with which they are typically built, are not maintainable. Throw-away prototypes in particular have been built for the purpose of eliciting requirements using prototyping tools. They do not typically exhibit the kind of properties, like performance, required of production models In the evolutionary approach the process begins by gathering requirements, building a prototype and then iterating until an acceptable production version is reached. The key problems with evolutionary prototyping are the following. 1. Typically, prototype evolution is so rapid that no design rationale is kept. Consequently, the prototype very quickly becomes unmaintainable. 2. It is extremely difcult to follow any standards during evolutionary prototyping. 3. Project planning becomes impossible if there is no schedule of deliverables or discipline applied to the prototyping. 4. Prototyping, evaluation and subsequent improvement can become never-ending. 5. There is always a signicant risk that the prototype being evaluated is out of date thus making the evaluation inaccurate or meaningless. 6. Proper documentation is very difcult to produce in very short cycle times. Incremental development combines the evolutionary approach with the discipline more traditional software development. It relies on building up requirements and delivering the system in an incremental fashion. 1. Maintains the discipline of planning and managing each increment. 98

2. Documentation can be produced and standards followed. 3. Allows for user feedback. But incremental prototyping also has its problems. 4. integration may be difcult, 5. design must be done early, 6. relies on isolating a well understood set of core requirements. A generic incremental prototyping process may appear as in Figure 6.10.
Requirements Design Code Test Integrate Maintain

Design

Code

Test

Integrate Maintain

Figure 6.10: A generic incremental prototyping process.

99

Chapter 7 Safety Critical Systems

7.1 The Nature of Safety Analysis
Safety in systems involving software is becoming extremely important. Increasingly we are seeing systems which affect our lives and our livelihood include software and in many cases the failure of a such a system may well result in loss of life or livelihood. Systems which are required to be safe include, but are not limited to, Computer Aided Dispatch Systems (CAD); The A320 Airbus Electronic Flight Control System (EFCS); Biomedical technology, for example, Pacemakers and surgical robots; Train protection systems; The Space Shuttle; Automated Vehicle Braking Systems; and Chemical plant control systems. The software is a key element in the safety of the system and despite the misgivings that some may have regarding software, there is still a great economic motivation for using software in such systems. For example, software brings a great deal of exibility to systems and the ability to increase or change functionality in existing systems at relatively little cost. A key example is the A320 Airbus where the use of a By-Wire Flight Control System has allowed the aircraft to be safer in many respects than the older elctro-mechanical ight control systems and more economical in its running costs. Care is needed when dealing with safety requirements. In fact there is no general agreement on the basic terms and the requirements for the safe operation of a system may vary from person to person. In these notes we will follow the denitions of the High Integrity Systems Group at York [12]. Further, we will be chiey concerned with physical artifacts. 100

(i) An artifact is unsafe if it causes unacceptable harm or damage; in terms of loss of life, in terms of environmental damage, in terms of loss of livelihood or extreme nancial loss. Note that weapons cause harm but it is unacceptable if it harms the wrong people. Banking normally requires that systems be secure but if those very same systems can cause irrevocable loss of funds then it is a hazard. (ii) We will assume that only physical systems can cause harm of this kind 1 (iii) Software only has the capacity to cause this kind of harm indirectly. Safety is typically considered from the perspective of a platform. A platform is typically the largest engineered artifact incorporating the system being developed. What we wish to avoid in
Platform Largescale artefact, e.g, oil and gas platform, aircraft, car.

Environment Including peer platforms and people, e.g aircraft passengers

Operators Humans controlling or monitoring the platform, e.g pilot

Figure 7.1: A generic view of a platform. engineering and operating our platform is accidents. The system that we build must avoid the hazards that lead to accidents. Denition 7.1 (i) An Accident is an event or sequence of events leading to harm, that is, death, injury, environmental damage, or nancial loss. (ii) A Hazard is a physical situation or state of the platform that can lead to an accident.
If we include loss of livelihood or extreme nancial loss then perhaps we are not really talking about physical systems anymore. There is an issue of whether such loss, caused electronically is the province of security or safety or both.
1

101

To understand the safety of a system and its subsystems, we must also understand how they can fail! To do this it is common to investigate accidents and accident sequences, that is, to understand the sequence of events leading to the accident and to try and determine which subsystems failed. It is important to realize here that accidents are not caused by a single events or single failures. Other domains such as avionics have shown us that accidents are usually caused by combinations of failures and or circumstances (see the Okecie Accident below). Remark 7.1 1. Hazards are really accidents waiting to happen. They are the preconditions for an accident. 2. In hazard identication we are concerned with thinking about the safety of the personnel or the platform. We often need to start from known accidents or consider possible accidents and work back to hazards. This is very much a brainstorming exercise. 3. We can also think of Hazards as conditions of the platform that, unless mitigated, can develop into an accident through a sequence of normal events and actions.

7.2 Software Safety is not Just Software Reliability!

Reliability is the probability that a system will work without failure for a specied period of time in a given environment1, or the probability that a system function will work on demand in a given environment. Reliability measurement and assessment techniques for software are statistical and use measures such as Failure Intensity (the number of failures observed per unit time) or Mean Time Between Failure, or Failure Probability gained from testing the computer based part of the system. The word failure is the key to understanding software reliability. In the usual approach to software reliability, a failure is dened as a deviation from the specied behaviour of the system. For safety it is always a deviation from the intended behaviour of a system, and especially where the deviation can lead to harm or damage. In the normal usage of the word failure, a system may be unreliable but still safe, and worse, it may be completely reliable but totally unsafe. The reliability approach to software relies on a sophisticated aw detection and removal process. Testing is maintained until an acceptable level of reliability is reached based on predictive Failure Models. The problem is that we must still determine what failures of the system lead to an unsafe system. The safety engineering approach outlined below is a more general method that assumes much of the work already existing in software and computer systems reliability.

7.3 The Safety Engineering Approach

The safety engineering approach is characterised by using Hazard Analysis techniques to determine the safety aspects of the system early in the development process, then monitoring safety throughout the product development process and nally by ensuring that there is enough evidence to build a Safety Case at the end of the product development process.

102

1. Requirements Analysis and Product Denition During the early stages of development exploratory analyses in the form a Preliminary Hazard Analysis (PHA) and other methods are used to determine the hazards, potential situations that can cause harm or environmental damage and their potential causes are listed. The intention is that we have a good understanding of the safety aspects of the systems prior to going into the design and implementation phases. 2. Design and Implementation Phases Two different kinds of techniques are used to rst guide the design and implementation and then secondly to verify that it does not lead to situations with the potential for harm or damage. To guide the design a deductive approach (one that starts with potential situations of harm or injury and works back to design or implementation elements) is used and this is typically followed up by an inductive approach (one that starts from component or subsystem failures and works back through sub-systems to see if hazards result is used to verify the safety elements in the design. 3. Defending in Depth Systems that must defend against situations of harm or damage must typically be ultra-reliable or there must be sufcient redundancy so that a safety related subsystem failure does not lead to a safety related system failure. This is the principle of Defending in Depth against potential accidents. 4. Building up Safety Cases Safety cases are the high level arguments that are presented to regulatory bodies, or customers that your system is safe. They are generally built up using all of the evidence gathered during the exploratory, deductive, inductive and design processes.

7.4 The Language of Hazard Identication

The causes of accidents are hazards and consequently hazards need to be identied and assessed as early in the development cycle as possible. The rst step in safety analysis is typically Hazard Identication. Hazard identication is the process of identifying those situations which could lead to an accident under credible situations. Hazard identication is often conducted in multidisciplinary focus groups or using brainstorming methods. The aim is really to determine the ways in which the system can cause accidents if nothing special were done to avoid accidents. Hazards in turn are caused by failures or failure modes. Failures are the externally observable manifestation of defects in the system design or its implementation. Failure Failures are unintended conditions or states of the system or the platform that can lead to a hazard. Failure Mode Failure modes are often used to identify specic (classes of) failures. Error Errors are unintended states of the system (platform) that can lead to failure. 103

Flaw Flaws are design defects or programming defects that give rise to errors when certain conditions are activated. Fault Faults are the events that result when a aw is activated. Remark 7.2 1. Failure, especially in safety critical systems, is with respect to intention and not with respect to specication as in more orthodox denitions of reliability. 2. Failures are properties of the execution of a program and must typically be observed in order to be detected. Errors and aws are properties of the systems within the platform and their function. Flaws are properties of the system. 3. The denition of failure given here is very general: it includes failures such as deviations from required response times, inaccurate of results including instability in numerical algorithms or poor precision leading to round-off errors, security that can be subverted, mean-time to failure below that required and other factors. 4. The usual process of testing and identifying failures, errors and determining the faults and aws that lead to these errors. 5. Most accidents are the result of multiple system failures at a number of levels, and often including operator error, mechanical, electrical and software errors. Systematic and Random Failures It is normal to consider design aws and random failures separately in requirements and in design. We also have the following classication of failures. Systematic Failures are due to design or requirements aws. Typically the requirements for systematic aws are given in terms of integrity levels (see below) for subsystems. Random (or Stochastic) Failures are due to physical processes or factors in the environment. Random failures are usually specied in terms of failure rates.

7.5 A Case Study: The Okecie Accident

The Okecie accident occurred because of an accident sequence. In safety critical systems most special domains, like avionics systems, have detailed reports of such accidents and the accident sequences must be taken into account when developing requirements for new systems. Here is the analysis of an A320 accident at Okecie airport in Warsaw in 1993. In brief, the Okecie accident occurred because the plane landed 750m down the runway (long) and travelling at 170 knots instead of the more usual 150 knots (hot) in torrential rain and heavy winds. The aircraft failed to brake in time and hit an earthen wall at the end of the runway and burst into ames. In normal operating conditions an A320 does not need a 2.8km runway in which to stop and even in torrential rain it can land safely and stop in under 1500m of runway. The consequences of the accident were assessed to be Major but probably not Catastrophic. Generally, planes have a weather prole and in this case the weather (torrential rain and high winds) is probably within the A320s weather prole. There were some weather factors which are believed to have contributed to the accident, 104

D = 750m S = 170knots T = 0sec No Braking

D = 1750m S = 154 knots T = 12sec Braking

D = 2800m S = 70 knots T = 30sec Braking

Approximate analysis; detailed reports are not yet available.

750m 1700m 2800m

Figure 7.2: The Okecie accident. strong winds veered from a cross-wind to a tail-wind on nal approach, and it was raining heavily. Further air trafc control (ATC) did not inform the aircrafts crew of the change in wind direction. The result was that the pilot had banked into what was believed to be a cross-wind on nal approach. The runway also had standing water on it which resulted in the aircraft aqua-planing after it landed.
At time T=0sec the airframe was at ground but the braking logic failed to detect this.

Figure 7.3: The attitude of the A320 on landing. The runway was probably built outside normal specications. The braking systems of the A320 are sketched in Figure 7.4. The logic appears as follows. AG is true if ((WoW 12 tonnes) and wheels spinning grt 72 km/hr) or (wheels spinning 72 km/hr and radio alt 10ft) whereAG means At Ground, and WoW means Weight on Wheels. Note that weight on wheels is a function of both wheels and not just an individual wheel. The standing water on the runway caused th aircraft to aqua-plane while braking and consequently the wheels were not spinning at the required rate to activate the braking logic. Thus we had, AG = False (weight on both wheels), WS = False (wheels spinning at 72 km/hr), 105

Radio Alt = True (radio altimeter 10 feet).

Spoliers 40% WoW LGCIU
Landing Gear Control

SEC
Spolier and Elevators

Altimeter

EFCS
Flight Control

Alt.

Brakes 40% BSCU

Brakes and Steering

Pilot Interface

Reverse Thrust 20% FADEC

Full Authority Digital Engine Controller

Figure 7.4: The braking systems of the A320 airbus The logic was implemented correctly but the system failed. The LGCIU and its related systems failed against intent. The operators and in particular the air-crew may have failed in this particular instance but there is no manual override in some modes of the EFCS. Overall, this is quite probably a failure in requirements but the situation is perhaps not a very credible one. Further, we can isolate the error, aw and fault which lead to the accident The error which caused the accident was the assignment AG = False, The aw leading to the error in the circumstance of the accident was that we required AG = WoW 12tonnes for both wheels2 . The failure arose because the aw was triggered in condition of wind and water on the runway. Remark 7.3 (i) Typically accidents arise from multiple failures rather than just single failures. This is why studying accidents and their causes is important. We must correct or avoid the circumstances of the accident if we are to develop safe systems. (ii) Failures occur with respect to intent, not necessarily with respect to the specication. In fact, many such failures result from not getting the requirements correct in the rst place. (iii) Causal analysis is complex because of the potential interactions of the system with its environment. Further, apportioning responsibility for accidents is rarely straight-forward and thus making it harder to judge the contribution of the systems involved to the accident. (iv) In aerospace, pilots are often blamed but the systems are usually a key factor in accidents.
2

But note that it is arguable whether or not this is really a aw because the situation is not very credible.

106

7.6 Requirements in Safety Life-cycles

Let us begin by considering a system development model like the one in Figure 7.5 based on the V model of Figure 2.6. In the systems development model we have concept and requirements phases
Requirements Overall System

Design

System

System Testing Integration Testing

Decomposition Software Requirements

Subsystems Units

Implementation

Figure 7.5: The V model for a system development process. for the system, followed by design and a decomposition of the system into hardware and software components. It is usually at this stage that software requirements phases occur since the software must work with the hardware to achieve the functions of the system. Superimposed on the system development life-cycle is the safety life-cycle. The safety life-cycle consists of a number of activities which are aimed at determining and verifying the safety functions of the system. We begin in Figure 7.6 with the initial hazard list which is the list of known hazards in
Initial Hazard List Hazard Identification Causal Analysis Consequence Analysis Implementation Causal Analysis Overall System

Figure 7.6: Safety analyses superimposed on the V system development model. the domain or a list of hazards obtained from similar systems or prior versions of the current system. We then go through a Preliminary Hazard Analysis (PHA) for the new system followed by the relevant consequence and causal analyses for the system. Preliminary Hazard Analysis is aimed at determining potential hazards for the new system as well 107

as the causes of failure leading to these hazards and the likelihood of such failures. It includes the Preliminary Hazard Identication phase. Consequence Analysis (inductive analysis) is typically performed bottom up, that is, we work from design elements to hazards. Consequence analysis together with causal analysis is predicative and often carried out before the design is completed. It is used to provide information into the design processes and is aimed at choosing between design alternatives. Some inductive methods for consequence analysis are Event Trees, Failure Modes and Effects Analysis (FMEA) and Zonal Hazard Analysis (ZHA). Causal Analysis (deductive analysis) is typically performed top-down working from hazards to design or model elements. Fault trees are the classic deductive analysis method and Hazard and Operability Studies (HAZOP) is also common. We have listed some inductive and deductive methods above but in practice there are over 90 different analysis methods that have been suggested in the literature. We will not be covering them all! Finally, there is a safety case that needs to be built up during the development process. A safety case is a clear, comprehensible and defensible argument that a platform will be acceptably safe throughout its life and decommissioning. Safety cases are required for the justication or certication of any safety-critical or safety-related system, facility or operation.
Initial Hazard List Safety Case

Hazard Log Supporting Evidence High Level Arguments

Implementation

Figure 7.7: Safety cases superimposed on the V system development model. In summary, the life-cycles require that: determine what we mean by safe for the platform hazard identication and consequence analysis; design the platform so that it is safe using hazard identication and causal analysis; show that the platform is safe produce a safety case.

108

7.7 Preliminary Hazard Analysis

Preliminary Hazard Analysis is typically the rst activity in the safety life-cycle and involves the identication of hazards and accident scenarios which are possible of the new system. The inputs to
Experts

Incident Data PHA Hazard Data Analyses Analysis of similar systems or prior versions of the same system. Preliminary Hazard List

Figure 7.8: Preliminary Hazard Analysis: Essentially a collating and ltering exercise. a PHA are the prior incident data for systems similar to the new system, Hazard data and previous analyses. The output is a preliminary hazard log. For example, a preliminary hazard analysis may be summarised in the following hazard log. Methods PHA is a group based activity where safety related design difculties and hazards are postulated. Usually conducted either Informally using brainstorming; Formally using some of the graphical or tabular methods. Checklists are commonly used for ensuring completeness. The group tries to pin down which aspects of the system will cause trouble. It is common to ask what if questions. Output An initial Hazard Log (see Table 7.1).

Inputs
The inputs required for a Preliminary Hazard Analysis (PHA) are: 109

 Prior incident data for systems similar to the new system, Hazard data, and Previous analyses.

Methods
PHA is a group based activity where safety related design difculties and hazards are postulated. Usually conducted either: Informally - using brainstorming; or Formally - using some of the graphical or tabular methods. Preliminary Hazard Analysis relies very heavily on experience, knowledge of previous systems and on ensuring that experts from all of the relevant disciplines are present. Checklists and questionnaires are commonly used for ensuring completeness. The group tries to pin down which aspects of the system will cause trouble. It is common to ask what if questions and take notes for later analysis including possible event sequences leading to accidents, system causes and other factors such as human factors. One approach, that is taken by the High Integrity Systems group at the University of York, partitions the PHA into three areas. Functional Failure Analysis: considers the consequences of the failure of each of the identiable system functions. Examples include, Failure to actuate brakes when a force is applied to the brake. Operational and Support Hazard Analysis: consider the tasks and interaction of the personnel with the system. Examples include: Burns from equipment, electrocution; Faulty equipment resulting in a failure to complete a task for example, dispatching an ambulance to a code red. Occupational Health Hazard Analysis: considers harm to personnel caused by the functioning of the system. Examples include Electrical, chemical or heat burns, or physical injury from the movement of parts.

110

Ref.

Hazard Possible Cause

Risk Class Target Risk Class

Table 7.1: An example hazard log.

Outputs
The output of a PHA is: Preliminary hazard log; and A set of safety requirements. A preliminary hazard log can be summarised as in the following table. The second output is a set of safety requirements for the system. Safety requirements are those requirements stemming from the PHA and other safety analyses that: Are related to systems or subsystems that must mitigate hazards, or lessen their effect; or Are related to the integrity levels of failure rates of safety related subsystems. Remark 7.4 1. Note that our example hazard log contains a column for the current risk class and a column for the integrity level. It is important to distinguish these concepts. Risk measures the likelihood of a hazard of a certain severity occurring and is a property of a hazard in a given environment. Safety integrity refers to the amount of risk reduction required of a safety related system used to mitigate the effects of the hazard or reduce its likelihood. In general, the higher the integrity level of the safety related system, the greater the amount of risk reduction it is responsible for. 2. Risk classes are calculated from the severity and likelihood of the hazards identied. Standards like IEC1508 provide tables for the qualitative assessment of risk. Quantitative risk assessment is also possible provided that the reliability of all components including software is known. The problem here is that reliability estimates for software components cannot usually be estimated so early in a project.

7.8 Risk is Severity by Likelihood

Note that Table 7.1 contains a column for the current risk class and a column for the target risk class. Risk classes are calculated from the severity and likelihood of the hazards identied. Standards like IEC1508 usually provide for a qualitative analysis. IEC-1508 provides a table for assessing the severity of an a hazard in the form of a table like the following. Catastrophic Critical Marginal Negligible and classies likelihoods into the following classes, 111

Frequent Probable Occasional Remote Improbable Incredible. Part of the problem of PHA is to assign meaningful measures to these classes so that hazards are interpreted consistently. In AS4048.1 and IEC65A the Risk Class is then given by Table 7.2. The interpretation of risk Frequency Consequence Catastrophic Critical Marginal Negligible Frequent I I I II Probable I I II III Occasional I II III III Remote II III III IV Incredible IV IV IV IV Table 7.2: Risk classes according to IEC65A which was a predecessor of IEC1508. classes according to IEC65A is given in Table 7.3. Class I Class II Class III Class IV Intolerable risk Undesirable risk and tolerable only if risk reduction is impractical. Tolerable risk if the cost of risk reduction would exceed the improvement gained. Negligible risk.

Table 7.3: The interpretation of the risk classes according to IEC65A.

7.9 Hazard Analyses

Hazard analysis is the process of determining the causes, effects and risks of hazards in safety related systems and to understand and monitor the level of integrity for safety related systems.

7.10 Exploratory MethodsHAZOPs

Hazard and Operability Studies (HAZOP) is a useful exploratory technique commonly used during requirements or as part of a PHA. HAZOP is a team activity requiring A Team leader who is responsible for: Planning and Preparation; Chairing the HAZOPs meetings; Signing any documentation; 112

Type of Technique Exploratory

Causal

Consequence

Good For . . . Exploring possible hazards, their causes and for completeness, but is very labour intensive and hard to change. Fault Trees This is the classic deductive approach and is good for determining what combinations of component failures lead to hazards. FMEA (Failure Modes This is the classical inductive approach and Effects Analysis) used for working from component failures (failure modes) back to hazards and is good for verifying ideas and designs. Table 7.4: Types of Hazard Analysis Methods.

Possible Methods HAZOP (Hazard and Operability Studies)

Ensuring follow-up work is completed. Recorder who is responsible for: Documenting the analysis; Participating in the study. Designers Understand and explain the (potential) design; Answer questions about the process. User(s) who may be an operator, or representative of other user groups such as maintainers of the system; Supply information about the context in which the system will be used; Help decide issues that may affect safety. Expert(s) The key function of experts is to Explore Ask questions; Suggest deviations, causes and effects. HAZOP uses guide words to consider the effects and causes of system failures of various kinds. The guide-words in Table 7.5 are taken form MoD 0058 and are for use with software HAZOPs.

113

Guide Word NO or NONE

MORE LESS AS WELL AS PART OF REVERSE OTHER THAN

EARLY LATE BEFORE AFTER

Deviation This is the complete negation of the design intention. No part of the intention is achieved and nothing else happens. This is a quantitative increase. This is a quantitative decrease. All the design intention is achieved together with additions. Only some of the design intention is achieved. The logical opposite of the intention is achieved. Complete substitution, where no part of the original intention is achieved but something quite different happens. Something happens earlier than expected relative to clock time. Something happens later than expected relative to clock time. Something happens before it is expected, relating to order or sequence. Something happens after it is expected, relating to order or sequence. Table 7.5: Guidewords for Software HAZOPs

114

Basic Event An initiating fault requiring no further action

Undeveloped Event An event which is not developed further, either because it is considered unnecessary or because insuficient information is available. Intermediate Event An event arising from the combination of other, more basic events.

Normal Event An event which is expected to occur as part of the normal operation of the system. Conditioning Event Specific restrictions that apply to some types of logic gates, for example the PRIORITY AND or INHIBIT gates.

Figure 7.9: Fault tree event symbols.

7.11 Causal Analysis: Fault Trees

Fault trees are on of the classic deductive techniques for hazard analysis and is now one of the most common deductive technique in use. Fault trees are typically drawn by working back from hazards to basic causes. Fault trees are a graphical notation and consist of events and gates. The most common events are shown in Figure 7.9 and the gates are shown in Figure 7.10. The basic method for working with fault trees is the following. 1. Select an Event Initially we select top-level events which are typically the hazards, or events which can lead to the hazards, identied in the PHA. 2. Identify immediate, necessary and sufcient causes of this event. immediate means that we need to avoid missing out intermediate events and should apply the think small principle; necessary means determining those events which must occur for the top-level event to occur and these should be linked with an AND gate; sufcient means getting those events which alone are sufcient to cause the top-level event and these are linked with an OR gate. 3. Classify intermediate events 115

AND gate All of the inputs must occur for the output to occur

OR gate One or more of the input events must occur for the output to occur

PRIORITY AND gate The output occurs if the input events occur in a specific sequence which is described in a conditioning event.

EXCLUSIVE OR gate The output occurs if exactly one of the input events occurs.

INHIBIT gate The output occurs if the single input event occurs in the presence of the enabling condition which is described in the conditioning event.

Figure 7.10: Fault tree gate symbols. Basic Event requires no further decomposition. Compound Defect which may one of (1) a primary failure which is a simple component failure and may be classied as a basic event, or (2) a secondary failure in which components fail because of external inuences and this usually requires further investigation, or (3) command failure in which components receive incorrect signals and this always requires further investigation. System Defect which is not attributable to a single component and always requires further investigation. 4. Repeat as required! There are some further heuristics, which have evolved over time, for the correct construction of fault trees. 1. All inputs to a gate should be dened before any one is examined in more detail. 2. The output of a gate must never be directly linked to the input of another gate all outputs of gates must go to events. 116

Tank overflows

B Controller

Valve A Closed

Valve B open

X Y A Valve B Failed Incorrect Control to Valve B

Controller Failed

Level Sensing Failed

Sensor X Failed

Sensor Y Faield

Figure 7.11: Fault tree example: chemical mixing. 3. The text in event boxes should be complete in the sense that they should always say what the event is and when it occurs. 4. Causes always chronologically precede consequences. Consider the simple chemical mixing plant shown in Figure 7.11 and its accompanying fault tree [12]. The top-level event which leads to a hazard in this case is that the tank may overow and cause environmental damage. The immediate, necessary and sufcient causes of this event are that the valve marked A is closed and that the valve marked B is open. Note that these events must occur before the tank overows. The fault tree does not investigate the causes of the event valve A closed further. On the other hand valve B is open if valve B has failed, which is a component failure but is not investigated further, or an incorrect signal has been sent to valve B, which is a command failure and must be investigated further.

7.12 Safety Requirements and Integrity Levels

The analysis provides us with three factors: (i) A list of Hazards, which can be added to during development, and an analysis of the potential failures or event sequences which can lead to a hazard. 117

(ii) An assessment of the Current Risk of the hazard and the Target Risk. (iii) Causal analyses indicating which system components can potentially lead to hazards if they fail. Next, we need to understand Safety Integrity. Safety integrity is the likelihood of a safety related system satisfactorily performing the required safety functions under all stated conditions. For example, a standard with known failure rates for subsystems; Integrity Probability of failure to Level perform system function 4 105 to < 104 3 104 to < 103 2 103 to < 102 1 102 to < 101 Note: the distinction between risk classes and integrity levels. Risk classes are assigned to hazards. Integrity levels are assigned to systems. It is not always possible to remove hazards entirely. It is the task of safety related systems must reduce hazard risks to tolerable risk levels which is why target risk assessments are important. The amount of risk reduction that is required to reduce the assessed risk to the target risk determines the integrity level. The more that the system is required to reduce the risk of hazards the higher the systems integrity level. Note that there are a number of ways of assigning integrity levels to subsystems. Quantitative methods rst determine the uncontrolled risk and then target risk levels numerically, by analysing the failure rates of subsystems from similar situations; Qualitative methods use risk graphs to determine risk qualitatively.

7.13 Safety Requirements

We are now in a position to derive the safety requirements for the system. The aim is to put into place safety subsystems which will reduce the assessed risk of a hazard to the target risk of the hazard and to assign integrity levels to these subsystems. We can use consequence analysis to determine which subsystems need to be high integrity, or where new subsystems may need to be introduced in order to meet the target risk assessments for each of the hazards. Safety requirements are simply safety related requirements. They can specify the integrity level of certain subsystems, the reliability of subsystems that must defend against hazards or that certain hazards must be defended in depth. The PHA can help to determine the safety requirements on the system but these are liable to change as a better understanding of the system and the safety implications evolve. The aim of hazard analysis is to identify and list these pre-conditions for accidents and to attempt to build a system that will avoid these. The safety requirements are intended to identify requirements on subsystems in terms of their functionality and reliability that will reduce the impact of an accident should it occur, or to avoid the hazard all together. Typically, safety requirements are requirements on 118

the system that we are building.

119

Bibliography
[1] W. Bischofberger and G. Pomberger. Prototyping-Oriented Software Development: Concepts and Tools. Texts and Monographs in Computer Science. Springer-Verlag, 1992. [2] B. Boehm. A spiral model for software development and enhancement. Computer, 21(5):440 454, May 1988. [3] G. Booch, J. Rumbaugh, and I. Jacobson. The Unied Modelling Language User Guide. Object Technology Series. Addison-Wesley, 1999. [4] M. Cotterell and B. Hughes. Software Project Management. International Thomson Press, 1995. [5] Davis, A.M. Software Requirements: Objects, Functions and States. Prentice Hall, 1993. Revised Edition. [6] David Harel. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8:231274, 1987. [7] B. Hargrave. When to prototype: Decision variables used in industry. Information and Software Technology, 37(2):113118, 1995. [8] ANSI/IEEE Std 610.12-1990,Glossary of Software Engineering Terminology. In IEEE, editor, IEEE Software Engineering Standards Collection. New York, 1994. [9] E. Kazmierczak, P. Dart, M. Winikoff, and L. Sterling. Verifying requirements through mathematical modeling and animation. Internation Journal of Knowledge Engineering and Software Engineering, 2000. To appear. [10] D. Kulak and E. Guiney. Use Cases: Requirements in Context. ACM Press, 2000. [11] Luqi. Status report: Computer-aided prototyping. IEEE Software, 9(6):7781, November 1992. [12] J. McDermid, T. Kelly, M. Nicholson, and D. Pumfrey. Computer system hazard analysis. Course Notes from the High Integrity Systems Group at York University, 1995. [13] B. Oestereich. Developing Software with UML: Object-Oriented Analysis and Design in Practice. Object Technology. Addison-Wesley, 1999. [14] S.L. Peeger. Software Engineering: Theory and Practice. Prentice-Hall, 1998.

120

[15] R. Pooley and P. Stevens. Using UML: Software Engineering with Objects and Components. Object Technology Series. Addison-Wesley, 1999. [16] R. Pressman. Software Engineering: A Practitioners Approach. McGraw-Hill, fourth edition, 1997. [17] W. Royce. Managing the development of large software systems. In IEEE WESCON, pages 19, August 1970. [18] J. Rumbaugh. Object-Oriented Modeling and Design. Prentice-Hall, 1991. [19] Philip Sallis, Graham Tate, and Stephen McDonell. Software Engineering. Addison Wesley Publishing Co., 1995. [20] Software Engineering Standards Commitee of the IEEE. IEEE Recommended Practice for Software Requirements Specications. IEEE, 1993. [21] I. Sommerville. Software Engineering. Addison-Wesley, fth edition, 1996. [22] A.M. Stareld, K.A. Smith, and A.L. Bleloch. How to Model It: Problem Solving for the Computer Age. McGraw-Hill Publishing Company, 1990.

121