Conference Draft for REFSQ’01, June 4-5 2001, Interlaken, Switzerland

Round-Trip Prototyping for the Validation of

Requirements Specifications
Andreas Homrighausen, Hans-Werner Six, Mario Winter
University of Hagen, Germany

Abstract. The new millennium opens with an increasing diversity of

computerized devices comprising an increasing diversity of interaction styles
used by an increasing diversity of user groups. Thus the incorporation of user
interface requirements into software requirements specifications becomes more
and more mandatory. Validating these requirements specifications with hand
made, throw away prototypes is not only expensive, but also bears the danger
that validation results are not sufficiently taken into account in the updated
requirements specification. In this paper we propose an enhancement of a UML-
based requirements specification for an explicit capturing of user interface
requirements. The advantages of the approach are twofold. First, presentation
prototypes for validation purposes can semi-automatically be generated. Second,
the model based construction of presentation prototypes allows for “round-trip
prototyping“ such that manual changes of the prototype during the validation
process are automatically fed back into the requirements specification.

1 INTRODUCTION
Due to the “ubiquitous computing“ paradigm, the new millennium opens with an
increasing diversity of computerized devices comprising an increasing diversity of
interaction styles for an increasing diversity of user groups [24]. For example modern
eBusiness domains demand for application families with shared functional cores but
vastly different device and user interface requirements. The diversity of devices ranges
from narrowband devices, including cellular phones and pagers, up to workstations
with high resolution graphic displays, while the diversity of interaction styles ranges
from the deck/card organizational metaphor up to high sophisticated multi-window
user interfaces. Finally the diversity of user ranges from incidental to professional.
Hence, a suitable software requirements specification (SRS) in such application
domains must sufficiently take into account user interface requirements.
In this paper we focus on requirements specification and especially on validation
activities in the setting above. In [19], we described SCORES, an approach for a UML-
based description of the functional, behavioral, and structural system requirements.
Following the UML [26], functional requirements are expressed by use cases, their
behavior modeled by activity graphs, while structural requirements are captured by
class models. SCORES proposes a refinement of activity graphs to meet the needs of a
suitable modeling of use case behavior. The refinement in particular supports the
proper coupling of activity graphs and the domain class model, which allows for
consistency and completeness checks of the multi model specifications.
Concerning the validation process, SCORES provides inspections and walkthroughs of
(business) scenarios [15][17], which are recommended validation means [23][34]. For
walkthroughs, scenarios are constructed according to the pre-conditions and activity
graphs of the underlying use cases. For a better comprehension, analysts build up user-
centered views of the scenarios and object constellations. For example, domain
2 Homrighausen, Six, Winter

specific pictograms and user interface mock-ups can be attached to each interaction in
the activity diagrams.
Using SCORES in a couple of applications with different devices, interaction styles, and
user groups has revealed some weaknesses of the validation procedure. First, despite of
pictures and mock-ups sometimes the imagination of users was overstrained, and a
more tangible representation seemed desirable. Second, wrong or missing
requirements, which were detected during the validation and materialized by changed
or new pictures and mock-ups did not always trigger the necessary changes of the
requirements specifications.
Prototyping is often recommended as a more appropriate validation technique in such
a context. In requirements engineering for information systems, most often exploratory
presentation prototypes and sometimes even functional prototypes are used to validate
the specified requirements [2][9]. While presentation prototypes illustrate how an
application may solve given requirements from a user interface point of view,
functional prototypes implement important parts of both the user interface and the
functionality of the application.
A pure generative approach of building prototypes needs a detailed specification and
does not allow for an easy change or extension of prototypes during validation
sessions. Hand made, throw away presentation prototypes are also expensive and bear
the danger that changes of the prototype are not sufficiently fed back into the
requirements specification. As pointed out by Ravid and Berry, in such a setting the
question “When the prototype and the SRS disagree, which do one believe?“ often
arises [27].
In this paper, to tackle these problems we introduce a fusion of SCORES and FLUID.
FLUID is a specification method for the requirements of direct manipulation user
interfaces which captures the essential structure of the user interface, the basic dialog
behavior, and the (parts of) domain objects to be presented [18]. Our approach allows
for the specification of functional and user interface requirements as well as the cheap,
semi-automatic construction of exploratory, horizontal presentation prototypes for
different devices and interaction styles. Due to the granularity and preciseness of the
SCORES functional requirements specifications, the matching abstraction levels of
SCORES and FLUID elements, and the traceability of the prototype construction process,
“round-trip prototyping“ is carried into effect, i.e. the requirements specification can
automatically be reconciled with manual changes of the prototype.
The paper is structured as follows. Section 2 briefly reviews the specification of
functional requirements with SCORES, while section 3 is devoted to basic elements of
FLUID. Section 4 explains the round-trip prototyping process, and section 5
summarizes our experiences with the prototype based validation. Section 6 sketches
some related work, and section 7 finally gives some conclusions.

