标识功能要求

已完成

要求通常称为功能要求或非功能要求。 功能要求描述解决方案需要做什么或其行为,而非功能要求通常描述解决方案的非行为方面,例如性能要求。 本主题涵盖功能要求的注意事项。

每个功能要求都应该明确捕获要求涉及的人员、内容和原因。 如果要求太大,应将其划分为较小的部分。

功能要求示例

以下应用场景描述功能要求的简单示例:

  • 作为一名销售,我需要能够将商机作为丢单结束,然后了解丢单的原因,以便我们可以在将来改进销售策略。

  • 作为一名销售经理,我需要能够审核报价单上的折扣,以便我可以降低总价并向客户提供一个折扣。

  • 作为一名会计师,我希望无法关闭具有待定项的批处理,这样我就不必在以后重新打开它。

这些情况会传达要求的人员、内容和原因。

下面是措辞不当的要求示例:

  • 商机可以赢单,也可以丢单。

  • 价格应反映折扣。

  • 从批处理项列表中,选择关闭批处理按钮(从左边数第三个按钮)应该会关闭批处理,前提是不存在阻止批处理发生的项目。

当您要收集各种各样的要求时,向流程映射而不是仅列出特性和功能将很有用。 为用户生成一个案例并描述用户将如何成功使用您正在设计的系统。 您可以在白板上写入或绘制,使用工具绘制流程图或在您所处的设计阶段使用适用于您的团队的任何方法。 您的团队稍后会将这些片段分解成更小的可操作项。

验收条件

请务必清楚了解如何满足要求。 通常,记录满意度有助于确定要求是否足够详细,大小是否合适。 在测试团队评估要求的实现情况时,本方法也很有用。 最后,应与利益干系人一起审查要求的满意度,以确保其准确性,因为它可用于帮助防止范围蔓延。 解决方案架构师需要查找无法满足的验收条件,然后通过协商达成可实现的折衷方案。

捕获异常

通常,简单要求(例如关闭交易)可能有一个简单路径以及几个异常路径。 请确保在捕获成功路径时,查找并标识这些异常。 在进入设计阶段时,您不想主要针对异常进行设计。 应该这样处理它们,但如果您不知道它们存在,则必须在以后重新设计。 此外,请记住捕获异常发生的频率,因为某些异常最好通过过程和/或流程(而不是软件自定义)来处理。

避免范围蔓延

如果未选中,每个项目都将根据设想和预算增加范围。 解决方案架构师在查找超出原始假设范围的要求时必须提高警觉。 项目治理流程应该用于评估在标识这些流程后如何处理它们。 通常,接受以便包含这些超出范围的要求可能会导致顺序发生更改,具体取决于项目的合同结构。 忽略范围正在增加这一事实很容易导致项目失败。

练习:查找功能要求

回顾 Woodgrove Bank 的团队并确定各个团队在执行其工作所需的功能中可能存在重叠。

  • 业务增长和资产管理 - 年交易额低于 10 亿美元的商业帐户。 这方面的增长是指用于在公司中进行再投资的贷款。 这些客户共享一组客户经理;它们未分配到个人。

  • 财富 500 强 - 本部门中的每个客户都分配有一位高级客户经理,作为他们所有银行事务的主要联系人。 当一家公司在本部门进行管理时,即使他们跻身进财富 500 强,也会留在这里。

  • 集团产品组合管理 - 该团队在一个共同框架下为拥有多个组织的公司管理父/子帐户。

  • 新业务开发 - 本部门主要负责新业务的市场营销。 客户合格并处于活跃状态后,将转到适当的管理团队。

  • 公共部门/政府/高等教育 - Woodgrove Bank 是全球许多主权政府以及私立大学的首选贷款机构。 本团队还面向少数由银行提供服务的高交易量非盈利组织。

  • 消费者贷款 - 本团队规模最小,因为 Woodgrove 专注于商业产品。 但是根据具体情况,也可以提供高额消费者贷款。 本团队不向外部目标客户宣传,但主要由公司客户的高管使用。

  • 关系经理 - 本团队由其他每个团队的成员组成,这确保一致的体验,因为客户可能会在团队之间移动并以其他方式进行交互。 本团队还确立面向用户的最佳做法。