A Method and Tool for Wide Audience Requirements Elicitation and Rapid

Prototyping for Mobile Systems

Matti Rossi, Tuure Tuunanen

Helsinki School of Economics, Information Systems Science, Po Box 1210, FIN-00101, Helsinki, Finland
{mrossi, tuure.tuunanen}@hse.fi

Abstract. In recent years, consumer oriented information systems development has become increasingly
important matter, as more and more complex information systems are targeted towards consumer markets. We
argue that developing IS for non-organizational users creates new problems, which IS and requirement
engineering (RE) community should attend to. First of all, the elicitation of requirements becomes more difficult
as usually consumers do not explicitly know what they want, and it is difficult for them to express their ideas. To
support different views of product development, project management and design, the method should present
requirements in a ‘rich enough’ way to avoid overloading management, but in the same time giving designers the
detailed information they need. Furthermore, to facilitate iterative requirements development the method should
allow for rapid development of prototypes from designs. To support these goals we have constructed an enhanced
requirements elicitation and mobile system construction method and its support environment within Metaedit+
Meta CASE tool. We based our method on Critical Success Chains (CSC) method, which supports top-down
approach for planning, but also provides for wide participation of IS customers to get rich information. CSC
aggregates the results of many individual interviews into meaningful graphical models of what is critically
important about a potential system. In our work, CSC is extended with customer segmentation and lead user
concepts from marketing. The high level results of CSC are turned into mobile applications running in Symbian
platform by using a novel domain specific method that supports generation of executable environments from
specifications.

Introduction

We argue that the traditional views of requirement engineering process and methods do not live up to the challenge
that the information systems engineering community is facing when dealing with the development of software and
embedded products for mass market audiences. Examples of these new types of software are applications for palm
top devices, Java powered phones, and JAVA enabled Digital TV sets. The companies developing systems for these
platforms have been up against the fact that many novel innovations that look good on tests do not win the
acceptance of customers.
The received view (e.g. [1, 2]) believes that requirements are out there to be gathered by the requirements engineers,
and firms have used managers and engineers as proxies for end-users to develop applications without knowing what
the customers want or are willing to pay for [3]. The problem has been that people have thought they only have to
find the right informants and use the right techniques to achieve the complete specification. Researchers [1, 2] have
seen that by selecting and prioritizing the requirements into usable sets an agreement can be reached on the common
goal.
In contrast, we present a view that often the end-users cannot express their needs [4], and as the end-users are
scattered and outside the traditional information systems development (ISD) environment, a single organization, it is
not a trivial task to reach them in the first place. Hence, questions should be raised and more focus placed on who
should actually be the participant in an ISD project. We argue that new methods are needed to elicit the hidden
needs of users of information systems that are targeted at a very wide audience of end-users, such as consumers. As
many of these systems do not exist currently, we should also consider how to extract requirements and relationships
that are not historical. In addition, we argue that these goals and specifications should then be expressed in a semi-
formal language that is accessible for both end-users and business representatives. We see this as critical for
integrating the more sophisticated elicitation methods with the traditional development process. Furthermore we
support believe that rapid prototyping using domain specific modeling languages supports refinement of the RE
results. We have constructed an environment for generating new services for Symbian Series 60 mobile platform,
which can be used to develop new service sketches based on user requirements.
In this paper, we seek to achieve these goals with a method engineering approach by applying a method engineering
tool. We present a method model that supports a cognitive elicitation method, critical success chains (CSC), used in
Information Systems Planning, supported by the MetaEdit+ CASE tool. In the next section, we define method
engineering and then create a Meta model of the CSC method. After this, we present a method construct based on
the research done earlier on the CSC method. Finally, we discuss the possibilities of the constructed integrated
environment and identify possibilities for further research.

Wide Audience Requirements Engineering

