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