第三章 需求工程之优秀实践

需求工程优秀实践

获取	分析	规范说明	验证	需求管理	知识	项目管理
定义愿景和范围	应用环境建模	采用需求文档模板	评审需求	建立变更控制流程	培训业务分析师	选择适合的生命周期模型
识别用户群	创建原型	识别需求源头	测试需求	分析变更影响	向干系人讲解需求内容	规划需求方案
选择产品代言人	分析可实现性	为每一个需求分配唯一标识	定义验收条件	建立基线，管理需求版本	向开发人员讲解应用领域	估算需求工作量
组织焦点小组	排列需求优先级	记录业务规则	模拟需求	维护变更历史	定义一个需求工程流程	基于需求做计划
识别用户需求	创建数据字典	描述非功能性需求		跟踪需求状态	建立一个词汇表	发现需求决策者
识别系统事件和响应	需求建模			跟踪需求问题		重新协商承诺
需求获取访谈	分析接口			维护需求可跟踪矩阵		管理需求风险
举行引导式需求获取讨论	将需求分配到子系统			使用需求管理工具		跟踪记录需求工作量
观察用户如何完成工作						回顾学到的经验
分发调查问卷
分析文档
检查问题报告
重用已有的需求

需求开发过程框架

典型的需求开发流程

需求获取活动

定义产品愿景及项目范围

• 愿景和范围文档包含产品的业务需求
• 愿景描述可以使所有干系人对产品的产出有一致的理解
• 范围界定了发布或者迭代中哪些功能应该或不应该出现

识别用户类型及其特征