Within the Software Engineering (SE) literature, Requirements Engineering (RE) has been focusing on the issues
surrounding the problems in eliciting and managing the changing requirements (e.g. [5]). Requirements are
generally specified as something that the product must do, or something that it should achieve when considering
quality [6]. However, if considered from the information systems viewpoint requirements can also be defined as
descriptions of how the system should behave (i.e. application domain information, constraints on the system’s
operation, or specifications of a system property or attribute) [2]. In RE, the requirements elicitation has usually
been done at the beginning of the SE process, or continuously during the process as is done in spiral development
approaches (for example [7]).
Most of the current RE approaches assume that the users are known, and therefore the requirements can be elicited
from them, using some predefined semi-formal methods. However, in the case of new product development for wide
audience end-users this is not so [8]. Wide audience end-users have been defined as a group of end-users that are
primarily external to the organization developing the information systems (IS). These external end-users can be
consumers, as in the case of the JAVA example described previously or web applications. This leads to problems in
committing the end-users to participation in development and, more importantly, actually finding the end-users for
the developed system. For systems like these, the traditional tools and techniques offered by SE and RE
communities are not suitable, as in many cases we do not even have ways of getting at the users’ opinions.
Researchers have realized that meeting consumers’ demands is different than when developing an information
system for an organization. They have pointed out that prioritization of requirements, continuous improvement of
requirements, and a short period of time-to-market are vital [9]. However, RE has not been dealing heavily yet with
consumer oriented products and eliciting information for these projects. These projects can easily involve something
that the end-user has not even thought of being possible, like the ability to download JAVA applications to mobile
phones and Digital TV sets. Some of the research on Commercial-of-the-Self (COTS) processes and market driven
requirements determination deals with closely related areas, but it makes stringent assumptions about the availability
of the end-users and the possibility of a relatively linear RE process. However, as Orlikowski [4] has pointed out,
when the products are taken into use, they are reinterpreted and innovatively applied by end-users in ways not
envisioned by the developers (an example of this is SMS messages, which were intended as operator messages for
end users).
Pohl’s [1] model of three dimensions of requirements engineering has been considered a good way of structuring the
RE process, and we also choose his approach as the main base construction of our method. The first dimension is
specification. We prefer the term “elicitation” to “specification”, to avoid the suggestion that requirements are out
there to be collected simply by asking the right questions [10]. The elicitation methods used are mostly unstructured,
such as brainstorming, open interviews and document inspection [11]. We suggest a structured cognitive method,
i.e. critical success chains [12], for elicitation of the requirements of wide audience end-users [8]. However, critical
success chains is not argued to be superior compared to other methods in the field [12], but like researchers [8, 13,
14] have described laddering shows great potential. The Representation dimension presents the gathered
requirements, using some form of either diagrammatical notation or natural language prose. In this dimension, the
important issues are such as the ease of understanding of the representation, its compactness etc. To these demands,
we present an answer by means of rich presentation of end-users needs [15] and organizing them with a CASE tool
in a structured way. The third dimension, the agreement, in turn deals with the issue of reaching a common vision,
or agreement on the key requirements and the goals of the system. We suggest a preliminary solution for the
agreement dimension, by using the concepts of CSC to communicate the requirements to different stakeholders, but
at the same time managing the evitable chaos of the changing requirements with a CASE tool. In the next section,
we develop an integrated support environment for the method within the MetaEdit+ tool.

Method Engineering

Method engineering provides methods and processes to specify, make explicit, codify, and communicate method
knowledge as well as technical tools to enact such processes effectively. In order to model IS development methods
we need a set of concepts during ME that can capture the content and form of any development method into a meta-
model. In its simplest form, a meta-model is a conceptual model of a development method [16]. Consequently, meta-
modeling can be defined as a modeling process, which takes place on one level of abstraction and logic higher than
the primary modeling process [17].

Figure 1 The data flow diagram of method engineering process [18]

During method construction, a meta-model is specified which makes method knowledge explicit. Meta-models,
thus, provide a mechanism to collect and organize development experience. For the analysis step, meta-models
allow the detection of those parts of the method, which are subject to further analysis.
The data flow diagram, figure 1, shows the major steps of ME. These steps deal with gathering experiences,
analyzing method use, and refining a method. They form an iterative cycle in which method improvements can take
place. Method selection is the process, where high-level decisions about methods are made. It deals with selecting
an appropriate method for each IS development situation or project (more in [19]). During method construction, a
meta-model is specified which makes method knowledge explicit. Meta-models, thus, provide a mechanism to
collect and organize development experience. For the analysis step, meta-models allow the detection of those parts
of the method, which are subject to further analysis. Like in method construction, alternative method refinements
can be carried out and compared by using the meta-modeling constructs.

3.1. Method Engineering Environment

