PRAGMATICS OF STORYBOARDING

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

Keywords:

Pragmatics, Web information system, Information portfolio, Utilisation portfolio.

Abstract:

A Web Information System (WIS) can be described by a storyboard, which on a high level of abstraction spec-

iﬁes 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.

1 INTRODUCTION

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 speciﬁc 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

speciﬁes 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

deﬁned by roles that determine obligations and

rights, and user proﬁles determining preferences,

and

• 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

ing process in (Harel Marelly, 2003). They generalise

business use cases as in (Robertson Robertson, 2006).

User models that are speciﬁed by user and actor pro-

ﬁles, 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 identiﬁed 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 ﬁnds

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.

2 INFORMATION PORTFOLIOS

A WIS portfolio consists of an information portfolio

and a utilisation portfolio. They are mapped to con-

tent and functionality speciﬁcations, 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

Information

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

scene.

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

space.

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

space.

Each WIS user who enters the system with a par-

ticular goal has information needs that have to be

satisﬁed 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 deﬁnitely 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

PRAGMATICS







*

Technical environment

of the user

User

Data

representation

Data

Functions

Function

representation

Information









Story



*

Content





Functionality







*

Layout





Playout





Information

metaphors





Story and

functionality

metaphors

Web utilisation space

SYNTACTICS

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-

tor.

Information consumption and information pro-

duction of an actor for all scenes together deﬁne 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-

ing.

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 insufﬁcient for the task under consider-

ation, or the necessary information cannot be easily

derived from data that is currently available, or the

uncertainty, indeﬁniteness, 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 insufﬁcient knowledge to cope with gaps, uncer-

tainties or conﬂicts 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 deﬁning information consumption and

production for each scene of the story space as deﬁned

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 proﬁle.

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 deﬁnition 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 speciﬁc 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 speciﬁc utilisation requirements.

A persona is characterized by an expressivename,

profession, intents, technical equipment, behaviour,

skills and proﬁle, disabilities, and speciﬁc 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-

ﬁle. User models characterize proﬁles 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-

ror,

• speciﬁc observed behaviour including skill sets,

behavioural pattern, expertise and background,

and

• speciﬁc relationships, requirements, and expecta-

tions.

EXAMPLE 1. Let us consider an information service

of a city and focus on business people. For these we

develop the following speciﬁc portfolio:

User Proﬁle. 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-

ogy.

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 trafﬁc.

Content Requirements. The information demand

may be mapped to general city information, in-

formation on restaurants, trafﬁc, 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.

Speciﬁc 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-

ering.

Jack-of-all-trades can be exempliﬁed to be a spe-

ciﬁc 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

Speciﬁc Behaviour: resumes story also after hours

Speciﬁc Interactivity: works alone, with interrup-

tions, no time for concentrated reading, ﬁnal re-

sults expected

Proﬁle: middle level manager, Masters degree in

business and computer engineering, workoholic

(around 60 hours per week)

Portfolio: collection of travel details with conﬁrma-

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 conﬁrmation 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 speciﬁcation of personae has several

beneﬁts. They provide communication means within

the development team, focus on a speciﬁc target set

of actors, and help to make assumptions about the tar-

get audience. Thus, personae may augment the WIS

portfolio speciﬁcation, 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 speciﬁc 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

model.

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 speciﬁcation 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 identiﬁcation 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 ﬁrst collects all choices in a

basket and later conﬁrms those choices, which are the

most appropriate.

The information portfolio is also enhanced by in-

formation that depends on the WIS context. This

can deﬁne 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-speciﬁc

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/beneﬁt 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.

EXAMPLE 3. The

www.cottbus.de

WIS provides

information on hotels, booking services, etc. For the

decision, which information should be provided we

may use a classiﬁcation along usability and economic

perspective. We can then assign ﬁnal 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 reﬂects 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.

3 UTILISATION PORTFOLIOS

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 speciﬁc 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 proﬁles and the port-

folio of the users and actors. Furthermore, the actor

context must be taken into account. Therefore, we

ﬁrst 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 proﬁles, and their life cases.

Users are grouped to actors for which portfolios have

already been developed. Based on the portfolio and

the context speciﬁcation 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

knowledge.

Users U . Users of edutainment WISs are mainly

students, people seeking for continuous educa-

tion, workers in companies with a speciﬁc 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

material.

Thus, typical learning WIS brands take the

form Teacher

2Learner

, 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 proﬁle 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 ﬁelds 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-

quirements.

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 ﬁnd 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 speciﬁc piece

of information and to possess knowledge or infor-

mation about. It may also include to know how to

do something. Learners obtain ﬁrst-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 proﬁcient and skilled

in some area. This mastership is closely related to

practising and experimenting with the new knowl-

edge.

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 ﬁelds have a complex structure, which

leads to functions requiring other support functions

associated with related word ﬁelds such as discover,

ascertain, catch on, and determine. One difference

to the word ﬁelds for e-business is their iterative ap-

plication. The word ﬁelds 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 ﬁelds 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.

selection

of exercise

portfolio

reminding

background

hints

& tricks

discussion

of request &

explanation

answering

worksheet

evaluation

of results &

analysis

presentation

of solution

presentation

of collected

gradings

Figure 2: KoPra scenario for training with optional exer-

cises.

4 CONCLUSIONS

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

REFERENCES

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–

181.

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