2 SPECIFICATION OF FUNCTIONAL REQUIREMENTS WITH SCORES

In this section we briefly review the specification of functional requirements with
SCORES [19], namely actors and use cases, activity graphs, and the domain class
model.
2.1 Actors, Use Cases, and Activity Graphs
According to the UML [26], actors represent the global business context the proposed
Round-Trip Prototyping for the Validation of Requirements Specifications 3

system will fit in. Actors characterize roles played by external objects which interact
with the system as part of a coherent work unit (a use case). A use case describes a
coherent work unit or task to be carried out by one or more actors with the help of the
system. Each use case describes a high level task which should be related to a
particular goal [25] of its participating actors.
The UML proposes activity graphs as more precise specifications of use case behavior.
In [19] we extended activity graphs to meet the needs for a suitable modeling element
for use case behavior. Firstly, we characterize actions within activity graphs more
precisely by introducing three stereotypes. An action stereotyped «contextual action»
is performed by an actor without the help of the system. An action stereotyped
«interaction» is supported or carried out by the system. The «macro action» stereotype
reflects the «include» and «extend» relationships between use cases within activity
graphs and "calls" or "activates" the activity graph of the associated use case (for more
details see [19]). The stereotype «actor in action» refers to an (anonymous) instance or
“role“ [5] of an actor involved in an action.
Example: We illustrate our proposal using WEBADMIN, a virtual university component
supporting the web-based administration of events at the FernUniversität Hagen, the
German distance teaching university. WEBADMIN covers the scheduling of,
registration for, and performance of written examinations and seminars.
Fig. 1 shows in the left part the use case diagram for the written examination
registration functionality of WEBADMIN. We identify two actors Student and
Supervisor, and three use cases: Written Examn Registration, Special Case
Registration, and Cancel Registration. The activity graph in the right part of Fig. 1
refines use case Written Examn Registration. After identifying himself, a student can
(repeatedly) select a lecture and registrate himself at a site for the first and/or the
second examination for this lecture, if offered. The use case may be extended for
special case registrations. Fig. 2 provides textual descriptions of the use cases
Written Examn Registration and Special Case Registration.

Examn Registration
Identification

«refine»

Select
Written Examn Registration Lecture
:Supervisor

«extend» :Student
Special Case Student

Select Site Select Site Special Case

1st Examn 2nd Examn Registration
Student Supervisor
Special Case Registration

Cancel Registration

Fig. 1. Use case diagram and activity diagram for use case Written Examn Registration
4 Homrighausen, Six, Winter

Use Case Written Examn Registration in Model WebAdmin

Actors: Student, Supervisor
Pre-Condition: examn sites exists
Description: A student registers to the offered written examns by se-
lecting one of the preset sites.
Extension Point Special Case
Post-Condition: 1st examn registration or 2nd examn registration
or special case registration conducted
End Written Examn Registration

Use Case Special Case Registration in Model WebAdmin

Actors: Student, Supervisor
Pre-Condition: examn selected
Description: A special case student (handicaped, prisoned, or living
in a foreign country) registers to the selected written examn with the
special case registration form and specifies his personal examn site
and supervisor. A registration message is forwarded to the supervisor.
Post-Condition: special case registration exists and registration
message forwarded
End Special Case Registration

Fig. 2. Textual descriptions of use cases Written Examn Registration and Special Case Registration

2.2 Domain Class Model

