Вы находитесь на странице: 1из 4

Towards an Evolutionary Framework for Agile

Requirements Elicitation
Sandra Kelly
Dundalk Institute of Technology
sandra.kelly@dkit.ie
ABSTRACT

recognised that no single technique is sufficient [5],


rather, a combination is needed. Some challenges are that
stakeholders have trouble seeing beyond the current
situation, developers dont sufficiently understand the
problem domain and as a result they dont fully understand
requirements [6]. Also identifying, gaining access to, and
engaging stakeholders is a difficult task.

Numerous reports document difficulties experienced with the


development of requirements in software projects.
Specifically problems include: developers have limited
access to stakeholders, dont fully understand the problem
domain and as a consequence, requirements are not well
understood. Agile Methods (AMs) encourage stakeholder
involvement throughout development however considerable
difficulty remains in accommodating continuous negotiation
between multiple diverse stakeholders in a given domain.
This paper reports on progress to date for developing an
evolutionary framework to improve the facilitation of agile
requirements elicitation. A potential solution is offered and
an initial study indicates positive results.

Requirements engineering (RE) involves the identification,


description, verification, validation and management of
requirements in software development [7]. The traditional
approach necessitates an extensive requirements
investigation at the beginning of a project producing a
formal specification. Usually, these specifications remain
fixed until project completion. However, requirements are
subject to continuous change [8] which this rigorous
approach has difficulty in accommodating. In response,
AMs have emerged and become increasingly popular. Here,
software is fully developed in short iterations enabling
regular feedback from stakeholders, providing opportunities
to frequently adjust expectations and requirements. With
AMs, requirements are initially documented through user
stories. Usually for user stories a high level user request is
written on an index card or post-it note. Other relevant
information such as story title, date, developers initials and
time estimates to complete are added to the story card.
Initially user stories are used to identify a high level plan
for each release of the project. Attention is then focused on
the first release with a number of stories used to identify the
first short iteration. Each story card is then used to provoke
an in depth discussion between developers and other
stakeholders.

Author Keywords

Requirements, Elicitation, Agile Methods (AMs), Open


Space Technology (OST), Scenarios.
ACM Classification Keywords

D.2.1. Requirements/Specifications: Elicitation Methods.


H.5.4. Hypertext/Hypermedia: User Issues. H.5.3. Group and
Organization Interfaces: Web-based Interaction
General Terms

Human Factors, Experimentation, Design.


INTRODUCTION

It is widely acknowledged that getting the requirements


right is crucial for successful software development. One
report claims that inaccurate system requirements are the
major factor in the failure of 90% of large software projects
[1]. Also, fixing mistakes made at the requirements
elicitation stage accounts for 75% of all error removal costs
[2]. One particular area where problems have been
expressed is in the development of interactive systems.
Only 16% of large web applications fully meet
requirements and 53% of internet projects do not fulfil
business needs [3]. Numerous techniques exist for
requirements development [4] however, generally it is

Despite widespread use, problems have been reported for


interactive systems development, however, some
suggestions for adapting current RE methods have been
made. These include: gaining a greater understanding of the
system context; involving relevant stakeholders; iteratively
defining requirements; and the need for stakeholders to
repeatedly negotiate requirements overtime [7].
The
dynamic nature of Home Care Systems (HCS) further
illustrates that a fresh approach is needed for identifying,
negotiating and resolving changing requirements [8]. In
addition, to resolving potential conflict, requirements
elicitation must endeavour to facilitate effective
communication and negotiation amongst multiple diverse
stakeholder groups [9]. This paper reports on the
development an evolutionary framework to improve the

Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise,
or republish, to post on servers or to redistribute to lists, requires prior
specific permission and/or a fee.
EICS10, June 1923, 2010, Berlin, Germany.
Copyright 2010 ACM 978-1-4503-0083-4/10/06...$10.00.

349

facilitation of agile requirements elicitation. Section 2


describes related work, section 3 presents research
questions, a potential solution linking Open Space
Technology (OST) with user stories through scenarios, is
proposed in section 4 followed by progress to date in
section 5. Section 6 concludes the paper and outlines future
work.

This research is inductive with results emerging over time.


Hence, the most appropriate strategy of inquiry is
qualitative research. In relation to the sampling strategy,
data will be collected using interviews and observations.
Data analysis will be achieved through open, axial and
selective coding to determine themes and categories that
emerge as the study progresses.
Proposed Solution

Related Work

A potential solution is offered by linking OST with user


stories through scenarios. OST is an evolutionary approach,
recommended for complex situations involving diverse
participants, a complexity of elements, passion (including
conflict) and the need for a quick decision [14]. Established
in 1985, OST has a proven track record for enabling diverse
participants who have a genuine interest in solving some
issue of importance to engage and achieve a solution in an
incredibly productive yet simple manner. Because simple
tools such as flipcharts, pens and paper are used, there is
virtually no learning curve involved and success has been
reported where groups from 5 to 2000 have participated.

