Skip to content. | Skip to navigation

Personal tools
You are here: Home Staff Peter Haumer How To Use Scenarios And Use Cases In The SystemsDevelopment Process

How To Use Scenarios And Use Cases In The SystemsDevelopment Process

The BCS Requirements Engineering Specialist Group One-day Symposium on 09.30-16.30, Thursday 14th May 1998 at City University, London

Despite the considerable recent interest in the use of scenarios and usecases in the systems development process, there is a lack of scenario-basedmethods, techniques and guidelines available to practitioners, or evenagreement about the definition of use cases and scenarios in the first place. As a result, discussions aboutuse cases and scenarios often lead to more questions than answers.

This symposium aims to provide some answers. It brings together practitioners, vendors and academics with different interests inscenarios and use cases. Experts will present and explore the diverse usesof scenarios and use cases, examine effective methods and guidelines,report on experiences and good practice, and propose a common path for the development and application of newscenario-based systems development methods.


09.00-09.30: Coffee and Registration

09.30-09.40: Welcome and Introduction, Neil Maiden, City University

09.40-10.10: "Validating Requirements:Beyond UML", Ian Graham, Chase Manhattan Bank, UK

10.10-10.40: "Scenarios and theirApplication for Requirements Definition, or What Do YouWant To Do with the System?", Andrew Daw, GEC-Marconi, UK

10.40-11.10: "Once upon a time...Using Scenario Based TechniquesDeveloped to Elicit Requirements from Children with Adults", NicolaMillard, BT Laboratories, Ipswich, UK

11.10-11.30: Coffee and Software Demonstrations

11.30-12.00: "Task Models toElicit Requirements and Generate Scenarios", Ian F. Alexander,Independent Consultant, UK

12.00-12.30: "Use Cases: A Reusable Way To RepresentRequirements Information", Ronald L. Krubeck, Rational SoftwareCorporation, US

12.30-14.00: Lunch and SoftwareDemonstrations

14.00-14.20: "CREWS: A European Project on Scenario Management",Matthias Jarke, RWTH Aachen, Germany

14.20-14.40: "Guiding Goal Modelling Using Scenarios", Colette Rolland,Universite de la Sorbonne, France

14.40-15.00: "Requirements Elicitation with Real World Scenes", KlausPohl, RWTH Aachen, Germany

15.00-15.20: "Scenario-Based Requirements Validation: The CREWS SAVREMethod and Tool", Alistair Sutcliffe, Centre for HCI Design, CityUniversity

15.20-15.40: "Animation of Scenarios for Requirements Validation", EricDubois, Universite de Namur, Belgium

15.40-16.00: Tea and Software Demonstrations

16.00-16.45: Panel Discussion


Programme Details


Validating Requirements: Beyond UML

Ian Graham, Chase Manhattan Bank

UML is put forward as a standard for object-oriented development but isdeficient in areas such as development process and requirementsengineering. In the latter area problems arise principally because of theweak semantics of the class modelling language (bi-directional associations and lack of rulesets), lack of theory andnon-OO semantics for use cases, lack of concurrency for sequence diagramsand too early use of the latter. This talk will show how all these problemscan be addressed and go further to show how an object model can bevalidated as necessary and suffient against a set of businessobjectives.

Ian is a Vice President at the Chase Manhattan Bank with responsibility forobject-oriented software development practices. His books includeObject-Oriented Methods, Migrating to Object Technology and The OPENProcess Specification. Ian is a Fellow of the British Computer Society.


Scenarios and their Application forRequirements Definition


What Do You Want To Do with the System?

Andrew Daw, GEC-Marconi

The paper presents a framework for, and definition of, activities forRequirements Definition, in which Scenario Generation and Animation play afundamental role. The paper discusses, within a Top Down SystemsEngineering perspective, the need for operational contexts of the system (in these examples complex whole ship navalplatforms) from which to answer the question - ‘What Do You Want to Do with the System? The use of scenarios is shown tooffer a consistent and coherent framework, not only for requirements elicitation but also for effectiveness and capability modelling,stimulation of structured functional design representations, and HumanFactor MMI Design and Human Operational analyses. In such circumstances,the scenarios offer an immediate vehicle for answering the second half of this question - ‘...and How WellDo You Want it To Do It?’

The paper draws together these issues and perspectives,and discusses the distinct points of focus offered by Scenarios, wherebythe operational context of theplatform can be defined and analysed; the management of change in thatcontext can be assessed; design trade offs can be identified andprioritised across multiple design paradigms; equipment comparisons can beachieved for cost effectiveness and performance analysis; and the definition of through life support models can beinitiated through appropriate scenario definition and management.