MetaEdit+ is a customizable CASE environment that supports both CASE and metaCASE functionality for multiple
users within the same environment. It supports and integrates multiple methods and includes multiple editing tools
for diagrams, matrices and tables. Architecture of MetaEdit+ is a client-server environment with the server
containing a central meta-engine and object repository and various modeling tools (diagramming, matrix etc.)
working as clients. The repository is implemented as a database running in a central server: clients communicate
only through shared data and state in the server. All information in MetaEdit+ is stored in the Object Repository,
including methods, diagrams, objects, properties, and even font selections. The adoption of full object orientation
enables flexible organization and reuse of software components in the environment and a high level of
interoperability between tools.
The core conceptual types of a method are defined at the repository level and can be modified by the method
developers. Method engineers can change components of a method specification even while system developers are
working with older versions of the method. The method can be developed and simultaneously tested in method
engineers’ workstation much in the same way as described in [20]. The data continuity, (i.e. that specification data
remains usable even after method schema changes), is confirmed by a number of checks and limitations to the
method evolution possibilities. The idea is that the user can always be guaranteed data continuity while working
with partial methods.

Construction of the Method

We begin the task of engineering the enhanced method by first choosing the specification language and process.
Various methods have been used and are used for the elicitation and text books often mention interviews, scenario
analysis, use-cases, Soft Systems Methods, observation and social analysis, ethnographic analysis, requirements
reuse, and prototyping. The number of techniques and methods developed for this is almost unlimited and Lauesen
[21] describes nineteen different ones. Nuseibeh and Easterbrook [22] have taken a more structured approach and
they have developed a classification of methods, which divides them in six metagroups: 1) traditional techniques; 2)
group elicitation; 3) prototyping, model-driven techniques; 4) cognitive techniques; 5) contextual techniques. For
our paper, we have chosen a cognitive elicitation method.
The selected conceptual structure and process, critical success chains (CSC), originates from Information
Systems Science and was developed by [15, 23]. The general process of using the CSC is described later in table 2
when we provide a step-by-step description of the method. However, before examining the process we must define a
meta-model. Therefore, we did a simplified version of the Critical Success Chains model using GOPRR meta-
modeling language [24] within MetaEdit+. The meta-modeling language is illustrated in table 1. The formal
metamodel allows the analysis of the methods conceptual structure, as well as, immediate tool support for modeling
using the method.
Table 1 Role based entity modeling (GOPRR)
Meta type Description Symbol
Objects Consist of independent and identifiable design objects. Examples: an Rectangle
Entity in an Entity Relationship Diagram or a Process in a DFD.

Properties Properties are attributes of objects and can only be accessed as parts Oval
of non-properties. Properties can be recursive in the sense that they can
be lists of other types or references to them. Example: Process Name of
a Process in DFD.
Relationships Properties are attributes of objects and can only be accessed as parts Diamond
 of objects or relationships. Example: a Data Flow in a DFD.
Roles Roles define the ways in which objects participate in specific Circle
relationships. Appear as the ends of Relationships (e.g. an arrowhead)
have properties. Example: a Role which an Object plays in a
Relationship, such as which end of a relationship is ‘to’ and which
‘from’.
Graphs Collections that can contain objects, roles, relationships and bindings Window
of these, have properties, and model concepts such as a whole DFD.
They also hold the information about the connections between graphs.

4.1. Conceptual specification of the method

Figure 2 below shows the conceptual definition of the CSC method according to GOPRR. The method definition is
done by identifying the key objects of the method, connecting them by the CSC relationship types and adding
properties to those. The CSC relationship types are further explained in section describing the CSC method in
below. Roles define how different object types can participate in the relationships, and in our model it describes the
interaction connection between the CSC meta-model and the data collect by an in-depth interviewing method stored
in a spreadsheet. Objects can be connected by explosion/decomposition links between the diagram types. When
these are defined with their graphical representations, we have a complete conceptual specification of the method,
which can be used immediately as a template for new models (see [24] for details). In the end of the chapter, we tie
the presented meta-model, figure 2, to the CSC method. This is offered in figure 5. We also present goals that can be
archived with the engineered method.

Figure 2 Meta model of CSC

4.2. Process specification of the method

