Scenario based design simplified testing procedureScenario based design simplified testing procedureAmare Kebede, Department of computer science,AMIT,firstname.lastname@example.orgAbstractScenarios based design help us to analyze, understand, familiar from the very beginning of the infantstage of the system up to the whole system every activities and processes of the system finally and willable to create new systems and applications. Scenario-based design similar to artifacts of human activitylike to things to learn from, like tools to use in ones work, as media for interacting with other people.Scenario-based design of software development addresses technical challenges: scenarios evoke refectionin the content of design work, helping developers coordinate design action and reflection. Scenarios are atonce concrete and flexible, helping developers manage the fluidity of design situations. Scenarios affordmultiple views of an interaction, diverse kinds and amounts of detailing, helping developers manage themany consequences entailed by any given design move. Scenarios can also be abstracted and categorized,helping designers to recognize, capture and reuse generalizations and to address the challenge thattechnical knowledge often lags the needs of technical design. Finally, scenarios promote work orientedcommunication among stakeholders, helping to make design activities more accessible to the great varietyof expertise that can contribute to design, and addressing the challenge that external constraints designersand clients face often distract attention from the needs and concerns of the people who will use thetechnology.
Scenario based design simplified testing procedure 1. Introduction finally it is the most selective to be Embedded systems are the base for narrative. While there is plenty of many types of the equipment available opportunity to do things that makes a for making our live easier. The design of difference, it is never unequivocal jus such a system starts at the base: a what should be done, or even just what problem which needs to be solved. In the real problems are. The problems can most cases it is not difficult to make an only be definitively analyzed by being abstract description of the solution. The solved; the appropriate solution methods translation of this abstract solution into a must typically be executed in order to be working embedded system is the hard identified; the solutions must be part. There are multiple ways of implemented in order to be specified. formalizing the design. One of these All the while, the designer faces approaches is scenario based design. convoluted networks of tradeoff and Scenario-based design is based on interdependency, the potential of descriptions of how people accomplish untoward impacts on people and their tasks. Many types of scenarios exist. social institutions, and the likelihood Well known types are using case that changing cultural and technological scenarios. Basically, use-case scenarios circumstances will obviate any solution are stories. They describe the users of before it can be deployed. Most software the embedded systems and their engineering methods belong to a activities. In general, a use-case scenario methodological tradition that seeks to has agents and objectives. The agent is control the complexity and fluidity of the user of the embedded system. Each design through techniques that filter the user, or group of users, has a certain information considered and decompose objective when using the system. An the problems to be solved. A example of a use-case scenario is a user complementary tradition seeks to exploit who powers on a mp4 player, selects a the complexity and fluidity of design by song and starts to listen to that song. The trying to learn more about the structure objective of an agent can also carry a and dynamics of the problem domain, timing constraint. The user in our by trying to see the situation in many example can require that the mp4 player different ways, and by interacting powers up within a second. (Peter van intimately with the concrete elements of Stralen September 24, 2009) the situation (Ackoff, 1979a, b; Check Designing of a given system is a land, 1981; Scho En, 1983). collection of plenty of realities and Scenario-based design techniques process and also Designers of belong to this complementary approach. information systems and applications In scenario based design, descriptions of face a disturbing reality so it is better to how people accomplish tasks are a clarify the system in descriptive manner. primary working design representation. Since we are developing the new system Software design is fundamentally about whose ground or base is on previous envisioning and facilitating new ways of system so it needs some investigation or doing things and new things to do. know how of the existing system rather Maintaining a continuous focus on than directly going to the solution situations of and consequences for
Scenario based design simplified testing procedure human work and activity promotes quite sharp, as when one must stop and learning about the structure and think before taking another step. But dynamics of problem domains, seeing frequently it is more a matter of trading usage situations from different off priorities. Scho Èn (1983, 1987) has perspectives, and managing tradeoffs to discussed this conflict extensively in his reach usable and effective design books on reflective practice. For outcomes (Carroll, 1994, 1995). example, he analyzes a coach reacting to 2. What are scenarios? an architecture students design concept In analyzing and designing systems and for a school building; the design software we need better means to talk includes a spiral ramp intended to about how they may transform and/or be maintain openness while breaking up constrained by the contexts of user lines of sight (she calls the idea ªa activity: this is the only way we can Guggenheimº):¼ when I visited open hope to attain control over the schools, the one thing they complained “materials” of design. A direct approach about was the ware-house quality of is to explicitly envision and document being able to see for miles. It [the ramp] typical and significant user activities would visually and acoustically break up early and continuingly in the the volume. (Scho Èn, 1987, p. 129). development process. Such descriptions, 4. Scenarios evoke reflection in often called “scenarios, “support design reasoning about situations of use, even Designers do try to create opportunities before those situations are actually for their own reflection. They organize created. Scenarios are stories. They are design review meetings in which the stories about people and their activities. whole team works through a set of For example, an accountant wishes to requirements, a progress report, or a open a folder on the system desktop in specification. It is also common to build order to access a memo on budgets. early prototypes to verify and refine However, the folder is covered up by a design requirements; one can directly budget spreadsheet that the accountant observe prospective users interacting wishes to refer to while reading the with such a prototype to make a memo. The spreadsheet is so large that it formative evaluation (Screven, 1967) of nearly fills the display. The accountant the design. These activities can facilitate pauses for several seconds, resizes the the identification and integration of spreadsheet, moves it partially out of the different perspectives; they can raise display, opens the folder, opens the concrete and detailed design issues to memo, resizes and repositions he memo guide further work. In this way they and continues working. help designers to reflect on the work 3. Challenge: design action they have already done. competes with reflection There is a fundamental tension between 5. Challenge: design situations thinking and doing: thinking impedes are fluid progress in doing, and doing obstructs Design analysis is always indeterminate, thinking. Sometimes this conflict is because design changes the world within
Scenario based design simplified testing procedure which people act and experience. The be prototyped and tested. At the same rapid evolution of spreadsheet software time the scenario is flexible, deliberately in the 1980s does not indicate a failure incomplete and easily revised or in the original requirements analysis for elaborated: in a few minutes, a piece of VisiCalc, but rather suggests the extent the scenario could be-written (e.g. to which the original spreadsheet perhaps the associated module opens programs altered the work situations in automatically) or elaborated (e.g. the which these programs were used module may be opened by following a (Carroll and Rosson, 1991). ‘related materials’ tag attached to the Requirements always change (Brooks, film clip). 1995). When designs incorporate rapidly 7. Scenarios promote work- evolving technologies, requirements orientation change even more rapidly. The more Scenarios are work-orientated design successful, the more widely adopted and objects. They describe systems in terms the more impactful a design is, the less of the work that users will try to do possible it will be to determine its when they use those systems. A design correct design requirements. And in any process in which scenarios are employed case, refinements in software technology as a central representation will ipso and new perceived opportunities and facto remain focused on the needs and requirements propel a new generation of concerns of users (Carroll and Rosson, designs every 2-3 years. 1990). 6. Scenarios are at once 8. Challenge: external factors concrete and flexible constrain design To manage an ambiguous and dynamic Designers must have constraints; there situation, one must be concrete but are just too many things that might be flexible. One must be concrete just to designed. Requirements, if they can be avoid being swallowed by the identified, are clearly the best source of indeterminacies; one must be Flexible to constraints because they indicate what avoid being captured by a false step. sort of design work is needed. But there Systematic decomposition is a are many other sources of constraints. traditional approach to managing The current state of technology ambiguity, but it does not afford development makes some solutions flexibility. Instead one ends up with a impossible and others irresistible: On set of concrete sub solutions, each of the one hand, designers cannot use which is fully specified. Unfortunately, technology that does not yet exist, by the time the set of sub solutions is though their work often drives specified, the requirements often have technology development toward changed. Scenarios of use help us to possibilities that are nearly within reach. reconcile concreteness and flexibility. On the other hand, designers like They are concrete in the sense that they everyone else, are caught up in a simultaneously fix an interpretation of technological zeitgeist that biases them the design situation and offer a specific toward making use of the latest gadgets solution: the scenario in Fig. 1 specifies and gizmos. In addition, designers are a particular usage experience that could
Scenario based design simplified testing procedure often biased toward deploying even when they are aware of limitations technologies they have used before, in these technologies. REFERENCE 1. J.M. Carroll, “five reason for scenario design”, Virginia tech Blacksburg, (2000) 2. peter van Stralen,” Scenario Based Design Space Exploration”, master grid computing university of Amsterdam, September 24, 2009 3. Irene Anggreeni Mascha van der Voort,” Tracing the Scenarios in Scenario-Based Product Design A study to support scenario generation”, Laboratory of Design, Production & Management, CTW-OPM, University of Twente, 4. Carroll, J.M. (Ed.), 1995. Scenario-based Design: Envisioning Work and Technology in System Development Wiley, New York.