WIXLIB

The advantage of scenarios lies in the way theyground argument and reasoning in specific detail orexamples, but the disadvantage is that being specific losesgenerality. We all naturally look for patterns andsimilarities in the world, which is the cognitive process ofgeneralisation. In RE our reasoning process is the same.Scenarios in the real world sense are specific examples.The act of analysis and modelling is to look for patterns inreal world detail, then extract the essence, therebycreating a model. So scenarios fit into the process ofrequirements elicitation which gathers stories andexamples from users and then looks for the generalities.Another advantage of scenarios lies in their focus onreality that forces us to address the “devil in the detail”during requirements specification and validation. In thiscase we confront abstract models with scenarios as testdata. Whereas an abstract model can go unquestioned,unless rigorous automated reasoning is used via formalmethods [26], the detail in scenarios naturally challengesassumptions in models. Examples exert a powerful effecton our reasoning because we can identify with detailthrough our experience. Real world scenarios are a formof episodic memory [27] that can give rich details ofevents and scenes, but the requirements engineer has tobeware that people’s episodic memory can be highlyselective, so a sample of scenarios may represent atypicalevents from a personal viewpoint. Since scenarios situateexamples with existing memory they help inunderstanding requirements problems. The concept ofobstacles analysis in RE [28] draws on scenarios to situateour thought about how problems in the real world (i.e.obstacles) might prevent a requirement being met.Scenarios can help to counteract pathologies inhuman reasoning [29], such as not testing hypotheses andassumptions in models. In RE scenarios can help to testmodels and specifications during requirements validation;unfortunately, scenarios can also encourage otherpathologies, so we need to be on our guard. First isconfirmation bias: we tend to seek only positive examplesthat agree with our preconceptions [30]. Scenarios shouldbe collected which include errors, counter-examples andexceptions as well as the norm. Encysting, or not beingable to see the wood for the trees, can result frombecoming obsessed with the detail in scenarios. Both themodel, abstract and detailed scenario views are necessary.Unfortunately the products of the generalisation process,abstract models, are not so easily understood; however,reasoning with concrete examples as well as abstractmodels helps comprehension by building a memoryschema linking the specific (scenario) with the general(model). This can improve requirements elicitation andvalidation. Scenarios can bias beliefs in frequencies ofevents and probabilities [29], so it is important to ensurethat a wide ranging sample of scenarios are gathered. Thisexposes one of the dilemmas in scenario based RE.Ideally the more scenarios the better to increase testcoverage, but gathering and using more scenarios incurscost. The problem is that we need many scenarios to test ageneral requirements specification, but how can we besure we have a complete or even an adequate set? Thiscan be summarised as the 20/20 foresight problem: howto capture (or generate) a sufficient set of scenarios tocover all the important problems in the application. I willreturn to this in section 7.4. Scenarios in the requirements and designprocessOne particular role of scenariosis to act as a“cognitive prosthesis” or an example to stimulate thedesigner’s imagination. Scenarios can guide thought andsupport reasoning in the design process [15, 31].However, this approach can lead to errors. A scenario, oreven a set of scenarios, does not explicitly guide adesigner towards a correct model of the required system.An extreme scenario might bias reasoning towardsexceptional and rare events, or towards the viewpoint ofan unrepresentative stakeholder. These biases are anacknowledged weakness of scenarios; however, we cantrust designers as knowledgeable, responsible people whoare capable of recognising such biases and dealing withthem productively. Indeed, some propose scenarios thatare deliberately exceptional to provoke constructivethought [32]. Although scenarios are useful as cognitiveprobes for design, this is not their only tivationScenariosof useinspirationRequirementsAnalysisinput formodellingContext & usescenariosMaintenanceSpecification& DesignImplementation& TestingRequirementsValidationContext & usescenariostest dataUsagescenariosgeneralisationfor modeltest dataFigure 2. Roles of scenarios in requirements anddesign.Scenarios are arguably the starting point for allmodelling and design, and contribute to several parts ofthe design process (see figure 2). Scenarios of usedescribe system operations at different stages ofdevelopment. Context scenarios add information about

