KSII The Second International Conference on Internet (ICONI) 2010, December 2010 479

Copyright ⓒ 2010 KSII

Requirements Elicitation in the Agile

Process with Social Network Services
Tae-Hoon Um, Neung-Hoe Kim, Dong-Hyun Lee, Hoh Peter In1
1
Department of Computer Science & Engineering, Korea University
Anam-Dong, Sungbuk-Gu, Seoul 136-713, Korea
Seoul, South Korea
[e-mail: ompa, nunghoi, tellmehenry, hoh_in@korea.ac.kr]
*Corresponding author: Hoh Peter In

Abstract

As customer requirements are constantly changeable, the lightweight-development methods are in

high demand in place of traditional processes [1]. Thus, the agile process has been proposed and it has
been gaining popularity, especially in connection with small-sized projects [2]. However, the existing
agile process has the limitation to elicit rich requirements from a small number of participants. Recently,
the popularity of social network services has enabled active online communication among users. This
feature of facilitated communication is also applicable to the software requirements elicitation. If it is
possible to effectively take into consideration the opinions not only of customers and developers, but
also of the social network users, it is likely to reach more trustful decisions and to find out new
requirements as well. Thus, we propose a process that integrates the requirements and opinions
collected both from the agile team and from social network users, in order to overcome the limitations
occurring under the existing agile process.

Keywords: the agile process, requirements elicitation, social network services, a customer

number of small enterprises that are not trained

1. Introduction
Small-sized projects usually entail short-term
periods of development, small number of
participating workers (and part-timers), simple
featured development and limited scope [3]. In
recent years, lots of small businesses tend to use
the agile process that has these features. If the
agile process is taken up by an experienced agile
team, they are likely to bring in advantages such
as fast decision making, rapid release and
customer satisfaction.
However, due to its short history despite diverse
forms put to use in practice, the agile approach
lies beyond the capacities of a considerable
properly. Thus, under the existing agile scheme,
the following problems may arise in the course of
requirement elicitation:
(1) In general, it takes a small number of people
to elicit and analyze customer requirements
under the agile approach. Likewise, a small
number of requirements are used for
software development, missing other
numberous requirements that may need to
be considered.
(2) In addition, burdened under time constraints,
the participants hastily elicit requirements to
meet release plans, thereby making it hard to
480 Um et al.: Requirements Elicitation in the Agile Process with Social Network Services

