2. Agile Requirements Strategies
This section provides an overview to
agile approaches to requirement elicitation and management.
This is important because your approach to requirements
goes hand-in-hand with your approach to validating those
requirements, therefore to understand how disciplined
agile teams approach testing and quality you first need
to understand how agile teams approach requirements.
Figure5 depicts a process map of thebest practices of
Agile Modeling (AM) which address agile strategies for
modeling and documentation, and in the case of TDD and
executable specifications arguably strays into testing.
This section is organized into the following topics:
5描绘了一个敏捷模型的最佳实践 ，他提出了对模型和文档的敏捷策略和 TDD（测试驱动开发）和可执行性需求进入到
Active Stakeholder Participation 涉众积极参与（需求方积极参与）
Functional Requirements Management 功能需求管理
Initial Requirements Envisioning 初始需求展望
Iteration Modeling 迭代模型
Just in Time (JIT) Model Storming 及时模型风暴
Non-Functional Requirements Management 非功能需求管理
Who is Doing This? 谁来做这些工作
The Implications for Testing 测试启示
Figure 5. The best practices
of Agile Modeling.
2.1 Active Stakeholder Participation
Agile Modeling’s practice of Active Stakeholder Participation
says that stakeholders should provide information in
a timely manner, make decisions in a timely manner,
and be as actively involved in the development process
through the use of inclusive tools and techniques. When
stakeholders work closely with development it increases
the chance of project success by increasing the:
敏捷模型中的涉众积极参与 是说涉众应该提供及时信息和及时做出结论。 并且通过使用工具和技术积极参与开发过程，当涉众积极参与开发活动，大大增加项目的成功几率：
Chance that the developers will understand the actual
needs of the stakeholders
Stakeholder's ability to steer the project by evolving
their requirements based on seeing working software
being developed by the team
Quality of what is being built by being actively involved
with acceptance testing throughout the lifecycle
The traditional approach of having stakeholders participate
in a requirements elicitation phase early in the project
and then go away until the end of the project for an
acceptance testing effort at the end of the lifecycle
proves to be very risky in practice. People are not
very good at defining their requirements up front and
as a result with a serial approach to development a
significant effort is invested in building and testing
software which is never even used once the system is
in production. To avoid these problems agilists prefer
an evolutionary approach where stakeholders are actively
involved, an approach which proves more effective at
delivering software that people actually want.
人们不善于在开始非常好的定义需求 并且经历一系列的开发活动构造和测试的那个重来没有使用的生产系统。 去避免这些问题敏捷专家喜欢通过涉众积极参与的进化的方法
2.2 Functional Requirements Management
A fundamental agile practice is Prioritized Requirements
Stack, called Product Backlog in Scrum. The basic ideas,
shown inFigure 6, are that you should implement requirements
in prioritized order and let your stakeholders evolve
their requirements throughout the project as they learn.
The diagram also indicates several advanced agile concepts.
First, it's really a stack of work items and not just
functional requirements (defect reports also appear
on the stack as you can see inFigure 2,more on this
later, and you also need to plan for work such as reviewing
artifacts from other teams and taking vacations). Second,
to reduce the risks associated with complex work items,
not all work items are created equal after all, you
will want to consider modeling a bit ahead whenever
a complex work item is an iteration or two away.
敏捷实践的基本原理是优先需求堆栈，在SCRUM中叫做产品Backlog 。 Figure 6中展示了基本的想法，
Figure 6. Agile requirements
change management process.
2.3 Initial Requirements Envisioning
Figure 7 depicts the project lifecycle of Agile Model
Driven Development (AMDD). As you see in Figure 7, during
Iteration 0 agilists will do some initial requirements
modeling with their stakeholders to identify the initial,
albeit high-level, requirements for the system. The
goal of initial requirements envisioning is to do just
enough modeling to identify the scope of the system
and to produce the initial stack of requirements which
form the basis of yourprioritized work item list (it
just doesn't magically appear one day, after all). The
goal is not to create adetailed requirements specificationas
that strategy actually increases your project risk in
Figure 7 指出了基于敏捷模型驱动开发的项目生命周期，在Figure7 中，你会看到在迭代0 敏捷者会合涉众一起做一些需求模型出示工作，去识别系统的初始的、高级的、需求。
Figure 7: The Agile Model
Driven Development (AMDD) Lifecycle.
Depending on logistics issues (it can be difficult
to get all the right people together at roughly the
same time) and your organization's ability to make decisions
within a reasonable timeframe, Iteration 0 may last
for a period of several days to several months of calendar
time. However, your initial requirements modeling effort
should only take up several days of effort during that
period. Also, note that there is a bit more to Iteration
0 than initial modeling -- the AMDD lifecycle of Figure
7 only depicts modeling activities. An important activity
during Iteration 0 is garnering initial support and
funding for the project, something which requires an
understanding of the initial scope. You may have already
garnered initial support via your pre-project planning
efforts (part ofportfolio management), but realistically
at some point somebody is going to ask what are we going
to get, how much is it going to cost, and how long is
it going to take. You need to be able to provide reasonable,
although potentially evolving, answers to these questions
if you're going to get permission to work on the project.
In many organizations you may need to take it one step
further and justify your project via a feasibility study.
根据逻辑问题和你的组织能力在合理的时间内作出决定 0迭代是持续几天或者几个月。 然而初始化需求建模工作在这个周期内应该几天时间。Figure
2.4 Iteration Modeling
As you see in Figure 6 agile team will implement requirements
in priority order by pulling an iteration's worth of
work off the top of the stack. To do this successfully
you must be able to accurately estimate the work required
for each requirement, then based on your previous iteration's
velocity (a measure of how much work you accomplished)
you pick that much work off the stack. For example,
if last iteration you accomplished 15 points worth of
work then the assumption is that all things being equal
you'll be able to accomplish that much work this iteration.
The implication is that at the beginning of eachConstruction
iteration an agile team team must estimate and schedule
the work that they will do that iteration. To estimate
each requirement accurately you must understand the
work required to implement it, and this is where modeling
comes in. You discuss how you're going to implement
each requirement, modeling where appropriate to explore
or communicate ideas. This modeling in effect is the
analysis and design of the requirements being implemented
that iteration. My experience is that a two-week iteration
will have roughly half a day of iteration planning,
including modeling, whereas for a four-week iteration
this effort will typically take a day. The goal is to
accurately plan the work for the iteration, identify
the highest-priority work items to be addressed and
how you will do so. In other words, to think things
through in the short term. The goal isn't to produce
a comprehensive Gantt chart, or detailed specifications
for the work to be done. The bottom line is that an
often neglected aspect of Mike Cohn’s planning poker
is the required modeling activities implied by the technique.
目标就是准确的计划迭代工作，识别最高优先级工作项目和怎么做。 换句话说，就是在短时间内进行思考。 这个工作目标不是产生一个完整的甘比特度或者详细的工作规范。
2.5 Just in Time (JIT) Model Storming
The details of these requirements are modeled on a
just in time (JIT) basis in model storming sessions
during the development iterations. Model storming is
just in time (JIT) modeling: you identify an issue which
you need to resolve, you quickly grab a few team mates
who can help you, the group explores the issue, and
then everyone continues on as before. One of the reasons
why youmodel storm is to analyze the details of a requirement.
For example, you may be implementing auser story which
indicates that the system you’re building must be able
to edit student information. The challenge is that the
user story doesn't include any details as to what the
screen should look like -- in the agile world we like
to say that user stories are "reminders to have
a conversation with your stakeholders", which in
other words says to do some detailed requirements modeling.
So, to gather the details you call yourproduct owner
over and together you create a sketch of what the screen
will look like drawing several examples until you come
to a common understanding of what needs to be built.
In other words, you model storm the details.
2.6 Non-Functional Requirements
Non-functional requirements, also known as "technical
requirements" or "quality of service"
(QoS) requirements, focus on aspects that typically
cross-cut functional requirements. Common non-functionals
include accuracy, availability, concurrency, consumability/usability,
environmental/green concerns, internationalization,
operations issues, performance, regulatory concerns,
reliability, security, serviceability, and supportability.
Constraints, which for the sake of simplicity I will
lump in with non-functionals, define restrictions on
your solution, such as being required to store all corporate
data in DB2 per your enterprise architecture, or only
being allowed to use open source software (OSS), which
conforms to a certain level of OSS license. Constraints
can often impact your technical choices by restricting
specific aspects of your architecture, defining suggested
opportunities for reuse, and even architectural customization
points. Although many developers will bridle at this,
the reality is that constraints often make things much
easier for your team because some technical decisions
have already been made for you. I like to think of it
like this—agilists will have the courage to make tomorrow's
decisions tomorrow, disciplined agilists have the humility
to respect yesterday's decisions as well.
Although agile teams have pretty much
figured out how to effectively address functional requirements,
most are still struggling with non-functionals. Some
teams create technical stories to capture non-functionals
in a simple manner as they capture functional requirements
via user stories. This is great for documentation purposes
but quickly falls apart from a management and implementation
point of view. The agile requirements management strategy
described earlier assumes that requirements are self-contained
and can be addressed in a finite period of time, an
assumption that doesn't always hold true for non-functionals.
There are four fundamental strategies,
all of which should be applied, for addressing non-functional
requirements on an agile project:
Initial envisioning. It is during your
initial requirements envisioning that you will identify
high-level functional requirements and non-functionals.
All forms of requirements will drive yourarchitecture
envisioning efforts, which occur iteratively in parallel
with requirements envisioning. The goal of your requirements
envisioning efforts is to identify the high-level requirements
and the goal of your architecture envisioning efforts
is to ensure that your architecture vision effectively
addresses those requirements. You don't need to write
detailed specifications at this point in time, but you
do want to ensure that you're going in the right direction.
JIT model storming. just in time (JIT)
model storming through the construction lifecycle to
explore the details
Independent parallel testing. This is performed throughout
the lifecycle to ensure that the system addresses the
non-functional requirements appropriately.More on this
Education. Developer education so that
they understand the fundamentals of the full range ofarchitectural
concerns described in the requirements.
2.7 Who is Doing This?
Figure 8 summarizes some results fromAmbysoft’s 2008
Agile Practice and Principles Survey. As you can see,
it is quite common for agile teams to do some up-frontrequirements
envisioning and that requirements details will emerge
over time (via iteration modeling and model storming).
A tools-based view is shown in Figure 9, which summarizes
some results fromAmbysoft’s 2008 Test Driven Development
(TDD) Survey. Although there is a lot of rhetoric aroundacceptance
test-driven development (TDD) the fact is that not only
hasn't it replaced agile requirements modeling techniques
it doesn't even appear to be as popular. The implication
is that requirements are explored via several techniques
on agile teams, and rightfully so because one single
strategy is rarely sufficient for real-world situations.
Figure 8. Requirements
practices on agile projects.
Figure 9. Requirements
capture practices on agile teams.
2.8 The Implications for Testing
There are several important implications that agile
requirements strategies have for agile testing:
Agile testing must be iterative. Agile requirements
activities, and design activities, and construction
activities, are iterative in nature. So must testing
Agile testers cannot rely on having
complete specifications. As you saw in Figures2 and7
requirements are identified, explored, and implemented
throughout the lifecycle. There isn't a single requirements
phase which produces a comprehensive requirements specification,
therefore your test strategies cannot rely on having
a complete specification available.
敏捷测不能依赖完整的说明书：当你看Figure 2 和 7中的需求被识别，研究和实现贯穿申明周期，没有简单的需求阶段去产出完整的需求说明书，因此，测试策略不能依赖完整的需求说明书。
Agile testers must be flexible. Testers
must be prepared to work to the best of their ability,
with the information provided to them at the time, with
the full understanding that the information they are
basing their work on today could change tomorrow.
敏捷测试人员必须是灵活的。 测试人员必须有最好的工作能力，根据被提供的信息进行工作。 能够全面的理解提供他们的工作的信息，而且这些信息可能经常变化。
The good news is that agile testing techniques exist
which reflect these implications. The challenge is that
you need to be willing to adopt them.