The domain class model in the sense of Jacobson et al. [15] comprises the most
important types of objects which represent "things" that exist or events that occur in
the context in which the system works. As described in [19], in SCORES for each use
case and each interaction in the activity graphs we determine a so-called class scope
denoting the set of (domain) classes involved in its execution, i.e. classes with
instances being created, retrieved, activated, updated, or deleted. Furthermore we
balance activity graphs and the class model such that for each «interaction» a so-called
root class defining a root operation exists, that accomplishes the «interaction» in the
class model.
Example: Fig. 3 sketches a part of the WEBADMIN domain class diagram. A lecture
can offer events. A special event is the written examination. A student must register to
events. The collaboration Written Examn Registration in the left part of Fig. 3
visualizes the class scope of the corresponding use case.

3 SPECIFICATION OF USER INTERFACE REQUIREMENTS WITH FLUID

According to [14], a suitable SRS should include the basic characteristics of the user
interface, among them the basic layout, dialog behavior, and usability aspects. It may
simply comprise a list of do’s and don’ts on how the system will appear to the user.
To specify user interface requirements and to support the convenient construction of
presentation prototypes for validation purposes, we augment use cases and interactions
in the activity diagrams by so-called user interface analysis (UIA) elements adapted
from the FLUID method [18]. UIA elements capture the most important decisions
concerning the user interface and do not address the detailed layout or GUI design.
The design rationale for UIA-elements is to meet the abstraction level of SCORES
elements.
Round-Trip Prototyping for the Validation of Requirements Specifications 5

WrittenExamn Student
Event
id-number
name ...
/participant name
date
... * * ...
...
1 ... ...
registerTo()
... 1
*
Registration
*
date of registration
1 *
Written Examn Registration ...
Lecture *
...
name
1 Room
lecture-id
EventSite
... name
town 1..n address
...
... 1 ...
...

Fig. 3. Partial sketch of the WEBADMIN domain class diagram

UIA elements provide concepts aimed at complex user interfaces with a broad range of
display and interaction styles. They are based on the assumptions that a direct
manipulation user interface is composed of building blocks like e.g. windows and sub-
windows, and that domain objects (more precisely: their attributes and associations)
appear inside of such building blocks where they can be viewed, selected and directly
manipulated by the user. The fundamental UIA elements are scenes comprising class
views and user operations, and relations between scenes modeling the navigation
structure.
3.1 UIA Elements: Scenes, Class Views, User Operations, and Relations
A scene is related to a use case, an «interaction», or a «macro action». The scene of a
«macro action» is the scene of the “called“ use case. The scene concept provides for a
homogeneous decomposition of a user interface into its main building blocks. A scene
will later be implemented as a window or sub-window, a deck of cards, or a similar
user interface feature. However, these implementation details are beyond the focus of
requirements engineering.
A scene can be characterized as multiple (there may exist multiple instances of the
scene), modal (all other scenes are locked until the associated task is completed), or
mutual exclusive (modal with respect to a group of scenes rather than to all scenes).
A scene may comprise class views. A class view is an abstraction of the presentation of
instances and relations of a domain class involved in the according user activity (i.e.
contained in the class scope). A scene with no class view represents only navigation
information, e.g. a menu or some buttons. A class view abstracts from actual user
interface details. In cases where the description of a class view does not sufficiently
characterize the situation, e.g. if domain specific renderings are required, graphical
drafts may additionally be attached.
Besides class views, a scene contains user operations. A user operation models
different kinds of activities: It is either a pure user interface operation like selection or
it invokes the root operation of an interaction in the activity diagram. “Semanticless”
operations like window moving and re-sizing or scrolling are not considered. As the
other UIA-Elements, user operations abstract from concrete user interface details. For
example, the particular interaction technique invoking a user operation, e.g. menu item
selection or drag and drop, is not specified. Likewise, low level interactions like mouse
button presses or basic text editing operations are not considered.
6 Homrighausen, Six, Winter

Written
Examn
Registration
Written Examn Registration
«navigate» «dependsOn»
«refine»

Identification Identifi-
cation Lecture
Lectures
modal Shortform

Select
Select «create&navigate» Lecture
Lecture

Special 1st Examn 2nd Examn

Case Registration Registration
Registration

Special Case
Select Site Select Site Registration
1st Examn 2nd Examn Select Select
1st Site 2nd Site

Site
Shortform

Fig. 4. Use case Written Examn Registration activity diagram and scenes (actors suppressed)

