《需求评审规范、需求质量规范、需求质量标准.docx》由会员分享，可在线阅读，更多相关《需求评审规范、需求质量规范、需求质量标准.docx（11页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、需求评审规范文档编写人：XXX编写时间：XXXX-XX独评估某项需求的可行性。可行性分析需要综合考虑多种因素。4.8可跟踪性那些能够追溯到需求来源，并能够依据开发生命周期跟踪到测试用例的需求，称为可追 溯的需求。能够跟踪到测试用例就表明需求得到了成功实现，需求之间也可以互相跟踪，并 可以跟踪到商业目的、目标和更高层级的需求。当需求发生变更或者其他变化影响到了该需 求时，如果每个需求都能够追溯到它的来源，就显得非常重要。当需求发生变化时，需求分 析师可以依据需求来源确定应该与谁联系。对于预测型周期项目，从项目管理的角度看，可追溯性为开发完成程度提供了相对准确 的估计。如果所有的需求都能通过设计和
2、构建阶段一直被跟踪到测试用例，那么目前的完成 进度，更重要的是还有多少未完成，这些都可以通过统计已成功实施的测试用例数目推算出 来。如果100%的测试用例都测试过了，那么至少在构建阶段的100%的需求都被满足了。4.9可用性可用性指需求分析说明书易于阅读、理解、修改、跟踪、维护、管理。具体应满足但不 仅限于下列要求：1）每项需求都有唯一标识，便于需求的引用、跟踪、管理；2）明确指出需求间的相互关联，便于在需求变更时确定变更所涉及和影响的范围；3）明确说明每项需求的来源和目的，便于需求的跟踪、维护；4）维护记录需求的修改历史，便于需求的跟踪、管理；5）对需求进行良好的组织，如：对需求进行类型划分
3、后将相关的需求分组，对需求进行层 次划分使需求的结构层次清晰，为需求建立目录表、索引等。便于需求的阅读、管理。6）编写、排版风格保持统一，便于阅读、理解，如对于同一类的内容，使用相同的表达方 式和方法；7）最终产品的每一个特性用某一术语描述，便于修改、维护；8）需求的粗细粒度耍保持一致；如软件需求分析说明书中同时存在下列的需求描述，其粒 度是不一致的：“用户信息对于红色合法的颜色代码应是R ”、“对于绿色合法的颜色 代码应是G ”、“产品应能对来自语音编辑指示做出反应L最后一个需求应作为一个 子系统而不应作为单个的功能性需求。9）对多处出现的同一内容进行统一的定义，再分别引用，便于修改、维护和
4、保证一致性;10）避免将多个需求合成单个需求；4.10可划分优先级划分优先级指为每个需求指定实施的优先级，以表明它在产品/项目中的重要程度及被 实现代优先顺序。具体应满足下列要求：为整个软件需求分析说明书制定统一的优先级划分标准；为每个需求指定一个定义好的优先级；5.附件此章节内容只作为开发人员编写软件需求分析说明书时的一个参考，不作为审查的内容。5.1 格式良好需求建议格式良好的需求包括以下内容： 条件。 主语。 祈使句。 主动词。 对象。 商业规则（可选）。 结果（可选）。例子一个格式良好的详细需求可能会这样写：按下新建帐户按钮（条件），系统（主语）将 （祈使句）显示（主动词）新账户输入屏
5、幕（对象），允许创建一个新账户（结果）。 .2其它编写建议列出软件需求分析说明书编写过程中的一些建议，这些建议的描述相对比较定性、笼统。1）使用书面语，不用口语；2）使用短句和短的段落；3）采用主动语气；4）语句表达方式的风格要保持一致；5）编写时尽量使用定量、客户的词汇，少用定性、主观的词汇；6）编写时以开发人员的角度来审视是否需要软件需求分析说明书作者的额外解释和帮助 开发人员才能理解需求，才能进行设计和实现？若是，则需进一步细化需求；7）避免一个段落中包含了多个的需求；对软件需求说明书进行持续的改进，软件产品的开发过程中，在项口的开始阶段可能 无法详细说明某些细节，在开发过程中可能发现缺
6、陷、缺点和错误，一旦发现需立即按 需求管理的流程改进；9）不要在一个需求中使用“和 / “或巴 以避免将多个需求合成一个需求；10）使用需求编制、管理工具，以便需求的变更并保证变更后需求仍是一致的、保证编写和 排版风格的统一；11）尽量使用形式化的语言，少用自然语言，如使用UML、图、表格、规范化模型等方式。 因为尽管自然语言是丰富多彩的，但不易精确表述；12）编写时重点在其表达的内容，不要拘泥于表达的形式，形式可以多种多样，合适易用 的即可；13）建议选择使用适用的需求分析说明书模板;文档修订记录章节编号版本号修订内容简述修订日期作者全部V1.0新增文档xxxx-xx-xxXX目录文档修订记
7、录21. 引言41.1 目的41.2 范围4评审参与人员42. 评审流程5质量要求52.1 明确性62.2 精确性62.3 一致性62.4 正确性72.5 完整性82.6 可验证性82.7 可行性92.8 可跟踪性102.9 可用性102.10 可划分优先级11附件112.11 格式良好需求建议112.12 其它编写建议111.引言目的软件需求说明书在软件开发、测试、质量保证、项目管理等项目活动中起着重要作用, 为了保证软件需求说明书的质量，本文档具体描述了软件需求分析说明书编写和评审时 需要关注的内容和质量要求。1.1 范日作为软件需求分析说明书是否可以进入正式评审的审查标准，符合该规范的可
8、以提 交正式需求评审；同时可作为评审人员进行评审时的参考。2 .评审参与人员软件需求质量的好坏以及项目参与人员对需求的理解程度，对项目能否顺利交付至关重要，因此参与需求评审的人员建议如下：3 .评审流程需求人员在完成需求文档后，先按照本文档规定的评审规范进行自查，在没有明显缺陷 后，可以提出正式的需求评审。一般需求评审在客户最终确认需求之前进行，先内部对需求， 特别是复杂需求达成一致（开发人员可从技术实现角度提出意见），然后跟客户进行最终需 求确认。一般正式评审召开一次，非正式评审可多次进行，目的是确保需求的理解和实现内部达 成一致。大概的流程如下：记录评审意见记录评审意见预约相关干系按照需求
9、评审规 范进行内容、格 式自查Demo演示需 求可准备简要 的需求说明视修改内容决 定是否再发起 正式评审文档等费料4 .质量要求软件需求分析说明书的格式没有固定要求，但是需求分析说明书的内容质量的好坏，对 系统方案设计、开发、测试和实施有着极其重要的影响。好的需求需要清晰简洁，并减少对 需要交付的产品产生不一致和模糊不清的理解，因此高质量的需求需要具有如下特点：1）明确性2）精确性3） 一致性4）正确性5）完整性6）可验证性7）可行性8）可跟踪性9）可用性10）可划分优先级4.1明确性需求说明书里描述的需求需要是清晰的，不是模棱两可的。当两个人对某项需求的含义 无法达成共识时，或当一个人理解
10、与该需求本义不同时，该需求就是模糊的。模糊的需求需要重 写以消除歧义，否则将会对系统的方案设计、开发、测试等工作造成错误的引导，因此需求在表 述时需要考虑更简单或者更直接的方式。如下表格为模糊与明确需求的例子。模糊需求明确需求系统需要检查名字栏只包含字母，地址栏只包 括字母或者数字，且仅是美国或加拿大的地 址，而数量栏则只能是数字1.1 系统需要确认1.1.1 名字栏只包含字母1.1.2 地址栏只包含字母或数字1.1.3 所有地址都在美国或者加拿大1.1.4 数量栏只包含数字从扫描仪通过时，系统提供员工身份信息明确需求当员工通过扫描仪时，系统在屏幕上显示雇员的图片4.2精确性精确性描述的是需求
11、说明书内容如何恰到好处的描述需求内容，不多也不少。因此要学 会选择恰当的用词，且清楚的知道需求应该要达到什么样的精确度，如下是精确和不精确语 言的例子。精确非精确当输入的部门代码和文件中的部门代码不匹配时，系统会显示“无效的部门代码”当输入的部门代码和文件中的部门代码不匹配时，系统会显示错误消息4.3 一致性每项需求都应该在需求分析说明书出现一次，以避免出现矛盾和冗余，该需求也不能和 文档中的其他需求有冲突。语言要始终保持一致，需求分析师通过重写、修订、更改和修改需求分析说明书来保持需求的一致性。具体应满足但不仅限于下列要求:1）同一内容在整个软件需求说明书中其内涵和外延都是一致的；2） 不存
12、在一个需求与软件的其他需求或高级别的系统需求发生冲突的现象；3） 术语的定义与标准、规范、行业用户的定义一致；4） 需求被引用时的含义与定义时的含义保持一致；5） 术语被引用时的含义与定义时的含义保持一致，若某一术语在某一特殊的行文中使用时具有多种歧义，那么对该术语的每种含义作出解释并指出其适用场合；一致和不一致语言的举例如下：一致不一致1.1安全系统将2.1安全系统将5.8安全系统将安全系统将1.1安全系统将2.1新安全系统将5.8安全卡系统将6.9.1 R/F安全系统将.4.4正确性正确性指对需求的定义必须是对的，它涵盖了软件需求分析说明书中所定义的需求与用 户的实际需求是一致的、对需求内
13、容的描述是明确、准确、精确和无歧义的。具体应满足但 不仅限于下列要求：1）每个需求与用户的实际需求是一致，即正确表达了用户的真正需求，可以使用让用户确 认的方式来保证；2）内容的表达没有错误，应满足包括但不仅限于下列要求： 使用正确的语法，拼写，标点；无错字和别字； 用词贴确；3）内容的表达无歧义，如同一读者对同一表达通过不同的断句方式得出多种正确的理解;4）无不一致的内容，详见质量要求的“一致性”部分；5） 没有因使用不明确的表述而存在可随意发挥的内容，如：描述中出现了对于软件需求分析说明书作者自己很清楚但读者并不清楚的主观性词语（除了己经对这些词语进行 了明确的定义或引用说明），具体如：“
14、待定”、“可能”、“即将”、“考虑、最好”、 最差、“一般情况”、“特殊情况”、“可以”、“用户友好性”，“容易”，“简单”，“快速”，”有效”，“几个”，“艺术级”，“改善的”，“最大”，“最小”、“较好”、“较差”、“等等”、“一期实现”、“根据需要”、“如果可能”、“高级”。4.5 完整性完整性是指软件需求说明书包含了所有应该具备的内容，具体如下：一 .需求没有遗漏：确定在需求分析说明书编制的过程中，没有遗漏需求获取阶段所确 定的需求。其依据为包括但不仅限于通过正式审核的下列文档：1）市场调研报告；2）用户需求调查报告；3）需求分析讨论会议记录二 .需求没有冗余：即同一需求不能在软件需求
15、分析说明书中出现多次；三 .不存在超出产品/项目范围的需求；.除设计上的特殊限制之外，软件需求分析说明书中不描述任何设计、验证或项目管 理细节的内容；四 .软件需求说明书应包含下列信息：1）导言（具体解释见产品需求PRD文档的“导言”章节）2）产品概述（具体解释见产品需求PRD文档的“产品概述”章节）3）功能需求（具体解释见产品需求PRD文档的“功能需求”章节）4）非功能需求（具体解释见产品需求PRD文档的“非功能需求”章节）5）相关文档（具体解释见产品需求PRD文档的“相关文档”章节）。五 .包含第五条中未列出但应该在需求分析说明书中说明的其他信息；可验证性可验证性指针对每项需求能够找到某种
16、方法,通过这种方法可以验证该需求被实现后其 实现的结果是否正确。具体应满足但不仅限于下列要求：1）每个需求必须是可行的，只有可行的才是可验证的；2）每个需求项必须有明确的验证标准，且验证标准在现有的技术水平下是可测量的（能够 找到某种测试方法，通过这种方法可以明确判断出是否己经达到预期指定的要求），如 对于该性能需求，必须给出已经量化的所要达到的具体性能指标，且这些指标都能用某 种方法或工具进行测量;3）需求必须一致的，详见质量要求的“一致性”部分；4）需求必须是明确的，详见质量要求的“正确性”部分的第5条；如任何需求如果说“产 品/项目将要支持什么”是不可验证的，必须具体说明何时支持，如何支
17、持。4.6 可行性需求可行性评估主要有如下几种分类方式：1）运营可行性某项需求满足后，是否它的实现能得到所有使用该产品或解决方案的干系人的认可和支 持？应该确保针对某干系人群体的解决方案需求不会对其他干系人群体产生产品无法 使用或效率低下的影响。2）技术/系统可行性目前所选技术是否能实现该需求？需求分析师需要和解决方案开发团队一起，以确保每 项需求在技术上是可行的。对于适应型项目，技术可行性分析相对容易。在某段时间内， 项目团队专注于一小部分工作，并且每天都紧密协作。对于预测型项目，则会存在需求 分析师与解决方案开发团队互动不够充分的风险。无论预测型或者迭代型，在确定需求 文件基准之前，需求分
18、析师都要确保解决方案开发团队对需求进行了可行性分析。由于 技术不可行而无法支持某项特性，则应该在需求收集的初期就告知相应的干系人，而不 是在项目后期再告知。3）成本效益可行性满足某需求所需耗费的成本，与该需求所能带来的商业价值相比，是否合理？成本可能 是一项被跟踪的需求属性。与解决方案开发团队、商业干系人和项目经理一起工作，对 每项需求进行成本效益可行性分析。当需求所带来的价值超过实现成本时，该项需求才 是合理的。4）时间可行性在项目阶段的分配时间内能否达成特定需求或者该功能是否应该推迟到将来的版本？ 某项需求可能导致项目延期，因此需要尽早了解是否有某项需求需要耗费解决方案开发 团队大量时间以至于超出了为整个开发周期所分配的时间。不管是时间因素还是成本因素，没有哪个因素能单独确定某项方案的可行性，或者能单