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:

这段提供一个需求调研和管理的敏捷方法，这是是非常重要的，因为你的需求方法和验证需求的方法是相辅相成的。因此，去理解严格的测试和质量方法前，你需要去理解敏捷团队的需求方法。Figure 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 practice.

Figure 7 指出了基于敏捷模型驱动开发的项目生命周期，在Figure7 中，你会看到在迭代0 敏捷者会合涉众一起做一些需求模型出示工作，去识别系统的初始的、高级的、需求。 初始需求设想的目的是有足够的模型去识别系统范围，并且生产出机遇你的工作项目优先级立标的初始需求堆栈。 初始需求设想的目的不是编写详细的需求说明书 ，那将增加项目实践风险。

Figure 7: The Agile Model Driven Development (AMDD) Lifecycle.

Fig：敏捷模型驱动开发生命周期

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 7 中仅描述了建模活动。

在0迭代中一个重要活动是获得项目的初始支持和资金，这些事情需要对初始范围的理解。 可能在项目前期的计划时已经获得了初始的支持，但实际上还会有些人问项目会收获什么，要花多少钱，要用多长时间。 你需要能够提供足够的理由。

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.

正如你所看到的在图6中敏捷团队将按照工作需求优先级顺序从迭代工作堆栈的顶部开始实现需求。要想成功的执行你必须能够准确的估算每个需求要用的工作量，然后基于前面迭代速度（一个完成多少工作的度量指标），在决定你再堆栈上拿走多少工作。 例如，你最后一次迭代完成了15个工作，那么在同等条件下，你在这次迭代中完成这么多的工作。也就是说在一个敏捷团队的每一个构造迭代开始时必须评估和安排计划这个迭代要做的工作。 准确的估算每一个工作，你必须理解实现工作的要求，这就是建模。

你们讨论怎么去实现每一个需求，在建模式中进行探讨和沟通想法。 这个建模实际上就反复的需求实现的分析和设计。我的经验是一个两周的迭代应该有半天的迭代计划时间，包括建模。如果是4周的迭代周期，这个工作大概花费1天时间。 目标就是准确的计划迭代工作，识别最高优先级工作项目和怎么做。 换句话说，就是在短时间内进行思考。 这个工作目标不是产生一个完整的甘比特度或者详细的工作规范。

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

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

敏捷测不能依赖完整的说明书：当你看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.