• 避免遗漏任何用户团队的需要，为产品识别出不同的用户组。
  • 使用频率
  • 所用[[0第一章 软件需求的本质#特性|特性]]
  • 权限级别
  • 经验方面
• 记录他们的工作任务、态度、位置或个性，都可能会影响产品设计
• 建立用户角色，就是一种虚拟人物，代表特定用户类型。

为每类用户选出用户代表

• 为每类用户找出一个能精确传达用户心声的个人，及产品用户代表
• 此人提出用户组的需求，并代表用户组做决策

安排由典型用户组成的焦点小组

• 将以前产品或类似产品的用户代表组成小组
• 收集他们期望有的产品功能及质量
• 焦点小组对商业产品尤其重要
• 焦点小组通常没有决策权

与用户代表协同发现用户雪球

• 与用户代表共同探讨他们需要用软件完成什么任务以及他们希望获得哪些价值
• 用户需求的表达方式
  • 用例
  • 用户故事
  • 场景
• 还涉及用户与能使其完成各项任务的系统之间的互动关系

识别系统事件和反应

• 列出可能经历的外部事件及其对每个事件可能做出的反应。
• 外部事件的分类
  • 信号事件
    • 控制信号或从外部硬件设备接收到数据
  • 时间事件
    • 时间或时间相关事件会触发一个响应
      • 定时事件
      • 延时事件
      • 循环时间
  • 业务事件
    • 在业务应用中触发的用例。

举办获取访谈

• 可以是一对一，也可以和一个小组干系人
• 是一种获取需求的高效方式，可以避免占用干系人过多的时间
• 为需求讨论会做准备

举办并引导需求获取讨论会

• 通过研讨会，分析师和客户能够精诚合作，高效探索用户需求和起早需求文档
• 有时也称作JAD，“联合应用设计”会议

观察用户如何工作

• 观察用户如何完成其任务分解，能够了解到一个新应用在这些用户中的潜在用途
• 简易的流程图可以描述出每个步骤以及所涉及的决策
• 展示不同用户组如何交互的
• 如果能将业务流程记录成文档，就能识别出解决方案是否能够支持此流程的需求。

分发调查问卷

• 调查问卷就是调差大量用户群，并判断他们有哪些需要。
• 如果用户群体比较大，就是和使用问卷调查
• 特别是用户比较分散，效果更好。

分析文档

• 现有的文档可以揭示系统目前如何运行或者人们期望它如何运行
• 文档的书面信息设计现有系统、业务流程、需求规范说明、对竞争对手的研究以及产品上架发行时的用户手册
• 检查并分析这些文档可以帮助你发现什么功能需要保留，什么功能没有被用到，人们如何完成他们的工作，竞争对手提供什么功能
• 软件供应商如何描述产品功能

检查现有系统在需求方面的问题报告

• 从用户那里获取问题报告和改进请求
• 可以将信增需求或改进纳入下一发布或新产品之中
• 客户支持或售后服务可以为未来开发工作提供很多有价值的需求

重用现有需求

• 如果客户所要的功能跟现有系统中已经提供的功能类似，看客户的需求是否能够变通，允许重用或者改写自己的组件。
• 另外一些可以重用的东西包括词汇表、数据模型和定义、干系人信息、用户类型描述以及用户角色

需求分析

为应用环境建模

• 系统环境关系图是一种简单的分析模型，展示的是新系统如何适应或融入其环境
• 定义了开发中的系统与外部实体（如用户、硬件设施或其他系统）之间的界限以及接口。
• 生态关系统展示了解决方案中的各个系统如何相互作用及其相互关系的本质。系统之间的输入、输入及关系（价值）链。

创建用户界面以及技术原型

• 当开发人员或用户对需求不太确定时，需要创建一个原型
• 一部分的、可能的或者初步实现的模型，目的是使概念及各种可能性更真实一些。
• 原型有助于开发人员以及用户对所解决的问题达成共识，并有助于验证需求。

分析需求可实现性

• 业务分析师应当与开发人员协同工作，评估在成本可接受范围内，[[0第一章 软件需求的本质#特性|特性]]需求实现的可能性及其在设定环境下的效果。
• 可以让干系人了解实现每个需求的可能存在的风险，包括不同需求间的冲突或相互依赖，对外部因素的依赖以及技术上的障碍
• 可以对技术上不可行或实现成本过于高昂的需求进行精简，但仍然可以实现项目的业务目标。

需求按优先级排序

• 优先级可以保证团队首先实现价值最高或具有时效性的功能
• 用分析的方法判断实现产品[[0第一章 软件需求的本质#特性|特性]]、用例、用户故事或功能需求的优先级
• 根据优先级决定每个[[0第一章 软件需求的本质#特性|特性]]或设定的需求应当纳入哪些发布或者增量之中。
• 在整个项目过程中，根据新需求的出现、客户的需要、市场情况以及业务目标的演进，不断调整优先级。

建立数据字典

• 把与系统相关的、对数据内容和结构的定义存储在数据字典中。
• 能保证项目中每个人都适用一致的数据定义
• 随着需求的开发，数据字典应收录问题领域内的数据内容，促进客户与开发团队之间的交流。

为需求建模

• 图表是一种分析模型，可以将需求可视化
• 模型可以揭示错误，不一致的、缺失的或是冗余的需求
• 包括数据流图、实体关系图、状态转移图、状态表、会话图和决策树

分析系统与外部世界之间的关联

• 所有的软件系统都通过外部接口与外部世界联通
• 信息系统有用户界面，并常与其他软件系统交换数据
• 嵌入式系统与硬件组件之间会互相关联
• 与网络相关的应用会有通信接口。

将需求分配给子系统

• 一个包含多个子系统的复杂产品，必须将需求分派到各个软件、硬件以及人工系统和组件

需求规范说明

需求规范说明的精髓就在于用一致的、可存取、可评审的方式记录不同类型的需求，且读者都可以理解这些规则。

使用需求文档模板

• 在组织中使用标准模板来记录需求
• 模板所提供的标准结构可以用来记录与需求相关的各类信息
• 模板可以提醒还有各类的需求信息有待挖掘和记录

明确需求来源

• 为了让所有干系人了解每个需求存在的合理性，就需要对其进行追踪溯源
• 它可能来自用例或其他一些用户的输入（一个概要的系统需求）或是业务规则
• 通过记录需求所影响到的干系人，在有变更请求时，知道联系谁
• 需求来源可以用一个可跟踪的链接标识或定义一个需求属性来跟踪

每个需求一个唯一标识

• 制定一个规则，为每个需求打上独立的标识
• 这个规则必须足够健壮，能够禁得住时间的考验，允许对其增加、删除和变更
• 标识需求使需求具有可跟踪性，并能记录变更

记录业务规则

• 业务规则包括公司政策、政府法律、标准和算法
• 要将业务规则从项目和需求中独立出来记录，因其生存期比项目更长
• 业务规则视为企业级资产，而不是项目级资产
• 有些规则会引申出功能需求，反过来会强化这些规则
• 定义这些需求及其对应规则之间的链接关系

记录非功能性需求

• 思维必须跳出功能的局限，这样才能理解对成功至关重要的质量[[0第一章 软件需求的本质#特性|特性]]
• 这些[[0第一章 软件需求的本质#特性|特性]]包括
  • 性能
  • 可靠性
  • 易用性
  • 可修改性
• 客户提出的这些质量属性的相对优先级使开发人员做出正确的设计决策
• 需要记录外部接口需求、设计和实现上的约束、国际化方面的考虑及其他非功能需求

需求验证

• 保证需求的正确性
• 展示期望的质量[[0第一章 软件需求的本质#特性|特性]]
• 并满足用户需要

需求评审

• 需求的同行审查，是一种高回报的质量保证实践。
• 组织一个小的评审团，从不同视角（分析师、客户、开发人员、测试人员）仔细审查需求文档、分析模型以及相关缺陷信息。
• 需求开发初期的非正式评审也很有价值
• 训练团队成员高效地评审需求并在组织中采用评审流程时非常重要的。

测试需求

• 测试为需求提供了另一个视角
• 写测试也就是要考虑如何证明系统是否正确实现预期功能
• 从用户需求中设计测试，就是想记录特定情况下产品的预期行为
• 和客户一起审查测试，确保他们反映了用户的真实期望
• 将测试与需求对应起来，确保没有需求被遗漏
• 并且每个需求有对应的测试
• 测试还可用于验证分析模型与原型的正确性。
• 在敏捷中通常使用验收测试来替代具体的功能需求。

定义验收标准

• 让用户自己说出来如何判断解决方是否满足自己的需要以及是否可用
• 验收标准包含一系列活动
  • 根据用户需求，软件通过一系列验收测试
  • 软件能展示出它具备满足特定非功能需求的能力
  • 对尚未修复的缺陷和问题进行跟踪记录
  • 发布前准备基础设施与培训

模拟需求

• 团队可以使用一些商业工具来模拟计划中的系统，代替或补充书面的需求规范说明书。
• 模拟器是原型系统的升级，可以让业务分析师和用户迅速搭建一个可运行的系统模型。
• 用户可以于模拟系统交互来验证需求并做出设计决策
• 使需求在没有进行代码实现之前就被赋予生命力
• 不能代替严谨的需求获取和分析活动，但能提供一个强大的补充

需求管理

• 一旦手上有最初始的需求，就必须做好准备应对变更
• 有效的变更管理包括提出变更、评估潜在成本及其对项目影响以及确保恰当的干系人可以判断要采纳哪些变更，并做出明智的业务决策。
• 拥有良好的配置管理实践是进行有效需求管理的一个前提条件
• 可以使用代码版本管理工具来管理需求文件
• 最好将需求放在需求管理工具中，工具内很多功能可以帮助你完成这些实践。

建立一个需求变更控制流程

• 与其抑制所有变更或奢望变更不会出现，不如接受变更最终难免这个事实
• 建立一个机制，以防不断出现的额变更引发混乱
• 变更流程
  • 定义如何提出
  • 分析
  • 解决需求变更
• 缺陷跟踪工具可以支持这种变更控制流程
• 组件一个项目干系人小组来担任变更控制委员会，负责评估大家提出需求变更，决定采纳哪些，并未它们设置实施优先级或者目标发布

对需求变更进行影响分析

• 影响分析师变更流程的重要元素，可以帮助变更控制委员会做出可靠的业务决策
• 评估提出的每个需求变更并确定他们对项目可能造成的影响
• 使用需求跟踪矩阵来发现其他可能需要修改的需求、设计元素、代码以及测试
• 明确实现变更所需要的任务并估算完成他们所需的工作量

监理基线并控制需求集合版本

• 基线定义是大家都认可的一组需求，通常是一个特定发布或迭代内的需求
• 当需求基线确定后，如果变更就只能通过项目变更控制流程
• 我们赋予需求规范说明书的每个版本的一个独特的标识，避免将草稿与基线或旧版本与当前版本搞混。

维护需求变更的历史记录

• 没做一次需求变更，就要留下一个历史记录
• 具备需求追溯能力，可回退到需求的某个早期版本或者希望了解需求如何变成现在这个形式。
• 记录需求变更日期、变更内容、谁做出的变更以及原因
• 版本控制工具或者需求管理工具可以完成类似的功能

跟踪每个需求的状态

• 为每个影响产品实现方式的独立需求都建立一个记录
• 保存每个需求的关键属性，包括状态（提出、批准、实施或验证）
• 这样可以检测在任何时间点处于每个状态的需求数量
• 随着需求在开发和系统测试中进行，要对每个需求进行跟踪，从而深刻洞察整体项目状态。

跟踪需求问题

• 项目复杂时，容易忽略很多问题
  • 需求要澄清
  • 缺陷需要弥补
  • 需求评审中发现的问题需要解决
• 问题跟踪工具可以帮助我们避免遗漏问题
• 要为每个问题制定专门的负责人，监控需求的问题状态，依此来判断需求的整体状态。

维护一个需求可跟踪矩阵

• 把每个功能需求与设计、实现它的代码以及验证它的测试相互联系起来，不可或缺
• 这样的跟踪需求跟踪矩阵有助于确认所有需求都已实现并且通过了验证
• 当维护期内需要修改需求时它也很有帮助
• 需求可跟踪矩阵还可以将功能需求与从其引申而来的高级需求、相关需求联系起来
• 在开发过程中同步建立这个需求矩阵，而不要等开发结束后再开始。
• 除了微型项目，都离不开这个工具的支持

使用需求管理工具

知识

训练业务分析师

• 承担业务分析师的任务，都应该参加需求分析师方面的培训
• 需要好几天的培训才能掌握其通常需要完成的各项任务。
• 业务分析师需要有耐心、有条理、拥有高效的人际沟通技巧，并且了解业务领域

帮助干系人理解需求

• 需求培训课想要收到最好的效果学员最好可以横跨多个项目领域，而不至于业务分析师。
• 参与软件开发的用户应当接受一到两天需求方面的培训，理解术语、关键概念和实践及其对项目成功的重要性。
• 此类信息对开发经理和客户经理也很有用
• 将不同的干系人召集在一起，为他们准备一堂软件需求可，也是一种有效的团建活动。
• 各个角色的人都会更加理解其合作伙伴所面临的挑战以及成员彼此之间有哪些需要，而这都是为了整个团队能够取得成功。
• 参加过需求培训的用户，以后可以进一步了解软件开发人员

帮助开发人员理解应用领域

• 为让开发人员对应用领域有一个基本的认识，我们可以组织一个研讨会介绍客户的业务活动、术语以及代建产品的目标。
• 有助于减少以后工作的困惑、误解以及可能的返工
• 在开发期间，为开发人员配备一个用户伙伴，帮助解释业务术语以及业务概念

制定一个需求工程流程

• 将组织所遵循的获取、分析、规范、验证以及管理需求流程记录成文档
• 为如何完成其中的关键步骤提供指引，使分析师一直得心应手
• 这样的流程也有助于计划每个项目的需求开发和管理任务、时间表以及所需的资源。
• 项目经理应当将需求活动作为一个独立任务加入项目计划中。

建立词汇表

• 词汇表是对应用领域中专业术语的一种汇总，有助于消除误解
• 包括
  • 同义词、首字母缩写、简称
  • 有多重含义的词汇以及在应用领域与平常生活中意义不同的词汇
• 词汇表可以称为一种可重用的企业级财产
• 定制词汇表的工作可以分配给团队新成员，因为他们最容易对陌生的属于感到困惑，需要进一步了解词汇表。

项目管理

• 软件项目管理方法与需求流程紧密相关
• 项目经理应当根据需要实现的额需求，规划项目时间表、资源以及做出承诺

选择一个合适的软件开发生命周期

• 组织应根据不同的项目类型以及需求的不确定程度指定多种相应的开发生命周期。
• 每个项目经理都应该选择并采纳最核实的项目生命周期
• 将需求活动纳入生命周期
• 如果可能，就增量细化和开发功能集，力求尽早项客户交付有用的软件。

规划需求活动

• 每个项目团队都应该计划如何进行需求开发和管理实践活动
• 业务分析师应当与项目经理协同工作，确保需求工程相关的任务可以及可交付物都会出现在项目管理计划中。

估算需求工作量

• 干系人一般需要指导项目中需求开发阶段需要多长时间以及花费在需求开发和管理上的工作量占总工作量的比例。
• 考虑那些指标性因素，能提供一个参考，告诉你需要花费更多还是更少的时间确保需求能够成为开发可依赖的基础。

基于需求确定项目计划

• 随着项目范围和需求细节逐渐清晰，以迭代的方式制定计划和时间表
• 首先估算初始产品愿景和范围内的用户需求所需的工作量
• 敏捷项目中，迭代式固定时间长度的，做计划就意味着不断调整范围，这样才能符合固定的时间和资源约束。

识别需求决策人

• 软件开发需要做很多决策
• 要解决用户需求输入的冲突
• 选择商业组件包
• 评估变更请求
• 因为需求问题需要做大量的决策，所以项目团队需要找出决策者并给它授权。

当需求变化时重新协商项目承诺

• 项目团队承诺在预定时间及预算内交付特定的需求集合
• 随着项目中加入新需求，需要重新评估基于现有资源仍然能够完成原来的承诺。
• 如果不能，将项目的实际情况告知管理层，并且协商一个现实，可行的承诺。
• 在开始阶段，需求的理解不那么清晰，估算也处于初始阶段，随着演化，需求会逐渐明晰并经过验证，这时需要重新协商承诺了。

分析、记录以及管理与需求相关的风险

• 如果项目准备不充分，突发事件和情况就可能对其造成灾难性破坏。
• 作为项目风险管理活动的一部分，要识别并记录与需求有关的风险
• 需要想办法降低甚至消除这些风险，实施能够降低风险的活动，记录活动进展和功效。

跟踪在需求上花费的工作量

• 为了能在未来项目中提高对需求所耗资源估算的准确性，要记录团队在需求开发以及管理中心所花费的工作量。
• 监控需求实践对项目产生的影响，从而判断在需求工程方面的投资有多少回报。

借鉴其他项目中关于需求的经验教训

• 学习型组织会定期组织回顾会，收集以往项目或当前项目早期迭代中的经验教训。
• 从以往的需求实践中学习经验教训，可以是项目经理和业务分析师对未来充满信心