The process of CSC starts by selection of participants for elicitation process. In case of wide audience IS [8] a lead-
user concept has been used [25] i.e. finding potential users for the service/application who are adapting innovations
at first [26]. One way to select lead-users may be the traditional customer segmenting used in marketing science (for
example [27]) and using snow-balling to find the participants [12]. Snow-balling refers to finding lead-users by
asking a peer reference. This follows the original ideas of wide participation of IS users for reaching cross
organization acceptance of IS, and finding the feature set providing the maximum positive impact [3]. However, the
selection of participants is not limited to these concepts and the selection process should be tailored according to the
project.
After the selection process, the prospects are contacted and during, for example, a telephone conversation, stimuli
for the system are collected informally. These are later used in requirement elicitation phase where the method
utilizes a variation of in-depth interview called laddering. It has been used successfully in marketing to define
features of consumer products (see [28, 29]). Laddering is based on Kelly’s work in 1930s and 1940s when he
worked as practicing psychologist [30]. He argued that by understanding how people see and understand the
surrounding world, one can predict their behavior. Hence, by using laddering we can make implicit requirements
more explicit and understand what the end-users actually want. This gives us the possibility to reflect what and how
people see the world and unhide their potential needs. The crucial benefit is that interviewees do not have to be
technology experts or they do not have to prepare for the interview. The interviewing process helps the participants
to express his or her needs and these can be later analyzed to understand what are the critical for development
success.

Table 2 Critical Success Chains Method - Process description, modified from [12]
CSC Process
01. Prestudy Preparation
Determine scope & Select participants to represent views you want to understand. May be
participants. Collect project idea
stimuli.
12. Data Collection
Elicit personal constructs from
org. members.
23. Analysis
Aggregate personal constructs
into CSC models.
4. Ideation Workshops
Elicit feasible strategic IS
from technical and business
experts and customers.
Objectives
Determine scope to manage complexity.
employees at various levels, suppliers, customers, and experts.
Arrange for data collection.
Collect interview stimuli.
Ask participant to rank-order stimuli on importance.
Ask series of “why would this system be important…” questions to
collect consequence and value data.
Ask series of “what is it about this system that makes you think it would
do that…” questions to collect attribute data.
Record answers as linked chains.
Collect several chains from each participant.
Interpret individual statements and label consistently across
participants.
Cluster chains.
Map clusters into network models.
Recruit workshop participants with technical and business skills.
Evaluate CSC network models and develop ‘back-of-envelope-level’
ideas for IS projects that satisfy the relationships implicit in the models.

The ladders can be collected during the interview, or in a post-process of transcribing the interviews and
reconstructing the ladders. The individual ladders form chains and an example chain, on a product feature level, is
illustrated in figure 3. The example is derived from previous research [3]. It expresses participants desire for the
ability to pay micropayments1 (0.1-2 €) with his/hers mobile phone.
When considering the requirement explosion that usually happens in an RE project, as well as the described
coherency and branching issues of the chains, an appealing way would be using a spreadsheet program, like
Microsoft Excel, to structure the ladders. This would also enable researchers to use hyperlinks between the chains
that branch out. In addition, it would be a simple task to add hyperlinks of the interviews themselves to a chain with
a time index referring to a MP3 file for example.
In analysis phase of CSC, these are clustered using Ward’s method [32] by researchers and the results are presented
using a rich graphical presentation [15, 25] showing the aggregated features, the consequences resulting from them,
and the values or the goals that explain why the end-users want these., the collected ladders are linked to critical
success factors [33, 34] of an information system that are further divided to system attributes, consequences of these
and goals or values of stakeholders. An example of this is presented in Figure 4 that describes mobile wallet
application for 3rd generation mobile phone reported in [15, 35]. It can be seen that ‘access to account’ and ‘ability to
pay small payments’ are important systems features and one of the key reasons is avoiding fraud. These, in turn,
result in more trust and economic security. The purpose of these ‘CSC maps’ are to show managers within few
minutes what are the most beneficial features.
In the next phase, these graphical presentations, or CSC maps, are presented in an initial workshop in order to
introduce the key features of the system to the client’s R&D people who evaluate the maps and identify the feasible
project ideas. The ideas are developed to a 'back-of-the-envelope' standard, so that participants can identify as many
ideas as possible. For each system, the participants are supposed to label the system, briefly describe its nature, its
likely architecture, the resources required to develop it, its cost, likely sourcing, the magnitude of the risk, and its
expected impact on the organization. Following this, researchers have suggested that the results are then returned to
the R&D function of the firm, and used in the system development process [12].