the system’s physical and social environment. At theinitiation of development, scenarios play three roles: firstas descriptions of the unsatisfactory state of affairs with acurrent system which the new system has to solve;secondly as visions of how the new system might operate;and thirdly as descriptions of behaviour, representing bothusers and the existing system. Usage or behaviouralscenarios are a common form and can be used later in thelife cycle as test data to validate requirementsspecifications, designs and implemented systems.Information on the system’s physical and social contextcan be added to usage scenarios, to provide a richer inputto requirements specification and validation, for instanceallowing reasoning about obstacles in the systemenivornment which may preventnt requirements beingachieved [27].Narrative descriptions of the real world provide inputto the process of generalisation that produces specificaction sequences (i.e. formatted scenarios) and then ageneral model that represents typical behaviour of a groupof users interacting with a system. The process ofgeneralisation inevitably loses detail and the analyst hasto make judgements about when unusual or exceptionalbehaviours are omitted, or explicitly incorporate them asalternative paths in use cases or in action sequences [11].Indeed there is merit is eliciting or creating mis-use casesthat describe threats and exception conditions that willtest the system [12]. A criticism of model approaches torequirements engineering is that they inevitably omitdetail which may be vital, whereas scenarios might beable to gather such detail but at the price of effort incapturing and analysing a “necessary and sufficient” setof scenarios.5. Methods for scenario-based requirementsengineeringOne productive juxtaposition of scenarios and modelsis to use scenarios as test data to validate design models.This approach, proposed in the Inquiry Cycle [8] and itsscuccessor ScenIC, uses scenarios as specific contexts totest the utility and acceptability of system output. Byquestioning the relevance of system output for a set ofstakeholders and their tasks described in a scenario, theanalyst can discover obstacles to achieving systemrequirements. Input obstacles can be derived fromscenarios to test validation routines and other functionalrequirements. Obstacle analysis has since been refinedinto a formal process for discovering the achievability ofsystem goals with respect to a set of environmental states,taken from scenarios [28]. Scenarios, therefore, can fulfiluseful roles either as test data, as a stimulant to reasoningin validating system requirements, or by providing datafor formal model checking.In HCI scenario-based methods have become anaccepted approach for requirements discovery and designexploration. For example, Carroll [15] proposes scenariosof use with claims, a design rationale that represents adesign principle with advantages and disadvantages.Beyer and Holtzblatt [33] argue for rich scenarios whichdescribe a business environment as well as system use incontext. Their method uses scenarios in conjunction witha suite of models analysing the business, socialrelationships and user tasks, whereas Carroll adopts aprototyping approach with scenarios functioning as “toolsfor thought”.Two RE methods have placed considerableimportance on the role of scenarios, the ScenIC method[27] and SCRAM [20, 29, 34], while many other REmethods include scenarios as part of the process (e.g. [35,24]).ScenIC [27] proposes a schema (see figure 3) ofscenario-related knowledge composed of goals,objectives, tasks, obstacles and actors. Scenarios arecomposed of episodes and action carried out by actors,who are usually people but may also be igure 3. Schema of scenario-related knowledgeafter Potts [27].Goals are classified into achieving, maintainting oravoiding states, while obstacles prevent goals from beingachieved, or inhibits successful completion of tasks. Themethod proceeds in a cycle of expressing scenarios in asemi-structured format, criticising and inspectingscenarios in walkthroughs which leads to refiningrequirements and specifications and the next cycle.Guidelines are given for formatting scenario narrativesand identifying goals, actions and obstacles. Scenarioepisodes are assessed with challenges to see if goals canbe achieved by the system tasks, whether the actors cancarry out the tasks, whether obstacles prevent the actorscarrying out the tasks, etc. In this manner dependenciesbetween goals, tasks, actors and resources can be checkedto make sure the system meets its requirements.

