- 确认需求
如果需求含糊其辞或者不完整，就会给软件开发人员带来挫败感。
将软件开发与制定测试计划和测试设计相结合的V字模型
概念性测试源自需求（故不依赖于实现），在写代码之前，就能暴露出需求和模型中的错误、不明确和疏漏。
确认与验证
除需求收集、需求分析和需求规范外，需求确认是需求开发的第四部分。
确认和验证是两种不同的工作。验证判断的是某开发活动的工作产出是否符合要求（正确做事）。确认评估的是产品是否满足客户需要（做正确的事）。
需求确认评估的是写的需求是否正确（源自业务目标）。
需求确认工作试图确保以下几点：
>软件需求准确地描述了预期的系统能力和特征，并且这些能力和特征能够满足不同干系人的需要。
>从业务需求、系统需求、业务规则以及其他来源中正确产生需求。
>需求是完整的、可行的、可验证的。
>所有需求都是必要的，并且整个需求集合足以满足业务目标。
>所有需求表示彼此都是一致的。
>需求能够为后续的设计和构建提供充分的依据。
需求评审
让需求文档作者以外的人查验工作产物中的问题，这种方式称为“同行审查”。
非正式评审用于找出显而易见的错误、不一致和分歧，可以帮助发现不符合高质量需求应有特征的话语。
正式同行审查遵循的是一种经过良好定义的流程。正式需求评审要产出一份报告，其中注明检查的材料、评审人以及评审团关于需求可否接受的意见。首要交付物是一份摘要，记录所发现的缺陷以及在评审过程中提出的问题。
最有建树的一种正式同行审查称为“审查”（inspection）。
追求软件质量的最大化，团队就应该对大多数需求进行审查。通过风险分析，将必须审查的需求辨别出来。
审查流程
审查是一种经过良好定义的多阶段流程，审查小组对工作产物进行仔细查验，力求发现缺陷和改进机会。
下面的描述基于费根审查技术。
>参与者
在开始之前，要确保能够召齐必须参加会议的人员。
>需求文档作者与其同行
>充当信息来源并将信息注入审查项的人
>要根据审查项开展工作的人
>负责系统接口的人
将审查团尽量限制在7人以内
>审查角色
>需求文档作者:
需求文档作者创建并维护待审查的工作产物。需求文档作者通常负责引导讨论。
>主持人:
主持人与需求文档作者制定审查计划，协调不同的工作，引导审查会议顺利进行。
>讲解员:
指定一名审查人为讲解员。讲解员给出自己的理解,方式的好处在于能够暴露出歧义、可能的缺陷或猜测。
>记录员:
记录员使用标准表格来记录会议中产生的问题和发现的缺陷。
>准入条件
只有满足特定的前提，一个需求文档才算是做好了审查准备。
下面推荐一些需求文档审查准入条件：
>文档符合标准模板，并且没有明显的拼写、语法和格式问题。
>为了便于引用定位，文档需要印有行号或者其他唯一标识。
>所有开放问题都标记为TBD
>主持人对文档进行标准采样检查
>审查环节
>>制定计划
需求文档作者和主持人共同制定审查计划。他们确定谁要参加、审查人员在会前应当收到哪些材料、覆盖材料所需的整个会议总时间以及应当何时安排审查。
每小时评审的页数在很大程度上影响着能够发现的缺陷数量。
>>准备工作
在审查会议之前，需求文档作者应当将背景信息分享给审查人员，以便他们能够理解审查项的上下文并且知道需求文档作者对审查的目标。
陷阱:如果审查会的参与者自己还没有完成查验，就不要召开审查会。没有成效的会议会导致“审查是在浪费时间”的错误结论。
>>审查会
在审查会中，讲解员引导其他审查人通览整个文档，用他自己的话逐个描述需求。审查人一一挑出可能的缺陷和一些问题，记录员就捕捉这些问题，并为需求文档作者记录到行动事项列表中。审查会的目的在于尽量多识别出重大缺陷。
在检查完所有材料之后，团队会决定是原样采纳、还是稍微修订或提出需要重大修订。
>>>返工
需求文档作者应当留出一些时间完成审查会之后的返工工作。
>>>跟进
在审查流程告一段落后跟进，并使主持人能够判断所有需求审查的准出条件是否全部都得以满足。跟进环节会暴露一些未完成的或者未正确执行的修改。
>>>准出条件
应当规定准出条件。这里列出了一些可能的需求审查准出条件。
1.在审查中产生的所有问题都得以解决。
2.对需求和相关工作产物所做的所有改变都得以正确执行。
3.提出的所有问题都得以解决，或者每个问题的解决过程、目标日期以及负责人都已经记录在案。
>缺陷检查清单
为了帮助评审人找出产品中典型的错误，需要为项目创建的每个需求文档分别开发一个缺陷检查清单。
| 完整性 |
| ▢ 需求是否解决了所有已知的客户或者系统的需要？ |
| ▢ 是否遗漏了任何必须有的信息？如0果有，是否标记为TBD? |
| ▢ 定义的功能性需求是否有内在的算法？ |
| ▢ 所有外部硬件、软件和通信接口都定义了吗？ |
| ▢ 是否记录了在所有所预测错误条件下的预期行为。 |
| ▢ 需求是否为设计和测试提供了充分的依据？ |
| ▢ 每个需求是否都有实现优先级？ |
| ▢ 每个需求是否都在项目、版本或者迭代的范围内？ |
| 正确性 |
| ▢ 是否有任何需求与其他需求冲突或重复？ |
| ▢ 是否所有需求都使用清晰、简洁、明白、语法正确的语言编写？ |
| ▢ 是否每个需求都可以使用测试、演示、评审或者分析加以验证？ |
| ▢ 是否所有错误信息都清晰并有意义？ |
| ▢ 是否所有需求都确实是需求，而不是解决方案或者约束？ |
| ▢ 是否所有需求在已知的约束中在技术上都是可行且可实现的。 |
| 质量属性 |
| ▢ 是否所有的可用性、性能、安防和保全目标都有正确的描述？ |
| ▢ 是否对其他需求进行记录和量化，并且具体说明各方均认可的权衡结 |
| ▢ 是否标出时间敏感的功能，并且规定具体的时间要求？ |
| ▢ 是否已经充分解决国际化和本地化问题？ |
| ▢ 所有质量需求是否都是可度量的？ |
| 组织及可追溯性 |
| ▢ 需求的组织方式是否和名称符合逻辑并且可理解？ |
| ▢ 对其他需求和文档的交叉引用是否全部正确？ |
| ▢ 所有需求撰写的详细程度是否一致、合适? |
| ▢ 每个需求的编号是否唯一、正确？ |
| ▢ 是否追溯了每个需求的起源(比如，系统需求、业务规则)? |
| 其他问题 |
| ▢ 是否遗漏了某些用例或者处理流程？ |
| ▢ 是否遗漏了用例中的某些选择分支流程、异常或者其他信息? |
| ▢ 是否识别出了所有商业规则？ |
| ▢ 是否遗漏了某些能使文档清晰易懂或完整的视觉模型？ |
| ▢ 所有必要的报表说明是否存在且完整? |
>需求评审提示
制定检查计划
尽早开始
分配足够的时间
提供上下文
设置评审范围
限制重复审
对评审排优先级
>需求评审面临的挑战
需求文档过长
审查团规模大
审查人地域分散
评审人准备不足
需求原型
概念验证（POC,Proof-Of-Concept）原型可以说明需求是可行的。演示原型让用户能够看到需求实现之后是怎样运作的并验证这就是他们预期的结果。仿真等其他复杂的原型，能够使需求确认更精准，但是，搭建的原型越复杂，越耗时。
需求测试
写功能测试能够折射出你希望系统在特定条件下应当有的行为。当你无法描述预期的系统响应时，会发现不明确和有歧义的需求。
陷阱：留意那些声称直到需求写完才能开始干活的测试人员，还有那些声称不需要需求就能对软件测试的测试人员。测试和需求有一种协同关系，代表互补的系统视角。
可以使用概念性测试来评估功能性需求、分析模型和原型。这些测试应当覆盖每个用例的一般性流程、选择分支流程以及异常，这些都能够在需求收集和分析中识别出来。
业务分析师写功能性需求与测试人员写测试的起点都是一样的，都是用户需求。
用户需求中的歧义以及理解的差异都会导致功能性需求、模型和测试所表达的视角不一致。
开发与测试工作产物的来源相同
使用验收条件确认需求
客户需要评估系统是否满足预定义的验收标准。验收标准或者验收测试,用于评估产品是否满足需求文档中的需求、是否适用于预期的操作环境。
验收条件
与客户一起制定验收条件，提供了一种验证需求和解决方案的方式。
验收条件能够将“你需要用这个系统做什么？”这一问题的启发转变为“你如何判断解决方案满足了你的需要？”鼓励用户在定义验收条件时使用SMART 原则：具体（Specific）、可度量（Measurable）、可达到(Atainable)、相关（Relevant）以及有时限的（Time-sensitive）。
验收标准满足几个维度要求：
>在软件进行验收并投入使用之前，必须能够正常工作的高优先级功能。
>必须满足的基本性非功能条件或者质量指标。
>特定的法律、法规或者合同条款。
>支持交接、基础设施或者其他项目（而非产品）要求。
>还可以考虑使用“拒收标准”对产品交付进行条件限定和评估，
验收条件不是功能单元测试，它们是系统达到客户满意度所需要的必要条件。功能测试和单元测试用于更深层的测试，用于测试功能流程、异常流程、边界条件和与故事相关联的相关功能。
验收测试
验收测试是验收条件中最大的组成部分。
应当专注于测试用例中的一般流程及其相应的异常，少留心使用不太频繁的选择分支流
陷阱：不要指望用户验收测试能够取代广泛基于需求的系统化测试，因为系统化测试能够覆盖所有正常或者异常路径、各种数据组合、边界值以及其他可能藏匿缺陷的位置。
写需求是不够的。需要确保需求的正确性，并且这些需求能够为设计、构造、测试和项目管理奠定足够良好的基础。验收测试计划、非正式同行审查、审查和需求测试技术将帮助你比以往更快、成本更低的方式构建更高质量的系统。
- 需求的重用
重用的终极目标是提升软件开发效率。
为什么要重用需求
有效重用需求会带来诸多收益，包括更快速的交付、更低的开发成本、应用内和不同应用之间的一致性、更高的团队生产率、更少的缺陷以及减少返工。重用可靠的需求，不仅能够节省评审时间，缩短审批周期，还会提升测试等其他项目工作的速度。如果有以往项目实现相同需求时所用的数据，重用就可以进一步帮助你准确估算工作量。
需求重用的维度
| 维度 | 选项 |
| 重用的范围 | 单独的需求陈述需求及其属性需求及其属性、环境及相关信息（比如数据定义、术语定义、接收测试、假设、约束以及业务规则）一组相关需求一个需求集合及其相关的设计元素一个需求集合及其相关的设计、代码和测试元素 |
| 变更范围 | 无需求的相关属性（优先级、理论依据、来源等）需求陈述本身相关信息（测试、设计约束、数据定义等） |
| 重用手段 | 从另一份需求规范说明复制和粘贴·从可重用需求库复制引用原始信息出处 |
重用范围
第一个维度与重用所需材料的质量密切相关。
修改范围
为使现有需求可以重用于新项目，是否需要一定程度的修改?
重用手段
哪些需求信息类型可以重用
相比单一、孤立的需求，某特定功能区域中相互关联的一个需求集合能够提供更大的重用价值。
可重用的相关需求信息分组：
>功能及相关的异常与验收测试
>数据对象及其相关属性与验证
>符合相关的业务规则，行业中其他规范性约束
>以及组织政策相关的指示
>对称性用户功能，比如撤销/重做（如果重用应用的撤销功能，也应当重用对应的重做需求）
>对数据对象的相关操作，比如增、删、改、查
一些可重用需求信息的类型：
| 重用范围 | 潜在可重用需求资产 |
| 在产品或应用内部 | 用户需求、用例中的具体功能需求、性能需求、易用性需求、业务规则 |
| 跨产品线 | 业务目标、业务规则、业务处理模型、内外关系图、生态地图、用户需求、核心产品特性、干系人资料、验收测试、术语表 |
| 跨企业 | 业务规则、干系人资料、用户类别描述、用户角色、术语表 |
| 跨业务领域 | 业务处理模型、产品特性、用户需求、用户类别描述、用户角色、验收测试、术语表、数据模型和定义、业务规则、安全需求、合规性要求 |
| 在操作环境或平台中 | 约束、接口、用以支撑特定类型需求（如生成报表）所需的功能基础设施 |
常见重用场景
软件产品线
当你创建一个产品家族（即一个软件产品线），各个产品之间就会有许多通用的功能。
>通用的，即出现在产品线的所有成员中。
>可选的，即出现在某些家族成员中，而在另一些家族成员中没有。
>变体，即特性的不同版本出现在不同的家族成员中。
再设计与替换系统
再设计与替换系统会从原始系统中一直沿袭重用某些需求，即便它们从未进行书面记录。
其他可能的重用机会
| 重用机会 | 例子 |
| 业务过程 | 通常，业务过程在不同的组织中是相同的，并且通常需要软件支持。 |
| 分布式部署 | 同一个系统通常会进行多次部署，每次只有轻微的变化。 |
| 接口与集成 | 通常，出于接口和集成的目的，需要对需求进行重用。 |
| 安全 | 用户认证和安全需求在不同的系统中通常是相同的。 |
| 通用的应用特性 | 业务应用经常包含一些通用的功能，其需求甚至其完整的实现都可以重用。 |
| 多平台的同类产品 | 即便不同平台中的一些详细需求和/或用户界面设计会有所差异,但仍然会使用同一组核心需求。 |
| 标注、规章及法规 | 许多组织会根据各种规章制度开发整套标准。这些标准可定义为一个需求集合，并且可以在不同项目间重用。 |
需求模式
运用可以简化需求编写工作的知识，也可以视为重用。
需求模式包含下面几个部分：
1.指南：与模式相关的基本细节，包括相关的模式、每种模式所适用（不适用）的场合以及如何写此类需求的相关论述。
2.内容：对需求应当传达哪些内容逐项进行详细的解释。
3.模板：具有占位符的需求定义，占位符可以填充可变的信息。可以使用填空的方式写这个类型的具体需求。
4.示例：这类需求的一个或多个示例。
5.额外要求：额外要求能够定义主题的某些方面或者一段阐释，说明如何写一组详细的要求才能列明满足一个初步的概要性需求必须做哪些事。
6.对开发和测试的考虑：在开发人员实现模式指定类型的某个需求时和测试人员对这些需求进行测试时应当牢记的因素。
促进重用的工具
工具通过跨多个项目或基线进行需求共享，从而实现对需求的重用。
使需求可重用
尽管重用（reuse)可以节省学习时间和金钱，但使需求变得易于可重用（reusable）是需要消耗时间和金钱的。
必须按适当的抽象级别和范围写可重用的需求。
在重用的简单化（更加抽象、更范化的需求）和经济化（更详细、更具体的需求）之间，很难找到一个合适的平衡。
选择恰当的需求抽象级别还能够使构建过程受益。
需求重用的障碍与成功要素
需求重用听上去很美，但是它并不总是可行或者适用的。
重用的障碍
缺少需求或需求碎片化：是以往项目中所开发的需求没有被记录下来而导致无法对它们进行重用。
NIH和NAH：NIH的意思是“并非发明于此”（not invented here）。NAH，或称“不适用于此”（not applicable here）。NIH和NAH往往可以体现他们不灵活的态度。
写作风格：最好能够采用一些标准的记录需求表达方式来促进重用。以同等粒度级别来写需求。术语一致性也很重要。有设计约束的需求很少有机会重用于不同的环境中。
组织方式不一致：需求文档作者会按照许多不同的方式组织需求，这也使得人们难以找到要重用的需求。
项目类型：与具体实现环境或者平台有紧密耦合关系的需求，不太可能形成重用的需求或者从现有的需求知识池中获益。
所有权：所有权是另一个不得不提的障碍。
重用的成功要素
一个重视重用的组织，应当建立一种机制来促进分享和利用现有的信息。
知识库：可以采用以下几种形式：
>一个单独的包含以往需求文档的网络共享文件夹。
>存储在可跨项目搜索的需求管理工具中的需求集合。
质量：重用需求的人需要信任信息的质量。
交互：需求之间通常存在逻辑关联和依赖。
术语：跨项目建立的通用术语和定义，有助于提升可重用性。
组织文化：管理者要从两个方面鼓励重用：建设真正具有重用潜质的高质量组件以及有效重用现有工件。
项目需求是最宝贵的企业信息。找一找需求知识中哪些可以视为企业级资
- 需求开发之外
需求驱动项目的计划、设计、编码和测试工作
估算需求工作量
判断需求工作所需的时间和工作量，是最早的项目规划工作之一。
通常，小项目的需求工作要占总工作量的15%~18%(Wiegers 1996），合适的百分比取决于项目的大小和复杂程度。
理解需求实际上会加速开发，正如下面的例子所述。
在估算时，凭紧验判断项目应当对需求开发投入多少工作量。
有效估算项目需求开发工作量的方法。这种方法包含三种相辅相成的估算：总工时占比；开发人员-业务分析师数量比；活动分解（使用基本的资源成本生成自下而上的估算）。通过对比三种估算的结果并对明显的偏差进行调和，使分析团队能够得到最精准的估算。
第一种：估算基于对项目整体工作量的估算占比。虑将约项目总工作量的15%分配给需求工作。
第二种：估算使用常用的开发人员-业务分析师人数比。默认值是6：1。这是一种经验性估算方式，而不是对未来的精准预言，所以应当根据具体的组织和项目类型进行调整。
第三种：以项目中创建的各种工件的预估数量为基础，根据从众多项目中积累的活动时间数据，估算每个活动所需时间，能够得到总需求工作量的估算值。
从需求到项目计划
由于需求是开展项目预期工作的基础，所以应当根据需求进行估算、规划和安排日程。记住，最重要的项目结果是满足业务目标，而不仅仅是根据原来的项目计划实现所有的初始需求。需求和计划只是团队为得到预期结果而对所需时间进行评估后得到的一个特定时间点。但是项目的范围可能早已脱离目标，也可能初步计划根本不切实际或者并没有很好地对准目标。业务需求、业务规则和项目约束，这些都会发生变化。如果不更新计划以迎合目标和现实情况，项目的成功就会有问题。
根据需求估算项目规模和工作量
对完成项目所需的工作量和时间进行切实的估算，取决于许多因素、，下列要给出一些常用的指标：
>可单独测试的需求的数量
>功能点
>故事点数或者用例点数
>用户界面元素的数量、类型和复杂度
>实现特定需求预估需要的代码行数
重点提示:如果不对比估算和实际项目结果，也不提升估算能力，估算就会永远停留于猜测阶段。只有花时间积累足够多的数据，才能将软件规模的度量同需求开发工作量和项目总工作量关联起来。敏捷项目的早期迭代可以为团队评估自身速率。
如果经常变更需求，那么再好的估算过程也会遭遇困境。
目标并不等同于估算值。一旦强制性的截止期限与经过周密估算的计划不符，就要进行谈判。由于能够根据深思熟虑的过程和历史数据来佐证估算，所以在谈判中，项目经理占的位置比仅靠猜测的人更有利。
不确定的需求导致不确定的估算。
重点提示：无论认为别人想要听到什么，都不要投其所好给出自己的估算。虽然需要协商才能消除预测失配过度，但是，不应只因有人不喜欢，就改变自己对未来的预测。
需求和排期
许多项目都采用“倒排时间”的方式：先敲定交付日期，然后再定义产品需求。这往往是由于无法在规定日期按预期质量水准交付所有必要功能。
但这样做不如在做出详细计划和承诺前定义软件需求现实。
考虑按阶段为项目制定计划和提供资金。
软件项目屡屡达不到到目标，并非由于软件工程师水平不够，而是由于开发人员和项目其他参与者的估算过于乐观以及规划不切实际。
有效的项目排期需要以下几个要素：
>预估的产品规模
>根据历史数据得知的开发团队生产率
>完整实现并验证某个特性或用例的必要任务清单
>相当稳定的需求，至少对即将开始的开发迭代如此
>经验，有助于项目经理根据每个项目的无形要素和独特之处进行调整
陷阱：不要屈服于压力而做出明知不可行的承诺。这样做的后果是两败俱伤。
从需求到设计和代码
在需求和设计之间并非界限分明，而是存在灰色、模糊的过渡地带。
理想情况下，对于系统的目的和用途，不应偏向于设计考虑因素。
UI 惯例往往会给项目带来设计约束。
架构与分配
功能、质量属性以及约束驱动着产品的架构设计。
分析架构有助于分析师对需求进行验证并调整需求的精度。
重要的一步时将高层系统需求分配到不同的子系统和组件中。分析师、系统工程师或者架构师会将系统需求拆解成软件和硬件子系统的功能性需求。
将系统能力分配给子系统和组件，必须自上而下地进行。
软件设计
下面的策略能够使所有项目受益：
>开发一个由子系统和组件构成的稳固架构，能够延长整个产品的寿命
>识别关键功能模块或者需要构建的对象类型，并定义其接口、职责以及与其他单元的协作
>定义每个代码单元的预期功能，遵循合理的设计原则，做到高内聚、
>松耦合以及信息隐藏（McConnell2004）
>确保设计能够适用于可能产生的异常条件
>确保设计能够达到预期的性能、安全以及其他质量目标
>识别所有可以复用的现成组件
>识别并遵守所有对软件组件的设计具有明显影响的限制或约束
从需求到测试
需求分析与测试珠联璧合。
需求是系统测试基础。
验收测试应当覆盖三要素：
在正常情况下的预期行为（正确的输入数据和有效的用户操作）。
应当如何处理预见到的错误情况和预期的失败场景（错误的输入数据或无效的用户操作）。
是否满足质量预期（比如响应时间、安全防护以及完成任务所需要的平均时间或者用户操作数）。
测试人员或质量保证人员应当确定如何验证每个需求的实现。可考虑采用以下方法：
测试（运行软件，找出缺陷）
审查（查验代码，确保它满足需求）
演示（展示产品的运行符合预期）
分析（推测系统在特定情境下如何运行）
清晰明确的业务需求能够驱动用户验收测试（UAT）
要想按照严重、中等和轻微清楚区分缺陷，就需要了解关键需求。
考虑如何验证每一个需求，每个功能性需求至少要对应一个测试。
随着开发的推进，团队会开始逐层细化需求，从来自用户的高层需求，到功能性需求，最终化为独立的代码模块说明。测试权威 指出，对于构建的软件，不要只在最终用户层面进行测试，必须按照需求对各个层面进行测试。
从需求到成功
试图了解大量需求确实很难，即便需求写得很清楚，但跳过这些需求是导致项目失败的关键因素。
软件开发项目的最终交付物是能够满足客户需要和预期的解决方案。在业务需求满足客户的道路上，需求是至关重要的一步。
如果没有以高质量需求为基础的项目规划、设计以及验收和系统测试，劳神费力可能也不见得能交付稳定的产品。
尽管如此，也不要成为需求过程的奴隶，不要花时间产生不必要的文档或者举行仪式性的会议，因为这样做毫无意义。
力求在严谨的规范与凭空编码之间取得合理的平衡，努力将构建错误产品的风险降到可接受的水平。
发表回复