Scenes and relations determine the main navigation structure of the user interface. We
distinguish three different kinds of relations: A navigate-to relation between two
scenes expresses the user’s explicit change of focus from one scene to the other, e.g.
from a task to a subtask. From the user interface point of view, this relation assures the
visibility of the target scene. The create-and-navigate-to relation is a special case of a
navigate-to relation. The target of the relation is a multiple scene. The user’s explicit
change creates a new instance of the target scene together with a navigation to that
instance. For example, there exist a create-and-navigate-to relation from the scene of a
«macro action» to the scene of the “called“ use case. A depends-on relation between
scene S and T (S depends-on T) denotes that scene S only exists or is visible if scene T
exists or is visible. For a dependency relation, a (create-and-)navigate-to relation is
implicitly given. For example, there exists a depends-on relation between the scene of
a use case and the scene of the first action in the activity diagram (of the use case).
Example: The UIA-elements for the use case Written Examn Registration and its
activity diagram are depicted in the class diagram in the right part of Fig. 4. On the top
right side, the scene UIA-class related to the use case is shown. Via an aggregation
stereotyped «dependsOn» it aggregates the (sub-)scene UIA-class Lectures, which is
related to the interactions Select Lecture. The scene class Lectures composes the class
view (UIA-class) LectureShortform, which presents a shorthand form of all lectures
subscribed by the student. The scene classes 1st Examn Registration and 2nd Examn
Registration compose the class view SiteShortform, which presents short form
information of all offered examination sites, including room information. The user
operations Select 1st Site and Select 1st Site invoke the corresponding root operation
registerTo() defined in class Event.
Round-Trip Prototyping for the Validation of Requirements Specifications 7

4 PROTOTYPING SUPPORT
SCORES and UIA elements introduced so far (SCORES+ elements for short) aim at the
specification of functional and user interface requirements. For a semi-automatic
generation of presentation prototypes, however, SCORES+ is not detailed and precise
enough. In the following subsection, we therefore enrich SCORES+ by domain object
variables, an additional concept that forms the basis for the prototype construction.
Section 4.2 deals with the proper construction of prototypes, while section 4.3
concerns the “round-trip“ prototyping.
4.1 Domain Object Variables
Class scope and scene of a use case or an interaction deal with domain classes and not
with concrete instances of that classes. The expressive power of such an approach is
too weak to specify the semantics on the level of preciseness needed for complicated
situations, and in particular not for a semi-automatic construction of prototypes. For
that purpose, the specification has to come down to the object level. It must be possible
to specify objects involved in a certain task. For example, it must be able to express
that the user can manipulate objects, like “the currently edited registration” or “the
currently selected site”, and invoke the corresponding application functionalities.
To this end, a scene can be augmented by so-called domain object variables. A domain
object variable is a UIA element which references a single instance or a collection of
instances of a domain class which plays a role in the scene the domain object variable
is attached to. While a domain object variable refers to exactly one domain class, a
domain class may be referred by more than one domain object variables.
A domain object variable can be associated with more than one scene. In this case, the
different scenes refer to the same object, resp. the same collection of objects. (The
need of expressing the fact that different scenes share the same domain object was the
main reason to introduce the concept of a domain object variable.) For multiple scenes,
a domain object variable is specified as multiple too, and to every new instance of a
scene a new “instance“ of the domain object variable is attached.
4.2 Semi-Automatic Generation of Prototypes with FLUID
UIA elements specify scenes and subscenes with navigability, which user operations
may be activated when, and what information of domain objects has to be displayed.
However, UIA elements do not determine how the user interface requirements are
implemented by an actual user interface. For example, it is still open whether scenes
are realized as decks or windows, class views as widgets or simple lines of text, or user
operations as buttons, menus, or drag and drop.
These decisions depend on the interaction style chosen for the implementation. UIA
elements together with a particular interaction style, and SCORES functional
specifications are integrated into an abstract user interface design model (UID model).
This model is automatically generated by the FLUID tool [13]. The UID model can be
worked over by refining the layout and adding further navigation information as well
as validation data generated from the domain class model [28].
From the UID model, the FLUID tool generates an executable prototype which runs in a
technical environment, like VisualWorks MVC, Java Swing, or some HTML dialect,
and on devices like a desktop computer running SUN CDE or MS Windows, a PDA
supporting HDML [32], or a WAP/WML [33] compatible handy (simulator). Fig. 5
shows the three main activities of the semi-automatic construction process for
8 Homrighausen, Six, Winter

Stakeholder Activities Artifacts