One oversight 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. Martin
et al. report eight practices that were used by successful XP
teams to enable real customer involvement [10]. 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.
Scenario-based usability techniques can be successfully
incorporated into agile development [11]. However, beyond
the customer representative, this does not aim to address the
issue of continuous involvement and negotiation of
requirements among all relevant stakeholders. Tartaglia et
al. report success in using open space to resolve cross-team
development issues [12]. Whilst communication was strong
between project managers and programmers, it was weak
between business analysts and programmers creating issues
that were successfully resolved using open space. In HCS
Newell et al. use live forum theatre to stimulate discussion
between users and designers [13]. This is achieved through
experienced script writers and scenes enacted by
professional actors. In contrast to an agile setting, a
bottleneck here is in the specialized skill required, the cost
and time consumption particularly in transcribing the
sessions. McBryan et al. developed an iterative model for
interaction evolution to manage sources of change in HCS
[8]. This model is clearly ideal in HCS and has the potential
to be applied in RE across other domains. But the authors
make no reference as to how the model could be integrated
into software development projects.

OST requires that based on a theme usually defined in


advance, participants create the meeting agenda themselves.
Each issue on the agenda is called a concern and must
directly relate to the theme. Participants voice concerns
specific to their own experience at the beginning of the
meeting. Other participants, who dont have a specific
concern but can relate to a concern already raised, sign up
to partake in a discussion to explore and improve the
concern. For example these participants may have
experience in the area, particular expertise to offer or may
simply benefit by learning from the experience of the others
in the group.
An important advantage of using OST during requirements
elicitation is that stakeholders, being the experts in the
domain collaborate with developers toward a solution by
exploring concerns prior to writing user stories. This
encourages stakeholders to think beyond the current
situation and to re-examine the viability of current business
process, which has essentially led to the original request for
a software solution from developers. Likewise developers
also have an opportunity to understand the business domain
more clearly before developing a software solution. It is
envisaged that open space would create an interactive
learning environment for all stakeholders to exchange
knowledge and skill while moving toward a solution in an
all-inclusive and collaborative manner.

Research Question

The research question to be investigated here is: How can


an evolutionary framework be developed to improve the
facilitation of agile requirements elicitation?
Objectives set out to answer this question are:
1. Investigate and classify the factors that affect the
communication of requirements between developers
and other stakeholders
2. Investigate and classify agile software development
approaches with particular relevance to the customer
role
3. Develop a suitable solution
4. Evaluate the solution in an appropriate environment

Scenarios in this context should be viewed from the


perspective of the CREWS report [15]. Here, rather than
being interpreted as purely textual descriptions scenarios
are considered under four distinct views: Form, purpose,
contents and lifecycle. As an output mechanism to OST,
scenarios in this view permit multiple modes of expression
for example, they can be informally or formally described
in either static, animated or interactive ways. Noteworthy is
that in this sense, scenarios fulfill the element of flexibility

350

needed for an evolutionary approach by ensuring that the


output mechanism does not by its nature restrict the content
produced by participants at an OST meeting.

While three characteristics fully comply, AMs are only


partially compliant with the above seven.
To establish whether or not it would be practical to combine
OST with a software development process, an initial
exploratory study was conducted with 14 final year
computing students, divided into two even groups. One
followed XP and the other the OST/XP linked approach.
During development each had access to a customer
representative. Both teams were required to address the
same problem, a Student Registration System, within an
eight hour time frame spread across four separate sessions.
Observations and questionnaires were used to collect data.
The XP group seemed to take a more plan-driven approach
with a large initial design. The OST/XP group appeared to
be more focused on and better understand the whole
problem. Observations indicated that scope creep was an
issue for the XP group. Also, they initially expressed
difficulty using XP because it doesnt provide a clear
path. Feedback indicated that overall the OST/XP group
felt that the linked approach was beneficial for: exploring
requirements with the customer prior to writing stories;
clarifying misunderstandings amongst the group;
prioritizing requirements and writing user stories. Despite
extra time required initially, the OST/XP group did not
appear to suffer in terms of productivity with at least as
much functionality developed by the project end. Also, user
stories and acceptance tests appeared to be of higher
quality.

In this work, OST is used by all stakeholders to discuss and


agree a theme to focus progress. Concerns raised can
represent high level requirements which are later
prioritized. Stakeholders subsequently develop scenarios for
the highest priority concern. From this more focused view
user stories are then developed before the next concern is
considered.
Progress to date

To date, progress has been made on a number of fronts.


Firstly, in addition to a review of the literature, local
organizations are currently being interviewed to establish
the state of the art. The suitability of AMs for interactive
systems, particularly HCS, has been examined and is
currently under review at another conference. This
identified that despite a close match, AMs fall short on the
following points:
1) Identification and Engagement of appropriate
stakeholders is partially compliant as AMs recognize the
need for this, however, no generalized methodical approach
as such can be applied here since realizing this depends on
constraints and circumstances often unique to each
situation.
2) Participatory elicitation is only partially compliant as
Active Stakeholder Participation (ASP) is encouraged in
AMs but achieving this remains problematic.

