1. Scenario based design uses narratives or stories to describe how users will interact with a system. These scenarios help designers understand user needs and how people will accomplish tasks with the system. 2. Scenarios are both concrete, providing specific examples of usage, and flexible, allowing for refinement and elaboration. This helps designers manage the fluid nature of design situations. 3. Considering scenarios promotes a work-oriented design process focused on the needs of users. Scenarios also help designers reflect on and evaluate their work throughout the design process.

1. Scenario based design simplified testing procedure
Scenario based design simplified testing procedure
Amare Kebede, Department of computer science,AMIT,kbde.amex@gmail.com
Abstract
Scenarios based design help us to analyze, understand, familiar from the very beginning of the infant
stage of the system up to the whole system every activities and processes of the system finally and will
able to create new systems and applications. Scenario-based design similar to artifacts of human activity
like to things to learn from, like tools to use in one's work, as media for interacting with other people.
Scenario-based design of software development addresses technical challenges: scenarios evoke refection
in the content of design work, helping developers coordinate design action and reflection. Scenarios are at
once concrete and flexible, helping developers manage the fluidity of design situations. Scenarios afford
multiple views of an interaction, diverse kinds and amounts of detailing, helping developers manage the
many 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 that
technical knowledge often lags the needs of technical design. Finally, scenarios promote work oriented
communication among stakeholders, helping to make design activities more accessible to the great variety
of expertise that can contribute to design, and addressing the challenge that external constraints designers
and clients face often distract attention from the needs and concerns of the people who will use the
technology.

2. 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

3. 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 student's 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

4. 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

5. 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.