J. Software Engineering & Applications, 2010, 3, 890-893
doi:10.4236/jsea.2010.39104 Published Online September 2010 (http://www.SciRP.org/journal/jsea)
Investigating the Suitability of Agile Methods for
Requirements Development of Home Care Systems
Sandra Kelly, Frank Keenan
Dundalk Institute of Technology, Dundalk, Ireland.
ABSTRACT
The ageing population in developed countries brings many benefits but also many challenges, particularly in terms of
the development of appropriate technology to support their ability to remain in their own home environment. One par-
ticular cha llenge reported for such Home Care Systems (HCS) is the identification of an approp riate requirements de-
velopment technique for dealing with the typical diverse stakeholders involved. Agile Methods (AMs) recognize this
challenge and propose techn iques that could be useful. This paper examines the desirable characteristics identified for
requirements development in HCS and investigates the extent to which agile practices conform to these. It also sets out
future work to improve the situation for the non compliant points found.
Keywords: Home Care Systems (HCS), Agile Methods, Requirements Development
1. Introduction
According to the World Health Organisation (WHO), the
population of over 60s in developing countries is ex-
pected to triple from “400 million to 1.7 billio n” over the
next forty years [1]. Rising healthcare costs and lack of
resources in terms of hospitals and the availability of
skilled doctors and nurses mean that by 2050, this situa-
tion will become unsustainable. In Ireland 11% of the
population is currently over 65 and this is expected to
double over the next 25 years, in particular a threefold
increase in those aged 80 and above is expected [2]. Ac-
commodating the ageing population is and will continue
to be an increasing challenge. For example, Technology
Research for Independent Living (TRIL) report that 40%
of older people are prematurely institutionalised due to
injuries sustained from falls in the home [3]. In general it
is beneficial to develop alternative approaches to prevent
or delay the institutionalisation of older people, enabling
the elderly to remain at home. This has subsequently
required an increase in the need to develop HCS.
HCS is defined as “a potentially linked set of services
including social care and health care that provide or
support the provision of care in the home” [4]. Along
with the cared person, many other stakeholders are in-
volved including family members, social care, home help,
health nurses and GPs. Given such diversity of back-
ground, perspective and experience, and perhaps geo-
graphic distribution, identification, access to and en-
gagement of the appropriate stakeholders to identify re-
quirements is difficult. To complicate things further,
modes of interaction are expected to be subject to con-
tinuous change over time as the condition of the home
dweller may change [5]. Identification of a more suitable
approach for requirements development is necessary.
Despite the numerous techniques that exist for re-
quirements development [6] and, indeed, efforts made to
classify them [7,8] it is claimed that current techniques
are inadequate, while McGee-Lennon suggests that a
novel approach is required. Despite this, it is acknowl-
edged that potential does exist if techniques could be
modified to deal with a “combination of multiple distrib-
uted and possibly conflicting stakeholder needs” along
with “long term configuration and evolution of these
needs” [5]. In general, for HCS, any approach should be
“lightweight enough to be useable yet rigorous so as to
be justifiable” [4].
A potential solution may however be offered through
the principles and practices suggested by agile develop-
ment. The Agile Manifesto promotes values of close and
continuous interaction between all interested stake-
holders, including the customer and development team,
very short iterations of fully working, and tested, soft-
ware, which provides the ability to easily accommodate
changing requirements [9]. At an initial inspection it
appears that the characteristics of agile development
closely match those identified for HCS.
This paper compares the desirable characteristics of

Investigating the Suitability of Agile Methods for Requirements Development of Home Care Systems 891
requirements development in HCS identified by [5] with
the general approach recommended for handling re-
quirements in agile development. Section 2 looks at how
requirements are developed in an agile setting, Section 3
compares the characteristics of HCS with AMs, while
Section 4 concludes th e paper and outlines future work.
2. Agile Requirements Development
AMs recommend a highly participative and iterative ap-
proach to requirements development [10]. Initially, re-
quirements are briefly documented, typically through
user stories. Usually for user stories a high level user
request is written on an index card or post-it note. Along
with specific functionality required, other relevant in-
formation such as story title, release date, order of prior-
ity, author’s initials and time estimates to complete can
also be included. During development, each story is used
to provoke an in-depth discussion between developers
and other stakeholders to examine each requirement in
detail [11].
Initially, collectively, user stories identify a high level
plan for each release of the project. The customer priori-
tizes each story according to business value. Attention is
then focused on the first release with a number of priori-
tized stories used to identify the first short iteration.
Typically this is a week or two in length [10]. Developers
further divide the stories into tasks and estimate a time-
frame to complete each task. It is expected that each
story is considered to be a placeholder, indicating that an
in-depth analysis will be con ducted during the iteration.
User stories and their associated tasks are placed to-
gether on a publicly-visible story board. The board fre-
quently referred to as “the wall” by [12], is the main fo-
cal point of the room. Developers choose a story to com-
plete from the board and commit to this by signing their
initials on the story card and taking it from the board for
development. When the user story is complete, the de-
veloper ticks the card and returns it to a new position on
the story board. Alternatively, if the story is not fully
complete, the card is considered to be still pending and is
returned to the same position on the board. Complete
stories become features of the system where they can be
further developed in upcoming iterations.
The story board provides a clear indication of what
work has been done and what has yet to be completed.
Stories placed with their tasks also allow developers to
envisage dependencies, essentially providing a visual
representation of the work plan to the team. The colour
of a card can also be used to convey specific meaning
and can indicate warning signs. Some examples from [12]
showed:
 Green cards signified stories, white for tasks;
 Blue cards related to features for staff;
 Orange flags indicated incomplete acceptance tests;
 Pink cards desc ribed bugs.
The positioning of the cards on the story board can
also communicate specific meaning. The top three rows
for instance in [13] contained recently completed stories.
To the left of the board were scheduled stories and to the
right were unscheduled stories.
2.1. The Customer Role
A key role for successful requirements development
within AMs is that of the customer, which differs from
that expected in a traditional development project, for
example with the waterfall approach the customer is in-
volved at the beginning of a project and the relationship
between the customer and the development te am th rou gh-
hout the project is contractual, whereas AMs prefer the
customer to be continuously involved for the duration of
the project. However, a misconception with early AMs is
that customer involvement was often reduced to a single
on-site customer with little guidance provided on how to
implement this role.
In distinguishing between traditional and agile Re-
quirements Engineering (RE) practice in industry, Cao &
Ramesh found that the “inability to gain access to the
customer and obtaining consensus among stakeholder
groups” were the most common challenges experienced
[14]. Martin et al. report eight practices that were used in
successful projects to enable real customer involvement
[15]. The authors illustrate the complexity of customer
representation, identifying ten roles on a customer team,
these were informally created with little prior guidance to
support the customer role. Each person on the customer
team negotiates with and represents a widely diverse
group of stakeholders.
Many authors have expressed the importance of hav-
ing the appropriate and relevant stakeholders on board. In
examining critical success factors in software develop-
ment, Boehm and Turner found that the customer role
should comprise of individuals who are Collaborative,
Representative, Authorized, Committed and Knowl-
edgeable (CRACK), deeming these crucial attributes
stakeholder representatives should possess in imple-
menting the customer role [16]. Hence, performing the
customer role in agile projects is a challenging task, fre-
quently taken for granted.
3. Agile Methods for HCS?
McBryan et al. identify ten desirable characteristics an
RE method should possess for HCS [5]. Table 1 summa-
rizes these characteristics in column 1 with an indication
of how AMs match these in column 2. Two ticks indicate
that AMs comply fully with the characteristic, one tick
indicates partial compliance and ‘x’ indicates no compli-

Investigating the Suitability of Agile Methods for Requirements Development of Home Care Systems 892
Table 1. HCS characteristics and agile methods compliancy
mapping.
Characteristics AMs
Iterative development 
Prioritization 
Correlation with other processes 
Appropriate stakeholders 
Participatory elicitation 
Identification of conflict 
Resolution of conflict 
Retention & traceability 
Annotation 
Distributed elicitation 
ance with the characteristic. The following poin ts discuss
the varying degrees of compliance between these.
Iterative development: with AMs, short iterations of
fully working software provide opportunities for con-
tinuous stakeholder input. Perceived needs can be clari-
fied and new ones emerge. As circumstances change re-
quirements will evolve based on stakeholder input. This
is a characteristic AMs are fully compliant with.
Prioritisation of requirements: different stakeholders
may need to be given different priorities depending on a
variety of circumstances. Specifically in [5], the authors
point out that in relation to particular features, if for in-
stance, usability is an issue then the needs of the person
in care may be the highest priority whereas care profes-
sionals may have higher priority requirements if it is the
case that the person concerned is a “risk to themselves or
others” in the home environment. AMs are fully compli-
ant with this characteristic as features can be prioritized
at the beginning of each iteration.
Correlation with other processes and work practices
calls for immediate benefit from solutions required. This
is entirely consistent with the agile approach which pro-
motes the early delivery of high quality ‘working soft-
ware’ to satisfy the customer’s business objective.
Identification and Engagement of appropriate stake-
holders is partially compliant as AMs recognize the need
for this. Although this is promoted within AMs and nu-
merous successes have been reported, difficulties have
emerged in certain situations particularly when multiple
stakeholders are involved. However, no generalized
method as such can be applied here since realizing this
depends on constraints and circumstances often unique to
each situation.
Participatory elicitation and negotiation requires thos e
involved in a care network including the cared person to
negotiate the suitability of a potential device or care ser-
vice proposed. Essentially, an opportunity to demonstrate
a candidate device or interaction mode to stakeholders in
advance of decisions to be made is necessary. This char-
acteristic is partially compliant as Active Stakeholder
Participation (ASP) is encouraged in AMs but achieving
this in practice remains problematic.
Identification of conflict partially complies since AMs
encourage conf lict to be aired as soon as possible but this
is often challenging if relevant stakeholders are not ac-
tively involved or, as is frequently reported, only identi-
fied during the latter stages of development.
Resolution of conflict partially complies, although the
need to air and resolve conflict early is recognized, suc-
cess here is again dependent on stakeholders’ active par-
ticipation in the project.
Retention and traceability of requirements is partially
compliant since AMs only retain artefacts such as user
stories for as long as they are deemed useful. Agile prac-
titioners recommend questioning traceability in terms of
time to complete and the re-examination of what value it
brings to stakeholders. This is to ensure that while trace-
ability may be needed, it must be applied in a timely
manner. An option here is to employ an appropriate pro-
ject management tool that does not detract from the
overall effort required in developing and maintaining the
software solution. Examples of available tools include
Envision VIP 9 and PACE 3.
Annotations to facilitate negotiation and traceability, is
also partially compliant as story cards are often anno tated.
However, it is likely that agile practitioners would inte-
grate the annotation as a main part of the user story. In
particular, this characteristic intends to add further con-
text to a requirement.
Distributed elicitation is a characteristic AMs are par-
tially compliant with since although AMs prefer face to
face communication, other means such as email and
video conferencing are most often used for dispersed
stakeholders. In addition to tools mentioned previously,
other tools, particularly XPlanner and TargetProcess en-
able distributed teams to communicate with geographi-
cally dispersed stakeholders.
Here, AMs are fully compliant with three characteris-
tics of a desirable approach to requirements development
in HCS. However, AMs show only partial compliance
with the remaining seven characteristics in dicating future
work needed to improve on these.
4. Conclusions and Further Work
In summary, due to the expected increase in older popu-
lations, the need to develop HCS is evident. Success in
software systems heavily depends on accurately obtain-

Investigating the Suitability of Agile Methods for Requirements Development of Home Care Systems 893
ing requirements from stakeholders. It is also difficult to
identify access, engage and support continuous negotia-
tion of requirements amongst relevant stakeholders. De-
spite the numerous elicitation techniques available, ac-
commodating diversity amongst multiple stakeholder
groups remains a key challenge. Suggestions made to
improve on this include a new or adaptive approach to
requirements development, However it is not entirely
clear how this could be achieved. AMs may provide a
solution but particularly, an important concern here is in
effective implementation of the customer role. This paper
compared the desirable characteristics for RE in HCS
with agile methods and indicates that there is a close
match. However, challenges still exist as AMs are only
partially compliant with many of the remaining charac-
teristics. Future work will investigate how this position
can be further i mproved.
REFERENCES
[1] World Health Organization (WHO), “Public Health Impli-
cations of Global Ageing,” 2010. http://www.who int/fea-
tures/qa/42/en/index.html
[2] S. Roberts, T. Basi, A. Drazin and J. Wherton, “Connec-
tions: Mobility and Quality of Life for Older People in
Rural Ireland” Intel Corporation, America, 2007.
[3] Technology Research for Independent Living (TRIL)
“Falls Prevention,” 2010. http://www.trilcentre.org/falls_
prevention/falls_prevention.474.html
[4] M. R. McGee-Lennon, “Requirements Engineering for
Home Care Technology,” Proceeding of the 26th Annual
SIGCHI Conference on Human Factors in Computing
Systems, Florence, Italy, 2008, pp. 1439-1442.
[5] T. McBryan, M. R. McGee-Lennon and P. Gray, “An
Integrated Approach to Supporting Interaction Evolution
in Home Care Systems,” Proceedings of the 1st interna-
tional Conference on Pervasive Technologies Related To
Assistive Environments, Athens, July 2008, pp. 1-8.
[6] A. Davis, O. Dieste, A. Hickey, N. Juristo and A. M.
Moreno, “Effectiveness of Requirements Elicitation
Techniques: Empirical Results Derived from a Systematic
Review,” Proceedings of 14th IEEE International Con-
ference of Requirements Engineering, Minneapolis, Sep-
tember 2006, pp. 179-188.
[7] H. Van Vliet, Ed., “Software Engineering Principles and
Practice,” John Wiley & Sons Ltd., Chichester, 2000.
[8] B. Nuseibeh and S. Easterbrook, “Requirements Engi-
neering: A Roadmap,” Proceedings of International Con-
ference on Software Engineering, ACM Press, Limerick
Ireland, 2000.
[9] K. Beck, et al. “The Agile Manifesto,” 2001. http://www.
agilealliance.com
[10] S. W. Ambler, “Agile Modeling: Effective Practices for
Extreme Programming and the Unified Process,” John
Wiley & Sons Inc., Chichester, 2002.
[11] D. Astels, G. Miller and N. Miroslav, “A Practical Guide
to Extreme Programming,” Prentice Hall, New Jersey,
2002.
[12] H. Sharp, H. Robinson, J. Segal and D. Furniss, “The
Role of Story Cards and the Wall in XP teams: A Distrib-
uted Cognition Perspective,” Proceedings of Agile, IEEE
Computer, Society Press, Washington, DC, 2006, pp. 65-
75.
[13] W. Pietri, “An XP Team Room,” 2004. http://www.scis-
sor .com/resources/teamroom
[14] L. Cao and B. Ramesh, “Agile Requirements Engineering
Practices: An Empirical Study,” Software, IEEE, Vol. 25,
No. 1, 2008, pp. 60-67.
[15] A. Martin, R. Biddle and J. Noble. “XP Customer Prac-
tices: A Grounded Theory,” Proceedings of Agile Con-
ference, agile, Chicago, August 2009, pp. 33-40.
[16] B. W. Boehm and R. Turner, “Using Risk to Balance
Agile and Plan-Driven Methods,” Computer, Vol. 36, No.
6, 2003, pp. 57-66.