敏捷开发框架下的软件工程/第二次迭代/功能需求
要点：功能需求进一步定义 时间：2 小时
输入：来自客户讨论的笔记、研究笔记、ERD。过程证据：功能需求草案列表。客户：讨论 
在第一次迭代中，我们使用计划游戏识别了一些系统的高级需求。这些需求随后被用来定义系统的范围（隐喻），进行道德分析，并作为首次发布的基础。它们为与客户和开发团队讨论项目提供了一个沟通工具。
敏捷运动对需求的处理方法是双重的：1. 需求总是会发生变化 2. 在项目开始时不可能定义所有需求
重要的是要理解，需求不是一个神奇的、定义好的实体。没有人知道所有的需求是什么。每个用户都会有自己的观点，所有观点都可能是正确的。我们将需求确定阶段描述为“探险”。Cohn（2005）扩展了这个隐喻，解释说“不同的网可以捕获不同大小的需求”（第 43 页）。我们的初始计划游戏是第一遍，捕获了最大和最明显的需求。在这次迭代中，我们将使用更小的网眼尺寸，以“捕获”更小的需求。
此外，Cohn 解释说“需求就像鱼一样，会成熟，也有可能死亡”（第 43 页）。在第一次迭代中定义的需求可能会变得多余，因为其他需求被定义，或者似乎是次要需求的可能成为项目的重要组成部分。（这些是最初为“如果系统也能……，那该多好啊？”的对话中出现的需求。）
最后，在关于捕鱼的主题中，虽然你在拖网探险中不会捕获所有需求，你可能会捞上来一些无关的藻类或螃蟹，但熟练的需求拖网者会使用最佳技术来使探险变得高效。
需求规格说明书传统的软件开发方法使用需求规格说明书来定义项目的范围。这种方法假设我们可以“第一次就获得正确、完整、简洁和清晰的需求”。http://satc.gsfc.nasa.gov/support/STC_APR98/do_reqmnt/do_reqmnt.pdf
许多大型开发组织发布了需求标准，供应商需要在投标时遵守这些标准。看看 NASA 网站，你会发现这些标准的绝佳来源。需求规格说明书可以非常庞大，并将需求定义到最小的细节。这项需求分析工作可能需要花费几个月甚至几年时间。
例如，用于火星着陆器的 ASPERA-3 处理和归档设施的需求规格说明中包含以下需求：“应向所有 ASPERA-3 合作者提供 ASPERA-3 和 MEX OA IDFS 数据以及任何 APAF 生成的 ASPERA-3 和 MEX OA 清理后的遥测中间文件。”（摘自 www.aspera-3.org/idfs/APAF_SRS_V1.0.pdf）
这些文件是结构化方法（通常是瀑布模型）的结果。它们是试图在项目失败率居高不下的情况下，为软件开发过程带来一定确定性的合理尝试。它们还为开发提供了法律和合同基础。这种方法的财务合理性源于一种观点，即项目中的变更是一件坏事，而且一旦我们能够就“正确”的需求达成一致，就可以继续进行设计和构建阶段。
变更成本曲线在敏捷论坛中，变更成本曲线备受争议。传统观点（这里我们谈论的是瀑布模型中产品的单个发布）认为，在开发周期的早期阶段发生的变更需求的实现成本很低，因为项目投入很少。在设计阶段更改需求将涉及重新分析和设计，成本也会更高。一旦开始编程，成本就会开始上升，组织可能会抵制修复损坏所需的工作。（“没关系，我们可以在下一个版本中添加该功能”。）产品发布后，更改的实现成本高得令人望而却步，涉及新版本软件、更新的用户文档以及对开发者声誉的损害。
敏捷版本建议，可以解决这种变更成本问题。通过确保缩短反馈循环，并在实现每个需求（用户故事）之前对其进行测试和验证，可以获得更平坦的敏捷曲线。任何增量或迭代方法都将改善变更曲线，因为它们可以防止对有缺陷的代码进行投资。
需求的规则第一条：需求会发生变化。为了遵循极限编程的敏捷原则，我们需要拥抱变化，并与利益相关者沟通，以确保我们对需求的理解足以满足开发过程的要求。Boehm 和 Turner（2004）指出，“成功的、可持续的软件开发既需要纪律，也需要敏捷”（第 23 页）。众所周知，敏捷方法最适合客户易于访问、需求可能会发生变化的较小项目。虽然对于大多数项目来说，200 页的需求文档的开销并不是必需的，但记录需求对于确保与客户就清晰理解达成一致还是很有帮助的，尤其是在较大或任务关键型项目中。编写良好的需求是一项有用的技能，可以提高开发团队对项目的理解。
“敏捷者会创建高价值文档”（Ambler，2006）。我们将使用计划游戏来引出更深入、更详细的需求。在第二次迭代中，我们需要了解用户的观点——用户需要系统执行哪些操作？我们将制作一份需求文档草案，该草案将成为您在第二次迭代中进行开发的基础。有勇气在您对项目的理解发生变化时更改您的需求。在开发过程中的任何时间都可以添加、删除或编辑需求。（您需要为这些决定提供理由！）编写良好的需求。
常见问题语言在所有需求中，对同一个项目使用相同的术语。每个需求通常可以写成以下格式：系统应提供 ........ 系统应能够 ........（使用“应”来描述需求，“将”来描述事实陈述，“应该”来描述目标是行业惯例。）
需求的语言很重要。如果您发现自己使用“是”、“为”、“曾”，那么您可能是在描述系统而不是它的功能。例如，“系统正在存储学生数据”。更可取的是“系统应存储学生数据”。
避免使用不必要的词语，如“必须”、“支持”（如“系统将支持备份”）、“但不限于”、“等等”、“和/或”以及列表。这些词语难以定义，会导致不确定性，并为多种解释留下了空间。如果需求不可定义，则可能需要将其退回给用户以进一步澄清。
避免使用弱语，如：最小化/最大化、快速、用户友好、简单、足够、充足、快捷。最好定义系统的实际限制。例如，不要使用“系统应快速为学生注册”，而是使用“系统应在 24 小时内处理每个学生注册”。
如果可用信息不足——编写出来的需求质量就会很差，因为开发人员会对缺失的信息做出假设。解决方法是经常进行清晰的沟通。
避免在需求中描述实现。您需要专注于“什么”，而不是“如何”。例如，“提供一个数据库”。更可取的是：“提供存储、显示和排序客户数据的功能”。这可能是数据库，但也允许其他可能性，例如 XML 文件。
避免描述系统的使用方式。例如，“系统应允许用户打开对话框并输入数据”。更可取的是：“系统应允许数据输入”。
优先级排序
第一组需求/用户故事通常是愿望清单，其中包含许多“希望有”的功能。在项目的过程中，会进行细化和澄清，并在后续的迭代中定义需求/用户故事。在对解决方案进行工程设计的过程中，会识别出额外的需求或对现有需求的更改。
谁应该参与需求/故事的优先级排序？
客户 开发人员 利益相关者
传统方法将需求分为“基本”需求，这些需求必须包含在系统中；“有用”需求，这些需求如果省略会导致系统效率降低；“理想”需求，这些需求不是核心需求的一部分，但会使系统对用户更具吸引力。
敏捷方法使用连续的迭代来识别最关键的需求。哪些需求或任务将在本迭代中实现？下一个迭代？Scrum 和极限编程方法都使用需求堆栈来对需求进行优先级排序。故事卡片按顺序排列，并在约定的级别添加新的卡片。卡片可以删除或重新排序。在任何时候，开发人员都正在实现优先级最高的那些需求。
总结编写良好的需求和用户故事是一项艰巨的任务，需要仔细思考和分析，但这不是魔法。随着经验的积累，开发人员可以通过编写有效且切合实际的需求来提高项目质量，最大限度地减少返工。
 案例研究 养老院管理系统 | |||
|
小组：Jason McBratney、John Hunt、Chris Morton 为 Leith Group
|
参考文献
Cohn, M. 用户故事
Boehm, B 和 Turner, R. 权衡敏捷性和纪律
http://www.agilemodeling.com/essays/changeManagement.htm
http://satc.gsfc.nasa.gov/support/STC_APR97/write/writert.html
http://www.agilemodeling.com/essays/costOfChange.htm
http://www.complianceautomation.com/papers/writingreqs.htm
http://www.reqexperts.com/media/papers/Managing_Requirements.pdf
http://www.reqexperts.com/media/papers/writing_good_requirements.htm
http://www.reqexperts.com/media/papers/A_Case_for_Priority.pdf