Agile, Requirements Practices

Cao and Ramesh (2008) empirically investigated the benefits and challenges
associated with agile requirements techniques in practice. They investigated
agile requirements practices in 16 organizations, and identified 7 important
development practices, many of which are reported on this and the following
slides. Full details are available in the cited paper.
The first important practice is face-to-face communication of requirements
over written specifications. This practice should not be a surprise, given that it
is central to agile development practices. One important benefit was that
customers can steer the project in unanticipated directions, especially when
their requirements evolve owing to changes in the environment or their own
understanding of the software solution.
However several challenges and downsides were also reported. Effective
communication depended heavily on intensive interaction between customers
and developers. When interaction did not work, requirements were
inadequately developed or even wrong. Factors influencing good
communication included customer availability and consensus between
customer groups. Another problem was finding on-site customers. As a result,
in some cases, product managers act as surrogate customers. When more
than one customer group with different needs and perspectives were involved
it was difficult to achieve consensus between them in the time available during
development cycles. As a result requirements negotiation suffered. Finally,
customers sometimes found it difficult to understand or trust agile
requirements processes. Establishing trust, although critical, could be difficult,
especially if customers were familiar with more traditional processes.

Cao L. & Ramesh B., 2008, ‘Agile Requirements Engineering Practices: An Empirical Study, IEEE Software,  25(1), 60-67.

In 14 of the 16 organizations reviewed, requirements emerged during
development, and not beforehand. Reasons for commencing
development without spending much time on requirements initially
included high requirements volatility, incomplete knowledge of the
technology used in development, and customers who can clearly define
the requirements only when they see them. Agile requirements
continues during each development cycle. At the start of each cycle the
customer meets with the development team to provide detailed
information on a set of features to be implemented. During this process,
requirements are discussed at a greater level of detail, and intertwined
with design. This often results in a set of requirements and a preliminary
design, and sometimes even an implementation plan. However, this
parallel requirements and design work can lead to the discovery of
useful and interesting solutions, as supported in creativity workshops.
However, problems with discovering requirements late also led to
problems. Lack of documentation can lead to ignorance and poor
analysis of non-functional requirements such as security and
performance. Lack of documentation also led to problems inducting
new members into the project team as insufficient material is written
down and easily accessible.
Another important practice in agile requirements projects was different
forms of requirements prioritization. Whereas traditional requirements
projects tend to prioritize requirements just once, agile requirements
teams prioritize requirements for each development cycle. One
consequence is that requirements are prioritized more on business
value rather than other criteria, in particular non-functional requirements
such as the need for an architecture to be scalable. Continuous reprioritization of requirements can also be seen to be destablizing to the
project.
Accommodating requirements changes during development is a way of
tuning the system to satisfy customer needs better. Changes are easier
to implement and cost less in agile development. Agile development
projects often report 2 types of requirements changes: adding or
dropping features, and changing already implemented features. In
contrast changes made in responses to unsatisfied requirements at the
end of each development cycle are rare, suggesting that requirements
are satisfied when prioritized.
In several organizations the architecture that the development team
chose during the early cycles became inadequate as requirements
changed. Redesign of the architecture added significantly to project
cost. Refactoring software can reduce costs, but the need to refactor
software is not always to agile development projects.
Another 2 common agile requirements practices are prototyping and
using review meetings and acceptance tests. Prototyping benefits and
challenges are similar to the issues reported in the first half of the
lecture. Software prototypes that are developed from features
implemented in earlier development cycles can improve communication
with customers. However, there are dangers that software prototypes
tend to become more operational software unintentionally, and this can
lead to problems relating to the quality of the resulting software system.
Almost all the organizations analyzed used frequent review meetings
for requirements validation. At the end of each development cycle, they
hold a meeting with developers, customers, quality assurance
personnel, management, and other stakeholders. During the meeting,
the developers demonstrate the delivered features , and the customers
and QA people ask questions and provide feedback. However, these
review meetings cover only minor issues.
Agile requirements practices focus more on requirements validation
than traditional approaches. However, it does not address aspects of
formal verification because there is no formal modeling of detailed
requirements. Consistency checking or formal inspections seldom
occur.

Reference: Neil Maiden (2011) Requirements Engineering Lecture Notes

Advertisements
This entry was posted in Requirements Validation and Agile Techniques and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s