需求的发展

有效的需求是任何软件项目的关键组成部分. 这些需求的成功收集和文档化依赖于软件的业务所有者和项目开发团队之间的协作. 这一联合工作确定了业务目标和目标(高级需求), 定义详细的功能需求以满足这些需求(用户描述), 并确定实现成功产品所需要的技术和非功能系统需求. 这个过程强调了需求是如何在整个软件项目中发展的.

the-evolution-of-business-requirements

收集业务需求可以通过多种方法完成. 最初, 与项目发起人举行小组会议,以了解企业试图解决的问题以及这与公司战略的关系. 另外, 可以对利益相关者进行访谈和调查,以更深入地了解公司现有的流程和当前的问题. 最后,可以进行用户观察,进一步调查发现的痛点. 来自这些来源的信息将被编译成业务目标和需求故事,这些目标和需求将证明项目将给公司和/或他们的客户带来的价值. 这些高级需求并没有定义如何处理这些问题, 它们是推动解决方案和设计讨论的起点. 对项目意图的基础和理解越强, 当开发开始时,情况就会越好. 业务目标和需求必须被关键的项目涉众消化并签署,以正式确定整个工作的意图——这些可以被看作是项目团队的灯塔.

业务需求故事格式:
作为一个 [内部或外部客户/实体]
我可以 (实现业务目标)
所以那t[对内部或外部客户/实体的价值]

例子:
作为一个 在线产品零售商
我可以 为顾客提供多种识别要购买物品的方法
我们的网站在市场上仍然具有竞争力,并提供最佳的产品列表

这个商业故事的价值是通过向客户提供当前系统没有提供但其他零售商正在提供的选项来实现的. 这个故事没有描述如何实现这一目标的任何细节,但它确实开启了对话. 业务需求故事并不计划是可实现的,因为它们描述了业务需求和解决它的价值. 通过对业务目标的理解, 项目团队可以围绕设计和解决方案展开讨论. 然后将单个业务需求转换为多个功能需求和用户场景.

功能和用户需求写成用户故事, 描述预期的功能,然后交给开发人员实现. 在这个级别, 目的是将业务目标和需求分解为最小的可操作的工作单元,同时仍然交付可以演示的功能 & 验证. 为实现这一目标, 与参加过第一次会议的涉众和新确定的涉众的后续访谈将推动功能和用户需求中记录的附加细节. 在进行面试时, 我们可以了解到一些不包括在这个项目范围内的需求, 但要把它保留在待办事项中. 结果是功能、支持工件和验收标准的描述. 与业务需求类似, 功能和用户需求保持解决方案中立,只描述需要的内容.

用户故事格式:
作为一个 [role]
我可以 (功能)
(用户价值)

例子:
作为一个 客户
我想 跟踪网上目录上我喜欢的任何产品
我可以在以后的时间里取回它们,以便可能的购买

支持工件和验收标准被添加到用户故事中,以进一步细化细节以达到澄清的目的. 构件是一种以可视格式与开发人员沟通功能需求的额外方式. 例子包括(但不限于)以下文件:
•线框图
•创意设计
•数据流
•用例

验收标准是用来验证和测试功能的必要条件. 如果满足验收标准,则认为用户故事已经完成. 这将包括所有业务规则的描述, 每种情况下的场景和预期结果(包括积极的和消极的结果)应该由业务分析师最少地共同编写, 开发人员, 和质量工程师.

验收标准格式:
先决条件 (资格)
行动 (行动)
结果 [结果]

例子:
先决条件 当一个签到的顾客已经确认了他们正在考虑购买的物品
行动 -他们可以选择和保存产品
结果 -产品项目、颜色、尺寸和数量保存到客户的帐户中,以备将来审核

这个需求演进中的最后一步经常被忽略,但同样重要, 技术和非功能系统要求. 这些需求可以跨越多个故事,在开发测试方法时应该始终考虑到这些需求. 常见的非功能系统需求是可用性, 安全, 可靠性, 基础设施, 和性能相关的. Technical requirements may take shape in defining computing hardware requirements to support the solution; specifications in how the solution integrates with other systems; or schematic designs the solution must follow. 业务涉众可能不会意识到这些需求,除非他们有技术表示. 如果是这样的话, 项目开发人员需要根据他们的专业知识帮助确定这些需求.

技术和非功能需求的文档可以通过多种方式完成,这只取决于项目团队的偏好. 通常称为“约束条件”, 这些需求可以作为额外的验收标准添加到用户故事中. 约束是使需求与质量期望保持一致的条件,也是确保非功能性需求得到满足的附加验证. 另一种可能是创建一个作为附加工件的技术和非功能需求规范文档. 记录这些需求的最后一种方法是利用用户故事格式.

用户故事的例子:
作为一个 首席技术官
我想 使用现有的订单数据库,而不是创建一个新的
我们不需要增加需要维护的数据库的数量

验收标准的例子:
先决条件 当一个签到的顾客已经确认了他们正在考虑购买的物品
行动 -他们可以选择和保存产品
结果 —客户帐户及相关产品数据存储在现有订单数据库中

收集需求是一个渐进的过程,其重点是从高级业务目标和目标开始的. 没有清楚地理解业务需求, 可能会开发出不符合预期项目愿景的解决方案. 然而, 如果提前花费时间,那么一旦执行,可能性就会大得多, 详细的和技术性的非功能性系统需求将对业务和外部客户产生价值

 

友情链接: 1 2 3