第十一章 需求工程之写出优秀的需求

需求陈述的特点

下面列出在理想状况下每一个业务需求、用户需求、功能性需求和非功能性需求应该具备的特点

完整性

• 每一个需求都必须包含所有的必要信息。
• 对于功能性需求，所提供的信息可以让开发人员正确实现它。
• 如果发现缺少特定信息，可以用TBD（待定）作为标准标志来表示这些不确定向，或记录到问题跟踪系统中便在后期进一步跟踪
• 在开发人员准备开发的部分需求里，应该已经解决掉所有的待定项

正确性

• 每个需求必须能准确描述符合用户要求的性能，通能也能清楚描述它所具有的的功能。
• 须从需求来源检查需求的正确性，可能源自提供最初需求的用户，或是源自更高一级的系统需求、一个用例、一条业务规则或其他文档。
• 低一级的需求与其上一级需求有冲突也是不正确的。
• 为了评估用户需求的正确性，用户代表或其用户代表应该审查需求

可行性

• 它必须可以再一定条件下实现。
• 这些条件包括已知的能力、系统的限定、运行环境还有项所限定的时间、预算和人力资源。
• 开发人员可以从技术角度审查可行性，检查哪些需求需要超预算、超资源才能完成
• 用来评估软件可行性的方法有增量开发方法和概念证明的模型法。
• 如果需求是因为不可实现而裁减，还要理解对项目前景和范围的影响。

必要性

• 每个需求都应该描述出其必要性
• 这可以是符合项目干系人期望的业务价值的性能需要或是产品在市场上的差异性，或者来自于外部标准、政策或法规的要求。
• 每个需求都应该源自一个有权提供需求的途径
• 每条功能性需求和非功能性需求都应该可回溯到一个代表用户声音的输入，比如一个用例或一个用户故事。
• 我们应该将每个需求关联到清晰的业务目标上

优先级排序

• 根据对达到预期目标的重要程度来对业务需求排序
• 对每个功能需求、用户要求、用例流程或者产品特性，按照实现的先后顺序对他们进行排序来表明他们对于某一个产品版本发布的重要性
• 需求排序是一个设计多放项目干系人利益的协作活动

有歧义

• 自然语言容易产生两种类型的二义性
  • 用多种方式解读某个需求
  • 多个人阅读有多种理解
• 虽然每个解读都合乎逻辑但其含义却大相径庭
• 审查可以很好的消除歧义
• 正式的同行审查，提供了一个很好的机会，可以让参与者比较他们各自对每个需求的理解
• 可理解性与没有企业关系，读者必须明白每个需求说的是什么。

可验证性

• 为了检查是否恰当实现每个需求，测试人员可以根据它来写测试用例或验证方法。
• 不完整的、不一致的、不可实现的或有歧义的需求都是不可验证的。

需求集合的特点

各个独立的需求都完美表述是不够的，一些需求集合是为某一个特定发布的基线或者迭代而产生。

完整性

• 不要漏掉任何需求或必要的信息
• 假设或是隐含的需求容易遗漏

一致性

• 是指需求不能和同类型的需求或者更高一层的业务、用户或者系统需求发生冲突
• 如果在实现之前不能解决冲突，风险很高。
• 记录下每个需求的来源，当不同的需求之间不一致的时候，可以于相关人员沟通

可修改性

• 需求可以重写，应该维护修改记录，尤其是在纳入基线管理后
• 明确需求之间的依赖和关联
• 每个需求有一个唯一标识，便于引用关联。
• 要避免重复性的需求说明
• 相关条目的交叉引用有助于同步
• 将不同的需求保存在同一个需求管理工具中，可以解决冗余的问题。有助于跨项目之间普通需求的重用。

可追溯性

• 需求应该能够回溯到它的来源，也可以向下追溯到延伸自它的需求、设计元素、实现它的代码还有用来验证它的测试。

续期编写指南

写文档的重要目标

• 任何阅读需求的人对需求的解读要一致
• 每一个读者的解读都与作者视图表达的意思一致

系统或用户的角度