conduct in-depth discussions on important make and build personal relationships. The SNS
matters. is categorized mainly into two types:
relationship-based network service and
It is necessary to consider a wide pool of interest-based sharing service [7]. In the early
requirements and to collect information thereon. days, the SNS was mainly used for socializing
Lately, more and more people subscribe to social with people and sharing daily lives. Recently,
network services, and share and communicate however, people began to use it to share thematic
with people around the world via the Web. The information or to discuss business subjects [8].
social network service also serves as a useful tool With the number of smartphone users on the rise,
to elicit requirements for software development. the relevant advertising and contents markets are
If an agile team reflects the opinions of external likely to expand. The SNS enables
users (i.e. social network users) for specific communication almost on a real-time basis, and
issues, it is likely for the development team to provides a useful vehicle for iterative
reach more trustful decisions and to find out new requirements elicitation under the agile process.
requirements as well. In this paper, we focused In this study, we use the SNS which has the
on the social network service which has interest-based sharing feature to gather user
community related to a specific domain for opinions about specific issues.
issuable topics. That kind of community helps an
agile team obtain what they need without any
unrelated information. To address the issues 3. The Requirements Elicitation
illustrated in the above (1) and (2), we proposed Process with the SNS
the process that integrates the requirements and
opinions from social network users as well as an As mentioned earlier, an agile team carries the
agile team. risks of, for example, overlooking some
important issues or functions, and of
consequently reaching inattentive decisions
2. Background arising out of inexperience on the part of the
agile team has not experienced.
2.1 The Agile Methods
The agile approach shows some features
commonly found in them, such as a repeated
short cycle and a small-sized team. Under the
approach, productivity is maximized through
communication and negotiation with
stakeholders [6]. The agile methods diverse
forms such as XP, SCRUM, DSDM, and Crystal
just to name a few. The story card has been
originally used in XP for elicitation of
requirements. Generally in the agile approach,
elicitation of requirements is conducted in a
customer-centric way. Customers present their
requirements on story cards. Then, the
requirements are prioritized through an repetitive
process, and arranged from highest to lowest in
priority [4][5]. Requirements may be changed
and newly added in an iterating process, and the
agile team reflects customers‟ opinions at any
time during the development process. Fig. 1. Conceptual Overview
Fig. 1 illustrates how requirements are integrated,
which have been elicited both from an agile team
2.2 Definition of Social Network Service
and from SNS users. Described herein is how to
A social network service (SNS) is a virtual incorporate the opinions of external SNS users to
community that serves as a place for people to make up for the aforementioned shortcomings.
KSII The Second International Conference on Internet (ICONI) 2010, December 2010
Fig. 2 shows the six stages of requirements
elicitation. Those are finally applied to a
repetitive agile process.
Fig. 2. The Requirements Elicitation Process
The 1st phase located on top is conducted
earliest in the development process. The next 4
steps in the 2nd phase are repeatedly performed
with an iterative release.
(1) Identifying Quality Attributes
In the first step, some essential quality attributes
(collectively referred to as “QAs”) of the
relevant system are defined using the Quality
Model [9]. By identifying QAs, it is intended to
filter out, for each QA category, non-functional
requirements (NFRs) from functional
requirements (FRs). To do this, a team workshop
may be held, including therein all stakeholders
such as customers and developers. The
development team is in charge of helping the
stakeholders recognize how important QAs are.
ISO/IEC 9126-1 presents a commonly
considered set of QAs as a quality model.
(2) Choosing Related Community
The agile team figures out a community
suitable for the domain of the system to be
developed. Since a user joins a cyber community
of her choice, it seems helpful to use one of the
thematic community services on social networks
such as Twitter, Facebook, and MySpace. To
select a most appropriate community for the
purpose of gathering opinions, it is
recommended to side by a highly ranked
community with a large membership.
481
Observance of the recommended conditions
seems favorable for collection of requirements
without the possible exposure to contamination
by unrelated information.
(3) Eliciting FRs from Agile Team
As represented in Fig. 4, some high-level FRs
are extracted in use of story cards in a
customer-oriented way. Basically, the FRs are
implemented in the time box of the current
release. In addition, participating customers and
developers adjust the number of FRs in
accordance with the relevant release plan and
velocity estimation, as explained in [10].
(4) Selecting and Uploading Topics
Some FRs are selected as topics out of the entire
pool of the FRs elicited in Step (3). Basically,
topics are chosen by customers. Some topics may
be the FRs of business values or marketability.
Also, such matters may turn topics that the agile
team has not experienced previously. If there is
no topic (if an agile team is able to completely
address issues), the agile team completes the
elicitation process. After selecting topics,
customers draw up questionnaires for each topic.
The questionnaire shall be constructed such that
it becomes possible to draw users‟ opinions. In
addition, context-free questions are
recommendable to avoid short responses such as
just „yes or no‟ [11]. Among the commonly used
requirements-eliciting methods such as interview,
questionnaire, use case and prototype,
questionnaires fit most, since most SNSs are
text-based. In case of multiple topics, one or
more SNS communities can be used. Firstly, a
brief explanation is provided to SNS users about
the system and topics at issue. Then, two types of
questionnaires (business and technical) are
uploaded.
 Topics Concerning Business Issues and
Marketability: SNS users are asked what
business values are expected of a system that has
relevant FRs. These questions may be easier than
technical issues to answer. Thus, it is possible,
with the questions, to induce natural
participation from the SNS users. The responses
to these questions help determine whether to
accept or reject relevant FRs and how much
priority to be assigned to. The following are the
examples of the questions:
482 Um et al.: Requirements Elicitation in the Agile Process with Social Network Services

 Have you ever seen any products having

similar functions? If so, do they have
something in common or any differences?
 If the system has this function, how do you
believe the function helps the system excel
others?
 How important role does the function
perform in the entire system? Why do you
believe so?

 Topics Concerning Technical Issues: The

questionnaire may also contain technical issues
concerning implementation of FRs. If customers
and developers do not have enough domain
knowledge or if FRs are new to them, technical
questions can be uploaded. Through these
questions, an agile team is able to obtain useful
tips or considerations for implementation.
Furthermore, new additional FRs related to a
topic could be emerged. The following examples
represent technical questions for the function of a
combat flying simulation game.
Function Description:
“When the fighter is ready to attack, the fighter’s
target zone traces the moving enemy.”
 When multiple enemies come into sight,
which algorithms would be more effective
for traceability of the target zone?
 What kinds of additional user interfaces
