RD-需求文档评审检查标准

《RD-需求文档评审检查标准》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、需求文档评审检查标准编号：CHECK版本20变更记录日期版本变更说明作者1.()新建1.1修订2.()发布新版本1范围需求验证包含以下几个方面的内容：1、软件盂求规格说明正确描述了预期的系统行为和特征；2、从系统需求或其他來源中得到的软件需求；3、需求是完整的和高质量的；4、所有对需求的看法是一致的；5、需求为继续进行产品设计、构造和测试提供了足够的基础。需求验证确保了需求符合需求陈述(Requirementstatement)的良好特征：•完整的•正确的•灵活的•必要的•具有优先级的•无二义性的和可验证的，并只符

2、合需求规格说明的良好特性(完整的、一致的、易修改的、町跟踪的)。2进入退出标准2.1需求文档进入审查的标准：1、文档符合标准模板；2、文档已经做过标准检查和语法检查；3、已经获得了审查员所需要的先前或参考文档，如业务需求说明书等;4、所有未解决的问题都被记录以便跟踪解决；5、包括了文档中使用到的术语词汇表。2.2需求文档退出审查的标准:1、已经明确阐述了审査员提出的所有问题；2、已经正确修改了文档；3、修订过的文档已经进行了拼写检查和语法检查；4、所冇问题已经全部解决，对遗留问题记录了解决的1=1标LI期;5、文档

3、已经检入项冃的棊线库。2.3建议的评审人员及其职责角色主要职责备注客户认可需求文档，评审时注重需求文档的完整性和、止确性项目总监批准需求文档客户经理注重文档的完整性项目经理关注需求的可跟踪性需求人员代衣（除作者外）关注需求的完整性、正确性设计人员代表从设计的角度注重需求的町实现性开发人员代表从开发的角度注重需求的可实现性测试人员代表注重需求的可测试性质量保证人员审计需求文档是否符合项目定义的标准3软件需求规格检查清单3・1完整性：通过不通过一般问题：1.所有对内部其他需求的交叉引用是否正确？2.是否所有需求在编写上

4、具有“一致性”和适当的详细程度？3.需求是否能为设计提供足够的基础？4.是否包扭了每个需求的实现优先级？5.是否定义了所有外部硬件、软件和通信接口？6.功能需求的内在算法是否已定义？7.需求规格说明中是否包括了所有已知的用户或系统要求？8.是否记录了対所有可预料的错误情况期望的动作/行为？非功能性需求相关：1.是否合理确定了所有的性能目标？2.是否合理地确定了安全与保密方Ifli的考虑？3.在合理的折衷情况下，是否清楚地记录了其他相关的质量属性目标，并加以量化？特殊问题：1.是否确定了所有的紧要时间(time-cr

5、itical)功能，并定义了他们的计时标准(timingcriteria)?2.是否已经明确地阐述了多语言的问题？3.2正确性：通过不通过般问题：1.是否冇需求与其他需求相冲突或重叠？2.是否简明、简洁、无二义性地表达了每个需求？3.是否每个需求都能通过测试、演示、审查或分析方法而得到验证？4.是否每个盂求都在项冃的范围内？5.是否每个需求都没有内容和语法上的错误？6.是否在需求中遗漏了必要的信息？如果冇，是否把他们标记为待确定问题。7.是否所有的需求都能在已知的约束条件下具备实现的可能性？&是否每一个列入清单的错

6、误信息都是唯一的和有意义的？9.是否所有的需求都是名副其实的需求，而不是设计或实现方案？3.4可维护性（可跟踪性）：通过不通过1.是否每个需求都是唯一的并被正确地找出，定位和定义？2.是否每一个软件功能需求都可追溯到一个高层次的需求，如系统需求，用例等。3.5经验数据：通过不通过4文档选择原则文档选择原则选择原因