Implementing Novel IT Products in Small Size Organizations
Technology-driven Requirements Engineering
Jolita Ralyté
1
and Laurent Biggel
2
1
Institute of Information Services Science, University of Geneva, Route de Drize 7, Carouge, Switzerland
2
Cambridge Technology Partners, Geneva, Switzerland
Keywords: Technology-driven Requirements Engineering, IT Product Adequacy Analysis, Novel IT Devices.
Abstract: The growing popularity of new mobile information technology products influences enterprises to buy them
without an appropriate evaluation of their usability. This situation is relatively new and conventional usage-
driven requirements engineering approaches are not well suitable. The objective of our work is to propose a
technology-driven requirements engineering approach where requirements are discovered not only from
business needs but also from product features and properties. In particular we take into consideration small
size organizations with a small number of business roles and activities.
1 INTRODUCTION
Today’s enterprises demonstrate a constantly
growing interest in new mobile information
technology (IT) products that they consider as
innovative and modern support for their business
activities. This popularity is mainly justified by their
multifunctional capabilities, intuitive usage facilities
and mobility. Smartphones and tablet computers are
being used as personal and professional tools at the
same time. Moreover, executives bring their
personal devices at their workplace and use them
instead of their office computers. This growing trend
arises multiple issues for the company: data backup
and recovery, material and data security, information
monitoring and so on. In order to keep control on
this situation, more and more companies are buying
those IT products and set them up before giving
them to their employees (Jern, 2012; Lai, 2012;
Narisi, 2012; Pettey and Van der Meulen, 2012).
Similarly, high education institutions are distributing
tablets for their students (Martinez, 2011) for
education purposes and paper saving. As big
companies and schools are starting to acquire
thousands of tablets or smartphones, smaller ones
are tempted to follow the trend sometimes without
considering the real need and the applicability of
these IT products in the enterprise business context.
It seems that traditional requirements
engineering (RE) approaches (e.g. goal-driven,
scenarios, use cases) are not sufficiently helpful in
this new situation because they are based on
business objectives and stakeholders’ problem
and/or needs analysis. The situation discussed in this
paper is slightly different – the main RE driver is not
a problem or a need for an IT product but the
product itself. The main question is how the product
fits its potential users’ activities and how it could
facilitate and/or improve their realization.
In this paper we consider the challenge of
introducing new mobile IT products/devices into
small and medium size organizations. In particular,
we propose an approach for technology-driven
requirements engineering where the purchase of a
particular IT product is influenced by the market and
current trend rather than by the enterprise activity-
based necessity. We aim to help enterprise decision
makers and project managers to determine the
benefit of those IT products for their enterprise and
its employees and to identify the most appropriate
usage of their capabilities. The approach aims to
cover the RE process starting from the analysis of
product features and potential needs, going through
the implementation requirements specification and
ending with the decision taking on product
acquisition. In particular, we take into consideration
the situation of small and medium size organizations
with a narrow scope of activity and small number of
organizational roles.
The approach has been initiated and tested on a
small non-profit organization called “Unions
Chrétiennes de Genève” willing to acquire tablet
153
Ralyté J. and Biggel L..
Implementing Novel IT Products in Small Size Organizations - Technology-driven Requirements Engineering.
DOI: 10.5220/0004864601530160
In Proceedings of the 16th International Conference on Enterprise Information Systems (ICEIS-2014), pages 153-160
ISBN: 978-989-758-028-4
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
computers for its executives. The study has been
conducted during a Master internship in this
organization. The obtained results demonstrate the
utility of the approach and highlight its limits and
potential evolutions.
The paper is organized as follows: in the next
section we describe the research context and
objectives. Then, we present our approach for
technology-driven requirements engineering and
illustrate its application in a small organization.
Finally, we conclude the paper with the discussion
about potential extension of the approach and future
research perspectives.
2 RESEARCH CONTEXT AND
OBJECTIVES
By definition a requirement designates “some
capability that somebody needs or wants”
(Robertson, 2001), or “a condition or capability
needed by a user to solve a problem of achieve an
objective” (IEEE Std610.12-1990). Most of the RE
approaches consider requirements as descriptions of
how a product or service should behave, what
functionalities and qualities it should offer, what
constraints it should respect and all other relevant
specifications it should have (Alexander and Beus-
Dukic, 2009; Kotonya and Sommerville, 1998; Pohl,
2010; Robertson and Roberston, 2012). Various
information sources such as information on existing
systems, stakeholders’ needs, organizational
standards, regulations and domain information are
used to discover and specify information system or
IT artifact requirements. We name these approaches
Usage-driven RE. They follow a general schema:
Identification of business goals and project
stakeholders.
Discovery and specification of stakeholders’
requirements towards the IT product by using
different requirements elicitation techniques.
IT Product selection and/or design according
to the specified requirements.
In our case, we need an approach, which would
be IT product driven with the focus on its integration
into the organization. We need to find the adequacy
between the functions and properties of the IT
product and the potential users’ needs. Therefore, in
our case, the starting point of the analysis is not a
group of stakeholders with their needs but the IT
product itself, for the simple reason that it is known
at the beginning of the project. Of course, one can
ask how an IT project can start without business
goals and justifications for the required budget.
However, the professional literature, web survey
(Jern, 2012; Lai, 2012; Martinez, 2011; Narisi, 2012;
Pettey and Van der Meulen, 2012) and our own
experience reveal that such situation is not rare,
because the technology and innovation trend has
more and more influence on enterprise managers.
Certainly, the evaluation of the IT product adequacy
to the organization and its potential contribution to
the business activities and their innovation is
necessary in order to justify the purchase. The main
objective of this analysis is to determine if the main
functions of the product/device match the activities
of the end-users, and to help enterprise mangers to
take the decision to acquire this product or not. In
case of a positive decision, the requirements related
to the product implementation in the organization
have to be specified. We name this approach
Technology-driven RE. Its general process can be
summarized like this:
Selection of the desired IT product.
Identification and appreciation of its main
qualities, properties and functions.
Identification of potential product users and
evaluation of the adequacy between the
product features and users’ activities and
profiles.
Specification of requirements for the product
configuration and implementation.
3 AN APPROACH FOR
Technology-driven RE
The construction of our Technology-driven RE
approach is based on the following assumptions:
The approach applies to a relatively small and
medium size organization that has a project to
acquire a new IT product for its employees.
The product to be deployed is known at the
beginning of the research, but different
versions or additional options may be subject
to further analysis.
The usage and the adaptability of the product
to the enterprise business have to be
discovered and evaluated.
The technical integration of the product does
not constitute a major obstacle for the
implementation but precise requirements have
to be specified.
To represent our approach we use an intention-
driven and multi-strategy process modeling
formalism named Map (Rolland et al., 1999),
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
154
Figure 1: Process Model for Technology-Driven Requirements Engineering.
which allows to express process models in
intentional terms instead of fixed steps and
activities. In a map, a process is represented as a
labeled directed graph where nodes define process
intentions and edges designate different strategies to
achieve the intentions. Each strategy represents a
particular technique to achieve the target intention.
Figure 1 represents the process model of our
approach formalized in terms of four main
intentions, named Specify Product Characteristics,
Characterize Organizational Context, Evaluate
Organizational Context/Product Adequacy and
Specify Implementation Requirements and several
strategies providing different complementary and/or
alternative means to reach these intentions. The
flexibility offered by the Map formalism enables an
iterative selection of the process strategies and their
underlying techniques. We explain below the four
intentions and the strategies to reach them.
3.1 Specifying IT Product
Characteristics
The first step consists in selecting and dissecting the
IT product to be implemented to highlight the main
benefits that it could bring to the organization. This
analysis is obviously easier if we can get the product
in hand to test its functionalities; we call this
strategy by product manipulation. Otherwise, the
information has to be collected from diverse
commercial sources like product documentation,
product vendors and their websites, media and blogs,
other companies or institutions that already adopted
this product, and from public product evaluations
made by other users. Data collected is then classified
– analyzed and compiled into a list of functions and
qualities considered as essential, those features that
characterize the product and could bring a real added
value to the activities of the potential users.
The combination of features and qualities chosen
allows the creation of one or more generic user
profiles (formalized as user profiles definition
strategy) characterizing typical users of the product.
These profiles are later compared with the potential
user profiles in order to identify similarities and
provide purchase recommendations.
3.2 Characterizing the
Organizational Context
The objective of the second step is to evaluate if the
selected IT product fits enterprise activities, roles
and business rules. The results of this step should
allow the decision makers to pronounce their initial
judgment: to buy this product or not. It consists in
specifying the application domain in which the
product should be introduced and involves the
following complementary activities:
Identification of the general objectives
justifying the product acquisition project by
using goal-driven analysis techniques;
Identification of the main organization
activities that could benefit from the product
acquisition with respect to the business rules
ImplementingNovelITProductsinSmallSizeOrganizations-Technology-drivenRequirementsEngineering
155
by following business activity analysis
strategy, and
Identification of the main organizational roles
as potential users of the product under
consideration by following business roles
analysis strategy.
The data can be retrieved either from the
available documentation (organization charts,
business reports, job descriptions, website, etc.)
and/or from the discussions with project initiators
and potential users. Goal-driven approaches
(Dardenne et al., 1993; van Lamsweerde, 2001) can
be used to create a clear view of different
stakeholders’ goals related to the product usage in
the organization. At this moment, it is not necessary
to specify in detail the responsibilities of each
potential user, but their important and recurring
tasks have to be known. Also, decision-makers, i.e.
people who will make the final decision concerning
the acquisition of the product, must be identified in
order to keep them informed throughout the process.
3.3 Evaluating Organizational Context
vs. IT Product Adequacy
This step gives a more active role to the project
stakeholders, in particular to the decision-makers
and the potential product users identified during the
organizational context analysis. They should be now
questioned about their daily activities and
responsibilities in order to relate them to the product
capabilities defined beforehand.
The traditional and most common way to
discover requirements is interviewing (Alexander
and Beus-Dukic, 2009). Interviews can be closed or
open (Kotonya and Sommerville, 1998),
standardized, exploratory, or unstructured
(Oppenheim, 2000), individual or group ones (Pohl,
2010). Stakeholders have to be interrogated about
their activities, responsibilities, recurring and
occasional tasks, and the tools they use. It is also
important to let them express their opinion about the
product and investigate what they would like to
improve in their job. We recommend to begin the
analysis with a questionnaire that allows to capture
some general information about stakeholders’
activities and work contexts. Starting with
questionnaires instead of direct interviews has a few
benefits. First of all, it allows quickly eliminating
some candidates for whom the product is clearly
useless and a complete interview would be a waste
of time. Then, the obtained answers permit to refine
the respondent’s profile and therefore make the main
interview more adapted to the person through the
development of complementary and targeted
questions. Finally, the mere fact to inform the
respondent about the product and some of its
functions makes him/her aware of its existence and
lets him/her to imagine possible applications later in
his/her daily work and express them during the
interviews.
The results of interviews and questionnaires
allow to define personal users’ profiles that are then
compared with the generic profiles defined
beforehand. This strategy for evaluating the product
adequacy is named by profile comparison. If the
potential user’s profile is close enough to one of the
standard profiles then we can assume that the
product will bring a sufficiently significant benefit
and the purchase will be recommended.
Group techniques like workshops and/or
brainstorming sessions sometimes can be more
effective than personal interviews. They allow to
generate many new ideas and to discover
unconscious requirements (Robertson, 2001).
To sum up, the final decision will depend, above
all, on the adequacy between the features offered by
the IT product and the requirements induced by the
activities of each user. The result, however, must be
qualified by various elements collected during the
analysis, such as the possibilities for future
applications, users’ opinions and open-mindedness
and, of course, the price. At the end of this step, the
results are presented to the decision-makers and
recommendations are made concerning the purchase
as well as the choice of product versions and/or
eventual alternatives. If the acquisition is not
validated and no alternative is considered, the
process ends here.
3.4 Specifying Implementation
Requirements
The acquisition of a new IT product requires
adequate measures to ensure its successful
integration within the organization. The main
strategy to achieve this intention is named feature
analysis; it consists in the identification, selection
and/or configuration of functional product features
according to the user’s profile and activities. It can
be done by using feature models from software
product line engineering (Kang et al., 2002), goal
models like AND/OR graphs (Dardenne et al, 1993)
or even use case techniques (Jacobson et al., 1992).
In addition, requirements related to the product
usage have to be identified and specified. In
particular, rules related to the product exploitation
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
156
(e.g. data storage) and rules concerning product
management (e.g. product updates) must be defined
in agreement with the management staff.
Respectively, these two strategies are named usage
constraints analysis and management constraints
analysis. The product/tool being provided by the
employer, the question of responsibility arises and
must be settled quickly and transparently with each
user. One of the ways to proceed would be to define
a charter specifying the limits of the product
exploitation and the consequences in case of its loss
or deterioration.
Compatibility with the existing IT/IS system
(IT/IS compatibility check strategy) as well as
control and security validation issues must be
addressed and resolved prior to the product
implementation. Especially, if the product requires a
certain level of monitoring (security, control,
maintenance), it may be necessary to create a new
position within the organization dedicated to its
management or to add a new responsibility to the
existing IT Manager role. If the specified
requirements appear to be too “expensive” (e.g.
maintenance, new roles to be created), the decision
still can be to abandon the acquisition of the product.
4 APPLICATION OF THE
APPROACH
As mentioned in the introduction of this paper, the
design and application of the methodology proposed
above was realized during a six-month internship in
a non-profit organization named Unions Chrétiennes
de Genève (UCG). UCG offers training, leisure and
social activities to foster personal development in a
community environment (see Table 1). UCG is
willing to be a modern organization and the
introduction of tablet computers, representing a
relatively avant-gardist technology for the
association, is a part of its innovation process. The
project to acquire iPads for some UGC executives
was launched by the President of UCG. The main
objective of our work was to provide arguments
allowing the UCG Management Committee to take
this decision.
Following our approach (see Figure 1), the first
step consisted in evaluating the selected IT product
(iPad in our case) itself and to select its main
features and characteristics. The analysis was based
on multiple information sources available on
Internet, such as commercial data and users’
evaluations, and it was completed by the
manipulation of the product itself. The results of this
Table 1: Activities of UCG.
Activity Description
Administra-
tion
Administration of the association: management,
maintenance, office supply, accounting, etc.
Villas
YoYo
Free spaces open every day after school hours
where children (4 to 12 years) benefit from
school support and various activities, animations
and summer camps.
@do
A space offering young people (10 - 15 years)
school support, social and cultural activities, and
an annual summer camp.
Web
Seniors
Offers various IT courses to seniors: office tools,
internet, webcam, skype, e-mail, digital photos
handling, etc.
Foyer
George
Williams
Offers to people (18 to 35 years) a possibility to
rent rooms for living and organizing parties or
other activities.
Fitness Management of subscriptions.
Meeting
room
The association rents a meeting room with a
capacity of up to 50 people.
Rehabilita-
tion
Professional and social reintegration support for
employees in difficulty.
step are summarized in Table 2, which also includes
a general user profile description established with
regards to the selected product characteristics.
The next step consisted in defining the
organizational context, i.e. identifying project
decision-makers and their main objectives, listing
the main business activities and describing
organizational roles considered as potential product
users. Information collecting has been greatly
facilitated by the multiplicity of information sources:
association’s website presenting the organizational
chart, activity reports, funding sources and of course
its activities, several available documents such as
statutes, archives and the book tracing the
association’s history. Furthermore, it was easy to
engage in informal discussions with associations’
members to glean the information regarding their
tasks and responsibilities. Goal-driven strategy was
applied to identify only very general project
objectives allowing to justify the product purchase in
general but not yet for each particular user. The
results of this step are summarized in Table 3. In
total, eleven people were selected as potential users
and considered as stakeholders for the rest of the
study.
In addition to the product qualities listed in Table
2, two major constraints had to be taken into
account: the price of the product and its reliability.
Both were evaluation as acceptable and satisfactory.
ImplementingNovelITProductsinSmallSizeOrganizations-Technology-drivenRequirementsEngineering
157
Table 2: Selected Product Characteristics and Generic User Profile.
Quality
Requirement
Facet Attributes
High mobility Autonomy
High capacity of the battery - a full working day.
No need to connect to any peripheral (e.g. screen, keyboard, mouse) to work.
Portability Appropriate size and weight. No need for additional peripheral.
Connectivity
Wireless and 3G connection. Availability of connectors to different peripherals
(monitor, beamer, keyboard).
Multi-
functionality
Multiplicity and variety of
functions and applications
The device is functional immediately because of several basic functions such as, web
browser, e-mail, notes, calendar, capture of photos and videos.
More than 650'000 applications for infinite purposes are available on the App Store.
Performance Rapid processor, while maintaining low consumption. Adequate storage memory.
Reduced paper
usage
Paper substitution
The width of the screen is close to the A4 format. Easy reading of the majority of
standard documents. Facilities to adapt the font size.
The portability of the tablet makes it easy to read documents at any place.
Simplicity and
accessibility
Facility of usage
The screen size close to the one of a small laptop computer. Easy installation and
manipulation of the applications. Quick and intuitive access to the applications.
Intuitive interface
Application-based operating system. The touchscreen interface is intuitive and learning
is much quicker than on a computer. People frustrated by the complexity of computers
may finally receive a viable and user-friendly alternative.
Generic User Profile
The tablet user regularly needs an electronic support when moving inside or outside the main workplace.
The tablet user utilizes the device as a multifunctional support (agenda, documents, presentations, web, mails, photos, video, etc.).
The tablet user is open to new technologies, at least as long as they are accessible to him/her.
Table 3: Results of the Organizational Context Definition.
Context
Elements
Organizational Context Specification
Decision-
makers
The Management Committee including the
President, the Associate Director and the Main
Director makes the final decision regarding the
acquisition of tablets.
Main
objectives
The main goal – Improve work efficiency – is
refined into the following sub-goals: facilitate
mobility of managers, offer a multi-functional
device supporting managers’ tasks, ensure
simplicity of the product usage and reduce
paper usage.
Potential
users
The following organizational roles were
identified as potential beneficiaries of the
tablets: Associate Director, Main Director,
Administrative Officer, Web Seniors Manager,
Administrative Assistant, Accountant, Head of
Maintenance, @do Manager and three
managers of the villas YoYo.
Activities See Table 1.
The next step in the decision-making phase
consisted in evaluating the adequacy between the
potential users profiles and activities on one hand,
and the product characteristics on the other hand.
Semi-open interviews, based on a list of generic
predefined questions, were used in this study. The
results of the questionnaire and the transcription of
interviews are available in (Biggel, 2012). The study
revealed that the roles of Accountant, Administrative
Assistant and Head of Maintenance were matching
by very far the standard profile, due to the little
mobility and the low potential for transferability of
the tasks already performed on a computer. It was
therefore not recommended to acquire tablets for
these three roles. In the contrary, the profile of the
Associate Director was considered very similar to
the generic tablet user’s one. She moves regularly
outside her office and uses her smartphone for some
tasks that would gain in comfort with a tablet for
taking notes in meetings, consulting e-mails and
editing presentations and documents. Therefore, the
recommendation to acquire a tablet was positive.
Concerning the Administration Officer, the result
was more nuanced: little mobility but an interesting
potential for the multifunctional aspect of the tablet.
The profiles of the Main Director and the Manager
of Web Seniors did not match the standard profile
due to their low computing needs and also because
of their difficulties in understanding and using new
technologies in general. Therefore, the
recommendation was negative. Similarly, the @do
Manager has a distant profile from the standard one.
Even if some of his activities take place regularly
outside the workplace, a computing support in these
cases is not needed. Already existing computers in
his main workplace fully meet his professional
needs. Finally, the three Managers of the villas
YoYo have quite similar tasks but they work and
operate differently, with a different material and
their respective profiles are not identical. However,
two of them are close to the standard profile and
show some enthusiasm and interest for the tablet;
they received positive recommendation.
Of course, we are conscious that this type of
analysis has some risks, in particular, triggering
some frustration of people who were discarded from
the project since the beginning or after the
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
158
evaluation of their profiles and their needs towards
the product. One can argue that in such situation the
company should simply buy the product to all
employees in order to avoid envy and conflicts.
However, our study, and in particular the final
interviews, revealed that some employees were not
interested in having a tablet computer for their job
and were convinced that such a purchase would be a
waste of money and energy.
Finally, the requirements for the tablet
implementation in the organizational context and
general rules for its usage were specified. The final
decision was to buy 4 iPad tablets and test their
usage in practice before acquiring more devices.
5 FURTHER EVOLUTION OF
THE APPROACH
Usually, requirements engineering is realized at the
beginning of an IT product acquisition/engineering
process. However, it is well known that users’ needs
evolve during the product usage in practice.
Moreover, new ways of using the product could be
discovered with the aim to innovate the enterprise
business model and activities. Therefore, we see that
logical continuation of our approach would be
considering requirements evolution management
during the product lifecycle. That would include
capturing user feedback and exploring the potential
business innovations enabled by the product usage.
Both steps would lead to the revision of the
requirements specification and the product update.
5.1 Capturing and Analyzing Users’
Feedback
The main objective of this step consists in evaluating
the product in use and identifying the problems
faced by its users, the changes made in their daily
activities, and the desired improvements. One way to
make this assessment would be a permanent
monitoring where users would be asked to report the
encountered problems, to explain what functions
they use the most, and to evoke the possible
applications. Of course, this method implies that a
regular contact with each of the users is possible.
Another possibility would be to conduct planned
interviews after several weeks of product usage
under the real work conditions. The major risk of
this technique is that people can forget about some
interesting situations implying the tool.
Feedback prioritization and organization can be
necessary in case of multiple users reports in order
to detect commonalities and discrepancies in them
and to extract the most relevant information. We
recommend to use techniques dedicated to explore
customer/user feedback collected in the form of
reviews, comments and surveys (Oelke et al., 2009).
The results obtained during the product assessment
may entail a return to the stage of requirements
specification where feedback reports are used to
identify new requirements concerning the product
implementation.
5.2 Exploration and Innovation
The objective of this step would be to explore the
prospects offered by the acquired IT product. The
aim of this analysis is to go beyond the mere
satisfaction of stakeholders’ needs and to imagine
what innovations it could bring to the users’
activities based on the product capabilities. This step
makes sense if the initial feedback reports are
favorable and the lifecycle of the product is
considered as relatively long.
In order to stimulate ideas and to discover new
ways to use the product, we recommend applying
creativity techniques used in requirements
engineering (Karlsen et al., 2009; Maiden et al.,
2010). Gathering some members of the organization
together in a brainstorming session or other
creativity workshop and leveraging the potential of
group thinking seems to be a great way to discover
unexpected applications or different ways to use the
product.
Once the ideas for future product applications
have been discussed and validated, the approach
would bring us back to the requirements
specification phase. For example, it can be required
to change the network infrastructure, to add new
features (applications), to accompany product users
to make changes in their work or even to change
assignments and tasks related to their position.
6 CONCLUSION
In this paper we propose an approach for handling
the implementation of new IT products in small and
medium size organizations. The construction of this
approach was instigated by a real project and the
need to evaluate an IT product acquisition in a small
non-profit association. The approach is mainly
adapted to the evaluation of multifunctional devices
like tablets and smartphones and is based on the
ImplementingNovelITProductsinSmallSizeOrganizations-Technology-drivenRequirementsEngineering
159
evaluation of the adequacy between the features
offered by the product and the business activities,
responsibilities and work context of its users.
Further investigations should be done in order to
broaden its scope to more general technology-driven
projects exploring business innovation with the help
of new technologies and IT artifacts.
We recognize that the comparison of user
profiles during the product adequacy evaluation step
needs further elaboration – introduction of
quantitative and/or qualitative criteria in order make
the assessment of profiles similarity more precise
and better adapted for bigger organizations.
We also imagine the extension of our approach
for managing requirements evolution and finding
possible business innovations with the help of the IT
product. We believe that fostering creative thinking
throughout the entire RE process is a great way to
combine fun and efficiency. We suggest trying some
creativity workshops in the early steps of the
analysis process in order to test social interactions
between different organizational roles and their
capacity to generate original ideas.
REFERENCES
Alexander, I. and Beus-Dukic, L., 2009. Discovering
Requirements: How to Specify Products and Services,
John Wiley & Sons Ltd, Chichester, West Sussex,
England.
Biggel, L. 2012. New Technology Product Implementation
in Small and Medium Organizations, MSc Thesis,
University of Geneva, Switzerland.
Dardenne, A., Lamsweerde, A. and Fickas, S., 1993. Goal-
directed Requirements Acquisition, Science of
Computer Programming, vol. 20, pp. 3-50.
Dieste, O., Juristo, K. and Shull, F., 2008. Understanding
the customer: What do we know about requirements
elicitation? IEEE Software, March 2008, pp. 11-13.
IEEE Std 610.12-1990, IEEE Standard Glossary of
Software Engineering Terminology (IEEE Std 610.12-
1990), IEEE, New York, 1990.
Jacobson I., M. Christenson, P. Jonsson, G. Oevergaard.
1992. Object Oriented Software Engineering: a Use
Case Driven Approach. Addison-Wesley.
Jern, M., 2012. Turning tablets into powerful tools for the
mobile enterprise, http://www.guardian.co.uk/media-
network/media-network-blog/2012/apr/19/tablets-
tools-mobile-enterprise
Kang, K.^C., Lee, J. and Donohoe, P. 2002. Feature-
Oriented Product Line Engineering. IEEE Software,
July/ August 2002, pp. 58-65.
Karlsen, I.K., Maiden N. and Kerne, A., 2009. Inventing
Requirements with Creativity Support Tools, REFSQ
2009, LNCS Vol. 5512, Springer, pp. 162–174.
Kotonya G. and Sommerville, I., 1998. Requirements
Engineering: Process and Techniques, John Wiley &
Sons Ltd, Chichester, West Sussex, England.
Lai, E., 2012. Top 100 iPad Rollouts by Enterprises &
Schools,
http://www.forbes.com/sites/sap/2012/08/31/top-50-
ipad-rollouts-by-enterprises-schools/
van Lamsweerde, A., 2001. Goal-Oriented Requirements
Engineering: A Guided Tour, Invited Minitutorial,
IEEE Conf. RE 2001, pp. 249-263.
Maiden, N., Jones, S., Karlsen, K., Neill, R., Zachos, K.
and Milne, A., 2010. Requirements Engineering as
Creative Problem Solving: A Research Agenda for
Idea Finding, IEEE Conf. RE 2010, pp. 57–66.
Martinez, S., 2011. Student iPad deployment – the first big
decision is not technical, it’s about agency,
http://blog.genyes.org/index.php/2011/07/29/student-
ipad-deployment-the-first-big-decision-is-not-
technical-its-about-agency/, July 29, 2011.
Narisi, S., 2012. Survey: Business iPad users will stick
with the tablet, http://www.itmanagerdaily.com/bu
siness-ipad-users-will-stick-with-the-tablet/
Oelke, D., Hao1, M., Rohrdantz, C., Keim, D.A., Dayal,
U., Haug, L-E., Janetzko, H., 2009. Visual Opinion
Analysis of Customer Feedback Data, in Proceedings
of VAST, IEEE Xplore, 2009, pp. 187-194.
Oppenheim, A.N., 2000. Questionnaire Design,
Interviewing and Attitude Measurement, 2nd edition,
Leicester University Press.
Pettey C. and Van der Meulen, R., 2012. Gartner Says
Worldwide Media Tablets Sales to Reach 119 Million
Units in 2012, http://www.gartner.com/it/page.jsp?
id=1980115
Pohl, K. 2010. Requirements Engineering - Fundamentals,
Principles, and Techniques, Springer.
Robertson, S., 2001. Requirements Trawling: Techniques
for Discovering Requirements, International Journal
of Human Computer Studies, vol. 55(4), pp. 405-421.
Robertson, S. and Roberston, J., 2012. Mastering the
Requirements Process, 3
rd
eds, Addison Wesley.
Rolland, C., Prakash, N. and Benjamen, A., 1999. A
Multi-Model View of Process Modelling,
Requirements Engineering, vol. 4(4), pp. 169–187.
Web UCG. UCG - Unions Chrétiennes de Genève,
http://www.unionschretiennesgeneve.ch/ucg/index.php
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
160