Dependency analysis and means-ends analysis, in whichtasks and the capabilities of actors are examined to ensuregoals can be achieved, are also present in RE methodssuch as i* [17], and this illustrates the convergence ofscenario- and model-based analysis in requirementsengineering. Two paragraphs hardly do justice to ScenIC;however, my purpose was to draw attention to theimportance of obstacle analysis, and urge the reader toconsult more detail in Potts [27].In SCRAM (Scenario-based Requirements AnalysisMethod), scenarios are used with early prototypes to elicitrequirements in reaction to a preliminary design. Theapproach is based on the hypothesis that techniqueintegration provides the best avenue for improving REand that active engagement of users in trying out designsis the best way to get effective feedback for requirementsvalidation. Another motivation is to use scenarios as ameans of situating discussion about the design, so thatnew requirements can be elicited by reasoning aboutproblems posed by scenarios describing a context of use.This approach essentially merges the elicitation andvalidation role of scenarios by providing the context forthe user to assess a design which itself is presenting ascenario of use. The method steps of SCRAM areillustrated in figure 4.Managers,usersprojectinitiationScenariosuser tasksInitialrequirementscapturehigh mentsexploration andvalidationScenariosdesign rationaleStoryboardingand designvisioningMockups,storyboardsrequirements &Initial designrequirements &interactive designTest tasksscenariosUsersPrototyping andrequirementsvalidationvalidatedrequirements& refined designFinaldevelopmentFigure 4. Process road map of the SCRAMmethod.SCRAM does not explicitly cover modelling andspecification, as this is assumed to progress in parallel,following the software engineering method of thedesigner’s choice (e.g. UML and Unified Process [18]).The method consists of four phases:xInitial requirements capture and l interviewing and fact-findingtechniques to gain sufficient information todevelop a first concept demonstrator. In practicethis takes 1-2 client visits.x Storyboarding and design visioning. This phasecreates early visions of the required system thatare explained to users in storyboardwalkthroughs to get feedback on feasibility.x Requirements exploration. This uses conceptdemonstrators and early prototypes to present moredetailed designs to users in scenario-driven, semiinteractive demonstrations so the design can becritiqued and requirements validated.x Prototyping and requirements validation. This phasedevelops more fully functional prototypes andcontinues refining requirements until a prototype isagreed to be acceptable by all the users.The method provides process guidance for conductingwalkthroughs and organising the requirements analysisprocess, with guidelines for interviewing and managingrequirements conversations. Initial requirements capturegathers facts about the domain and captures users’ highlevel goals for the new system. Scenarios are elicited asexamples of everyday use of the current system, withstories of problems encountered and how they are dealtwith. Gathering a sufficient set of scenarios is a vexedquestion. There are several problems that might beencountered:x Users tend to miss out steps in scenarios thatthey assume are known to the analyst: theimplicit or tacit knowledge problem.x Each person may give an individual view ofproblems encountered. It can be difficult to distila set of common problems from users withdiverse views.x Acquiring a sufficient set of scenarios to covernot only normal use but also situations whenthings go wrong can take considerable effort.The volume of scenarios can become daunting,and this presents a problem of finding a validsub-set.x People tend to either forget abnormal examplesortoexaggerateproblems.Problemsencountered most frequently and recently will berecalled first, but individuals will rememberdifferent episodes. Unravelling these potentialbiases can be difficult, e.g. a personality clashmay make a particular problem vivid for oneindividual whereas for everyone else, theproblem was minor.The best way to proceed is to gather scenarios ofnormal system use; look for commonalties betweendifferent individual versions and create a common

“normal use case”. Note that where individual variationsoccur, these can be useful hooks for questions later onabout different individual strategies for using the system.Once the normal use case is in place, gather a set ofexceptions (c.f. alternative paths in use cases). Thenumber of alternatives necessary depends on systemcomplexity and safety criticality. This phase also capturesusers’ high-level goals.Scenarios complement goal modelling because, whilegoals focus on abstractions that describe users’ intentions,scenarios make abstract intentions clearer by givingexamples of how a new system might work to fulfil users’goals. Policies and high-level aims are decomposed intolower-level goals, and scenarios of business strategy,competitors’ actions and system operation can help thisprocess. To give an example, in safety critical systems thetop level policy might be “to expedite the safe navigationof the ship within the constraints of operationalefficiency”. The weakness of goal modelling is recordingvague intentions without real thought about their practicalimplications. Scenarios can help by making the abstractconcrete. As visions of the future system’s usage,scenarios cannot be created until analysis has decomposedthe system to a level where some detail of sub-goals isapparent. An example might be “the system diagnoses thepotential fire hazards with different types of cargo andrecommends safety measures to take if the cargo is likelyto be explosive or emit noxious chemicals. Theinformation is passed to the fire fighting crew who cantake appropriate action.” This scenario suggests furtherquestions (and hence discovers further goals) aboutassumptions concerning the system’s knowledge of thecargo – which may not be accurate –and whether the crewknow what the appropriate action is (prompting a possibletraining requirement). Scenarios therefore have their roleto play in complementing goal models that record ahierarchy of user intentions and their relationships.1. 2. Display of hazardous cargoHold 2-L1CO2alarmFire detected in no. 2hold; alarm soundscolourcode forhazardisolatesprinklercargo3.Evacuation instructionsActivate automatic systemsvstatusteamengines readyforward standbyaft?v?statusCO2evacn xmuster x4. Advice on fire fightingcargoCrew muster instructionsand report status?vcrewstrategyCO2 xhoseisolateGive instructions to crewFigure 5. Storyboard sketches for a shipemergency management system.Storyboards are created by developing a preliminarydesign from a sub-set of the usage scenarios gathered inphase 1. Storyboards are sketches or mock up screens thatshow key steps in user system interaction. Figure 5illustrates a storyboard sequence derived from thescenario script. The analyst walks through the storyboardexplaining what happens at each stage in terms of systemfunctionality, and asks for the users’ opinions. Thelimitation of storyboards is their poor interactivity. Userscan be asked to simulate the actions they would carry out,but mimicking the system response is more difficult. Oneof the merits of storyboards and scenarios is that they helpinvolve users in design. When users voice concerns abouta design, users’ reactions and suggestions forimprovements are recorded. Storyboards and paperprototyping allow for quick iterations of a design, but theycan mask the system functionality. Better feedback willbe obtained by demonstrating an interactive prototype inthe next phase of requirements exploration.Prior to the session the concept demonstrator isdeveloped and tested. A concept demonstrator is an earlyprototype with limited functionality and interactivity (seefigure 6), so it can only be run as a “script”. Scriptsillustrate a scenario of typical user actions with effectsmimicked by the designer. Concept demonstrators differfrom prototypes in that only minimal functionality isimplemented and the user cannot easily interact with thedemonstrator. A contextual scenario is developed basedon the preliminary domain analysis. This is a shortnarrative (half to one page) describing a situation takenfrom the users’ work context, e.g. “a typical day in the lifeof .” running through key tasks. It should also containsufficient background material to “situate” the action, thatis to give the users enough information to interpret thescript. An example for a ship emergency managementsystem follows.

