第十章 功能需求
功能需求指明了产品必须做的事情，即产品为了满足它存在的根本需求和根本理由，而必须执行的一些动作。
需要功能需求，是因为当业务分析是理解了产品必须的功能后，他要用功能需求告诉开发者要构建什么。
如果利益相关者对产品用例场景达成一致，业务分析师写下一组功能需求，确定该场景表明的功能，接下来开发者利用这些需求来构建产品。
1 细节程度或力度
需求是由一个单句写成，只有一个动词。
注意产品“应该”的形式，他使用了主动句，并关注于沟通产品打算做的事情。
也为开发者和其他利益相关者提供了一致的形式，这些人需要清楚地理解产品打算做什么。
2 描述和理由
需求不止包含描述，你需要在需求中添加理由，说明需求为什么存在。
在某些情况下，这可能很明显。
但在许多情况下，这是需求的关键部分。
加入理由后，你不仅让开发者有机会构建最好的解决方案，而且也告诉测试人员，需要在测试这项需求上投入多少工作量。
很清楚理由表明这项需求值得关注，对描述给出理由，需求本身就变得更有用了。
也向未来的维护者说明了需求一开始为什么会存在。
理由也有助于克服不小心写下解决方案，而不是真正的需求。
很容易通过描述一种实现来隐藏重要的功能，也容易选择最明显的实现，忽略可能更好地实现。
不论需求最终如何实现写下描述和理由，显然会导致发现真正的需求。
3 数据你的秘密武器
只要你开始收集常用的术语，就应该在数据字典中定义术语的含义。
你列出这些数据流的属性，从而定义他们，这些属性又让你能建立业务数据模型。
这个数据模型作为某些功能需求的定义，并为团队提供了共同的语言。
4 异常和可选方式
异常是不期望，但不可避免地对正常情况的偏离。
是由处理的错误或不正确的活动引起的，对于这些需求必须明确的说明，只有当异常发生时，他们才会成为现实。
为了做到这一点，可以标明一些需求与特定的异常有关，或者于每一项需求都包含这个异常条件。
5 有条件的需求
如果需求只有在特定的处理环境下才会发生，就会出现这种情况。
6 避免二义性
不论你的需求来源是书面的文档还是访谈的口头描述，都应该注意大量潜在的二义性和由此带来的误解，比如一词多义。
7 技术需求
技术需求是纯粹因为所选择的技术而需要的功能。
技术需求不是因为业务上的理由而存在，而是为了让选择的实现方式能工作，将技术需求放在一份单独的规格说明书中记录下来。
小婧的总结：
本章对于描述功能需求方面进行了一些讲解。
值得关注的是第二个部分，关于“理由”的说明。
我非常赞同与研发团队沟通的时候“顺便”介绍一下我们为什么要做这样的需求。
有的时候研发团队在设计的时候会根据你这个“顺便”提供更好的可扩展的设计和解决方案。
但是在这个过程中要警惕“需求镀金”。
第十一章 非功能需求
非功能需求描述的产品必须具备的品质。
换言之，将事情做到什么程度。
这些需求让产品有吸引力，易用、使用快速、可靠和安全。
需要这些属性不是因为他们是产品的功能活动，而是因为客户希望这些活动以特定的方式执行并达到特定的品质。
非功能需求并不改变产品的基本功能，也就是说不管增加多少属性，功能需求都会保持不变。
更复杂的事，非功能需求可能为产品增加功能。
功能需求导致产品去完成工作，非功能需求为工作赋予特征：功能需求是动词，非功能需求是形容词。
非功能需求类型：
- 观感：产品的外观精神实质
- 易用性和人性化：产品的用心程度，以及更好的用户体验所需的特征 可用性考虑
- 执行：功能的实现必须多快，多可靠，能完成多少处理量，可用性，多精确
- 操作：产品的操作环境，以及对该操作环境必须考虑的问题
- 可维护性和支持：预期的改变以及完成改变允许的时间，也包括对产品的支持的规定
- 安全：产品的安全性、私密性、可恢复性和可审计性
- 文化和政策：由产品的操作所涉及的人的文化和习惯所带来的特殊需求
- 法律：哪些法律和标准适用于该产品
为了遵从不要写解决方案的指导原则，请检查你的需求，如果它包含任何技术因素或任何方法，就重写它，避免提及任何技术或方法。
可能需要反复做几次，直到达到要求的技术无关性，但对最终产品设计的影响来说，这是值得的。
小婧的小结：
其实非功能需求很多都是和业务场景以及功能需求相关的。
我们在考虑非功能需求的时候可以从这些角度出发。
比如这个场景下会有哪些非功能的要求。
然后站在模块或者产品的角度去思考诸如安全性、可维护性等方面的非功能性需求。
而且我个人觉得非功能性需求之间可能也存在权衡和取舍的问题，比如要考虑数据安全性，可能就会损失一些易用性。这个具体要看产品的要求以及客户的关注点。
第十二章 验收标准和理由
我们这里所说的验收意味着：解决方案完全满足或符合需求。也就是说，解决方案准确的实现了需求所要求做的事情，或具备需求所要求的属性，不多也不少。
需求本身必须是可测量的，需求的测量指标就是验收标准。
它炼化了需求的行为执行方式以及一些其他的品质。
想准确的了解需求，必须以某种方式对描述进行量化。
一旦测量需求，也就是用数字来表述，误解的可能性就很小了。
1 验收需要标准的原因
如果产品有一项需求，要执行某个功能或具备某种属性，那么测试活动必须展示产品确实执行了该项功能，或具备了该项期望的属性。
为了进行这样的测试需求，必须有一个测试基准，这样测试者才能比较提交的产品和最初的需求。
测试基准就是验收标准，基于需求的量化，它说明了产品必须到达的标准。
2 需求理由的理由
理由就是需求的原因或存在的道理。
为需求加上理由，可以更容易理解真正的需求。
利益相关者常常会告诉你一个解决方案，而不是他们真实的需求。
或者他们会告诉你一向很模糊的需求，以致暂时没有什么用处。理由不仅是帮助你发现验收标准的指导，也帮助你发现是否有好几项不同的需求，伪装成了一项需求。
而且，理由也为如何实现需求的决定提供了基础。
在产品使用和运维人员方面，理由将起到重要的作用。
假定你需要对产品进行变更，由于不理解理由而导致的问题，也是软件维护成本非常高的一部分原因。
测试者需要做出最佳决定，就需要理解需求的理由。
理由是业务和提交的产品之间认识的纽带。
你必须问为什么，不断的问为什么，知道理解了需求的真正理由。
3 测量的尺度
所有需求都可以测量，你要做的就是找到合适的尺度来测量它。
测量的尺度是用于测试产品符合程度的单位。
比如对于一个易用性需求，可以测量学习产品所需的时间，或达到供热能力水平的时间，或者可能是使用该产品完成工作的差错率。
各种品质都有测量尺度，你可以测量很多东西。
4 非功能需求的验收标准
非功能需求是产品必须具备的品质，诸如应用性、观感、执行特点等，因此验收标准是对这些品质进行量化。不要为了需求可测量而放慢需求发现的过程。
要了解利益相关者的意图以及理由，然后分析你的理解，编写对验收标准的最佳阐释，与利益相关者讨论并改进它们。
你们必须都同意你建议的验收标准，准确地测量了这项需求。
5 功能需求的验收标准
功能需求是产品必须做的某件事情，即产品必须完成的动作。
验收标准指明了如何得知产品已经成功地完成了该动作。
对功能需求来说，不存在测量的尺度。
因为动作要么完成，要么没完成。
完成就是权威满意，因为产品正确地执行了该动作。
这里的权威要么是数据源，要么是发起该行动的相邻系统。
功能需求的一般原则是：验收标准确保功能正确的执行。
6 验收标准的形式
编写验收标准，最常见的方式是采用自然语言的文字和数字。
如果你采用这种方式，就要确保验收标准中使用的所有数据，在规格说明书中都有定义，并在需求中一致的使用。
最好的方式是创建数据字典，定义工作范围内的术语。当然你也可以使用其他图式验收标准。比如，决策表、过程模型状态、模型、决策树、动态模型和其他技术。
只要能够以二义性最小的方式表达所需的测量指标，具体方式无所谓。
7 解决方案限制条件的验收标准
限制条件是一种特殊类型的需求，他们是全局需求，通常是管理层预先规定的。
但他们也需要正确制定，像其他类型的需求一样，所有其他限制条件，如实现环境，伙伴应用，商业上架销售软件，开源软件工作场地，环境时间预算，财务预算都应该有验收标准。本章小结
验收标准既不是测试，也不是对测试的设计，而是测试提交的产品时必须采用的测试基准。
它是构建测试用例的输入信息，测试者通过测试用例来确保产品的每项需求。
都符合它的验收标准，量化或测量需求，让你有更好的机会和利益相关者进行交流。
为需求加上验收标准，鼓励测试人员参与需求过程。
验收标准是真正的需求，验收标准是用精确方式来陈述的，可能使用数字或测量指标来表达它的含义。
验收标准也是多个利益相关者之间达成一致的手段，验收标准通常写在需求描述之后。
小婧的小结
需求的验收标准非常重要，特别是如果你是使用敏捷框架。
一个需求怎么才能算是完成，这个有很多判定的条件，其中验收标准是非常重要的一个。
通常我们的验收标准写的可能主要是针对功能性的，因为非功能性的需求不好提，不好验。
但是本章作者给我们举了很多生动的例子，证明非功能需求也是可以进行量化和测试的，这是很好的启发。但是值得注意的是这些指标数字要有理可据，而不是拍脑袋的。
另外针对需求的理由，确实也应该记录。
否则不说人员离职将这部分信息带走了，就个人而言过个一年半载的也不记得当时的理由，这是很正常的。
而记在哪里这件事情我觉得值得商榷。
因为作者是基于“白雪卡”等方式去管理需求的，所以可以在上面进行记录。
我们倒是可以考虑在story或者SRS中增加这么一个条目，专门用来记录这项需求的理由。
第十三章 质量关
需求来自于人，人们并非总能确定他们需要什么，并非总能解释他们想要什么，需求也并非总是编写的很小心完整无二义性。
需求工作的要点是，你必须确保交给开发者的东西是准确的、完整的、成熟的、真正的需求，任何不足都有违需求工作的初衷。
开发者可以构建任何东西，但他们必须首先知道他们必须构建什么。
质量关守关人确认每项需求，然后将它们加入需求规格说明书中。
当规范的潜在需求到达质量关，是它应该足够完整、以便进行测试，决定是否纳入规格说明书。
被拒绝的需求，退回个体后退回给提出者，要求澄清修改或取消。
1 需求质量
需求规格说明，是指一项或多项需求的集合。
它可以是你选择的任何方式，包括存在在你的头脑中。
如果规格说明是错的，产品也会错。
质量关测试就是要尽可能的保全保需求的正确性
需求错误代价巨大，如果允许错误，经过需求过程进入后续的开发工作，代价会越来越大。
及早的发现错误修正的成本就越来越低。
2 使用质量关
质量关防止不受欢迎的，不想要的需求进入需求规格。
需求通过质量关并进入需求规格说明，必须经过一系列测试，这些测试确保需求是完整的、准确的，不会因为不合适将来的设计和实现而引起麻烦。
3 超出范围
项目中有一个很常见的问题，就是超出范围的需求。
我们讨论了如何建立上下文范围，来确定工作的范围。
而上下文范围的另外一种用法，就是作为需求是否超出范围的仲裁者。
上下文模型中的数据流入或者离开工作领域。
他们决定了功能，也就是说如果你决定要自动化，某些功能就必须编写需求。
虽然上下文模型很清楚的说明了范围，但你也必须考虑需求的相关性。
要测试需求的相关性，就要比较他的意图和项目的目标。
测试相当简单，这项需求对项目的目标作出贡献吗？
这项需求对项目对产品满足项目目标有直接或间接的帮助吗？
需求可能逐渐的对产品作出贡献，有时候产品的需求需要做一些事情与目标没有直接的关系，但是如果没有这些需求产品将不能实现他们的目标。
质量关守关人可以放行这样的需求，他们对项目的目标作出了贡献。
许多非功能性需求也可以看作对象，目标有间接贡献。
无关的需求可能意味着利益相关者对项目的目标有误解，或者意味着新的业务领域正在打开。
4 测试完整性
完整性测试指出，每项需求都应具备的相关属性。
如果缺少某些属性原因要么很明显，要么需要解释。
对需求的每个属性进行测试，站在每个利益相关者的角度问一下，是否有可能误解。4 测试验收标准
质量关守关人的任务就是要确保验收标准是合理的需求测量指标。
即可以对照需求来测试产品。
第一个要问的问题就是：需求是否有一个正确定义的验收标准？
如果没有对它的理解就可能不充分。
对验收标准的下一个问题是：是否能作为设计验收测试的输入信息？
你也应该考虑是否存在经济有效的方法来测试。
实现这项需求的解决方案，验收标准也必须符合现实项目的目标。
验收标准可能是采用事先定义的标准，安全需求也可能会采用标准作为验收标准。
质量关守关人应该检查标准是否适用于这项需求，验收标准采用数字还是用标准，这取决于需求的类型。
不论哪种情况，缺乏合适的验收标准，就足以拒绝这项需求。
依据使用术语，要让指定的需求只能用一种方式理解，除了验收标准之外，你还需要在规格说明书中定义术语及其含义，保持一致的第二件事是检查每项需求使用的数据方式都符合定义，关于不一致性最后的一点，应该对他有心理准备，你应该利用质量观来消除它
5 现实条件下是否可行
可行的需求是指这样一些需求：我们能以经济有效的方式为他们开发解决方案，并在实施之后能够成功运营。
你是否具备这项需求的技术能力？
你是否有时间和财力来实现这项需求？
是否所有利益相关者都接受该需求？
是否存在其他限制条件要求不可行？
是否存在一些伙伴应用或预期的工作环境与该需求冲突？
是否存在一些解决方案限制条件，使得需求难以实现或不可能实现？
6 需求还是解决方案
很不幸，对需求的描述常常以解决方案形式给出。
这导致把重点放在一种可能的解决方案上。
这种方案不一定最合适，通常隐藏的真正的需求。
方法：
- 检查该需求，它是否包含技术元素，它的编写方式是否描述了某种过程？
- 想想潜在的解决方案。
- 如果以一种抽象的方式来编写需求，其他解决方案都是可能的。
- 检查需求的基础内容，你必须拒绝所有不是需求的解决方案，除非解决方案实际上是限制条件。
7 需求价值
需求所附的顾客满意度/不满意度评分，说明了顾客对该项需求价值的认识。8 镀金需求
"镀金"这个术语来自镀金浴室龙头.
软件业用这个术语来指代那些不必要的特征或需求：他它们对产品成本的贡献多于对产品功能的贡献，它存在也许是因为有了就很不错，但如果产品不实现该功能，没有人会介意。
对镀金的第一项检查就是：如果没有该需求，会有影响吗？
如果没有人能真正地提出该需求的正当理由，那么可以认为它是镀金需求。
第二项检查也许更可靠：查看需求所附的满意度/不满意度评分。不满意度，评分很低，说明该需求可能是镀金的。
8 需求蔓延
需求蔓延是指在大家认为需求已经完成后，新需求又进入了需求规格说明书。
很自然，需求过程永远不会结束。
但总存在一个项目阶段，在这个阶段打算要开始构建产品的工作。
在这个阶段之后，发生的需求被视为需求蔓延。
质量关在控制蔓延方面是有作用的。
你可以利用上下文模型中的数据浏览，决定需求是否超出范围。
同时你也应该确保每项需求都包含有效的顾客满意度/不满意度评分。
这些评分告诉你，顾客认为该需求具有的价值。
如果评分高，那么蔓延的需求也许可以容忍。
如果需求蔓延到项目范围之外或许产品的目标无关，你就应该认真考虑一下，范围是否正确。
产品的目标正确吗？
符合实际吗？
你需要仔细找出需求蔓延的根源。
也许范围在一开始就说错了，也许范围应该变更。
需求蔓延的名声不好，主要是因为他打乱了开发进度，增加了因此而导致提交产品的成本。
首先大多数需求蔓延都是因为一开始没有正确的设计需求。
如果用户和客户没有机会完整地参与需求过程，那么毫无疑问需求将是不完整的，几乎可以肯定当提交日期临近时需求会蔓延，用户开始要求那些他们知道需要的功能。
还有一种蔓延产生的原因是最初的预算太低，不符合实际情况。
9 实现质量关
第一项决定是谁来实现质量关。
建议从两个人开始实现你的质量关，可能是需求分析师和一名测试人员。
这个质量关是对需求的快速简单的测试，而不是涉及半数团队成员的辛苦过程。
比如需求分析师通过电子邮件将所有需求发送给质量关守关人，守关人将其中一些加入的校规和说明书中。
第二种方式是使用自动化的工具。有助于减少质量关过程中人的干涉，某些需求收集工具可以完成初步的机械性的检查，把所有的属性都存在使用了正确的术语，提供了正确的标识符等。
伙伴相互检查对方的输出，在过程的早期发现错误。
第二个阶段是同级复查，由团队中的其他人员正式复查每项需求。
第三个阶段是团队复查，包括顾客和用户。
第四个阶段是管理者复查，主要关注质量关成功和失败的总结。
小婧的小结：
目前我们的需求的解决方案确认方式是通过同级复查，然后再进行SRS编写和提交需求评审/对接。
其实，针对目前业务尚不是很复杂，BA不是很多的情况下是可行的。
但是如果随着团队的扩大，和产品复杂度的增加，确实需要对需求这部分的质量关进行把关。
另外，本章说的其实是需求的质量关而不是解决方案的质量关。
在这个方面，感觉周围人都做的很少。
第十四章 需求与迭代开发
我们的行业中有一项重要的进步，即开发者和业务人员共同承诺，尽一切努力，尽可能的交付有价值的适当的能工作的产品。
让我们看看这个承诺中“快”的部分，许多组织机构不是等待需求的所有细节都得到定义，而是更喜欢迭代完成这项业务活动。
这样增量式交付发行版本直到解决方案被判定完成，这种迭代的方式意味着业务环境的开发环境中的关注点、想法和变化更加同步。目的是开发者更了解今天的业务问题，工作的产品更适合今天的业务环境。
1 迭代的需求过程
2 如何编写好用户故事
要发现用户故事，问这个问题：产品可以为用户做些什么来满足这个业务用例背后的业务意图？要编写真正的好故事，你不能只是被动地聆听业务利益相关者，写下他们认为最想要的东西。
你必须运用业务分析师的许多手艺，包括：创新、思考问题本质、业务事件的真正起源、在横线上思考。
3 迭代需求的角色
你需要一名主题事务专家。
他是业务和工作问题的知识来源，提出业务要求也回答问题，告诉你变更做出业务方面的选择。
业务分析师是业务知识的有用来源。
业务分析师既不属于业务，也不属于开发团队。业务分析师中立的渠道，他所受的训练是观察和发现业务需求，并将这些需求告诉开发者。
技术知识体现为开发者和系统架构师测试员，外部供应商的角色的某种组合。
第十五章 复用需求
每个人都想写出别人能复用的组件，没人想复用别人的组件。
但是你如果要为新产品制定需求，那么开始时问一下：这些需求或相似的需求是否已经写过？
总有可能节省一些工作量。
1 什么是复用需求？
成功的复用始于一种组织文化。
这种文化有意识地鼓励复用，而不是重新发明。
在召开项目启动会议时，就触发关于复用的问题。
- 项目的目标：组织机构中是否存在其他项目与本项目一致，或实际上包含相同的领域？
- 客户顾客和其他利益相关者：可以复用一份利益相关者名单，利益相关者图个利益相关者分析表格吗？产品的用户，其他产品是否涉及相同的用户，从而具有类似的易用性需求？
- 强制的限制条件：限制条件是否已在其他项目中指定？是否有组织机构的限制条件也适用于你的项目？
- 命名标准核定义：你几乎可以肯定利用原有词汇表的一些部分
- 相关事实与假定：注意最近一些项目的相关事实，对其他项目的假定也适用于本项目吗？
- 工作的范围：你的项目很有可能成为组织机构正在开发的其他项目的相邻系统，要利用其他工作上下文模型已经建立好的接口，考虑你的工作范围是否其他项目已经定了类似的业务时间
- 业务模型：业务数据模型和数据字典，是否有重叠或相关的项目，其业务数据模型可以作为你的起点。别太急着说现在的项目与之前的任何项目都不同。
是的，主题是不同。
但如果你不去看那些名字，有多少底层的功能实际上是一样的呢？
启动会上的利益相关者是很好的可复用组件的来源。
2 可复用需求的来源
非正式的有关经验的需求复用，当我们向同事询问问题时，我们希望从他人的经验中学习，这样不必从头开始努力。一旦你知道了工作的上下文范围，就可以寻找针对全部或部分。
这一上下文的需求规格说明，将它们作为潜在的客户有需求的来源。来源可以是任意一种同事的经验，也有的需求规格说明，模型当然还有书籍。
3 模式
模式是一种指南。
如果你试图重复某项工作或近似地重复某项工作，它可以给出一种可遵循的形式。
但是从需求的角度来看，什么是模式呢？
是因为这个从某种逻辑功能组的一组需求模式，改进了需求规格说明书的精确性和完整性。
注意模版的角色。
它是一个指南，而不是一种严格的指令或实现。
它可以复用，因为不需要重做实验或发明，它是一组知识或经验可以进行调整和直接使用。
4 领域分析
可以把领域分析看作是非项目系统分析，目的是为了了解有关的业务策略数据和功能，而不是构建什么东西。
在该领域所获得的知识将用于该领域内所有构件产品的项目，最好是得到复用。
领域知识被发现被记录并记录下来后，就可以被任何构建该领域产品的人使用。
领域知识适用于该领域的所有产品，要点不是重新发现已经存在的知识，而是使用真实的模型。
领域分析是一项长期过任务，战略分析上投资就像其他投资一样，投资将得到回报。
小婧的小结：
领域建模和领域分析非常重要。
这些年我越发的体会到业务对于BA的重要性了。
你也许有很多需求调研、分析、开发的工具和技能，但是如果不了解业务就永远无法深入核心。
与客户在沟通上也会有很多二义性产生。
就最近，我们听客户说“配建”，我们以为是“配件”。
这只是一个很简单的例子，我们需要不断的学习才能得到长远的进步。
第十六章 沟通需求
在开发世界的一头，你有业务；在另外一头，你有开发者和技术员。
他们已经为这项业务做了一些工作。
对需求的要求是：它们传递的方式必须让收到信息的人正确去读它、理解它、利用它。
“沟通需求”并不是必须要将需求写成规格说明书，但是它们必须规范到一定的程度，让所有涉及的利益相关者都能看清楚，并且同意你对需求的理解。
让需求正确，不是让开发变得更加官僚主义，而是让它更加有效。
1 将潜在需求变成书面需求
在网罗需求或制作原型时，发现的需求并不总是准确的，因为它们只是关于需求的想法或意图，有时候是模糊的半成型的。
而你得到的需求规格说明是产品构建合同的基础。
因此，它必须包含清晰、完整、可测试的要求，说明必须构建什么。
为了做到这一点，我们利用了规格说明书模板和需求项框架。
模板是一个拿来就可以用的需求规格说明编写指南或检查清单。
需求项框架是针对单独一项需求的容器，我们称之为“原子需求”。
2知识与规格说明书
在开始编写需求，并将它们汇集成需求规格书之前，值得花一些时间来考虑需求过程中积累起来的知识，比如下图的需求知识模型。
建议大部分的信息都可以包含在规格说明中。
知识模型中的累与其他类关联，这些关联表示的工作关系，未来模型的信息提供了额外的意义。可以将这些知识模型看作是收集管理和追踪的需求信息的一种抽象表示。
现在由你决定如何格式化并保存这些知识。
你决定使用怎样的自动化过程和手动过程，组合来记录和追踪这些内容。
你也应该考虑哪类的知识的哪些部分放在哪些文档中公布。
3 需求规格说明书模板
需求规格说明书模板是“站在巨人的肩膀上”完成的。
本书的作者从那些成功构建的产品的需求规格说明中，借用了一些有用的元素，把这些最好的元素打包成一份可复用的模板。
这个模板可以作为你的需求规格的基础，这样你也“站在了巨人的肩膀上”。
模板包括了五大部分内容：
- 第一部分是项目驱动。这些因素首先导致了项目的发生驱动。包括了项目的目标，为什么你会参与该项目的需求收集，以及谁想要这个产品。
- 接下来是项目限制条件。它们将限制条件的需求和结果，限制条件在项目启动阶段写进规格说明，但可能有一些机制能够更早地确定它们。
- 接下来是产品的需求。功能需求和非功能需求，每一项需求都以一定的详细程度进行描述，这样产品的构建者就能精确地知道要构建什么来满足业务需要，要测试什么，来确保交付的产品满足其需求。
- 最后一部分是项目问题。这些不是产品的需求，而是如果产品要件变成现实就必须要面对的问题。模板的这一部分也包括了“后续版本需求”，其中保存那些不打算在产品的首次发布中实现的需求，如果你采用迭代开发技术，“后续版本需求”类似于开发列表。
4 发现原子需求
原始功能需求和非功能需求应该写的更正式采用一致的结构，我们称之为“原子需求”。
因为他们不需要分解。
他们确实包含一些属性，就像真正的原子，包含一些亚原子粒子。
但作为一个单元来处理更有用，这些属性构成了完整的原子需求，最好是看成需求项框架，比如我们之前提到过的白雪卡。
5 汇编需求规格说明
与其说需求规格说明书写出来的，不如说是汇编的。
顾客需求模板和白雪卡提供了方便的指导，说明了汇编哪些内容才能得到完整的需求规格说明书。
模板指出了需求规格说明书要包含的主题，白雪卡表明了每项源自需求需要包含的内容。
6 自动化的需求工具
如果项目中有多位需求分析师，你会发现随着工作的推进和需求数量的增加，自动化自动化的工具会带来好处。
工具只是为你记录需求。
在你决定使用某个工具之前，请将需求知识模型也可用的工具进行比较，该工具能帮你记录哪些知识，不同类知识之间的关系如何记录，该工具能帮你维护哪些关系。
要知道你不太可能找到一个工具，能处理你的知识需求知识模型的方方面面。
但你肯定能找到一个尽可能接近的。
四处看看，你肯定会找到适合记录供需求的工具组合。
7 项目问题
项目问题是需求活动中发现的一些关注点。
我们在需求规格说明书中加入项目问题是担心如果不这样做，就会遗漏它们。
但是如果你的组织机构已经有了过程或合适的文档来记录这些信息，就不要将这些信息加到需求规格说明中。
本章小结
无论何时，如果需求分析是有所发现，就写下需求或部分需求。
并非所有的需求都是同时完成的。
正确的编写需求是很重要的。
一组好的需求能得到数倍的回报：
构建工作更精确，维护成本更低，完成的产品更准确地反映了客户的需要和想法。
小婧的小结：
需求规格说明其实一直都是我们BA最关注的内容。
虽然很多的互联网项目因为迭代周期短，不会形成大篇幅很正式的需求规格说明书（SRS），但是不论你是用什么方式进行记录，比如在原型上记录，或者采用白雪卡，或者采用用户故事。我觉得你需要“汇编需求规格说明”，也就是将你的产品中的所有需求及相关属性进行汇编。
这个是一项非常重要的组织过程资产，为后期的开发、测试、维护、使用、优化都提供了依据。
第十七章 需求完整性
在需求过程的某个阶段，你需要发布全部或部分需求规格说明。
因为其他人如开发者、测试者、市场人员及供应商需要它。
待发布的需求规格说明不一定包括全部需求。
在发布之前，需要确保相对于它的目的它是完整的。
这里使用术语“规格说明”来表示你拥有的任何形式的需求组合，不一定是正式的书面规格需求说明书，甚至不一定是正式的。
复查需求规格说明是否完整，可以考虑如下内容：
- 确定是否遗漏了需求
- 排列需求优先级，这样构建者能理解需求的重要性和紧急性
- 检查需求之间的冲突，这会阻碍一项或多项其他需求的实现
- 预估构建的成本，物评估项目所面临的风险复查的过程是迭代式的，寻找问题或遗漏，修正问题，这可能意味着引入新问题。
需要让这个过程迭代一次或两次，确保规格说明书中没有漏洞。
1 审查
有一种相当有效的规格说明审查方式，它是一个正式的过程，称为Fagan审查，具体步骤如下：
- 审查过程开始时，有一名协调人确定要审查的材料和审查者
- 审查者收到被审查的文档的概要，他们大概有一天的时间来研究这些材料
- 审查会议限制在两个小时以内，利用以前发现的问题的检查清单来分析文档
- 如果发现新错误，不在清单上的错误，就会更新清单
- 作者对文档进行返工协调人，确保所有的错误已经消除，如有必要协调人会安排跟进的审查
2 发现遗漏的需求
功能需求应该足够完成每个用例的工作。
为了检查这一点，假设你就是这个产品，把每个产品用例推演一遍。
如果做了需求要求的所有事情，是否能够得到用力的成果，用户是否满意地认为产品会完成他们的工作要求。
寻找产品必须处理的异常情况，复查场景。
针对每一步确定是否可能产生异常，或者是否有异常组织用户到达这一步。
针对非功能需求类型检查每个产品用例，是否具备了它需要的和合适该类用例的所有非功能需求。
3 发现所有业务用例
针对每个业务事件，你确定业务的响应，并确定相应的哪些部分需要由产品来完成。
建议你每次收集一个产品用例的需求，持续到涵盖所有业务事件为止。
4 排l需求优先级
确定优先级很复杂，因为他们涉及不同的因素，而且这些因素彼此之间常常产生冲突。
另外由于不同的利益相关者可能有不同的目的，对优先级达成一致意见可能比较困难。
虽然困难，这项工作迟早要做，越早越好，越早排队优先级就越容易。
每项需求都应该包含：顾客满意度和顾客不满意度评分。
这些评分帮助顾客考虑单向需求的相对价值，并对它们排列优先级。
影响优先级的因素有：
- 实现的成本
- 对顾客或客户的价值
- 产品所需的时间是技术实现的容易程度
- 业务或组织机构实现的容易程度
- 对业务的好处
- 遵守法律的要求
何时确定优先级？
一旦存在两项任务即可作出选择。
让需求知识变得越可视，就越有机会进行不盲目的选择，并帮助他人进行选择。
不断排列优先级的一部分，原因是期望值管理。
利益相关者常常假定术语“需求“，意味着这些功能肯定会实现。
需求实际上是一些期望和愿望，需要清楚地了解他们，以决定是否实现它们。
如果你在项目过程中一直不断地排列优先级，人们就能够接受这种折中，而不会感觉到欺骗。
排列优先级让利益相关者准备好接受一个事实，也就是你不能实现所有的需求。
小婧的小结：
需求的遗漏一直是一个大难题。
而需求的遗漏也是造成需求变更的一个非常常见的原因。
有的时候是BA觉得这“显而易见”，不需要进行描述。却没有想到会产生二义性。
我认为复查等方式是非常有必要的。
特别是找别人来复查。
当大家开始针对一段需求的描述进行讨论时，二义性就产生了。
我们必须保证需求是清晰、明确、可测试、完整，才能保证产品的正确性。
另外，关于需求的优先级我觉得有多种评分方式。
现在简单的高中低已经完全没有办法满足我们日益复杂的产品的需要了。
小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！