Use Case
Model
Class
Model
Selection and
Generation
UIA
Analyst, Tester, Elements
Domain Expert

Interaction
Manual Style
Adaption UID Description

Analyst, Tester,
Developer

Generation
Technical
Environment
Description Validation
Data

Presentation
Prototype

Fig. 5. Prototype construction process

presentation prototypes, and the artifacts and stakeholders involved. An important
aspect of the presentation prototypes constructed in the proposed way is the
traceability maintained by the FLUID tool from each element of the prototype via the
UID back to the SRS.
Example: The left part of Fig. 6 depicts a screen shot of a WIMP-style presentation
prototype for the WEBADMIN example. In the right part of Fig. 6, a screen shot of the
presentation prototype for a WAP/WML compatible handy simulator is shown.
4.3 Validation and “Round-Trip“ Prototyping
Before a validation session starts, analysts, testers, and domain experts have to select
the part of the SRS to be validated and a particular interaction style. From this
information the FLUID tool generates the executable prototype. The validation session
comprises a series of walks through business scenarios conducted with the help of the
prototype. The validation proceeds analogously to the document based process
described in [19]. During the validation, the prototype can be modified or extended by
an assisting developer according to the actual findings. Typically, further navigation
relations between scenes, or attributes to class views are added. The changes can be
performed on the prototype, the UID, or the SRS. In the latter cases, an incremental re-
generation of the prototype takes place.
If the prototype is modified, the FLUID tool automatically feeds the modifications back
into the UID. In a last step, the updates of the UID are mapped back to the SRS. A
change of a dialog box or a list triggers a change of the corresponding class view and
domain class, a change of a window from modal to non-modal triggers a change of the
according scene. A modification of the navigation structure is mainly reflected by a
change of the use case model. The round-trip prototyping brings the prototype and the
SRS in sync and the prototype can be discarded when the validation process is
finished.
Round-Trip Prototyping for the Validation of Requirements Specifications 9

Fig. 6. Screen shots of a windows- and a handy/WML presentation prototype

Stakeholder Activities Artifacts

Business
Scenarios
Walkthroughs
of Business
Scenarios
User,
Domain Expert,
Tester Presentation
Prototype

Validation
Protocols Validation
Data

UID
(Reverse)
Engineering UID
Developer, Analyst

Wrap Up
Use Case
Model

Class
Model

UIA
Elements

Fig. 7. Round-Trip prototyping

10 Homrighausen, Six, Winter

5 EXPERIENCES
We have applied the SCORES+ specification and validation techniques to a couple of
projects ranging from small database applications over CASE tool components up to
some main components of a “virtual university“. This section summarizes our
experiences with the prototype-based validation of the SRS for WEBADMIN.
The SRS for WEBADMIN comprised 4 actors, 37 main use cases, 24 domain classes,
and 28 main scenes. The presentation prototype for a window-based user interface
architecture comprised 13 windows with full navigation capabilities and some added
application functionality like object creation and manipulation. Some simple WAP/
WML-based prototypes were built, too. The effort for the construction of the
prototypes and the validation data was less than one person-week.
The prototypes were used and adapted in several validation sessions conducted for
particular user groups. Most of the participating stakeholders were experts of the
problem domain and used to window-based applications, such that they did not
encounter problems to identify the main tasks in the prototype. All stakeholders felt
much more inclined in the prototype based validation process compared to a rather
document centered one. In accordance to a study conducted by Cerpa and Verner [8],
the analysts and especially the developers felt much more “safe“ during the whole
development of the system than they did in former projects without prototype based
validation.
With the prototype-based validation, we found omissions in the SRS which would
presumably not have been found with our validation approach sketched in the
introduction. For example, in the original SRS the supervisory staff for written
examinations had to be among the official staff of the FernUniversität. Thus in the
prototype the supervisor for a particular written examination only could be selected
from the university staff. During a validation session, some user asked for a “free form
entry“ for supervisors, which was added to the prototype. Round-trip prototyping
incorporated that requirement back into the SRS as a new interaction of the use case
Specify Supervisor and a new domain class Staff, of which the original domain class
UniversityStaff and a new class Supervisor became subclasses.
Our main experience with prototypes for interaction techniques like WAP/WML
browsers is as follows. In the requirements elicitation activities, stakeholders often
came up with a bunch of needs w.r.t. WAP/WML-based services. But while walking
through some use cases with a WAP/WML browser prototype as shown in the right
part of fig. 6, the experienced inconvenience helps a lot in separating real needed WAP/
WML-based services from wishful thinking. Our recommendation is to prototype
some of these services very early, especially before negotiating the interaction styles
for all use cases.
Besides revealing errors and omissions in the SRS and clearing the needs for
interaction styles, the prototypes also served as a medium to line up the notions and
concepts. For example, in the original SRS the actor Coordinator depicted the person
coordinating the rooms, supervisors, and cover sheet colors for all examinations to be
conducted at a particular date. When we presented the prototype to some users from a
particular faculty, they immediately asked, why the coordinator could not select the
examinations for a particular date. So in this faculty the coordinator was also
responsible to schedule all examinations for a semester, while in all other faculties this
responsibility was the duty of a member of the examination commission. This
Round-Trip Prototyping for the Validation of Requirements Specifications 11

