Ecomo Rossi Tuunanen.pdf

download Ecomo Rossi Tuunanen.pdf

of 12

Transcript of Ecomo Rossi Tuunanen.pdf

  • 8/8/2019 Ecomo Rossi Tuunanen.pdf

    1/12

    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 enhancedrequirements 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 challengethat 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 isnot 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

  • 8/8/2019 Ecomo Rossi Tuunanen.pdf

    2/12

    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 systems

    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 developmentapproaches (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 somethingthat 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).

    Pohls [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

  • 8/8/2019 Ecomo Rossi Tuunanen.pdf

    3/12

    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 methodknowledge 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

  • 8/8/2019 Ecomo Rossi Tuunanen.pdf

    4/12

    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 workingwith 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. Forour 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

    Entity in an Entity Relationship Diagram or a Process in a DFD.

    Rectangle

    Properties Properties are attributes of objects and can only be accessed as parts

    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.

    Oval

    Relationships Properties are attributes of objects and can only be accessed as parts Diamond

  • 8/8/2019 Ecomo Rossi Tuunanen.pdf

    5/12

    of objects or relationships. Example: a Data Flow in a DFD.

    Roles Roles define the ways in which objects participate in specific

    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.

    Circle

    Graphs Collections that can contain objects, roles, relationships and bindings

    of these, have properties, and model concepts such as a whole DFD.

    They also hold the information about the connections between graphs.

    Window

    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 storedin 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

  • 8/8/2019 Ecomo Rossi Tuunanen.pdf

    6/12

    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 Kellys 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 participantsto 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 Objectives

    01. Prestudy Preparation

    Determine scope &

    participants. Collect project idea

    stimuli.

    Determine scope to manage complexity.

    Select participants to represent views you want to understand. May be

    employees at various levels, suppliers, customers, and experts.

    Arrange for data collection.

    Collect interview stimuli.

    12. Data CollectionElicit personal constructs from

    org. members.

    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.

    23. Analysis

    Aggregate personal constructs

    into CSC models.

    Interpret individual statements and label consistently across

    participants.

    Cluster chains.

    Map clusters into network models.

    4. Ideation Workshops

    Elicit feasible strategic IS

    from technical and business

    experts and customers.

    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

  • 8/8/2019 Ecomo Rossi Tuunanen.pdf

    7/12

    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 Wards 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 clients 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.

  • 8/8/2019 Ecomo Rossi Tuunanen.pdf

    8/12

    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 chains 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 XMLand 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,

  • 8/8/2019 Ecomo Rossi Tuunanen.pdf

    9/12

    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

  • 8/8/2019 Ecomo Rossi Tuunanen.pdf

    10/12

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

  • 8/8/2019 Ecomo Rossi Tuunanen.pdf

    11/12

    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 TechnologyTheory & Application, vol. 5, pp. 45-62, 2003.

    [9] B. Regnell, M. Hsta, 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 Jyvskyl, 1998.

    [19] F. Harmsen, "Situational Method Engineering," inDept. of Computer Science. Twente: University of Twente, 1997, pp.

    310.

    [20] G. Hedin, "Incremental Semantic Analysis," inDepartment 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," inAdvanced Information Systems Engineering, proceedings of the 8th International ConferenceCAISE'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 ymmrt laajojen loppukyttjryhmien vaatimukset ja tarpeet," inDivia

    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.

  • 8/8/2019 Ecomo Rossi Tuunanen.pdf

    12/12

    [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," SloanManagement 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.