Figure 3 Example chain collected from a participant, adapted from [3].

We have integrated the CSC elicitation method and its philosophy of representation of the requirements into the
Metaedit+ Method engineering environment. We present slight changes to the original way of the representation by
adding three specific features:

1) Segment number identifying the requirement (an individual ladder);

2) Chain list object for handling of branching chains;
3) Tape reference connected into each chain.

1
More about Mobile commerce and micropayments:
[31] N. Mallat, M. Rossi, and V. K. Tuunainen, "Mobile banking services," Communications of the Acm, vol. 47, pp. 42-46,
2004.
We argue that by these modifications we can tackle most of the difficulties faced by practitioners when considering
losing the traceability of requirements to the source [36]. These three features were tested in a field study conducted
with a major Finnish newspaper in MS Excel environment [25].
In figure 5 below, we demonstrate the engineered method. We created an example model that constitutes a part of
the CSC map, and the ladders are mapped back to this specific diagram. The model includes objects (attributes,
consequences, and values) with references to the individual segments i.e. the ladders in the chain. The objects are
arranged according the roles specified in figures 3 and 4. Additionally, we show how it is possible to enable
hyperlinking to the original spreadsheet containing the actual interview data. The given example chain also includes
a hyperlink into the interview recording that is indexed according to the chain’s starting time.

4.3. Constructed method support environment

Our theoretical framework is argued to enable practioners to avoid three important issues faced daily basis in the
RE. First of all, the framework provides an organized way of how to handle changing requirements coherently. The
same problems that we were faced with a study that used MS Excel based support environment [25]. To avoid this
we developed a version of the CSC chains into the MetaEdit+ environment. Metaedit+ stores the models into an
object oriented database and allows linking the objects according to the method. This gives us the possibility of
keeping the traceability information and connecting to the original needs of the end-users during iterative
development process. Furthermore, it enables us to create RE documents expected by the engineering with no extra
effort from the analyst. The standard reporting options allow reporting in various formats, such as HTML and XML
and the report scripting language gives possibilities for defining special reports for various needs. In addition to
these, we have prepared to implement more features of the developed new requirements elicitation method to our
support environment. These include clustering the results within the support environment and including ranking
information of features within the model.

Figure 4 Example CSC map ‘mobile wallet’, slightly modified from [12]
We believe that our method and tool together contribute by integrating complex requirement elicitation methods into
the standard RE process, while avoiding the traceability dilemma. Thus it provides answers for two key questions in
current discussion about RE. However, even more importantly the enhanced CSC method can be used to identify
critical requirements for the project and needs of end-users, which are not explicit. This is an essential area of
research considering radically innovative information systems for wide audience end-users. On the practical side,
the developed tools allow for immediate tool support for the method and they allow us to change the method easily
to accommodate for changed development needs. Furthermore, we are working on the method to support very fast
iteration from ideas to running prototypes, which could be used for providing rapid and concrete feedback for the
users. The idea of the proposed method is shown in figure 5. The developed environment is expected to go into field
trials in several organizations during the fall of 2004.
The implemented environment, which can be seen in figure 4 supports the CSC method by linking together the
original interviews of users, which are kept in MP3 files.
After creating an object oriented database of requirements within the CASE tool, we can use the requirements
information for product concept generation. The requirements are transformed into product prototypes or other form
of presentation. We suggest that by using a domain specific modeling method within MetaEdit+ with proper domain
knowledge we can produce prototypes from the requirements very rapidly.
There are several implementations available and we are currently working on an existing method that generates
running prototypes for the Symbian2 platform (see figure 6). As the platform has emulators, running on browser
windows, that represent Symbian enabled phones, the prototypes can be produced and run seamlessly in either a
workstation, over the internet, or in a Java enabled phone. This kind of environment enables us to provide prototypes
or product concepts for validation almost immediately. It also makes the presentation of alternatives easier. Figure 6
describes an example of a domain specific method that can be used to define new services for Symbian phones. The
defined method produces running software for Symbian Series 60 platform from these models without the need for
coding by hand. Currently the status of the environment is such that we have the Excel sheets used by the field
interviewers, the CSC method in MetaEdit+ and a preliminary version of the rapid prototyping environment (see
figure 4) available and running.