• 对于功能性需求，可以从系统运行或是用户使用的角度来写。
• 用一致的风格来表述需求，就像“系统应该”或者“用户应该”然后跟一个行为动词，再跟一个明了的结果。
• 导致系统运行某些功能的前置操作和条件也要表述出来。
• 【可选的前置条件】【可选的前置事件】系统应该【期望的系统响应】
• 有时以用户行为词组而不是系统的角度来描述需求可能更自然
• 使用“应该”并以主动语态来描述可以更清楚谁是动作的主体
• 某个【用户类别或者角色名称】应该能够【对某个对象】【做某事】【限定条件，响应时间或质量描述】
• 系统可以让（允许、准许或能使）【某个特定用户类别的名称】做某事

协作风格

• 首先把要点写出来
• 要点是我们要表述的需要或功能
• 紧接着是支持它的细节
  • 依据
  • 缘由
  • 优先级
  • 需求的其他特点
• 使用表格、结构化的列表、图表和其他可视化元素，提供更好的沟通方式。
• 易于理解和阅读是基本要求

清晰和简洁

• 正确的语法、拼写和标点符号构成完整的句子
• 句子和段落简短明了
• 用用户业务领域内简单直接的词语，而不是一些行业术语。

关键词“应该”

• “应该“可以清楚地表述期望的功能，也符合以清楚和有效沟通为首要目的这一原则。

主语动态

• 用主语动态可以清楚地表述谁是使动者
• 例如：
  • 当产品升级上市发布的时候，序列号应该在合同里面得到更新。更正如下：
  • 当实施者确认他们上市发布了产品的升级时，系统应该用新产品的序列号来更新客户的合同。

独立的需求

• 避免用打断的叙述来表述多个需求。
• 把各个需求及其背景或上下文信息清楚滴区别出来
• 需求中“和”、“或者”、“另外”、“也”这些词表名可能存在多个需求合并表述的情况。
• 保证这些连词连接的是同一个需求的两个部分，而不是两个独立的需求。
• “买家的信用卡可以用来支付，除非信用卡过期”
  • 如果买家的合法信用卡在有效期内，系统就应该可以用该卡进行收费
  • 如果买家的合法信用卡已经过期，系统应该允许买家更新当前信用卡的信息或者另外用一张性用卡进行支付。

细化程度

需求规范应该细化到包含的信息刚刚沟通的程度。让开发人员和测试人员正确实现。

恰当的细化

• 为了理清和充实更高一级的需求，需求分析的一个重要任务就是对它进行充分的分解和细化。

一致的粒度

• 没有必要将所有需求都用同一个粒度进来进行细化
• 如，有些部分可能有更高的风险，就应该更深入的细化
• 对于一个相互有关联的需求集合，最好使用一致的粒度来写功能性需求。
• 有帮助的指导原则是写可以独立测试的需求。
• 如果能相处少量相关的测试用例来验证需求是否正确实现，它的粒度就应该是合适的。
• 如果预见需要大量不相关的测试用例才能够验证需求，就说明可能有几个需求被合并到一起了。应该分开。

表述技巧

• 与目标听众沟通需求时，尽量使用最有效的表述方式
• 列表、表格、可视化分析模型、图表、数学公式、图片、音频片段和视频片段
• 增强用户的理解

避免歧义

需求质量是从用户视角来衡量的，而不是作者的角度

模棱两可的词

• 一致并按照词汇表中的定义使用术语
• 留心同义词或近义词

A/B结构

• 很多需求规范说明都包含A/B结构的表述
• 它们由两个相联系（同义词或反义词）的词语以反斜杠连在一起
• 这样的表述尝尝会产生歧义。

边界值

• 业务规则和需求中，数字范围的边界尝尝会出现歧义。

否定句式的需求

• 如果合同没有余额，就不让用户激活合同（仅当合同有余额时，系统允许用户激活合同）
• 为了支出某些特定功能时需求范围之外的功能，不要使用否定语句说明，把这个限制包含在愿景和范围文档的限定条款部分。

避免不完整性

对称性

• 成对的操作往往会造成遗漏需求
• 如
  • 在手动创建合同时，用户必须能够在任何一个时间点保存合同
  • 创建和保存两个操作，容易遗漏保存（不完整保存合同）

复杂逻辑

• 二元或多元条件时，需分别组合各种可能情况

遗漏异常处理

• 对于描述系统在正常状态下如何工作的需求，必要时也应该有一个相对的需求，描述异常情况下系统应该如何响应。