Scenarios have numerous possible applications in system development. Carroll (1995) lists 10 different "roles of scenarios in the system development lifecycle": •
Requirements analysis: scenarios describe the "state-of-the-art" (often called "as-is"); acted scenarios help to discover requirements as analysts "stage a simulated work situation". •
User-designer communication: users contribute scenarios important to them, or situations they want to experience or avoid. •
Design rationale: rationale can explain design "with respect to particular scenarios of user interaction". •
Envisionment: scenarios "can be a medium for working out what a system being designed should look like and do." In this role, scenarios can be "graphical mockups such as storyboards or video-based simulations", and may form early
prototypes of the system under design. •
Software design: "scenarios can be analyzed to identify the central problem domain objects" needed; the same scenarios can be developed to describe the objects' state, behavior and interactions. •
Implementation: software can be built one scenario at a time, helping "to keep developers focused" and "producing code that is more generally useful". •
Documentation and Training: "scenarios of interaction that are meaningful to the users" can bridge the gap between the system as built "and the tasks that users want to accomplish using it". •
Evaluation and testing: since "a system must be evaluated against the specific user tasks it is intended to support", scenarios are ideal for evaluation. •
Abstraction: general rules that apply across different tasks (or systems) can be identified by comparing scenarios. •
Team building: "a set of touchstone stories is an important cohesive element in any social system". ==In differing styles of system development==