Figure 6. Concept demonstrator for shipemergency management system.Contextual scenarioYour ship is a modern container ship of 30,000 tonsdisplacement with a multinational (mainly Filipino) crewof 36 with five UK officers. The cargo manifest listscontainers with a mixture of industrial goods anddomestic removals. You have left Southampton at 10a.m. this morning en route to Cape Town andare proceeding west down the English Channelheading 250 degrees at 15 knots, position 50miles south of Plymouth. The weather is fine,visibility range 15 miles, wind NW force 3. At3.10 a member of the crew reports smoke innumber two hold, and a fire alarm sounds.A scenario script, based on the captain’s emergencymanagement task, is used for the concept demonstrator.1. The location of the fire is investigated andpreliminary instructions given to the crew toevacuate the area if necessary.2. Automatic fire suppression systems are activatedif present, such as flooding compartments withCO2.3. Instructions are given by tannoy to the crew toproceed to fire muster stations and start to fightthe fire.4. Junior officers are assigned to manage key firefighting teams.5. The cargo manifest is checked to see if anydangerous (explosive, flammable, corrosive, etc)cargo is present near the fire.6. Fire fighting tactics are planned to account forany dangerous cargo and other hazards, e.g.electrical equipment.7. Instructions are given to fire fighting crews. Theprogress of fire fighting is monitored and furtherinstructions given as necessary, until the fire isunder control.Note that the scenarios do not attempt to cover all aspectsof the users’ tasks or the situation; for instance thedamage assessment phase is not described, nor is themeans of communication between the captain and crew.A number of validation sessions may be necessary to testdifferent parts of the design.Probe questions are asked at key points in thedemonstration script. The users are invited to critique theconcept demonstrator. The concept demonstrator isexplained by the analyst, while another member of thedesign team runs and interacts with the system. Limitedhands-on testing may be provided at the end of thesession. In a follow-up phase, the users are encouraged toclarify any points they found ambiguous, go back to anyparts of the demonstration, and elaborate furtherrequirements. The requirements engineers may alsofollow up points raised or user comments made during thesession.Scenarios can be linked to design decisionsrepresented in design rationale diagrams that illustratetrade-offs and assumptions affecting choice (see figure 7).Further links can complete the pathway from scenarios tomore formal requirements specifications.Steps in scenarioDesign rationale diagramFire is detectedSound warningAlarm raisedHow to raisethe alarmCause of problemdiagnosedResponse plannedVisual alarmSound andvisual alarmindicates locationRequirementsissuesDesign options Broadcastwarning- Reliable gure 7. Design rationale diagram illustratingalternative design solutions for requirementsissues linked to the concept demonstratorscenario script.Once the demonstr

Anton and Potts [5] survey the different representations of scenarios in HCI, object-oriented software engineering and RE, ranging from informal narrative to formatted texts and more formal models. They also compare scenarios as models with concrete scenarios or instances that represent a single example of an event sequence [6].