Once upon a time...Using Scenario Based TechniquesDeveloped to Elicit Requirements from Children with Adults

Nicola Millard, BT Laboratories, Ipswich

Tools and techniques for requirements elicitation aregenerally unsuitable for use with children and for innovative andfuturistic developments. Using case studies, this talk explores practicalmethods to get requirements for futuretechnologies from children. Techniques such as scenario building,roleplaying and storyboarding proved successful in involving children inthe requirements process and stimulating innovation. The talk will look athow these methodscan be adopted to take a more fundamental approach to requirements elicitation for adults.

These techniques help requirements engineers face thedifficult task of getting system requirements from users of whatever age,ability or background. They also enable requirements engineers toanticipate some of the futurechanges that might occur before or as a consequence of the installation ofa new system. The lack of specialist notation was found to promotecommunication throughout the analysis and design process and gives thedesigners a context in which to design.

Nicola is a user centred requirements analyst and humanfactors researcher at BT Laboratories in Suffolk. NicolaUs requirementsexperience ranges from developing software for call centres to buildingsystems for theenvironmentally friendly disposal of telephony products ! She is currentlyinvolved in a wide range of activities gathering requirements forinnovative future products and services.


Use Cases: A Reusable Way To RepresentRequirements Information

Ronald L. Krubeck, Rational Software Corporation

Software requirement information has typically beenspecified via traditional techniques such as a ProductRequirement Document and a Software RequirementsSpecification. Such techniques show requirements in a static, declarative way and offerfew, if any, ways to promote reuse of these requirements byother functional groups such as Quality Assurance and Documentation. Use cases, used as a way to capture softwarerequirements, promise greater reuse by other functional areas withinan organization.

Ronald L. Krubeck is a Principal Engineer with the Requirements Management Business Unit in the RationalSoftware Corporation.


Task Models to Elicit Requirements AndGenerate Scenarios

Ian F. Alexander, Independent Consultant

Scenario Plus is a specially-designed tool forcreating, editing, measuring, and exploring task models. A task model is a detailed analytic description of a task that might becarried out by a future system, or by a system together with otheragents including human users. Task models are visualisedprimarily as hierarchies of subtasks, but tasks can be combinedin a variety of ways. A task can be given a type, such as Sequence,Alternatives or Parallel, indicating the relationship betweenits children. Looping is permitted by means of an explicit Periodictype, as well as a Link

type which corresponds to an unconditional jump. Scenario Plus cananimate task models, enabling users to step through plannedtasks quickly or deliberately. During animation, the user is offered a choice when a set of Alternatives (etc) is encountered. Generation of a path isthus semi-automatic, enabling users to select just the pathsof interest. Metrics indicating the complexity of the model, interms of the minimum

number of paths it can generate, can be displayed atany time. Any generated path through a model can be saved asa Scenario, for later use. Scenarios can be replayed, or usedto filter the task model, displaying only the relevant tasks. These can form the basis ofrequirement documents, safety analyses, and testspecifications. Scenario Plus runs on all DOORS PC andUNIX platforms.


CREWS: A European Project on Scenario Management

Matthias Jarke, RWTH Aachen, Germany

The European ESPRIT project CREWS (Cooperative RequirementsEngineering With Scenarios) is concerned with systematic support for theusage and management of scenarios in the development of complex systems.The project has developeda classification scheme for scenario-based techniques which was thenapplied (a) to gain a structured overview of the state-of-the-art in thefield, and (b) to structure a broad survey of current scenario practice inEurope. The talk summarizes the result of both studies and gives an overview of the work done in CREWSto remedy some of the identified issues.

Matthias Jarke is professor of Information Systems andchairman of the computer science department at Aachen University ofTechnology. Prior to joining Aachen in 1991, he served on the faculties ofNew York University's SternSchool of Business and of the University of Passau, Germany. His researchinterests focus on information systems support for design processes inbusiness and engineering. Related to requirements engineering, he has beencoordinator of three European ESPRIT projects, DAIDA, NATURE, and CREWS. He is editor-in-chief ofthe journal Information Systems and served, in 1997, as program chair ofthe International Conference on Very Large Data Bases (Athens, Greece), andas General Chair of the German National Computer Science Conference.


Guiding Goal Modelling Using Scenarios

Colette Rolland, Universite de la Sorbonne

