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:

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.

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.

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.

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.

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.

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 later.

Education. Developer education so that they understand the fundamentals of the full range ofarchitectural concerns
described in the requirements.

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
activities.

敏捷测试必须是迭代：敏捷需求活动和设计活动以及构造活动，本质是迭代的，所有测试活动也是迭代的。

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.

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.