You are on page 1of 5

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
Department of Computer Science & Engineering, Korea University
Anam-Dong, Sungbuk-Gu, Seoul 136-713, Korea
Seoul, South Korea
[e-mail: ompa, nunghoi, tellmehenry,]
*Corresponding author: Hoh Peter In


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

Fig. 2 shows the six stages of requirements Observance of the recommended conditions
elicitation. Those are finally applied to a seems favorable for collection of requirements
repetitive agile process. 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.
Fig. 2. The Requirements Elicitation Process Also, such matters may turn topics that the agile
team has not experienced previously. If there is
The 1st phase located on top is conducted no topic (if an agile team is able to completely
earliest in the development process. The next 4 address issues), the agile team completes the
steps in the 2nd phase are repeatedly performed elicitation process. After selecting topics,
with an iterative release. customers draw up questionnaires for each topic.
The questionnaire shall be constructed such that
(1) Identifying Quality Attributes it becomes possible to draw users‟ opinions. In
In the first step, some essential quality attributes addition, context-free questions are
(collectively referred to as “QAs”) of the recommendable to avoid short responses such as
relevant system are defined using the Quality just „yes or no‟ [11]. Among the commonly used
Model [9]. By identifying QAs, it is intended to requirements-eliciting methods such as interview,
filter out, for each QA category, non-functional questionnaire, use case and prototype,
requirements (NFRs) from functional questionnaires fit most, since most SNSs are
requirements (FRs). To do this, a team workshop text-based. In case of multiple topics, one or
may be held, including therein all stakeholders more SNS communities can be used. Firstly, a
such as customers and developers. The brief explanation is provided to SNS users about
development team is in charge of helping the the system and topics at issue. Then, two types of
stakeholders recognize how important QAs are. questionnaires (business and technical) are
ISO/IEC 9126-1 presents a commonly uploaded.
considered set of QAs as a quality model.
 Topics Concerning Business Issues and
Marketability: SNS users are asked what
(2) Choosing Related Community
The agile team figures out a community business values are expected of a system that has
suitable for the domain of the system to be relevant FRs. These questions may be easier than
developed. Since a user joins a cyber community technical issues to answer. Thus, it is possible,
of her choice, it seems helpful to use one of the with the questions, to induce natural
thematic community services on social networks participation from the SNS users. The responses
such as Twitter, Facebook, and MySpace. To to these questions help determine whether to
select a most appropriate community for the accept or reject relevant FRs and how much
purpose of gathering opinions, it is priority to be assigned to. The following are the
recommended to side by a highly ranked examples of the questions:
community with a large membership.
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
 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 Fig. 3. The Example of FR Refinement Form
questions can be uploaded. Through these To refine, this form adopts 3 categories: „subject‟
questions, an agile team is able to obtain useful referring to an actor, „object‟ indicating the target
tips or considerations for implementation. and „actions‟ referring to activities to be done in
Furthermore, new additional FRs related to a the system. The section „Considerations‟
topic could be emerged. The following examples contains the information not only on the FRs
represent technical questions for the function of a related to topics, but also on other items such as
combat flying simulation game. constraints and opinions.
Function Description:
(6) Selecting Final FRs and Eliciting NFRs
“When the fighter is ready to attack, the fighter’s
Through the steps (1) to (5), customers and
target zone traces the moving enemy.”
developers infer requirements from the agile
 When multiple enemies come into sight, team itself and SNS users. After reviewing the
which algorithms would be more effective opinions gathered through the SNS, finally
for traceability of the target zone? customers choose the FRs really in need.
 What kinds of additional user interfaces However, topic-related FRs or newly suggested
would be needed to control the target zone? FRs are not always selected for a release. If
technical defects are discovered or the customer
According to [12], if the number of questions is no longer demands new FRs, they are rejected.
more than 10, respondents are usually passive in
answering them. Thus, we recommend a
maximum set of 10 questions at a time.

(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‟ Fig. 4. Enhanced Story Card
opinions in an SNS community during a release.
Thus refined, the information is used for the Finally, NFRs are derived from the selected
next release. SNS users‟ responses related to pool of FRs in use of the QA categories on the
business aspect are written in the „Opinion Lists‟ story card, as shown in Fig. 4. Eliciting NFRs is
section. Described in the „FR‟ section are the also essential to meet the system‟s quality. The
detailed information on FRs for a certain topic or QA categories (i.e. PER: PERformance; SEC:
the information on new FRs. 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,

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

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

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