would be needed to control the target zone?
According to [12], if the number of questions is
more than 10, respondents are usually passive in
answering them. Thus, we recommend a
maximum set of 10 questions at a time.
Fig. 3. The Example of FR Refinement Form
To refine, this form adopts 3 categories: „subject‟
referring to an actor, „object‟ indicating the target
and „actions‟ referring to activities to be done in
the system. The section „Considerations‟
contains the information not only on the FRs
related to topics, but also on other items such as
constraints and opinions.
(6) Selecting Final FRs and Eliciting NFRs
Through the steps (1) to (5), customers and
developers infer requirements from the agile
team itself and SNS users. After reviewing the
opinions gathered through the SNS, finally
customers choose the FRs really in need.
However, topic-related FRs or newly suggested
FRs are not always selected for a release. If
technical defects are discovered or the customer
no longer demands new FRs, they are rejected.

(5) Collecting and Refining FRs

Customers collect additional requirements and
feedbacks from SNS communities. Once
gathered, information is classified into an FR
type with the use of the FR refinement form, as
shown in Fig. 3. Customers observe users‟
opinions in an SNS community during a release.
Thus refined, the information is used for the
next release. SNS users‟ responses related to
business aspect are written in the „Opinion Lists‟
section. Described in the „FR‟ section are the
detailed information on FRs for a certain topic or
the information on new FRs.
Fig. 4. Enhanced Story Card
Finally, NFRs are derived from the selected
pool of FRs in use of the QA categories on the
story card, as shown in Fig. 4. Eliciting NFRs is
also essential to meet the system‟s quality. The
QA categories (i.e. PER: PERformance; SEC:
SECurity; and AVB: AVailaBility) are on the
bottom of the story card, and the number of the
NFRs is presented for each category.
KSII The Second International Conference on Internet (ICONI) 2010, December 2010 483

4. Conclusions [5] Helen Sharp, Hugh Robinson, Judith Segal,

A small number of people carry out the
requirements-collecting activity under the
existing agile approach. We have incorporated
the SNS in our agile approach to elicit more
requirements and more opinions from external
SNS users. We proposed a process in which SNS
users‟ feedbacks are integrated with an agile
team‟s FRs, thereby, eventually enabling a
customer to choose FRs. The proposed process
makes it possible to overcome the limitations
occurring when a small-sized group elicits
requirements. It further eases out the time
constraints imposed on important topics. Once
refined, story cards help easily elicit quality
requirements. However, the communication
overhead still exists during some of the
processing phases. In addition, results may vary,
depending on how positive participants are. Thus,
it is necessary to conduct experiments to prove
the usefulness of the present approach. In the
future, we plan to work on how to induce more
active participation from SNS users within a
fixed amount of time, and how to systematically
help customers quickly decide on their final FRs.
Dominic Furniss. "The Role of Story Cards
and the Wall in XP teams: a distributed
cognition perspective", Proceedings of
AGILE 2006 Conference(AGILE'06)
[6] Mike Cohn, “User Stories Applied”,
p.133-139.
[7] All about IT Trends, ittrend.egloos.com
[8] The markets get anti-social with social
networks, Deloitte TMT Predictions
[9] ISO / IEC 9126-1 : Software Quality
Characteristics and Metrics Part1 1997
[10] Mike Cohn, "Agile Estimating and
Planning", p.49-60, p.145-165, p.177-186,
2006
[11] Karl.E. Wiegers, “Software Requirements
2nd Edition”, Microsoft, p.123
[12] Huang Longjun, Jiang Changgen, Zhou
Caiying, “The Research of Requirements
Elicitation for Project”, 2010 Second
International Conference on Multimedia
and Information Technology

5. Acknowledgement
This research was funded by the MKE (Ministry
of Knowledge and Economy), Korea, under the
ITRC (Information Technology Research
Center) support program supervised by the
NIPA (National IT Industry Promotion
Agency)" (NIPA-2010-(C1090-1031-0001))

References
[1] Mario Pichler, Hildegard Rumetshofer,
"Agile Requirements Engineering for a
Social Insurance for Occupational Risks
Organization: A Case Study", 14th IEEE
International Requirements Engineering
Conference(RE'06), 2006
[2] Manifesto for agile software development,
http://www.agilemanifesto.org
[3] Seiyoung Lee, Hwan-Seung Yong, “Design
and Evaluation of Agile Framework for
Small Projects
[4] Ron Jeffries, Ann Anderson, Chet
Handrickson. "Extreme Programming
Installed", p.37-44