Conclusions and Future Work

In summary, it is difficult to identify, access and engage


relevant stakeholders, this contributes toward problems for
developers in gaining a sufficient understanding of
requirements in the problem domain. Also stakeholders are
unable to see beyond the current situation. Agile methods
may be able to improve on this. A comparison of ten
desirable RE characteristics identified by [8], with AMs
indicates a close match however, AMs, in relation to seven
of these, fall short indicating only partial compliance. A
potential solution is to link OST with XP through scenarios
to overcome partially compliant points. An initial study,
although limited, has provided positive feedback indicating
that the linked approach is helpful for exploring and
clarifying requirements prior to writing user stories and that
this can be achieved in an agile manner. Future work will
report on the findings from industry in answering the
research question and objectives, the primary focus here is
to compare the literature with practice and to evaluate the
linked approach.

3) Identification of conflict partially complies since AMs


encourage conflict to be aired as soon as possible but this is
often challenging if relevant stakeholders are not actively
involved or as is often reported, only identified during the
latter stages of development.
4) Resolution of conflict partially complies because
although the need to air and resolve conflict early is
recognized, success here depends again on stakeholders
active participation in the project
5) Retention and traceability of requirements is partially
compliant because AMs only retain artifacts such as user
stories for as long as they are deemed useful and
traceability is questionable and only employed if
stakeholders specifically request a need for it.
6) Annotations to facilitate negotiation and traceability is
also partially compliant as physical story cards can be
annotated. However, it is likely that agilists would integrate
the annotation as a main part of the user story. In particular,
this characteristic intends to bring further context to a
requirement.

REFERENCES

1. Davis, CJ., Fuller, RM., Tremblay, M.C. and Berndt D.J.


(2006). Communication Challenges in Requirements
Elicitation and the Use of the Repertory Grid Technique
Journal of Computer Information Systems, 46, (5), 78.

7) Distributed elicitation partially complies because


although AMs prefer face to face communication, other
means such as video conferencing are often used for
dispersed stakeholders.

351

2. Urquhart, C. (1999). Themes in early requirements


gathering: The case of the analyst, the client and the
student assistance scheme. Information Technology &
People, 12(1), 44.

Assistive Environments, vol. 282. ACM, New York, NY,


1-8.
9. Nuseibeh, B. and Easterbrook, S. (2000) Requirements
Engineering: A Roadmap. ICSE-2000. ACM Press,
Limerick, Ireland.

3. Cutter Consortium. (2000). Poor Project Management


Number-one Problem of Outsourced E-projects, Cutter
Research Briefs,
http://www.cutter.com/research/2000/crb001107.html

10. Martin, A., Biddle R. and Noble J. (2009) Agile


Conference, XP Customer Practices: A Grounded Theory,
agile, pp.33-40.

4. Davis, A., Dieste, O., Hickey, A., Juristo, N. and Moreno,


A.M. (2006). Effectiveness of Requirements Elicitation
Techniques: Empirical Results Derived from a Systematic
Review, Requirements Engineering. 14th IEEE
International Conference, vol., no., 179-188, 11-15

11. Obendorf, H. and Finck, M. (2008). Scenario-based


usability engineering techniques in agile development
processes. Extended Abstracts on Human Factors in
Computing Systems CHI 2008. ACM, New York, NY,
2159-2166.

5. Alexander, I. et al. (2009). Discovering Requirements.


John Wiley & Sons Ltd. P 16.

12. Tartaglia, C. M. and Ramnath, P. (2005) Using Open


Spaces to Resolve Cross Team Issue, Agile Development
Conference, ADC 2005. 173-179.

6. Ambysoft Inc. (2009). Agile Requirements Modeling,


http://www.agilemodeling.com/essays/agileRequirements
.htm#Challenges

13. Newell, A. F., Carmichael, A., Morgan, M., and


Dickinson, A. (2006). The use of theatre in requirements
gathering and usability studies. Interactive. Computing,
18(5), 996-1011.

7. Grnbacher, P. (2006) Requirements Engineering for


Web Applications In: Kappel, G. Proll, B. Reich, S.
Retschitzegger, W. Web Engineering John Wiley & Sons
Ltd

14. Owen, H. (1995). Tales from Open Space. Abbot


Publishing, Maryland, USA.

8. McBryan, T., McGee-Lennon, M. R., and Gray, P.


(2008). An integrated approach to supporting interaction
evolution in home care systems. 1st international
Conference on Pervasive Technologies Related To

15. Rolland, C., Achour, C. B., Cauvet, C., Ralyt, J.,


Sutcliffe, A., Maiden, N., Jarke, M., Haumer, P., Pohl,
K., Dubois, E., and Heymans, P. 1998. A proposal for a
scenario classification framework. Requir. Eng. 3, 1
(Sep. 1998), 23-47.

352

Вам также может понравиться