misconception even was not detected by the inspections of the data dictionary.
We close this section denoting some pitfalls of the prototype-based validation of SRS.
On the one hand, even for highly sophisticated window environments, only “rough“
prototypes should be constructed. This helps the users to focus on the functional
requirements and not to discuss detailed layout and usability features too early. It also
reduces the risks that users create unrealistic expectations and are reluctant to discard
the prototype. On the other hand, for simple interaction style devices even rough
prototypes bear the danger of reinforcing such discussions, because at the first glance
the user interfaces of “real“ applications don’t differ very much from the prototypes.
A common experience is that users, when faced with a prototype, often demand for
more and more functionality [12]. This is partially due to the fact that the tangibility
and modifiability of the prototype lets them easily imagine increased functionality
without considering the additional costs, and partially because “users do seem to
always ask for more“ [27]. However, these new functionalities have to be negotiated.
The most important of them can be added to the prototype and validated at once, while
others are either discarded or first incorporated in the SRS and then validated later. All
in all, the resulting SRS will be more complete than a conventional validated one.
Last not least, as already pointed out in [9], one should build prototypes focusing on
critical requirements that are either poorly understood or not fully negotiated.
Otherwise, the participating stakeholders pretty soon either begin to discuss detailed
features of the prototype, imagine additional features as discussed above, or become
bored. In either case, the efficiency of the validation sessions degrades.

6 RELATED WORK
As mentioned in the introduction, Ravid and Berry aim at reconciling the difference
between the prototype and other SRS documents [27]. Based on a case study, they
propose a generic approach to taylor the process of constructing a prototype. The main
idea is to identify before the prototype is constructed the kinds of requirements
information that the prototype will contain and will not contain. This information is
called “intent-information“ and should answer the question of “When the prototype
and the SRS disagree, which do one believe?“.
Schneider proposes a strategy to extract crucial pieces of knowledge from a prototype
and from its developer [30]. The strategy is based on monitoring explanations that
developers give, analyzing their structure, and feeding results back to support and to
focus explanations. During this process, the prototype turns into the centerpiece of a
hyperstructured information base, which can be used to convey concepts,
implementation tricks and experiences.
Both approaches are contrary to ours and the problem tackled by them seems to
disappear or at least to be attenuated due to our “round-trip“ facility synchronizing the
prototype and the SRS.
Elkoutbi et al. suggest a process that generates a user interface prototype from
scenarios and yields a state-based specification of the system [10]. Scenarios of use
cases are acquired as UML collaboration diagrams enriched with user interface
information, i.e. messages are labelled with an optional “widget mark“ indicating the
widget-type that the analyst wants to find in the resulting user interface. The main
drawbacks of the approach are the tedious manual task of specifying all scenarios on
the level of widget interactions, which requires the analyst to have the concrete user
12 Homrighausen, Six, Winter