Figure 5 The implemented CSC environment

2
about Symbian operating system, see http://www.symbian.com
 Figure 5 Method for developing Symbian applications

Discussion and Conclusion

In this paper, we have sought to develop a support environment for a theoretically grounded requirements gathering
and organization method [12]. The novelty of the method is its integrated computer support environment for the
whole gathering and organization process. We present a sophisticated way for elicitation of the requirements with a
cognitive approach. The approach facilitates extracting requirements and relationships that are not historical i.e. do
not have an existing system to compare to. In representation level, we enhanced the classic CSC model to facilitate
the use of CASE tool. In addition, we introduced a novel approach of using MP3 interview files enabling the system
analyst to drill down from the high level maps into the original comments in the interviews in the source tapes. This
allows the analyst to easily recall the critical requirements for the project, but in the same time it provides the
designer more detailed information for design work. We claim that this bestows initial solution for providing rich
enough information for different stakeholders.
Limitations are acknowledged. First of all, the selection of the participants needs more attention. Snowballing to
recruit the participants has proven exhausting task in practice [37]. Clearly, research is needed to ease up this task.
In method development, we aim to create a technique that would produce easy tools for practitioners for prioritizing
the requirements with a simple process, and additionally a little effort from the potential wide audience end-users. In
addition, more research has to be done in many practical issues such as how to input information into the CASE tool
in field research. The CASE tool may be too complex tool to use during laddering interviews and mitigating
solutions probably is needed. However, the CASE tool provides extensive selection import filters, such XML. Thus
more common tools can be used during data collection if needed and the data can be later imported to the CASE
tool.
In the future, we seek to test the constructed support environment in real world settings. The method is currently in
use in a few case organizations in a manual form [15, 25]. In the next phase, we seek to deploy the developed
support environment into a case to develop new innovative mobiles services with data gathering in three countries.
This should lead into refinements in both the method and the support environment.

References

