Viewpoints principles, problems and a practical approach to requirements engineering

Ian Sommerville and Pete SawyerCooperative Systems Engineering GroupTechnical Report Ref: CSEG/15/1997

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

ABSTRACT

The paper includes a survey and discussion of viewpoint-oriented approaches to requirements engineering and apresentation of new work in this area which has been designed with practical application in mind. We describe thebenefits of viewpoint-oriented requirements engineering and describe the strengths and weaknesses of a number ofviewpoint-oriented methods. We discuss the practical problems of introducing viewpoint-oriented requirementsengineering into industrial software engineering practice and why these have prevented the widespread use of existingapproaches.

We then introduce a new model of viewpoints called Preview. Preview viewpoints are flexible, generic entitieswhich can be used in different ways and in different application domains. We describe the novel characteristics of thePreview viewpoints model and the associated processes of requirements discovery, analysis and negotiation. Finally,we discuss how well this approach addresses some outstanding problems in requirements engineering (RE) and thepractical industrial problems of introducing new requirements engineering methods.

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

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

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

RUNNING TITLE: VIEWPOINTS FOR REQUIREMENTS ENGINEERING

Contact details:

Prof. Ian Sommerville

Computing Department, Lancaster University,LANCASTER LA1 4YR, UK+44 1524 593795 (phone)+44 1524 593608 (fax)is@comp.lancs.ac.uk

1

Viewpoints: principles, problems and a practical

approach to requirements engineering

Ian Sommerville and Pete Sawyer,

Computing Department, Lancaster University,

Lancaster LA1 4YR, UK

ABSTRACT

The paper includes a survey and discussion of viewpoint-oriented approaches to requirementsengineering and a presentation of new work in this area which has been designed with practicalapplication in mind. We describe the benefits of viewpoint-oriented requirements engineering anddescribe the strengths and weaknesses of a number of viewpoint-oriented methods. We discuss thepractical problems of introducing viewpoint-oriented requirements engineering into industrialsoftware engineering practice and why these have prevented the widespread use of existingapproaches.

We then introduce a new model of viewpoints called Preview. Preview viewpoints are

flexible, generic entities which can be used in different ways and in different application domains.We describe the novel characteristics of the Preview viewpoints model and the associated

processes of requirements discovery, analysis and negotiation. Finally, we discuss how well thisapproach addresses some outstanding problems in requirements engineering (RE) and the practicalindustrial problems of introducing new requirements engineering methods.

2

1.INTRODUCTION

The specification of large computer-based systems is a very complex process. Ideally, a systemspecification should only define what services the system should provide and the operational

constraints on the system. It should be complete and consistent, should not include implementationdetail and should be presented in such a way that it is understandable by a range of readers frompotential end-users of the system to engineers responsible for its implementation.

In practice, these are unrealisable goals. For technical, human and environmental reasons,system requirements specifications will always be imperfect. However, although perfection isimpossible, there is no doubt that much can be done to improve the quality of most systemspecifications. It has been recognised for many years that problems with specifications are