interface already in his mind, and the lack of support of user interaction techniques
alternative to menus and windows. The approach also lacks the mapping of validation
results back from the (modified) prototype to the requirements specification.
Many software tools for the generation of user interfaces are known [24]. Some of
them, e.g. Lauesens EFDD approach [21], use only the structural (data) model. Others
(e.g. Johnsons ADEPT [16] or the approach of Bomsdorf and Szwillus [4]) are based
solely on a functional (task) model. A few approaches e.g. Forbrigs and Schlungbaums
TADEUS [11] or the Genova system by Arisholm et al. [1] are based on functional and
structural models. While all of these approaches can be used to generate presentation
prototypes, most of them are related to full fledged user interfaces and focus on
detailed dialog and widget specifications, and none of them allows for a round-trip
prototyping.
Formal specification based prototyping approaches like e.g. the CAPS project by Luqi
[22] mainly focus on the (semi-)automatic generation of functional prototypes.
Presentation prototypes are either neglected or must be created manually.
Development systems like e.g. Rhapsody from I-Logix or KIDS and Specware from
Kestrel [31] provide intuitive, high-level operations for the transformational
development of programs from specifications. Thus they concentrate on specification,
refinement, program generation and visualization, but neglect the user interface.

7 CONCLUSION
We proposed the SCORES+ enhancement of UML-based requirements specifications.
SCORES+ is based on the combined SCORES and FLUID modelling elements for an
explicit capturing of functional and user interface requirements. The advantages of our
approach are twofold. First, presentation prototypes for validation purposes can be
semi-automatically generated. Second, the model based construction of presentation
prototypes allows for “round-trip prototyping“ such that manual changes of the
prototype during the validation process can be automatically fed back into the
requirements specification. Due to “round-trip“ prototyping we combine the
advantages of a cheap, throw-away prototype construction and an evolvable, always
up-to-date SRS. Moreover, the SCORES+ SRS is able to cope with more than one
interaction technique. Our experiences so far indicate that the approach is both feasible
and valuable in real life projects.
The tools used in our projects consist of home-grown VisualWorks developments for
FLUID and extensions to Rational Rose for SCORES. Currently we develop SCORES+
extensions (implemented in Java) for the Together/J CASE tool supporting the UML
notation. Since we always had the UML extension mechanisms in mind while
developing SCORES+, the modelling parts were easily integrated in Together/J.
Presentation prototype generation is possible by exporting the model (in XML-format)
into our Fluid tool for VisualWorks, round-trip prototyping then works vice versa.
Future work on SCORES+ concerns the development of transformation rules for further
interaction techniques, the seamless transition into design, and the early generation of
GUI-based system acceptance test cases.

8 REFERENCES
1. E. Arisholm, H. Benestad, J. Skandsen, H. Fredhall: Incorporating Rapid User
Interface Prototyping in Object-Oriented Analysis and Design with Genova. Proc.
Round-Trip Prototyping for the Validation of Requirements Specifications 13

8. Nordic Workshop on Programming Environment Research, Ronneby, Sweden,

August 1998
2. D. Bäumer, W. Bischofberger, H. Lichter, H. Züllighoven: User Interface Prototyp-
ing — Concepts, Tools, and Experience. Proc. ICSE-18, Berlin, Germany, March
25 - 29 1996, pp. 532-541
3. Boehm B. Verifying and Validating Software Requirements and Design Specifica-
tions. IEEE Software, Jan. 1984, pp 75-88
4. B. Bomsdorf, G. Szwillus: Coherent Modelling & Prototyping to Support Task-
Based User Interface Design. CHI’98 Workshop "From Task to Dialogue: Task-
Based User Interface Design", Los Angeles, California, 1998
5. G. Booch, J. Rumbaugh, I. Jacobson: The Unified Modeling Language Users
Guide. Addison-Wesley/acm Press, Reading, MA, 1999
6. J. Brunsmann, A. Homrighausen, H.-W. Six, J. Voss. Assignments in a Virtual Uni-
versity — The WebAssign System. Proc. 19th World Conf. on Open Learning and
Distance Education, Vienna, Austria, 1999
7. J. M. Carroll (Ed.): Scenario-Based Design — Envisioning Work and Technology in
System Development. J. Wiley & Sons, New York, 1995
8. N. Cerpa, J. Verner: Prototyping: some new Results. Information and Software
Technology, Vol 38, Elsevire, 1996, pp. 743-755
9. A. Davis: Software Prototyping. in: M. Yovits, M. Zelkowitz (Eds.): Advances in
Computers, Vol. 40, Academic Press, San Diego, 1995, pp. 39-63
10. M. Elkoutbi, I. Khriss, R.K. Keller: Generating User Interface Prototypes from
Scenarios. Proc. RE 99, IEEE Computer Society Press, 1999, pp. 150-158
11. P. Forbrig, C. Stary et al.: From Task to Dialog: How Many and What Kind of
Models do Developers Need? Proc. CHI’98 Workshops, April 1998
12. V. S. Gordon, J.M. Bieman: Rapid Prototyping: Lessons Learned. IEEE Software,
Vol. 15, Nr. 1, Jan. 1995, pp. 85-95
13. A. Homrighausen, J. Voss: Tool support for the model-based development of inter-
active applications - The FLUID approach. Proc. 4th Eurographics Workshop on
Design, Specification and Verification of Interactive Systems, Granada, 1997
14. IEEE Guide to Software Requirements Specifications IEEE Standard 830, IEEE,
New York, 1993
15. I. Jacobson, G. Booch, J. Rumbaugh: The Unified Software Development Process.
Addison-Wesley/acm Press, Reading, MA, 1999
16. P. Johnson, H. Johnson, S. Wilson: Rapid Prototyping of User Interfaces Driven by
Task Models. Chapter 9 in [7].
17. G. Kösters, B.-U. Pagel, T. de Ridder, M. Winter: Animated Requirements Walk-
throughs based on Business Scenarios. Proc. 5th euroSTAR, Edinburgh, 1997
18. G. Kösters, H.-W. Six, J. Voss: Combined Analysis of User Interface and Domain
Requirements. Proc. 2nd IEEE Int. Conf. on Requirements Engineering, Colorado
Springs, 1996
19. G. Kösters, H.-W. Six, M. Winter: Coupling Use Cases and Class Models as a
Means for Validation and Verification of Requirements Specifications. Require-
ments Engineering, Vol. 6, Nr. 1, Springer, London, January 2001, pp. 3-17
14 Homrighausen, Six, Winter