[1] K. Pohl, "Three Dimensions of Requirements Engineering: framework and its application," Information Systems, vol.
19, pp. 243-258, 1994.
[2] G. Kotonya and I. Sommerville, Requirements Engineering, Processes and Techniques: John Wiley, 2002.
[3] K. Peffers and T. Tuunanen, "Using Rich Information to Plan Mobile Financial Services Applications with Maximum
Positive Impact: a Case Study," presented at Tokyo Mobile Round Table, Tokyo, Japan, 2002.
[4] W. J. Orlikowski, "CASE Tools as Organizational Change: Investigating Incremental & Radical Changes in Systems
Development," MIS Quarterly, vol. 17, pp. 309 - 340, 1993.
[5] C. J. Neill and P. A. Laplante, "Requirements Engineering: The State of the Practice.," IEEE Software, vol. 20, pp. 40-
45, 2003.
[6] S. Robertson and J. Robertson, Mastering the requirements process: Addison-Wesley, 2002.
[7] J. Iivari, "Hierarchical spiral model for information system and software development Part 1: theoretical background,"
Information and Software Technology, vol. 32, pp. 386 - 399, 1990.
[8] T. Tuunanen, "A New Perspective on Requirements Elicitation Methods," JITTA: Journal of Information Technology
Theory & Application, vol. 5, pp. 45-62, 2003.
[9] B. Regnell, M. Hösta, J. N. o. Dag, P. Beremark, and T. Hjelm, "An Industrial Case Study on Distributed Prioritisation
in Market-Driven Requirements Engineering for Packaged Software," Requirements Engineering Journal, pp. 51-62,
2001.
[10] M. Jirotka and J. Goguen, "Requirements Engineering: Social and Technical Issues," Academic Press, 1994.
[11] S. Kujala, "User involvement: a review of the benefits and challenges," Behaviour & Information Technology, vol. 22,
pp. 1-16, 2003.
[12] K. Peffers, C. E. Gengler, and T. Tuunanen, "Extending critical success factors methodology to facilitate broadly
participative information systems planning," Journal of Management Information Systems, vol. 20, pp. 51-85, 2003.
[13] G. J. Browne and V. Ramesh, "Improving information requirements determination: a cognitive perspective,"
Information & Management, vol. 39, pp. 625-645, 2002.
[14] G. J. Browne and M. B. Rogich, "An empirical investigation of user requirements elicitation: Comparing the
effectiveness of prompting techniques," Journal of Management Information Systems, vol. 17, pp. 223-249, 2001.
[15] K. Peffers and T. Tuunanen, "Planning for IS Applications: a Practical, Information Theoretical Method and Case
Study In Mobile Financial Services.," Information & Management, vol. in press, 2004.
[16] S. Brinkkemper, "Formalisation of Information Systems Modelling," in Computer Science Department. Amsterdam:
Univ. of Nijmegen, 1990.
[17] J. v. Gigch, Systems design and modeling and metamodeling. New York: Plenum Press, 1991.
[18] J.-P. Tolvanen, "Incremental Method Engineering with Modeling Tools: Theoretical Principles and Empirical
Evidence. Dissertation," University of Jyväskylä, 1998.
[19] F. Harmsen, "Situational Method Engineering," in Dept. of Computer Science. Twente: University of Twente, 1997, pp.
310.
[20] G. Hedin, "Incremental Semantic Analysis," in Department of Computer Sciences. Lund: Lund University, 1992.
[21] S. Lauesen, Software Requirements, Styles and Techniques: Addison-Wesley, 2002.
[22] B. Nuseibeh and S. Easterbrook, "Requirements engineering: a roadmap," in The Future of Software Engineering, A.
Finkelstein, Ed., 2000.
[23] K. Peffers and C. Gengler, "How to Identify New High-Payoff Information Systems for the Organization,"
Communications of the ACM, 2003.
[24] S. Kelly, K. Lyytinen, and M. Rossi, "MetaEdit+: A Fully Configurable Multi-User and Multi-Tool CASE and CAME
Environment," in Advanced Information Systems Engineering, proceedings of the 8th International Conference
CAISE'96, Lecture Notes in Computer Science, P. Constapoulos, J. Mylopoulos, and Y. Vassiliou, Eds. Berlin:
Springer-Verlag, 1996, pp. 1-21.
[25] T. Tuunanen, "Miten kohdata ja ymmärtää laajojen loppukäyttäjäryhmien vaatimukset ja tarpeet," in Divia
loppuraportti 2003, M. Raulas and M. Merisavo, Eds. Helsinki: LTT-Tutkimus Oy, 2004, pp. 158-162.
[26] E. M. Rogers, "New Product Adoption and Diffusion," Journal of Consumer Research, vol. 2, pp. 290-301, 1976.
[27] P. Kotler, Management Analysis, Planning, Implementation, and Control, 8 ed: Prentice-Hall, 1994.
[28] T. J. Reynolds and J. Gutman, "Laddering theory, method, analysis, and interpretation," Journal of Advertising
Research, vol. 28, pp. 11-31, 1988.
[29] C. E. Gengler and T. J. Reynolds, "Consumer understanding and advertising strategy: analysis and translation of
laddering data," Journal of Advertising Research, vol. 35, pp. 19-33, 1995.
[30] G. A. Kelly, Psychology of Personal Constructs. New York, NY: W. W. Norton and Co., 1955.
[31] N. Mallat, M. Rossi, and V. K. Tuunainen, "Mobile banking services," Communications of the Acm, vol. 47, pp. 42-46,
2004.
[32] M. S. Aldenderfer and R. K. Blashfield, Cluster Analysis, vol. series no. 44. Beverly Hills and London: Sage Pubns,
1984.
[33] J. F. Rockart, "The changing role of the information systems executive: a critical success factors perspective," Sloan
Management Review, vol. 24, pp. 3-13, 1982.
[34] J. F. Rockart, "Chief executives define their own data needs," Harvard Business Review, vol. 52, pp. 81-93, 1979.
[35] K. Peffers and T. Tuunanen, "Using Rich Information to Plan Mobile Financial Services Applications with Maximum
Positive Impact: a Case Study," presented at Mobile Round Table, Tokyo, 2002.
[36] B. Ramesh and M. Jarke, "Towards Reference Models for Requirements Traceability," IEEE Transactions on Software
Engineering, vol. 27, pp. 58-93, 2001.
[37] E. L. Olson and G. Bakke, "Implementing the lead user method in a high technology firm: A longitudinal study of
intentions versus actions," Journal of Product Innovation Management, vol. 18, pp. 388-395, 2001.