Since a few years, scenario based requirements engineeringapproaches have gained in popularity. Textual scenarios are narrativedescriptions of flows of actions between agents. They are often proposed toelicit, validate ordocument requirements. The CREWS experience has shown that the advantage ofscenarios is their easiness of use, and that their disadvantage stands inthe lack of guidelines for authoring. In this article, we propose guidancefor the authoring of scenarios. The guided scenario authoring process is divided into two mainstages : the writing of scenarios, and the correcting

of scenarios. To guide the writing of scenarios, we providestyle and contents guidelines referring to a conceptual and a linguisticmodel of scenarios. To guide the correcting of scenarios, we propose a setofenactable rules. These rules aim at the clarification, completion andconceptualisation of scenarios, and help the scenario author to improve hisscenarios until acceptable quality in the terms of the former scenariomodels. The paper presents both style/contents guidelines, and correction

rules, and illustrates them with the London Ambulance Serviceexample.


Requirements Elicitation with Real World Scenes

Klaus Pohl, RWTH Aachen

Scenarios are an excellent means for eliciting and validatingrequirements. A scenario represents a concrete example of current or futuresystem usage. We call a persistently recorded usage of the current system areal world scene (RWS). This talk presetsso called abstraction guides which support therequirements-engineer in eliciting requirements from RWS and in validatingrequirements against RWS. During the elicitation and validation, theabstraction guides relate theconceptual definition of the requirements to the parts of the RWS whichhave caused their definition or which have been used to validate therequirement. Thereby a fine-grained interrelation between the conceptualmodels and the RWS is established. These interrelations significantly improve the traceability andunderstandability of conceptual models. The interrelation provides thebasis for: explaining and illustrating conceptual models to, for example,new team members; comparing conceptual models defined by different stakeholders; comparing different observations usingcomputed annotations; and refining or detailing a conceptual model duringlater process stages.

Klaus Pohl is senior researcher with the Information Systems group atAachen University of Technology, where he also obtained his doctoral degreein 1995. In 1996 he was a visiting professor at the University of Namur,Belgium. Klaus Pohl is/waswork-group leader in the ESPRIT Reactive Long Term Research project oncooperative requirements engineering with scenarios (CREWS) and in theESPRIT Basic Research Action on novel approaches to theories underlyingrequirements engineering (NATURE). Heis initiator of the international workshop series on Requirements

Engineering: Foundations of Software Engineering (REFSQ), member of theeditorial board of the Requirements Engineering Journal and the vice-chairof the GI requirements engineering interest group.


Scenario-Based Requirements Validation: The CREWS SAVREMethod and Tool

Alistair Sutcliffe, Centre for HCI Design, City University

The presentation will introduce the CREWS-SAVRE method andbriefly review the tool demonstration that will be available. The methoduses scenarios in two senses; examples or stories of use taken from thereal world andthreads of interaction generated from use cases. Different validationtreatments are linked to the two scenarios types. First, real worldscenarios are used as test data to check dependencies between input andoutput to the system from the environment. Requirements are elaborated to deal with normal and abnormal input whilethe impact of system output on different stakeholders is assessed.Secondly scenarios are generated from use cases by an interactive dialogue.Checklists of possible errors andtheir causes are used to suggest when user-system interaction may go wrong,and generic requirements are proposed to deal with these problems. Themethod, implemented in the SAVRE tool assists the requirements engineer toexplore the possibilities of future system behaviour and then detectspossible problems by validation frames. The frames act as patternrecognisers for different combination of agents and events which may giverise to obstacles to normal system operation. The tool uses an extensive database of problems that it matches tosolutions (i.e. generic requirements) and iteratively builds use cases andrequirements specifications documented in the Requisite Pro tool. Use ofthe method

and tool will be illustrated with a banking case study.


Animation of Scenarios for Requirements Validation

Eric Dubois, Universite de Namur, Belgium

Albert II is a formal language designed for the purpose ofexpressing requirements inherent of distributed real-time systems. Thelanguage has been the subject of several technology transfer initiatives.In particular,it has been used by industrial partners in the context of the developmentof two large, distributed, software-intensive, heterogeneous systems (avideo-on-demand application and a satellite-based telecommunicationsystem.

We are currently developing a number of tools for supportingthe use of the language as well as the verification of the producedspecifications. At the validation level, checking the adequacy of a formalrequirementsspecification towards the needs expressed by stakeholders is far from beinga trivial issue. To overcome this problem, we work on a so-called animatorthat the stakeholders can use interactively and cooperatively inorder to explore different possible behaviors (or instance-level scenarios)of the future system allowed by the formal requirements specification. Thepurpose of the tool comes down to test if a given scenario proposed by oneor several stakeholders is compatible with the requirements specification.

Document Actions