20. V. Lalioti, P. Loucopoulos: Visualisation of Conceptual Specifications. Information

Systems Journal, Vol. 19, April 3, 1994, pp. 291-309
21. S. Lauesen, M. B. Harning, C. Grønning: Screen Design for Task Efficiency and
System Understanding. In: S. Howard and Y.K. Leung (eds.): OZCHI 94 Proceed-
ings, 1994, pp. 271-276
22. Luqi, et al.: CAPS as Requirements Engineering Tool. Proc. RE and Analysis
Workshop, SEI, CMU, Pittsburgh, 1991 (http://wwwcaps.cs.nps.navy.mil)
23. N.A.M. Maiden, S. Minocha , K. Manning, M. Ryan: CREWS-SAVRE: Scenarios
for Acquiring and Validating Requirements. Proc. ICRE98, IEEE Press, 1998
24. B. Myers, S. E. Hudson, and R. Pausch: Past, Present, and Future of User Interface
Software Tools. ACM Transactions on Computer-Human Interaction, Vol. 7, No. 1,
March 2000, pp. 3-28
25. B. Nuseibeh, S. Easterbrook: Requirements Engineering: A Roadmap. ICSE-18,
The Future of Software Engineering, Limerick, Ireland, 2000, pp. 35-46
26. Object Managment Group: Unified Modeling Language Specification. Version 1.3,
OMG, June 1999
27. A. Ravid, D. M. Berry: A Method for Extracting and Stating Software Require-
ments that a User Interface Prototype Contains. Requirements Eng 5 (2000) 4, pp.
225-241
28. J. Rogotzki: Generating Domain-Data from GeoOOA-Models. Diploma thesis,
Dept. of CS, FernUniversität Hagen, 1997 (in German)
29. M. B. Rosson, J. M. Carroll: Narrowing the Specification-Implementation Gap in
Scenario Based Design. Chapter 10 in [7].
30. K. Schneider: Prototypes as assets, not toys: why and how to extract knowledge
from prototypes. Proc. ICSE 18, 1996, pp. 522 - 531
31. Y. V. Srinivas, J. L. McDonald: The Architecture of Specware, a Formal Software
Development System. Kestrel Institute Technical Report KES.U.96.7, August 1996
32. W3C: Handheld Device Markup Language Specification. May 1997
http://www.w3.org/pub/WWW/TR/NOTE-Submission-HDML-spec.html
33. WAP-Forum: Wireless Markup Language Specification. WAP-191, June 2000,
http://www.wapforum.org
34. Weidenhaupt K, Pohl K, Jarke M, Haumer P. Scenarios in System Development:
Current Practice. IEEE Software, March/April 1998, pp 34-45