probably the principal reason for project failure where systems are delivered late, do not meet thereal needs of their users, and perform in an unsatisfactory way [GAO, 1979; (Gibbs, 1994; Barlas,1996).

Improving the quality of specifications can be achieved in two ways:1.By improving the requirements engineering process so that errors are not introduced into thespecification.2.By improving the organisation and presentation of the specification itself so that it is moreamenable to validation.This paper discusses an approach to system requirements engineering which addresses both ofthese improvement dimensions. This is based on collecting and analysing the requirements for acomputer-based system from different perspectives or viewpoints. Viewpoints are entities whichmay be used to structure the process of requirements elicitation and to structure the requirementsspecification.

In the remainder of the paper, we introduce the notion of viewpoints, describe severalviewpoint models which have been proposed and practical problems of introducing these into

industrial software engineering. We go on to propose a flexible, ‘lightweight’ model of viewpoints(Preview) which has been designed to be incorporated into existing requirements engineeringprocesses at relatively low-cost . Finally, we assess the utility of this approach.2.

VIEWPOINTS

A viewpoint-based approach to requirements engineering recognises that all information about thesystem requirements cannot be discovered by considering the system from a single perspective.Rather, we need to collect and organise requirements from a number of different viewpoints. A

3

viewpoint is an encapsulation of partial information about a system’s requirements. Informationfrom different viewpoints must be integrated to form the final system specification.

The principal arguments in favour of a viewpoint-based approach to requirements engineeringare:

1.Systems usage is heterogeneous - there is no such thing as a typical user. Viewpoints mayorganise system requirements from different classes of system end-user and other systemstakeholders.2.Different types of information are needed to specify systems including information about theapplication domain, information about the system’s environment and engineering informationabout the system’s development. Viewpoints may be used to collect and classify thisinformation.3.Viewpoints may be used as a means of structuring the process of requirements elicitation.4.Viewpoints may be used to encapsulate different models of the system each of which providessome specification information.5.Viewpoints may be used to structure the requirements description and expose conflicts betweendifferent requirements.The notion of viewpoints for requirements engineering is intended to formalise what we believeis a natural part of any analysis process. A good requirements engineer will collect informationabout whatever is being studied from a number of different sources and will recognise that thesesources may have different, often equally valid, perspectives. Recognising these perspectives andreconciling differences between them is essential if the analysis is to be valid. Viewpoint-orientedapproaches are simply a means of formalising this intuitive multi-perspective analysis.

In the viewpoint-based methods which have been developed, two different kinds of viewpointhave been proposed:

1.Viewpoints associated with system stakeholders. Informally, a system stakeholder is anyonewho is, directly or indirectly, affected by the existence of a system. Hence stakeholders may beend-users of a system, managers of organisations where systems are installed, other humanand computer-based systems in an organisation, external entities who have some kind of

interest in the system (e.g. regulatory bodies, customers of an organisation which has installedthe system) and engineers involved in the design, development and maintenance of the system.2.Viewpoints associated with organisational and domain knowledge. Organisational anddomain knowledge is knowledge which constrains the system requirements. The constraintsmay be physical (e.g. network performance), organisational (e.g. incompatible hardware used

4

in different divisions of a company), human (e.g. average operator error rate) or may reflectlocal, national or international laws, regulations and standards. This type of viewpoint cannotbe associated with a single class of stakeholder but includes information collected from manydifferent sources (people, documents, other systems, etc.)

To illustrate the range of viewpoints which may be useful for discovering, analysing and

documenting the requirements for a computer-based system, consider a (relatively simple) Internet-based system to provide on-line banking facilities to customers through a WWW interface.Viewpoints which may have to be considered are:

1.One or more customer viewpoints, depending on different types of customer such as businessand personal customers (stakeholder)2.One or more bank staff viewpoints covering the operation and management of the system(stakeholder)3.A security viewpoint (stakeholder)4.A marketing viewpoint (stakeholder)5.A database viewpoint (organisational)6.A personnel viewpoint (organisational)

7.A regulatory viewpoint (domain - banks have external regulators)8.An engineering/networking viewpoint (domain)

In practice, if too many viewpoints are identified, it is difficult to manage the large amount ofinformation generated and prioritise the requirements. Therefore, an essential stage of most

viewpoint-based methods is to select only the most critical viewpoints to be used in the analysis.Requirements engineers must balance the advantages of wider coverage offered by additionalviewpoints against the costs of analysis and the problems of information management.

This paper focuses on viewpoints for requirements engineering of computer-based systems butthe concept has also been found to be useful in other areas. In intelligent teaching systems anddistributed AI, the notions of cognitive viewpoints to encapsulate beliefs have been found to beuseful (Moyse, 1992; Self, 1992); in communications, the ODP reference model defines fiveviewpoints (enterprise, information, computational, engineering and technology) from which asystem may be specified (Linington, 1995; Bowman et al., 1996); in CSCW, viewpoints havebeen used to structure organisational analyses (Hughes et al., 1995) and in concurrent engineering,viewpoints have been proposed as a systematic approach to conflict analysis (Klein, 1992). To avoid an information explosion, we have restricted the discussion here to approacheswhich have adopted the explicit notion of a viewpoint rather than a more general multiple

5

perspective approach to analysis. This more general notion is supported in the approach to

requirements engineering proposed in the NATURE project (Jarke et al., 1993; Zemanek et al.,1995) by Jackson and Jackson (Jackson and Jackson, 1996) and by Feather (Feather, 1993).3.

VIEWPOINT MODELS FOR REQUIREMENTS ENGINEERING

A number of different models of viewpoints have been developed as part of different multi-perspective approaches to requirements engineering. Different models are applicable at differentstages in the requirements engineering process. Of course, we recognise that there is no such thingas a ‘standard’ requirements engineering process but we believe that most processes broadlyconform to the general model illustrated in Figure 1.

RequirementsdiscoveryRequirementsanalysisRequirementsnegotiationRequirementsspecificationStatement of needs.Existing system information.Regulations, Standards, etc.Domain experience.User requirementsdocumentSystem specificationFigure 1 The requirements engineering process

The cloud icons in this model indicate that the boundaries of these activities are not well-defined. The inputs to the model are a statement of organisational needs plus information onexisting systems which impact the system to be procured in some way. These may be directlyinterfaced to the system or may have to be reused, in some way, as part of the system

development. Other inputs include applicable standards and regulations, and domain experience.The phases of this generic requirements engineering process are:1.Requirements discovery

Given a statement of organisational needs, various different sources are consulted to

understand the problem and the application domain and to establish their requirements. Theserequirements may not be complete and may be expressed in a vague and unstructured way2.Requirements analysis

The requirements collected during the discovery phase are integrated and analysed. Usually,

6

this results in the identification of missing requirements, inconsistencies and requirementsconflicts. The discovery phase generally has to be re-entered to find additional information toresolve these problems.

3.Requirements negotiation

The system stakeholders negotiate to agree on a set of requirements for the system. Generally,there are a greater number of desirable requirements than can be implemented so decisions haveto be made at this stage about leaving out requirements and modifying requirements to result ina lower-cost system.4.Requirements specification

The set of agreed requirements is documented. The output from this process may be either auser requirements document, a system specification or both of these. A user requirementsdocument is usually a natural language document where the system requirements are set out ina form understandable by customers and end-users of the system. A system specification is amore detailed description of what services the system should provide and the constraints on itsdevelopment and operation.This process model is consistent with Freeman and Leite’s discussion (Leite and Freeman,1991) of requirements engineering activities. They suggest that these activities fall into two classes:••

Elicitation activities which are concerned with fact finding, communication and fact validation.Modelling activities which are concerned with requirements representation and organisation.

In our model, the elicitation activities are requirements discovery, analysis and negotiation;requirements specification is a modelling activity.3.1

Viewpoints for Requirements Elicitation

Where viewpoints are used to support requirements elicitation, they are clearly outside of thesystem being specified and are, primarily, the sources of the system requirements. At this stage,only informal descriptions and models of the system are likely to be available. Requirements areusually expressed using natural language, diagrams and domain-specific notations such asmathematical formulae, etc.

Leite and Freeman (Leite and Freeman, 1991) describe an approach to viewpoint-orientedelicitation where they consider a viewpoint to be:

“a standing or mental position used by an individual when examining or observing auniverse of discourse. It is identified by an individual e.g. his name, and his role in theuniverse of discourse, e.g. a systems analyst, programmer or manager”

7

From this definition, they go on to describe an approach to requirements elicitation based oncollecting information from different viewpoints and constructing views. A view is an integration ofdifferent types of information (e.g. data processing information, data structure information) takenfrom the same viewpoint.

An interesting characteristic of this work is that there is a one-to-many mapping from

information sources to viewpoints. The viewpoint is a mental position so the same individual mayprovide information from several different viewpoints. This reflects the fact that people often havea number of different roles in an organisation (e.g. the same person can be a system end-user andresponsible for overall system security). The strength of this work is that it provides for automaticchecking and problem detection at an early stage of the elicitation process.

We have also been involved in previous work on viewpoints for requirements elicitation. Inthe first version of this work (Kotonya and Sommerville, 1992), we modelled a viewpoint as areceiver of services from a system and a provider of data and control information. Viewpoints weretherefore clearly associated with entities which interacted with the system to be specified. Theseinteractors could either be system end-users or other computer systems which were interfaced tothe system being specified.

The arguments in favour of this approach are:1.It is relatively easy to decide whether or not an entity is a valid viewpoint. If it interacts with thesystem in some way, it is a viewpoint and the interaction must be defined.2.A large class of systems may be modelled as service delivery systems. This is confirmed byGreenspan (Greenspan and Feblowitz, 1993) who discusses the advantages of this approach.It is particularly appropriate for interactive systems. End-users find it fairly natural to describetheir requirements in terms of services as, for example, they can relate services to the supportof their own business processes.3.Non-functional requirements such as performance and availability requirements can beassociated with the delivery of a service or a set of services. They are expressed as service

constraints (Kotonya and Sommerville, 1993). These may differ from one viewpoint to anotherand part of the viewpoint analysis process is to detect and resolve such conflicts.4.Control information associated with the starting, stopping and delivery of the services may benaturally included with the service description.5.Specific user interface requirements may be associated with services delivered through theinterface.A method called VORD (Viewpoint-Oriented Requirements Definition) and associated toolswere designed to support this model of viewpoints. The VORD process included activities

8

concerned with viewpoint identification, viewpoint service description, cross-viewpoint analysis todiscover inconsistencies, omissions and conflicts and developing an object-oriented model of thesystem from the viewpoint analysis. VORD allowed the services to be specified in any appropriatenotation either informal, structured or formal. Multiple specifications, in different notations, of thesame services could be provided and linked.

An evolution of the VORD method (Kotonya and Sommerville, 1996) introduced the idea ofindirect viewpoints. Indirect viewpoints may express requirements on a specific service, on a set ofrelated services or on all of the services provided by the system. This is a broad notion whichencompasses viewpoints such as engineering viewpoints which are concerned with the systemdesign and implementation, organisational viewpoints which are concerned with organisationalissues such as process re-engineering and external viewpoints such as the viewpoint of a regulatorresponsible for certifying safety-critical systems.3.2

Viewpoints for Requirements Modelling

As part of the detailed requirements specification of a system, it is common practice to develop aset of system models which may be expressed in informal, structured or (less commonly)mathematically formal notations. There is an important strand of work in viewpoint-oriented

requirements engineering which considers a viewpoint to be a framework for identifying, definingand checking the consistency of these system models.

Structured methods, such as JSD (Jackson, 1983) or the various flavours of object-orientedanalysis (Rumbaugh et al., 1991; Jacobson et al., 1993; Booch, 1994), incorporate an implicitnotion of viewpoints. These methods suggest that a number of different system models should bedeveloped, each of which can be thought of as a different viewpoint on the system. SADT (Ross,1977; Schoman and Ross, 1977) goes further in that it suggests that analysis should be undertakenfrom different viewpoints but it does not include viewpoints as explicit entities in the method.Rather, viewpoints are seen as sources or sinks for data in a data-processing model of the systemwhich is required by the method.

The CORE method (Mullery, 1979) which is based on SADT-like ‘data processing’ models ofa system was the first structured method to include viewpoints as method entities. It includesexplicit viewpoint identification and analysis steps as part of the method. CORE has been widelyused for UK defence projects and in the European aerospace industry but has made less of animpact outside these domains. There is no good public documentation on the method or low-cost,readily available supporting tools.

In structured methods, the set of models, the notations used, and the rules and guidelinesapplied to these models are pre-defined. The system models can only be presented from the

perspectives defined in the structured method. This can lead to misunderstandings because of the

9

misfit between the customer and end-users perception of the system requirements and the systemdescription. The method rules are often inappropriate as requirements are evolving so that themethod-support tools are a hindrance rather than a help.

A complementary approach to system modelling with viewpoints is to define the viewpointsfrom which models should be developed without constraining the model representation. Themodels developed are not necessarily limited to models of the software whose requirements arebeing specified but may include organisational models, process models, etc. For example,Greenspan (Greenspan and Feblowitz, 1993) defines four viewpoints which may be used inderiving system requirements:

1.A service viewpoint where a set of services provided to customers is modelled. These servicesmay be provided through an automated system, by people or by some mixture of the two.2.A set of workflows or work processes which provide the services.3.A model of the organisation responsible for service provision.

4.A model of the set of systems which provide the capabilities and the resources for providingthe services.The approach of pre-defining a set of viewpoints and constructing models based on theseviewpoints has the merit of simplicity. It also limits the amount of information which has to becollected and provides a basis for the requirements discovery and elicitation process. However, itis restrictive in that the models proposed may be inapplicable in some domains and inappropriatefor some types of system. For example, we agree with Greenspan that the service-oriented

perspective is a useful one for many types of system. However, we found that it was artificial (anddifficult) to apply this approach to real-time control systems.

The approach proposed by Nuseibeh et al. (Nuseibeh et al., 1994) is a flexible approach whichallows specification from multiple viewpoints without pre-defining the notations which should beused. Viewpoints are defined as “loosely coupled, locally managed, distributable objects whichencapsulate partial knowledge about a system and its domain, specified in a particular, suitablerepresentation scheme, and partial knowledge of the process of development”. They are structuredencapsulations of information with five slots:

1.A representation style which defines the notation used in the specification,2.A domain which is defined as ‘the area of concern addressed by the viewpoint’,3.A specification which is a model of a system expressed in the defined style,

4.A work plan, with a process model, which defines how to build and check the specification,

10

5.A work record which is a trace of the actions taken in building, checking and modifying thespecification.This approach to viewpoints can be considered as a ‘method’ in its own right but it is perhapsmore appropriate to view it as a meta-method which is used to define requirements engineeringmethods for use in a specific application domain or organisation. A method engineer must define aset of viewpoint templates (including the viewpoint consistency rules) which are then instantiatedduring the requirements engineering process.

A novel feature of this approach is its notion of inconsistency management (Easterbrook andNuseibeh, 1996). The system does not enforce consistency across viewpoints but provides

support for detecting and, if necessary, resolving inconsistencies. As inconsistencies are inevitablein an evolving specification but need to be resolved in a final specification, this inconsistencymanagement is an important contributor to the usefulness of the approach.

This viewpoint model has a great deal of flexibility and may be used as a basis for automatingpart of the requirements analysis process. In our view, however, it suffers from two specificproblems which limit the applicability of the method to the later stages of system specification.These two problems are:

1.Its support for inconsistency management relies on the ability of the analyst to write inter-viewpoint consistency rules. Checking these automatically requires the system model to beexpressed in at least a structured and, preferably, a formal notation. Where requirements areevolving, this is unlikely to be cost-effective. Specially trained staff are required to write thisspecialised notation. Furthermore, inconsistencies are often a consequence of interactionsbetween functional and non-functional requirements which are impossible to express in aformal way.2.It is a ‘heavyweight’ approach in that it defines a process for establishing and checking thesystem models and the notations which must be used to establish these models. Although ittolerates inconsistency, it does not tolerate informality nor does the viewpoint structure appearto have any slots for including informal, natural language descriptions of the system model.In our view, these limitations mean that there is a high introductory cost in introducing thismethod which constitutes a real barrier to its practical industrial use.4.

PROBLEMS WITH VIEWPOINTS

Very few people doubt the wisdom of considering requirements from multiple perspectives.

Different models of viewpoints have their own strengths and weaknesses but, without exception,they offer advantages over an unstructured approach to requirements elicitation, definition and

11

specification. However, only CORE has made the transition from research to practice and the useof this method is almost entirely limited to UK defence contractors.

We believe that the technical merits of viewpoint-oriented approaches are self-evident but thatthe developers of these techniques have paid insufficient attention to the practical problems ofintroducing them into existing defined and standardised software processes. From our experiencein industrial projects, we have identified the following practical problems which make viewpoint-oriented approaches difficult to use for non-trivial projects:•

Inflexible viewpoint models If the viewpoint model is too restrictive in its definition of a

viewpoint, it will not encompass all of the possible stakeholder and domain viewpoints whichmay be required. Many requirements problems are human, social and organisational problems.Viewpoints need to be able to reflect these positions and not just technical expressions ofsystem requirements.

Fixed notations for requirements definition Requirements sources often will not have time toexpress requirements in anything but their normal working notations. They are unlikely to beable to translate these easily into some different modelling notation. Automated or semi-automated conflict analysis of requirements is, in our view, impractical.

Limited support for requirements evolution Not only is the system’s organisational, economicand political environment changing as the requirements are developed, the better understandingof the system which emerges during the RE process causes requirements to evolve. Viewpoint-oriented approaches must recognise this and must not, for example, require consistency at alltimes.

Limited support for requirements negotiation The process of establishing a final set ofrequirements for a system normally involves stakeholders negotiating changes and

compromises between conflicting requirements. Some means of discovering conflicting andoverlapping requirements is helpful here. However, automated conflict resolution may becounter-productive as it does not recognise the non-technical factors which influence therequirements negotiation activity.

No industrial-strength tool support Viewpoint-oriented approaches tend to generate a largeamount of information which must be managed and this obviously requires tool support ofsome kind. This tool support must be available on platforms used by application developers,must be of good quality, must be compatible with other tools which have already beenpurchased and must be reasonably cheap. It is extremely difficult to meet these support

requirements for any new method because the costs and risks of tool development are so high.

•

•

•

•

12

•

No recognition of the problems of non-functional requirements In some applications, non-functional requirements are more critical than functional requirements. For example, in manycontrol systems, there is an inflexible requirement to maintain the safety of the system whereasthe functional capabilities of the control system are usually negotiable. Requirementsengineering methods don’t handle non-functional requirements very well, especially whenthese are ‘system-level’ requirements rather than requirements associated with a particularfunction or class of functions.

Incompatibility with other software engineering methods Organisations which might benefitfrom the use of viewpoints for requirements engineering generally have existing, defined,design processes. Any requirements engineering method must be compatible with existingdesign methods.

•

These are difficult problems and we do not believe that the designers of viewpoint-orientedmethods have taken sufficient account of these pragmatic difficulties. If requirements engineeringprocesses are to be improved by introducing viewpoints, then we need a ‘lightweight’ approachwhich can be introduced at relatively low cost and risk and which requires evolutionary rather thanrevolutionary process improvement. Such an approach is described in the remainder of this paper.5.

THE PREVIEW APPROACH

The viewpoint model which we describe in the remainder of this paper was developed in a researchand development project called REAIMS, whose principal objective was to investigate techniquesfor requirements engineering process improvement. None of the industrial partners in the projectmade use of viewpoints explicitly in their requirements engineering processes but all agreed that theapproach had potential. However, no existing viewpoint-oriented method could be integrated withtheir existing processes because of the practical difficulties identified above.

We therefore developed a new model of viewpoints which we call Preview (Process andRequirements Engineering Viewpoints) which could be introduced into existing RE processes inan evolutionary rather than a revolutionary way. The priorities of our industrial partners were toimprove the processes of requirements discovery, analysis and negotiation rather than systemspecification. Preview is therefore classed as a viewpoints approach for requirements elicitationrather than system modelling.

Key characteristics of Preview are:1.Requirements associated with a viewpoint may be expressed in any notation. Normally, weexpect these requirements to be expressed in natural language, tables and diagrams. Structuredor formal notations may also be used if appropriate.

13

2.The analysis is driven by a set of concerns which reflect the critical non-functionalcharacteristics of the system.

3. Viewpoints must limit their scope and explicitly describe their perspective in order to facilitaterequirements discovery and analysis.4.Preview may be used for the analysis of processes as well as system requirements. This isuseful because understanding the real requirements for a system is often helped by an analysisof the processes which the system is required to support. We do not cover process analysishere but cover it in a separate paper (Sommerville et al., 1995).5.1

Preview Viewpoints

As in other methods, each Preview viewpoint is an entity which encapsulates some but not allinformation about a system’s requirements. This information may be derived from an analysis ofexisting processes and systems, from discussions with system stakeholders or from domain andorganisational information. Complete requirements for the system are created by integrating therequirements derived from different viewpoints.

A Preview viewpoint includes the following information:1.The viewpoint name. This is used to identify and refer to the viewpoint and should normally be

chosen to reflect the focus of the viewpoint. The name may reflect a role in the organisation ora part of the system or process to which the analysis is restricted.2.The viewpoint focus. A viewpoint's focus defines the scope of the viewpoint. It is expressed asa statement of the perspective adopted by that viewpoint. This is quite difficult to definesuccinctly and we discuss it in more detail later.3.The viewpoint concerns. The viewpoint concerns reflect the organisational goals, businessobjectives and constraints which drive the analysis process.4.The viewpoint sources. Viewpoint sources are explicit identifications of the sources of theinformation associated with the viewpoint.5.The viewpoint requirements. This is the set of requirements arising from analysis of the systemfrom the viewpoint's focus. The requirements may be expressed in terms of systemfunctionality, user needs or constraints arising from application domain or organisationalconsiderations.6.The viewpoint history. This records changes to the viewpoint as an aid to traceability. It

includes changes to the focus, the sources and the requirements encapsulated in the viewpoint.

14

A viewpoint is defined by its focus and we do not exclude any type of viewpoint which anorganisation may find useful in its requirements engineering process. However, we have foundthat viewpoints generally fall into one of three classes:•

Interactor viewpoints These are the viewpoint of something (human or machine) whichinteracts directly with the system being specified. Examples include human operators whoimpose usability requirements or requirements for specific process support functions andexternal systems which impose compatibility and information exchange requirements.Indirect stakeholder viewpoints These are the viewpoint of an entity (human, role or

organisation) which has an interest (stake) in the problem but who does not interact directlywith the system. Examples include operating organisations and standards/regulatory bodies.Indirect stakeholder viewpoints allow Preview to explicitly decouple requirements whichmight be generated by an operator from those which might be generated by the operator'sorganisational structure.

Domain viewpoints These represent a set of related characteristics of the domain which cannotbe identified with a particular stake or interactor but which nevertheless impose requirementswhich are implicit in the domain. For example, requirements on a communication system maybe imposed by signal propagation time in copper and optical cables. Because requirementsarising from domain phenomena are often part of domain experts' knowledge, they may beoverlooked if domain expertise is unavailable or poorly utilised. The use of viewpoints torepresent domain phenomena provides a defence against this.

•

•

Examples of viewpoints from these classes taken from a computer-based system for enginecontrol in an aircraft might be a pilot viewpoint (interactor), a maintenance planning viewpoint(indirect stakeholder) and an electromagnetic radiation environment viewpoint(domainphenomenon).

The statement of requirements encapsulated in a viewpoint may be expressed in any notationand at any level of detail. This reflects the practical consideration that it is difficult to define

requirements precisely at any early stage of the RE process. This lack of precision has benefits asover-prescription at this stage causes problems when conflicts between requirements have to benegotiated.

Of course, this informality does not allow for any automated cross-checking and conflict

analysis across viewpoints. We do not feel that the lack of such analysis is a serious problem. Wehave already discussed that there is a significant cost in writing requirements so that they may bechecked and that non-functional considerations are generally excluded from such automated

checks. For these reasons, our industrial partners did not consider automated consistency checkingto be cost-effective.

15

Like Nuseibeh et al. (Nuseibeh et al., 1994) we think it useful to maintain a viewpoint changehistory as an aid to traceability. This is useful during requirements analysis as it helps the analyst tounderstand changes which have been made and to avoid proposals which have already beenrejected during the initial process of requirements discovery. The change history is simplymaintained as a textual list of changes made and the associated rationale for these changes.5.1.1

Viewpoint concerns

Viewpoint concerns are an innovative feature of Preview and have been introduced so that the

requirements can be explicitly linked to organisational goals and priorities. Concerns correspond tohigh-level strategic objectives for the system. They are used to ensure that the requirements for thesystem are consistent with the business goals of the procuring organisation.

Examples of concerns which are associated with a system might therefore be:1.Safety. Does the system as a whole or parts of the system pose a threat to human life or thesystem’s environment?2.Availability. Will the system be available for service when required?

3.Functionality. What functionality must the system provide in order to be of value to theorganisation procuring the system?4.Maintainability. What are the implications of specific requirements on the maintainability ofthe system?Concerns are established after discussion with strategic management in an organisation and arefirst expressed at a very high level of abstraction. They are frequently common to applicationswithin the same domain . To be effective, the number of concerns should be small (typically nomore than 6) and rigorously scrutinised to eliminate all but the most overriding, system-wide high-level goals and constraints.

It may seem that concerns are a kind of viewpoint but we think it helpful to make a distinctionbetween concerns and viewpoints:

1.Concerns reflect organisational priorities which drive the requirements analysis process.2.Concerns may be broken down into sub-concerns and finally into specific questions whichmust be considered by all viewpoints. These questions act as a check list to ensure thatrequirements from a specific viewpoint do not conflict with organisational priorities.3.Concerns are a way of expressing critical ‘holistic’ requirements which apply to the system as awhole rather than to any specific sub-set of its services or functionality. An example of such arequirement, if safety was a concern, might be that software failures cannot propagate across

16

module boundaries. All viewpoints inherit these requirements and viewpoint requirements mustnot conflict with them.

Concerns cut across all viewpoints and the questions associated with concerns must be linkedto all viewpoints and posed to viewpoint sources as part of the analysis process. This is illustratedin Figure 2 which shows classes of possible viewpoints. These range from equipment connected tothe system and system operators (at the apex of the triangle) to viewpoints associated with thesocio-political environment in which the system is installed.

Safety

Cost

Functionality

equipmentVIEWPOINTSoperatorssupervisors/line managersorganisationsocio-political environmentCONCERNS

Figure 2 The orthogonality of viewpoints and concerns

System functionality may be included as a concern like other non-functional concerns such assafety, reliability, performance, etc. This reflects the fact that, for large and complex systems, it isoften necessary to make trade-offs between functional and non-functional requirements. Systemfunctionality is often negotiable rather than immutable as is sometimes implied by other REmethods.

The practical application of concerns require them to be decomposed into more detailed sub-concerns and questions. Each sub-concern represents a special case of the concern and is

applicable to a subset of the problem space. For example, consider a situation where safety is asystem concern. In this case, a hazard analysis is carried out to identify hazards which thesoftware system should protect against. Each of these hazards may be expressed as external

requirements which apply to the system as a whole and are thus part of all identified viewpoints.Figure 3 shows part of this concern decomposition for a paper guillotine system. This is asoftware-controlled system where a blade moves to cut stacks of paper to some specified size.

17

Safety

Operator safetyEnvironment safety

Cutting hazardsElectrical hazards

Q1Q2

Setup hazardsUsage hazardsMaintenance hazards

ER1ER2ER3

Figure 3 Safety concern decomposition for paper guillotine

The external requirements (ERx) in this example, are derived from the organisational need for asafe maintenance process. Examples of such requirements are shown in Figure 4.

RequirementER1

Name

Accidental startup

Description

The control system must disable the guillotine sothat it cannot be started accidentally during themaintenance process.

ER2

Blade installation

The control system must include a visualindicator to show that both the principal andbackup blade fixing mechanisms are properlysecured.

The guillotine must be disabled until bothprincipal and backup blade fixing mechanisms aresecured.

ER3

Blade removal

The control system must ensure that the bladeshield is in place before the blade lock may beopened.

Figure 4 External requirements for a guillotine system

Under the heading of environmental safety, two questions may be identified:

18

1.In the event of correct operation or system failure, could a requirement compromise the safetyof the environment in which the machine is installed?2.Within a viewpoint, are there any specific requirements for environmental safety which shouldbe identified?Questions associated with concerns are likely to be fairly general and are used both as a driverof requirements discovery and as a checklist for requirements analysis. 5.1.2

Viewpoint focus

A viewpoint's focus is an explicit statement of the perspective adopted by that viewpoint. Thefocus can be a statement of the parts of the problem, the system or the process with which theviewpoint is associated, a statement of the role of the viewpoint sources, a statement of an

organisational function such as management, health and safety, engineering or, perhaps, a mixtureof these. Focus is the defining characteristic of a viewpoint. No two viewpoints have the samefoci (otherwise they would by definition be the same viewpoint) but viewpoints may have fociwhich intersect.

Examples of viewpoint focus might be:•••

User requirements concerned with the interactions between human operators and on-boardsystems

Call charging and customer communication security requirements imposed by atelecommunications regulator

Constraints imposed on system components affected by proximity to high-voltage ignitionsystem components

Different viewpoints may have overlapping foci (see Figure 5). For example, in an air trafficcontrol system we may identify a ‘chief controller’ viewpoint whose focus is the chief controller’sinterests in the display sub-system. This would clearly overlap with a radar controller viewpointwhose focus was the display sub-system in general. It is important to identify these overlappingfoci as they help us discover potential requirements conflicts.

The notion of focus forms a link between the problem space (the “domain” in Jackson's

(Jackson, 1995) terms) and the system (the “machine” ) which is to be developed. Focus is usuallydefined in such a way that it encompasses both system and domain considerations. This isillustrated in Figure 5 where the foci of viewpoints VP1-VP3 (represented as circles) coveroverlapping parts of both the problem and the system which is to be developed to address theproblem.

19

VPs focusing on the requirements inherent in the problem

ProblemVP1VP2VP3VPs projecting the requirements onto the system with the focus on parts of the systemSystemFigure 5 Viewpoints on a problem

The notion of viewpoint focus is useful for a number of reasons:

1.It provides a basis for a coverage analysis. By reviewing the foci of viewpoints, we may beable to find specific parts of the system, problem or domain which have not been considered.2.As we discuss later, it helps identify viewpoints which may include conflicting requirements.3.It is a useful way of discovering requirements sources i.e. people or documents which mightprovide system requirements.4.Where the focus is primarily domain-based, it serves to identify viewpoints which encapsulaterequirements which are potentially reusable across a range of systems.It is not easy to define, at the outset, the focus of all viewpoints. Focus definition is usuallyiterative. Initial foci are proposed and requirements sources are identified. A coverage analysis iscarried out to see if essential parts of the system or domain are not covered by the union of theviewpoints foci. Along with information from sources, the results of this coverage analysis arethen used to re-define the viewpoints’ foci.5.1.3

Viewpoint sources

The sources associated with a viewpoint are an explicit record of where the information associatedwith a viewpoint has come from. Maintaining such a record is valuable for external traceabilitywhere a requirement or a group of requirements can be traced to its source. This simplifies analysiswhen conflicts are discovered and when changes are required.

20

Viewpoint sources are not simply individuals or roles in an organisation. They may alsoinclude:•••••

Manuals of operating procedure

International, national or organisational standardsDomain knowledge

Experience data such as incident descriptions.

Other requirements placed on the system (requirements often cause further requirements to begenerated).

Several sources should be associated with each viewpoint. In a well-understood application,the identification of viewpoint sources normally follows identification of the viewpoint’s focus. Asource is concrete (a named individual or identifiable document) while a viewpoint’s focus may bea role within an organisation, a sub-system or some physical, cognitive or social phenomenon ofthe domain.

However, in an unfamiliar application domain or organisational structure, the processes ofviewpoint identification, focus definition and source selection are inter-leaved. Here, the set ofrelevant viewpoints will not be immediately apparent but will emerge as analysis proceeds anddomain understanding increases. Having identified a potential viewpoint, the requirements

engineer must verify that a corresponding source (e.g. a specific end-user) exists from which theviewpoint requirements may be discovered. Information from that source may then be used todefine the focus and hence point to other possible information sources.

Links to sources at the viewpoint level do not link specific requirements to specific sources.We have adopted this coarse-grained traceability for pragmatic reasons in that it reduces theoverhead of maintaining the information, it emphasises that sources may be equivalent and itavoids over-burdening the requirements engineering with documentation which must be

maintained. Requirements may come from a single source but are an interpretation of informationcollected from several sources. In this respect, it would be artificial to link a requirement directly tosources.

Of course, we recognise that, for some systems, finer-grain traceability is required. This isparticularly likely where there are very specific requirements which are suggested by some source.The Preview model can accommodate this simply by treating a requirement record as a compositedocument which includes a statement of its sources. The viewpoint sources are then the union ofthe sources recorded with each requirement.5.2

The Preview Process

21

Preview is applicable to requirements elicitation activities and we have defined an informal processwhich may be used to apply the Preview approach. This is a 6-step process as illustrated in Figure6.

Requirements discoveryIdentify Elaborate IdentifyDiscoverconcernsconcernsVPsrequirementsConcerns,Viewpoints,DiscoveryExternalAnalysisRequirement requirements,Negotiationpromotions,cycleVP changesRequirementsResolveAnalyse VPInconsistenciesInteractionsRequirements Requirements negotiationanalysisInconsistenciesIncompletenessViewpointsConcernsIntegrate and formatRequirementsdefinitionFigure 6 The Preview process

5.2.1

Requirements discovery

The requirements discovery process is broken down into four activities namely:•Identification of concerns

•Elaboration of concerns as external requirements and questions•Identification of viewpoints

•

Discovery of the requirements for each viewpoint

22

Concern identification and elaboration are critical activities as the fundamental role of concernsis to concentrate the requirements elicitation process on the factors which are central to the system'ssuccess. They correspond to very high-level strategic goals of the organisation procuring and/ordeveloping the system. The first phase in their identification is to ask the question:

What fundamental properties must the system exhibit if it is to be successful?

Where ‘successful’ may mean several things; e.g. profitable for the developer, allowing thecustomer's market position to be maintained, satisfying the current and projected operatingregulations, etc. Knowledge of the fundamental principles of the application domain and the

constraints under which the stakeholders operate are necessary for concern identification. Concernsare therefore normally elicited from the customer (or developer's marketing organisation) and thedeveloper of the system.

Examples of answers to the above question might be:

Application 1: Bank customer account systemStakeholder: Bank

Security, AvailabilityStakeholder: DeveloperCompatibility

In this example, the stakeholders are the bank and the software developer. The bank will suffera catastrophic loss of reputation if the public perceives their systems to be insecure so security is aconcern. Similarly, the public's tolerance of poor availability will be low so this too is a concern.The software developer will only make money if development and maintenance costs are

minimised and these will be high if the issue of compatibility with existing bank systems is notexplicitly addressed.

Application 2: Anti-lock braking system (ABS) control softwareStakeholder: Car manufacturer's marketing divisionSafety, Functionality

Stakeholder: Component supplier

Reuse

In this example, the stakeholders are a car manufacturer (as represented by their marketingdivision) and a component supplier. As with the bank, the car manufacturer is acutely sensitive toreputation. Hence, its concerns are that its ABS system is perceived to be safe and, in order to givea competitive edge, more functional than competitors' products. The component supplier is hereconcerned with maximising the reuse of existing components to minimise development costs.

23

Once identified, the concerns must be elaborated so that they can exert a direct influence onsubsequent requirements activities. The decision on whether to elaborate them to external

requirements or concern questions depends, at least partly, on the extent to which the concern canbe made explicit.

For example, as illustrated earlier a safety concern can typically be decomposed to a number ofexternal requirements, each associated with a specific hazard identified by hazard analysistechniques. Similarly, a security concern could be decomposed to a number of external

requirements, each associated with the avoidance of a particular security risk. An availabilityconcern could be decomposed to a specific external requirement expressed in terms of someavailability metric.

In the case of the availability concern, a specific requirement can be identified; for safety andsecurity, this may be more difficult so associated questions are derived to assess requirementsagainst these concerns.

Following concern identification and elaboration, the application must be analysed to identifythe set of viewpoints to be used. This analysis is based on an iterative process where viewpointsare proposed and their foci and sources identified. These are analysed. The set of viewpoints isthen re-examined to assess if new viewpoints are required, if viewpoints are redundant or if thefocus of identified viewpoints should change. Iteration continues until a stable set of viewpointswith defined foci and sources have been identified.

This identification process is a judgmental one which must be based on organisational andapplication domain experience. However, we do provide some guidance with initial viewpointidentification. This is based on a viewpoint hierarchy which is based on a decomposition of

viewpoint types. The initial viewpoint hierarchy which we propose is included in Appendix A butwe recommend that organisations tailor and adapt this to their own requirements.The identification guidelines which we use are:1.At least three viewpoints should be identified corresponding to an interactor viewpoint, anindirect stakeholder viewpoint and a domain viewpoint.2.Using the organisational viewpoint hierarchy, decide which viewpoints are likely to be relevantto the problem. Prune unwanted viewpoints from the hierarchy.3.If more than 6 viewpoints remain, think carefully about whether all viewpoints are reallynecessary. Too many viewpoints at this stage can lead to an explosion of information whichmust be managed and an unduly expensive elicitation process.4.Define the foci of each identified viewpoint. If this is difficult or unduly vague, you probablyneed to define more specific viewpoints.

24

After an initial set of viewpoints have been identified, their foci should be compared. This mayidentify where gaps lie in the viewpoint requirements' coverage of the system functions and

constraints. The discovery of these gaps - for example, if no viewpoint imposed requirements onthe characteristics of a database server to be used in the bank customer account system - impliesthat the resulting requirements specification will be incomplete.

New viewpoints may have to be added to the existing set, whose foci explicitly included themissing areas. They are emergent viewpoints, the need for which only become apparent followinganalysis of the existing viewpoints' foci. The use of focus analysis cannot, of course, guaranteecompleteness, but it acts as a mechanism to uncover viewpoints not immediately apparent from theinitial analysis of the domain.

Once the set of viewpoints has been defined, the requirements discovery process may begin.This may involve the development of outline system models from background material, structuredinterviews with sources, observations of processes, analyses of data and data processing, etc.In the requirements discovery process, we try to avoid ‘blank sheets’. If we ask people whatthey want without presenting them with some alternatives, they may either express unrealisticrequirements or have little idea where to start. Rather, we start with an initial outline of

requirements and ask sources to describe its deficiencies and omissions. As sources are consulted,the requirements description is refined. It is therefore important to have several sources associatedwith each viewpoint.

This approach helps to reduce intra-viewpoint conflicts as many inconsistencies and omissionsare immediately revealed. Source B is presented with source A’s requirements and expresses theirrequirements as an extension to these. If conflicts arise, we try to resolve them by informalnegotiation. If this fails, the conflict is recorded and taken forward for later analysis andnegotiation.

It is sometimes helpful to partition requirements which have been discovered by decomposingan existing viewpoint into sub-viewpoints and associating relevant requirements with each of them.Decomposition of a viewpoint into sub-viewpoints should be considered if:•

The internal requirements lack cohesiveness If the internal requirements apply to disjoint sub-sets of the viewpoint's focus, this implies distinct viewpoints. For example, there may be farecollection and vehicle control sub-viewpoints where a viewpoint is associated with the operatorof some public transport system.

The internal requirements conflict Internal requirements may conflict, especially if they arederived from different sources. In itself this is not necessarily sufficient to justify viewpointdecomposition. It is common for two users to articulate different requirements even if their

•

25

roles are the same. However, if the sources of the requirements have imperfectly matched focithen viewpoint decomposition may be appropriate.

The cost of adding new viewpoints at this stage is much less than identifying them initially asthey are a structuring mechanism for the requirements rather than a way of organising the elicitationprocess. Of course, simply decomposing a viewpoint with conflicting requirements doesn'treconcile them but it helps the requirements negotiation process by partitioning the problem andassociating conflicting requirements with their source.5.2.2

Requirements analysis

The purpose of this phase of the Preview process is to identify those requirements which are

inconsistent with concern questions, external requirements, or other viewpoints’ requirements. Theobjective is to discover internal viewpoint conflicts and external inconsistencies where

requirements from different viewpoints are in conflict. The result of this activity acts as the input tothe requirements negotiation activity where the inconsistencies should be resolved.

Internal conflicts and omissions are highlighted by analysing each viewpoint requirementagainst the concerns which drive the analysis. Hence for concern questions, those questionsshould be posed for each requirement e.g. ‘What are the safety implications of this

requirement”’. Similarly, where concerns have been decomposed to external requirements, eachof these must be checked for compatibility with the viewpoint's requirements. All sourcesassociated with a viewpoint should review the viewpoint requirements to discover potentialinconsistencies.

When all viewpoints are internally consistent, the requirements in each viewpoint must then bechecked for external consistency. This consistency checking does not simply encompass

conflicting functional requirements. As well as being checked against each other, functional andnon-functional requirements must also be checked against domain and organisationalrequirements.

For example, a user viewpoint on a network operating system might include a functionalrequirement that files' locations can be changed, and a non-functional requirement that drag-and-drop should be the user's normal means of interacting with the file store. A network viewpointmay be used to represent constraints and requirements imposed on the system by the network suchas the rate of data transmission and protocols used. When analysed with the requirements from theuser viewpoint, a potential inconsistency may become apparent. Drag-and-drop interaction, with itsreliance on rapid semantic feedback, may be impractical due to network delays.

Preview's approach is to exploit the focus attribute to direct the requirements engineer'sattention to viewpoints which impose requirements on the same system components or features.Viewpoints whose foci intersect are the most likely sources of conflict. Figure 7 illustrates a

26

scenario with 3 viewpoints; viewpoints VP1 and VP2 have intersecting foci so the threerequirements of VP1 should be checked for consistency with the four requirements of VP2.

By comparing viewpoints' foci and isolating only those whose foci intersect, the requirementsengineer narrows the search space for inconsistent requirements. VP3's focus is disjoint from bothVP1 and VP2 so there is less chance of conflict between these viewpoints. Of course, there couldbe some subtle conflicts which are not reflected in the focus or there could be unforeseen overlapsbetween the foci. Nevertheless, the explicit guidance provided by overlapping foci means thatlimited analysis effort can be deployed in the most effective way.

VP1req1areq1breq1cIntersectsVP2req2areq2breq2creq2dVP3req3areq3bfocus 2focus 1focus 3Figure 7 Viewpoints with overlapping and non-overlapping foci

For each pair of viewpoints with intersecting foci, their requirements must be checked formutual consistency. We propose a simple tabular method similar to the Quality Function

Deployment (QFD) method (Errikson and McFadden, 1993) to act as a checklist of requirements'compliance. Figure 8 shows a tabular plotting of the intersecting viewpoints VP1 and VP2 fromfigure 7. Here, VP1's requirements are represented as rows and VP2's requirements are

represented as columns. Where they intersect, the requirements engineer must examine them toassess whether they are:•

Overlapping. There is some overlap between the requirements in each viewpoint which shouldbe discussed with a view to simplifying the requirements. A ‘1000’ is used to indicateoverlapping requirements.

27

••

Conflicting. There is a conflict between the two requirements which should be resolved. A ‘1’is used to indicate conflicting requirements.

Independent. The viewpoint requirements are independent. A ‘0’ is used to indicate twoindependent requirements.

VP2req2a

VP1

req1areq1breq1c

010

req2b010001000

req2c010

req2d001

Figure 8 Checking VP1 and VP2 for mutual consistency

In this example, req1b conflicts with req2a and req2c, while req1c conflicts with req2d. Theseconflicts would go forward to the requirement negotiation phase for resolution. Similarly, req1band req1c overlap with req2b. When the requirements specification document is developed fromthe viewpoints analysis, it may be possible to rationalise these three requirements.

The advantage of using numeric values to represent overlapping and conflicting requirements isthat a simple spreadsheet may be used to assist with the analysis process. By summing the rowsand columns, dividing the result by 1000 and taking the dividend and the remainder, we can

identify the number of overlaps and conflicts. The most problematic requirements are revealed andmay be given particular consideration in the requirements negotiation process.

We recognise that using the viewpoint focus to discover potential conflicts is not an infallibleprocess. Some kinds of conflict will not be revealed by this approach particularly those arisingfrom implicit organisational and political factors. For example, bank staff may deliberately designprocedures for customer interaction so that they cannot be readily automated. They may then

express automation requirements which they know are unrealisable so that the system developmentfails and they keep their jobs. We are not aware of any approach which addresses this type ofproblem.5.2.3

Requirements negotiation

The inputs to this phase are the sets of conflicting and overlapping requirements. Preview does notprescribe how conflicts are resolved or how overlapping requirements are rationalised as this willtypically necessitate trade-offs and compromise. Normally, we expect the people who are

28

viewpoint sources to meet together, discuss the requirements and agree on priorities. The

viewpoint concern, focus and source information associated with each requirement should be usedto inform the negotiation process and provide a context for resolution.

The results of the process will typically be a set of changed requirements. These changesshould be fed back to the requirements discovery phase and should be recorded in the relevantviewpoints’ histories.

It is feasible that some requirements in conflict with others prove, on analysis, to always takeprecedence or to be immutable. The identification of immutable requirements reveals that theirstatus is on a par with that of concerns and should be treated as such. Consideration should begiven to ‘promoting’ these to associate them with concerns and thus ensure that they are consideredby all viewpoints in subsequent analysis. This feedback connection provides some measure ofself-correction in the process to guard against a failure to identify all pertinent concerns in the earlystages of the requirements discovery phase.6.

CONCLUSIONS

Preview is a pragmatic framework for requirements elicitation activities. It can be introduced intoreal RE processes in an evolutionary rather than a revolutionary way.

The Preview approach is distinguished by the following characteristics:1.The approach explicitly recognises the importance of organisational needs and priorities

through its identification of concerns. The Preview process has been designed to include theseexplicitly in the analysis.2.The lack of prescription in the viewpoint model means that it can be used with existing designand analysis notations. Viewpoints do not have to conform to a particular type so theapplicability of the approach is generic rather than specific to a particular class of system.3.Viewpoints are independent entities which do not rely on explicit relationships or the existenceof other viewpoints. The approach may be used incrementally. Adding more viewpointsimproves coverage but benefits accrue when as few as two viewpoints are explicitlyrecognised.4.Preview supports a user-centred approach by recommending that interactor viewpoints shouldalways be considered in the requirements elicitation process.A key goal of the development of Preview was that practical industrial requirements should betaken into account. Figure 9, shows our assessment of Preview against the practical problems ofintroducing viewpoint-oriented approaches identified in Section 5.

29

Identified problemPreview assessment

Inflexible viewpoint models

Preview viewpoints are flexible and user-definable. They are definedby their focus rather than according to any pre-defined model. Theymay be established according to organisational needs and may rangefrom system end-users to organisational, social and politicalconstraints on the system.

Fixed notations forThere is no pre-defined notation for expressing requirements. Anyrequirements definition

appropriate notation may be used. This includes natural language,diagrams, equations, formal descriptions or graphical system models.

Limited support forBackward traceability is essential for supporting evolution. Previewrequirements evolution

viewpoints include links to sources of requirements and maintainchange histories.

Limited support forProblems are most likely to arise when viewpoints have overlappingrequirements negotiation

foci. The QFD-based comparison identifies overlapping andconflicting requirements which may be an input to the negotiationprocess. The explicit definition of a viewpoint focus also helps withviewpoint prioritisation.

No industrial-strength toolThe method is not reliant on special-purpose tool support. It hassupport

been designed so that existing tools for requirements managementmay be used to manage the information in a viewpoint.

No recognition of theWe have addressed this, to some extent, with the notion of concernsproblems of non-functionalwhich ensures that critical non-functional requirements may drive therequirements

analysis process and all identified requirements are checked againstthem.

Incompatibility with otherThis problem has not been explicitly addressed. As the system doessoftware engineeringnot depend on pre-defined notations, requirements modelling notationsmethods

which are compatible with design notations may be used. Therefore,if an organisation is already committed to object-orienteddevelopment, viewpoints may include object models which areprocessed by existing tools.

Figure 9 Preview assessment

30

The Preview approach has been applied in a number of projects in the aerospace and railwaysignalling domain. The key results of these projects confirmed our views that flexibility is the keyto practical use of viewpoint-oriented approaches. Some conclusions of the evaluation were:1.An initial viewpoint decomposition such as that given in Appendix 1 is useful but too manyviewpoints result in an unmanageable explosion of information. Therefore, after the initialdecomposition (which is very helpful for identifying viewpoint sources), there should be areification step to reduce the number of viewpoints. We suggested six as the maximum - inpractice, we found that no-one wanted to work with more than four viewpoints.2.An important advantage of viewpoints was that it structured the presentation of requirements. Ithelped make clear where requirements came from (e.g. a safety requirement) and, in general,made the requirements more readable.3.It helps to have both viewpoints and concerns but there is a blurred distinction between them. Itis sometimes necessary to turn viewpoints into concerns and vice-versa. A pragmatic waywhich we found to address this problem was to allow a concern to be another viewpoint.4.Conflict analysis was not as much of a problem as we had envisaged. Viewpoints had limitedbut well-defined areas of overlap and there was no need to use the QFD-based approach whichwe had proposed. This may reflect the class of system used as examples and the fact that thestakeholders had a fairly clear idea of their requirements. We suspect that, for informationsystems, this may not be true.5.Almost everything had to be interpreted flexibly and introduced incrementally. For example,our viewpoint identification guidelines (find an interactor, an indirect stakeholder and a domainviewpoint) were largely ignored. Users based viewpoint identification on their own experience.Furthermore, if there is no history in an organisation of recording requirements sources, it isvery hard to get people to include this information. This doesn’t mean it isn’t useful - it simplymeans that time is needed to change working practices.We are investigating possible extensions to the viewpoint concept to improve its usability,

carrying out further trials on real applications and exploring how tool support for the approach maybe provided. We are completely against the notion of special-purpose tools and are committed toevolving the concept, if necessary, so that it can be used with existing tools for requirementsmanagement. Our initial experiments in this are based on a tool called DOORS (see URL

http://www.qss.co.uk/) for more information) and it seems that this system can support most ofthe viewpoint model which we have developed.

A possible extension is the notion of a viewpoint vocabulary. Terminology problems are

endemic in requirements engineering and it seems to us that defining a viewpoint vocabulary would

31

create a reusable resource which could be used to discover when sources were using the sameterms in the same way. However, we have not yet explored how this concept may be supportedand used.

In summary, Preview helps improve the quality of requirements specification by providing aframework which can support both requirements elicitation and the structuring of the requirementsdocument. In some respects, it is ‘less advanced’ than other approaches. We do not proposetechnological solutions such as automated conflict analysis nor have we invented expressivenotations or new processes. However, we have built on previous research to develop an

evolutionary approach which addresses outstanding requirements engineering problems in a waywhich is pragmatic and relevant to industrial needs.7.

REFERENCES

Barlas, S. 1996. Anatomy of a Runaway: What Grounded the AAS. IEEE Software , 13(1): 104-6

Booch, G. 1994. Object-oriented Analysis and Design with Applications,. Benjamin Cummings,Redwood City, Ca.

Bowman, H., Derrick, J., Linington, P. and Steen, M. 1996. Cross-viewpoint consistency inOpen Distributed Processing. BCS/IEE Software Eng. J. , 11(1): 44-57

Easterbrook, S. and Nuseibeh, B. 1996. Using ViewPoints for inconsistency management.BCS/IEE Software Eng. J. , 11(1): 31-43

Errikson, I. and McFadden, F. 1993. Quality Function Deployment: A Tool to Improve SoftwareQuality. Information and Software Technology , 35(9):

Feather, M. 1993. Requirements Reconnoitering at the Juncture of Domain and Instance. In Proc.Int. Symp. on Requirements Eng., San Diego. 73-7

GAO 1979. Contracting for Computer Software Development - Serious Problems RequireManagement Attention to Avoid Wasting Millions. US General Accounting Office.

Gibbs, W. W. 1994. Software’s Chronic Crisis. Scientific American , 271(3): 72-81

Greenspan, S. and Feblowitz, M. 1993. Requirements Engineering Using the SOS Paradigm. InProc. RE’93, San Diego, CA. 260-65

Hughes, J., O’Brien, J., Rodden, T., Rouncefield, M. and Sommerville, I. 1995. PresentingEthnography in the Requirements Process. In Proc. Proc. RE’95, York. 27-35

Jackson, D. and Jackson, M. 1996. Problem decomposition for reuse. BCS/IEE Software Eng. J., 11(1): 19-30

Jackson, M. A. 1983. System Development. Prentice-Hall, London

Jackson, M. A. 1995. Problems and Requirements. In Proc. Proc. 2nd IEEE Int. Symp. onRequirements Eng., York, England. 2-9

Jacobson, I., Christensen, M., Jonsson, P. and Overgaard, G. 1993. Object-Oriented SoftwareEngineering. Addison-Wesley, Wokingham

32

Jarke, M., Bubenko, J., Rolland, C., Sutcliffe, A. and Vassiliou, Y. 1993. Theories UnderlyingRequirements Engineering: An Overview of NATURE at Genesis. In Proc. IEEE Symp. onRequirements Eng., San Diego. 19-31

Klein, M. 1992. Conflict Management in Concurrent Engineering (special issue). Concurrent Eng.J. , 2(3)

Kotonya, G. and Sommerville, I. 1992. Viewpoints for requirements definition. BCS/IEESoftware Eng. J. , 7(6): 375-87

Kotonya, G. and Sommerville, I. 1993. A framework for integrating functional and non-functionalrequirements. In Proc. IEE Workshop on Systems Engineering for Real-time Applications,Cirencester, UK. 148-53

Kotonya, G. and Sommerville, I. 1996. Requirements engineering with viewpoints. BCS/IEESoftware Eng. J. , 11(1): 5-18

Leite, J. C. S. P. and Freeman, P. A. 1991. Requirements Validation through ViewpointResolution. IEEE Trans. on Software Eng. , 17(12): 1253-1269

Linington, P. F. 1995. RM-OD - the architecture. In Proc. IFIP TC6 Int. Conf. o OpenDistributed Processing, Brisbane, Australia.

Moyse, R. 1992. VIPER: The design and implementation of multiple viewpoints for tutoringsystems. In Knowledge Negotiation (R. Moyse and M. T. Elsom-Cook ed.). Academic Press,London

Mullery, G. 1979. CORE - A Method for Controlled Requirements Specification. In Proc. 4th Int.Conf. on Software Engineering, Munich. 126—35

Nuseibeh, B., Kramer, J. and Finkelstein, A. 1994. A Framework for Expressing the

Relationships between Multiple Views in Requirements Specifications. IEEE Trans. on SoftwareEng. , 20(10): 760-73

Ross, D. T. 1977. Structured Analysis (SA). A Language for Communicating Ideas. IEEETrans. on Software Engineering. , SE-3(1): 16-34

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W. 1991. Object-orientedModeling and Design. Prentice-Hall, Englewood Cliffs, N.J.

Schoman, K. and Ross, D. T. 1977. Structured Analysis for Requirements Definition. IEEETrans. on Software Engineering. , SE-3(1): 6-15

Self, J. 1992. Computational Viewpoints. In Knowledge Negotiation (R. Moyse and M. T.Elsom-Cook ed.). Academic Press, London

Sommerville, I., Sawyer, P., Kotonya, G. and Viller, S. 1995. Process Viewpoints. In Proc.Proc. 5th European Workshop on Software Process Technology, Amsterdam, The Netherlands.Zemanek, G., Huber, H., Nissen, H. and Jarke, M. 1995. Requirements from MultiplePerspectives: Experiences with Conceptual Modeling Technology. Lehrstuhl fur Informatik,Aachen

33