Web Information Systems Portfolios
Klaus-Dieter Schewe
Information Science Research Centre, Palmerston North, New Zealand
Bernhard Thalheim
Institute of Computer Science, University of Kiel, Germany
Pragmatics, Web information system, Information portfolio, Utilisation portfolio.
A Web Information System (WIS) can be described by a storyboard, which on a high level of abstraction spec-
ifies who will be using the system, in which way and for which goals. Syntax and semantics of storyboarding
have been well-elaborated. Pragmatics is the necessary complement addressing what the storyboard means
for its users. The part of pragmatics concerned with usage analysis by means of life cases, user models and
contexts has been dealt with before. In this paper we complement usage analysis by WIS portfolios, which
comprise two parts: the information portfolio and the utilisation portfolio. The former one is concerned with
information consumed and produced by the WIS users, which leads to content chunks; the latter one captures
functionality requirements.
A Web Information System (WIS) is an information
system that can be accessed through the world-wide-
web. So far, many approaches to WIS conceptual
modelling have been developed, e.g. (Ceri et al.,
2003; De Troyer and Leune, 1998; Houben et al.,
2003; Lowe et al., 2002; Rossi et al., 1999; Schewe
Thalheim, 2005), most of which are centered around
content and navigation modelling, occasionally cou-
pled with specific requirements models.
In (Schewe Thalheim, 2005) we characterised a
WIS by strategic characteristics such as purpose, mis-
sion, intentions and ambience (more details in (Moritz
et al., 2005)), usage characteristics such as tasks,
users and stories, content and functionality character-
istics, context, and presentation, which leads to an ab-
straction layer model for WIS development. Central
to this approach to WIS development is the method
of storyboarding, which on a high level of abstraction
specifies who will be using the system, in which way
and for which goals. In a nutshell, a storyboard con-
sists of three parts:
a set of tasks that are associated with goals the
users may have,
a set of actors, i.e. abstractions of user groups
defined by roles that determine obligations and
rights, and user profiles determining preferences,
a story space, which itself consists of a hierar-
chy of scenarios describing scenes and actions,
and is accompanied by a plot describing the ac-
tion scheme.
Syntax and semantics of storyboarding including
customisation to preferences have been well elabo-
rated in (Schewe Thalheim, 2005; Schewe Thalheim,
2007a; Schewe et al., 2009). However, in order to
link storyboarding to the systems requirements and to
provide guidelines and means to derive the complex
storyboards from informal ideas about a WIS with-
out any technical bias, this has to be complemented
by pragmatics, which according to (Webster, 1991) is
the “balance between principles and practical usage”.
In (Schewe Thalheim, 2007b) we addressed the
pragmatics of storyboarding focusing on usage anal-
ysis. Based on intentions we investigaed life cases,
user models and contexts. Life cases, capture ob-
servations of user behaviour in reality, and can be
used in a pragmatic way to specify the story space.
Life cases have already been envisioned in (Carroll,
2004) and integrated into the entire software engineer-
Schewe K. and Thalheim B.
PRAGMATICS OF STORYBOARDING - Web Information Systems Portfolios.
DOI: 10.5220/0002800400400047
In Proceedings of the 6th International Conference on Web Information Systems and Technology (WEBIST 2010), page
ISBN: 978-989-674-025-2
2010 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
ing process in (Harel Marelly, 2003). They generalise
business use cases as in (Robertson Robertson, 2006).
User models that are specified by user and actor pro-
files, and actor portfolios.They are used to get a better
understanding of the tasks associated with the WIS,
and the goals of users. Goals have been identified as
a crucial component of requirements engineering in
(Giorgini et al., 2002). Task descriptions are also used
in participatory design, e.g. in (Carroll, 2004; Kens-
ing Blomberg, 1998; O’Neill Johnson, 2004). Con-
texts characterise the situation, in which a user finds
himself at a certain time in a particular location. For
WISs we must handle different kinds of contexts and
analyse the way they impact on life cases, user models
and the storyboard.
In this paper we extend our work on WIS prag-
matics focusing on WIS portfolios, which address the
pragmatics associated with content and functionality.
We distinguish between information as processed by
humans and data as its carrier that is perceived or
noticed, selected and organized by its receiver. Con-
tent is complex and ready-to-use data, and may be en-
hanced by concepts that specify the semantic meaning
of content objects, and topics that specify the prag-
matic understanding of users.
Thus, information is directed towards pragmatics,
whereas content may be considered to highlight the
syntactical dimension. If content is enhanced by con-
cepts and topics, then users are able to capture the
meaning and the utilisation of the data they receive.
Analogously, functionality refers to functions offered
by the system, thus highlists the dynamic aspects of
the syntactic dimension, whereas utilisation is linked
to the stories supporting users’ life cases, thus is di-
rected towards pragmatics. This distinction is illus-
trated in Figure 1.
Accordingly, a WIS portfolio consists of two
parts: the information portfolio and the utilisation
portfolio. The former one is concerned with informa-
tion consumed and produced by the WIS users, which
leads to content chunks. We will elaborate on this in
Section 2. The latter one captures functionality re-
quirements. We will elaborate on this in Section 3
focusing on utilisation portfolios for learning WISs.
A WIS portfolio consists of an information portfolio
and a utilisation portfolio. They are mapped to con-
tent and functionality specifications, respectively. In
doing so we distinguish between content provided by
the WIS and information, which is related to an actor
or user.
2.1 Consumption and Production of
Following (Schewe Thalheim, 2005) on a high level
of abstraction we may think of a WIS as a set of ab-
stract locations, which abstract from actual pages. A
user navigates between these locations, and on this
navigation path s/he executes a number of actions. We
regard a location together with local actions, i.e. ac-
tions that do not change the location, as a unit called
Then a WIS can be described by an edge-labelled
directed multi-graph, in which the vertices represent
the scenes, and the edges represent transitions be-
tween scenes. Each such transition may be labelled
by an action executed by the user. If such a label is
missing, the transition is due to a simple navigation
link. The whole multi-graph is then called the story
A story is a path in the story space. It tells what
a user of a particular type might do with the system.
The combination of different stories to a subgraph of
the story space can be used to describe a “typical”
use of the WIS for a particular task. Therefore, we
call such a subgraph a scenario. Usually storyboard-
ing starts with modelling scenarios instead of stories,
coupled by the integration of scenarios to the story
Each WIS user who enters the system with a par-
ticular goal has information needs that have to be
satisfied by the system. In addition, an active WIS
will also request information from its users. We use
the term information consumption for the information
provided by the system to its users, and information
production for the information entered by a user into
the system.
When a user enters the WIS, the information
needs are usually not known in advance. Part of the
needed information may depend on other parts, on
decisions made while navigating through the WIS,
and even on the information provided by the actor
him/herself. That is, the information consumption
and production depends on the path through the WIS,
i.e. in our terminology on the story. Therefore, in-
formation consumption and production is associated
with each scene of the story space. Assuming that
there is a database for the data content of the WIS
with database schema S , information consumption on
a scene s definitely accounts for a view V
over S .
That is, we have another schema S
and a computable
transformation from databases over S to databases
over S
. Such a transformation is usually expressed
by a query q
With each scene s we associate a view V
PRAGMATICS OF STORYBOARDING - Web Information Systems Portfolios
Technical environment
of the user
Story and
Web utilisation space
Figure 1: The Web Utilization Space Based On the Characteristics of WIS.
, q
) called information consumption view.
Elements of q
(db) for some database db repre-
sent the information consumption of an actor.
With each action α we associate a data type t
called information production type. Values of type
represent the information production by an ac-
Information consumption and information pro-
duction of an actor for all scenes together define the
information portfolio of the actor.
2.2 Information Need and Demand
We distinguish between the information need and the
information demand. The former one refers to a per-
ceived lack of something desirable or useful, while
the latter one results from an act of demanding or ask-
The information need is generally related to ob-
jectives such as becoming informed. It is based on
the intuitive insight that the current information and
knowledge is insufficient for the task under consider-
ation, or the necessary information cannot be easily
derived from data that is currently available, or the
uncertainty, indefiniteness, fuzziness, and contradic-
tions do not permit drawing conclusions.
The information need can be considered to be sub-
jective, but at the same time it can be the reason for
a certain user visiting a website without an intention
that is related to a life case. The information need
is based on the conceptual incongruity in which a
user’s cognitivestructure is not adequate to a task, e.g.
when a user recognizes that something wrong in their
state of knowledge and desires to resolve the anomaly,
when the current state of knowledge is less than what
is needed, when internal sense runs out, or when there
is insufficient knowledge to cope with gaps, uncer-
tainties or conflicts in a knowledge area. Therefore, as
the behaviour of actors is mainly related to life cases
and the portfolio, we have to distinguish between in-
formation provided for support of life cases and auxil-
iary consumed information that is provided to visitors
as a service.
The information demand is related to the portfolio
under consideration and to the intents. We may dis-
tinguish between information that is necessary, desir-
able, or feasible. The information demand is mapped
to the views defining information consumption and
production for each scene of the story space as defined
above. The information demand is characterised by
information that is missing, unknown, necessary for
task completion, and directly requested.
We can distinguish between the information de-
mand of an actor and the information demand of a
user. As actors represent groups of users, the infor-
mation demand of a user contains the information de-
mand of an actor. While the information demand of
actors is determined by the portfolio, the additional
information demand of a user is determined by the
user profile.
2.3 The Concept of Persona
The information demand is used to derive the infor-
mation consumption of each user. This is related to
the definition and meaning of information for the user
based on received/ requested data, which has to be or-
ganized, interpreted, understood, and integrated into
his/her knowledge. In general, this would require to
model the user, the specific request of the user, the
ability to understand the data, and the skills, which
is infeasible. However, as the information demand of
actors is a subset of the one of users represented by
the actor, we can use prototypes of individuals called
personae to determine the information demand. In
addition, we model a task-oriented life case of these
WEBIST 2010 - 6th International Conference on Web Information Systems and Technologies
individuals, and derive the information demand, data
requirement, and the specific utilisation requirements.
A persona is characterized by an expressivename,
profession, intents, technical equipment, behaviour,
skills and profile, disabilities, and specific properties
such as hobbies and habits. A persona is a typical in-
dividual created to describe the typical user based on
the life cases, the context, the portfolio, and the pro-
file. User models characterize profiles for education,
work, and personality. This characterization can be
extended by
identity with name, pictures, etc.,
personal characteristics such as age, gender, loca-
tion, and socio-economic status,
characterization of reaction to possible users er-
specific observed behaviour including skill sets,
behavioural pattern, expertise and background,
specific relationships, requirements, and expecta-
EXAMPLE 1. Let us consider an information service
of a city and focus on business people. For these we
develop the following specific portfolio:
User Profile. Jack-of-all-trades is a business man.
He intends to visit the city through a short-term
visit. He is interested in culture and history. He
likes short distances and 4-star or better hotels. He
is usually in a hurry. He likes good dining and
talking. Additionally, he is familiar with technol-
Intention and Information Demand. Jack-of-all-
trades visits the information site for business trip
preparation. His information demand includes
hotel information, spare time information for the
evenings, and information on the central traffic.
Content Requirements. The information demand
may be mapped to general city information, in-
formation on restaurants, traffic, culture, busi-
ness clubs, and good dining addresses. There-
fore, the information consumption of Jack-of-all-
trades must be supported by the corresponding
databases. At the same time, Jack-of-all-tradesre-
quires a handy booking service.
Life Case. The life case we envision includes a brief
survey on the city including places to see, the se-
lection of a convenient hotel, a survey of events
of interest, the booking procedure for events, a
search for good dining places, and some informa-
tion what else to see and whom to talk to.
Specific Utilisation. The collection of data is similar
to a basket collection. Jack-of-all-trades prefers
shallow navigation and fast search. He is also in-
terested in highlights for the period he is consid-
Jack-of-all-trades can be exemplified to be a spe-
cific persona:
Personal: name: Bernhard Karlowics, age: 48, male,
married, lives in northern Germany, profession:
business assistant, income: around Euro50.000
per year
Robustness: errors are not taken as own errors,
download time is critical
Kind of User: kind but pretentious, makes quick de-
cisions, interested in history, culture, classical
musics, usually in a hurry
Specific Behaviour: resumes story also after hours
Specific Interactivity: works alone, with interrup-
tions, no time for concentrated reading, final re-
sults expected
Profile: middle level manager, Masters degree in
business and computer engineering, workoholic
(around 60 hours per week)
Portfolio: collection of travel details with confirma-
tion and payment, prefers hotels with four-stars
or higher, checking through direct connection to
booking services
Life Case: preparing for travel, single use of the sys-
tem, email confirmation necessary, spare time in-
formation, events of interest, dining places, busi-
ness clubs
Context: business environment, typically client-
server computers at workplace, occasionally mo-
bile phone for contact while on the move
The explicit specification of personae has several
benefits. They provide communication means within
the development team, focus on a specific target set
of actors, and help to make assumptions about the tar-
get audience. Thus, personae may augment the WIS
portfolio specification, but should not be overused.
2.4 Content Chunks
In order to model the information portfolio we collect
the information demand of all actors we would like to
support. In addition, we can include some specific in-
formation demand of users matching with the groups
of users. This information demand can be combined
into a single content chunk that is demanded by all
actors of similar steps in the life case. This informa-
tion demand can later be modelled within a database
PRAGMATICS OF STORYBOARDING - Web Information Systems Portfolios
This combination turns around the viewpoint we
have taken so far. We try to envision which content
is necessary for which actors or users. We may start
with the intention why an actor may demand a given
content. The content-centered view allows us to de-
rive a specification of steps in which a certain chunk
of content is requested.
The content-centered analysis is used during
brainstorming sessions in which we try to derive sce-
narios, intentions, and the information need of users.
At the same time we can derive the service kind, util-
isation, actors, presentation, content, and functions
supporting this content. We can also derive directly
the intersection among the content chunks, which pro-
vides a basis for the development of queries to extract
the content demanded from the WIS.
Content chunks are arranged within content-
extended scenarios, in which each scene is associated
with a content chunk. This content chunk combines
the consumption of actors, auxiliary content that is
provided for the support of users, and the content that
is additionally provided due to the intentions of the
WIS providerand the context of the current scene. We
further enhance this scenario by data that is produced
by the actor or that stems from the environment.
EXAMPLE 2. Let us continue Example 1 and con-
sider the booking scene. If the actor has decided to
choose a particular hotel, then we may associate with
the choice action the selection of an identification for
the hotel, which extends the booking scene with the
content that provides information to the actor on ho-
tels. With the choice of a hotel the actor leaves this
scene and produces the selection data. In the next
scene the actor can be asked about the payment.
The same scene can also be used in a different sce-
nario, in which the actor first collects all choices in a
basket and later confirms those choices, which are the
most appropriate.
The information portfolio is also enhanced by in-
formation that depends on the WIS context. This
can define content associated with control, which nor-
mally is internal to the WIS and not accessible by ap-
plications, content that is used to determine the tran-
sitions and to control the WIS context, e.g. for the
pre- and post-scene conditions, transition conditions
depending on the databases used, or assignment for
collaborating actors, etc., content that might be useful
as reference, e.g. meta-information on time, responsi-
bility, and links to other WISs, or application-specific
data that is not accessible by the WIS.
The content set required for each step in a life case
may become too large. So we must prioritise the de-
velopment of content chunks. There are two perspec-
tive for prioritising:
In the usability perspective we evaluate the impact
the content has for the the WIS portfolio. The im-
pact is based on the occurrence the content has
in steps and activities and on the number of ac-
tors requiring this content. The impact is high if
the majority of users need it frequently or cannot
continue their work if the content is missing.
In the economic perspective we evaluate the
cost/benefit relation. Since projects have limited
budget, contract commitments, resource restric-
tions, technologicalconstraints, marketplace pres-
sures, and deadlines we must limit the efforts.
We may classify those content chunks which have
high impact into strategic, high value, targeted
and luxuries.
WIS provides
information on hotels, booking services, etc. For the
decision, which information should be provided we
may use a classification along usability and economic
perspective. We can then assign final decisions to the
evaluation such as approved (
), under review (),
and rejected (6 ). In a similar way we may evaluate
all content chunks we discovered. The evaluation is
used for deciding which content is to be developed
and to which extent.
Content chunks are often composed only of data,
i.e. they relate to media objects on the conceptual
model (Schewe Thalheim, 2005). The description of
the data is based media types, viewpoints, and adapta-
tion facilities. Content is also based on semantics, i.e.
associated concepts capturing basic pieces of knowl-
edge or their annotations, and restricted by pre- and
postconditions. Content must also be annotated using
a commonly agreed vocabulary or a dictionary. This
agreement is bound to actors or communities. We de-
note items of dictionaries by topics. The pragmatics
also reflects the context of potential usage. As content
is often used in a form that combines content chunks
with other content chunks we also specify related con-
tent chunks.
The second constituent of the WIS portfolio is the
utilisation portfolio, which can be considered to be a
collection of requirements for functionality and WIS
utilisation in general. It describes the intentions of the
users, their goals, their context, and their specific re-
quirements, and as such is based on the life cases that
WEBIST 2010 - 6th International Conference on Web Information Systems and Technologies
were modelled before, and the profiles and the port-
folio of the users and actors. Furthermore, the actor
context must be taken into account. Therefore, we
first discuss the utilisation portfolio and then derive
its impact on the functionality required by the user.
The utilisation portfolio combines the actor or
user perspective to the WIS. We already know in-
tentions of users, their profiles, and their life cases.
Users are grouped to actors for which portfolios have
already been developed. Based on the portfolio and
the context specification life cases were extended.
The WIS utilisation portfolio cannot be described
in general for all different categories of WIS such as
e-business, learning and edutainment, communities,
etc., though these categories are mixed in real appli-
cations. The separation into categories eases, how-
ever, the description of the WIS utilisation portfolio.
In the following we will describe the development of
the WIS utilisation portfolio for learning WISs.
A large number of WISs provide learning and edu-
tainment services. Examples of technology-supported
learning include computer-based training systems, in-
teractive learning environments, intelligent computer-
aided instruction systems, distance learning systems,
and collaborative learning environments. The general
brand P
of a WIS (Moritz et al., 2005) has to
be specialised for edutainment WISs:
Provider P . For the time being providers are mainly
educational institutions or educational communi-
ties. Then the provider plays the role of a teacher.
Product W . Since control and assessment of learn-
ing progress is a still unsolved issue and appro-
priate presentation of complex information is of-
ten not feasible, edutainment WISs concentrate on
easy-to-understand information or easy-to-grasp
Users U . Users of edutainment WISs are mainly
students, people seeking for continuous educa-
tion, workers in companies with a specific portfo-
lio, people interested in auxiliary information, or
groups of such users. The main behavior of such
users is characterised by the role of the learner.
Activities A . Activities are mainly centered around
learning, searching for content, collecting content,
and solving exercises. Activities also include to
ask questions, to act in teams for problem solving,
and to discuss issues associated with the learning
Thus, typical learning WIS brands take the
form Teacher
, where W stands for
content chunks or knowledge, and A can be one of
{receive, respond, solve in teams,raise questions,
possibly apply}, {learn, validate, control, advice},
{recognise, listen, work on it, solve exercises,
ask urgent questions}, {discuss, get feedback,
work on it}, etc.
Edutainment WIS are currently mainly or ex-
clusively supporting student actors. Students ob-
tain knowledge through teachers, their schedules, and
their abilities; they need guidance, motivation, and
control. The behaviour of actors may, however,
be more complex, in particular in case of learning
groups, in which the collaboration of students de-
pends on a cooperation profile with rights and obli-
gations. Communication partners exchange content,
discuss and resolve questions, seek for hints or for
better understanding, supporting and motivating part-
ners are users with control, motivation and supporting
functions. Furthermore, teachers have various obliga-
tions and rights, and are involved in a variety of roles.
In order to derive the utilisation portfolio we anal-
yse the word fields associated with common verbs
in the learning context such as learn, know, master,
study and nouns such as skill. This gives rise to sto-
ries and consequently determines the functionality re-
Learn. Learning is a very complex activity that in-
cludes gaining knowledge, understanding, obtain-
ing skills, etc. by studying, instruction or expe-
rience. In addition, learning is associated with
memorizing, being able to perform some task,
and to know this ability. Learning is based on
obtaining content, discovering the concepts be-
hind them, annotation, ordering, and integration.
Learning is associated with the role of a learner or
student, who are usually supported by other actors
who teach and instruct. Learners determine con-
tent with certainty, usually by making an inquiry
or other effort. They check the content to find out
whether it is useful or whether additional content
is needed.
Know. As learning aims at improving skills, abilities,
and knowledge, the improvement should be mea-
surable and learning success examined. Knowing
means to be cognizant of a fact or a specific piece
of information and to possess knowledge or infor-
mation about. It may also include to know how to
do something. Learners obtain first-hand knowl-
edge of states, situations, emotions, or sensations,
and the change in knowledgeis acknowledged and
recognized by other actors.
Master. Learning usually intends to enable master-
ing problems and to become proficient and skilled
in some area. This mastership is closely related to
practising and experimenting with the new knowl-
PRAGMATICS OF STORYBOARDING - Web Information Systems Portfolios
Study. Studying refers to the activities associated
with learning, i.e. reading learning content, excer-
cising, checking, examining, inspecting, survey-
ing, etc. Therefore, the presentation of the learn-
ing material and the storyboard are essential. Fur-
thermore, learners need to mind, perpend, think
(out or over), and weigh, which requires time and
workplaces. Studying can be performed by one-
self without any teacher, supporter, or observer.
Skill. Skills are abilities that have been acquired by
training, e.g. abilities to produce solutions to
some problems. A learner is trained until s/he ob-
tains these skills.
These word fields have a complex structure, which
leads to functions requiring other support functions
associated with related word fields such as discover,
ascertain, catch on, and determine. One difference
to the word fields for e-business is their iterative ap-
plication. The word fields are extended by the learn-
ing style to be supported. The three different learn-
ing styles sequenced or blended learning, interac-
tive learning, and group learning – result in rather dif-
ferent scenarios. So far, only sequenced learning ap-
proaches have received the necessary theoretical ba-
sis in pedagogical research and didactics. Interactive
learning is still an open research issue.
EXAMPLE 4 . The KOPRA project within the Ger-
man University Notebook Initiative was aiming at the
support of adaptive and collaborative learning, focus-
ing on practical training in database programming.
The system is supporting communication and inter-
action of learners, organization and coordination of
collaborating communities, free access to material de-
pending on the progress, roles and portfolios of part-
ners, and the stepwise development of training mate-
rial. Learners act in a collaborative setting depending
on their needs and the goals of the learning program.
The analysis of the word fields above highlighted
the utilisation of importance of exercising of crucial
part of the WIS. While often only multiple-choice ex-
ercises are supported, complex exercises have a more
complex pattern. Figure 2 shows the derived scenario
for exercise training for this case. Learners are al-
lowed to choose either their own data or data provided
by the system. Learners may also choose an algorithm
that can be used for solving the exercise.
of exercise
& tricks
of request &
of results &
of solution
of collected
Figure 2: KoPra scenario for training with optional exer-
In this paper we extended our previous work on prag-
matics of Web Information Systems. We introduced
WIS portfolios, which are composed of an informa-
tion portfolio and a utilisation portfolio. The informa-
tion portfolio captures information consumption and
production by users in the scenes of the story space.
This is linked to the information needed by a user to
understand the task and the information demand to
perform the appropriate action. Modelling informa-
tion demand of all potential users is infeasible, but
the concept of persona permits to deal with prototyp-
ical users instead. The integration of information de-
mands leads to content chunks.
Likewise, the utilisation portfolio consists of tasks
users might wish to accomplish within the system,
and goals they want to achieve by this. It can be con-
sidered as the necessary means for collecting func-
tionality requirements. Different from the informa-
tion portfolio the utilisation portfolio depends on the
application category. Here we focused on the cate-
gory of learning WISs.
WIS portfolios complete the research on WIS
pragmatics, which is an independing connector ele-
ment between systems requirements and conceptual
models. In this paper, due to space limitations we
had to omit many details, which are reported in an
extended journal version (Schewe Thalheim, 2010).
Carroll, J. M. 2004. Participatory design of community in-
formation systems - the designer as bard, in COOP’,
pp. 1–6.
Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai,
S. Matera, M. 2003. Designing Data-Intensive Web
Applications, Morgan Kaufmann, San Francisco.
WEBIST 2010 - 6th International Conference on Web Information Systems and Technologies
De Troyer, O. Leune, C. 1998. WSDM: A user-centered
design method for web sites, in ‘Computer Networks
and ISDN Systems – Proc. 7th Intern. WWW Confer-
ence’, Elsevier, pp. 85–94.
Giorgini, P., Mylopoulos, J., Nicchiarelli, E. Sebastiani, R.
2002. Reasoning with goal models, in ‘ER’, pp. 167–
Harel, D. Marelly, R. 2003. Come, Let’s play: Scenario-
based programming using LSCs and the play-engine,
Springer, Berlin.
Houben, G.-J., Barna, P., Frasincar, F. Vdovjak, R. 2003.
HERA: Development of semantic web information
systems, in ‘Third International Conference on Web
Engineering ICWE 2003’, Vol. 2722 of LNCS,
Springer-Verlag, pp. 529–538.
Kensing, F. Blomberg, J. 1998. ‘Participatory design: Is-
sues and concerns’, Computer Supported Cooperative
Work 7(3/4), 167–185.
Lowe, D., Henderson-Sellers, B. Gu, A. 2002. Web exten-
sions to UML: Using the MVC triad, in ‘Conceptual
Modeling ER 2002’, Vol. 2503 of LNCS, Springer-
Verlag, pp. 105–119.
Moritz, T., Schewe, K.-D. Thalheim, B. 2005. ‘Strategic
modelling of web information systems’, International
Journal on Web Information Systems 1(4), 77–94.
O’Neill, E. Johnson, P. 2004. Participatory task modelling:
users and developers modelling users’ tasks and do-
mains, in ‘TAMODIA’, pp. 67–74.
Robertson, J. Robertson, S. 2006. Requirements-Led
Project Process, Addison-Wesley.
Rossi, G., Schwabe, D. Lyardet, F. 1999. Web application
models are more than conceptual models, in P. Chen
et al., eds, Advances in Conceptual Modeling’, Vol.
1727 of LNCS, Springer-Verlag, Berlin, pp. 239–252.
Schewe, K.-D. Thalheim, B. 2005. ‘Conceptual modelling
of web information systems’, Data and Knowledge
Engineering 54(2), 147–188.
Schewe, K.-D. Thalheim, B. 2007. a , ‘Personalisation of
web information systems - a term rewriting approach’,
Data and Knowledge Engineering 62(1), 101–117.
Schewe, K.-D. Thalheim, B. 2007. b , ‘Pragmatics of sto-
ryboarding for web information systems: Usage anal-
ysis’, International Journal of Web and Grid Services
3(2), 128–169.
Schewe, K.-D. Thalheim, B. 2010. ‘Pragmatics of web in-
formation systems - information and utilisation port-
folios’. submitted for publication.
Schewe, K.-D., Thalheim, B. Wang, Q. 2009. ‘Customis-
ing web information systems according to user prefer-
ences’, World Wide Web 12(1), 27–50.
Webster 1991. ‘Webster’s ninth new collegiate dictionary’.
PRAGMATICS OF STORYBOARDING - Web Information Systems Portfolios