需求规格说明书评审

需求规格说明书评审要:《需求规格说明书》是软件工程需求阶段的成果性文档,其质量的好坏直接关系到软件开发项目的成败,监理方作为项目质量的监控方,有责任和义务对《需求规格说明书》进行审核把关,本文就审核的重点和需要把握的要点进行阐述,最后给出监理审核报告模板,以供监理同行探讨和改进。君欲食坚果必先破其壳需求范围控制是需求阶段控制的难点,如果处理不好,会导致业主方与承建方的纠纷,甚至项目没完没了,不能验收。因为在项目验收时往往以招标文件、投标文件、开发合同、需求成果文档为依据来确定项目是否达到了范围的要求…

要:《需求规格说明书》是软件工程需求阶段的成果性文档,其质量的好坏直接关系到软件开发项目的成败,监理方作为项目质量的监控方,有责任和义务对《需求规格说明书》进行审核把关,本文就审核的重点和需要把握的要点进行阐述,最后给出监理审核报告模板,以供监理同行探讨和改进。
    君欲食坚果 必先破其壳  
    需求范围控制是需求阶段控制的难点,如果处理不好,会导致业主方与承建方的纠纷,甚至项目没完没了,不能验收。因为在项目验收时往往以招标文件、投标文件、开发合同、需求成果文档为依据来确定项目是否达到了范围的要求,往往是招投标文件对用户需求范围规定不细,合同没有规定,如果需求成果文档再写的很草,项目到了上线试运行时,业主方会认为所要的功能没有实现,承建方认为用户开始没有提出需求,后来不断改变和新增需求,项目不可控,永远没法验收。为解决这一难题监理方应从中起到重要作用。建议的做法是:
    一是控制好软件开发方法利于需求获取:根据项目复杂度、业主方信息化基本情况,选好开发方法,如果复杂度高业主方信息化基础弱可能选用原型法,如果时间紧、承建方经验丰富可选用敏捷法。
    二是巧妙引导使用《用户需求说明书》,协调、建议业主方和承建方,需求调研时汇总“需求调研表”形成《用户需求说明书》对开发的范围和性能目标需求进行界定,并建议业主方业务部门对其业务需求签字确认,同时约定更的范围比如10%—15%为合理变更范围,如果在这个范围内,承建方应开发和调整不增加费用,如果超出这个范围或对系统架构有较大的变更,业主方要增加费用。形成会议纪要或备忘录各方遵守。
    三是以《用户需求说明书》为依据对《需求规格说明书》的开发范围进行检查和审核。
    金玉其外 秀慧其中  
    要求《需求规格说明书》形式与内容并重,本节主要阐述形式要求和内容的完整性,只有形式与内容都达到要求才认为是合格的《需求规格说明书》。
    一是形式完美:包括封皮完美、版本控制信息清晰、章节分部合理、文字简练、准确、专业、无冗余、图文并茂等
    二是内容完整:包括引言(包括目的、范围、阅读对象、参考资料、缩写词、略语、相关法律法规等);功能需求;非功能需求(包括可靠性、安全性、易用性、可用性、可扩展性、可维护性、可移植性等);接口需求、约束条件等文档结构合理,其中要求运行环境、操作方式、故障处理、备份需求、反应速度、流量、频度等一应俱全,把握一个原则是:不能缺项。
    慧眼点睛 更上层楼  
    重点一:把握《需求规格说明书》的三要素是审核的第一关键,首先要了解软件开发中采用结构化方法、面向对象的方法、SOA架构对《需求规格说明书》的影响。《需求规格说明书》除了与用户沟通要用户理解、监理人员作为控制项目的依据、测试人员作为测试依据之外,也是开发设计人员的依据和工作指南,如果开发方法用的是结构化方法,那么《需求规格说明书》中“业务流”、“数据流”、“数据字典”成为其不可缺少的三要素,缺一不可,并且是环环相扣,相互对应,下面分别述之。
    一是业务流程图:要与用户实际业务一致,要以用户容易理解的、标准的图形清晰表述,如果较复杂就用子图分层的方法表述,以简易和容易理解业务为原则。
    二是数据流程图:先是与业务流程图一一对应,再是涉及的输入或输出表应明确画出,表划分合理、无冗余。注意处理好分层时的表达。
    三是数据字典:实际上是数据流程图中输入、输出表中对应的数据项,需要说明的是要标出数据项要求的类型或字长等属性。
如果是面向对象的方法,由于其迭代和无间隙的特点,需求和设计没有明显的界限,所以在审核《需求规格说明书》时至少要有用例图、顺序图、类图等,所要表述的要把握基本与结构化方法三要素相对等的信息,如果情况复杂时还要有状态图,以下简述之:
用例图:能清晰反映出角色和用例,可以对应业务流中的主要功能项,通常用例将转化为程序菜单,主要用于审核检查业务范围。
顺序图:审核检查顺序图的粒度,基本上能对应业务流程和数据流程就行了,它是以时间顺序描述流程的,也可以空间顺序的协作图来代替其描述流程。
    类图:类图主要是描述数据项,可以将其对应为结构化方法的数据字典,但其更贴近自然,更能适应变化。
    重点二:把握接口和安全尤为重要,接口和安全是软件开发的重点和难点,处理不好,会给项目埋下定时炸弹,即使回避一时,但矛盾很快会暴露,根据项目实际情况对这两个方向的把握也是监理审核的重点。
    啰啰嗦嗦 终要定格  写了这么多最终还是建议完成“关于对《需求规格说明书》的审核”监理报告,以下抛出一砖来,希望引来金凤凰。

关于对《需求规格规格说明书》的审核
审核报告

项目名称

XXXX信息管理系统建设项目

业 主 方

业主方全称

监 理 方

监理方全称

承 建 方

承建方全称

XX监理公司于XXXX年X月X日对承建方提交的《需求规格说明书》(包括:《OA系统需求规格说明书》、《网站需求规格说明书》、《业务系统需求规格说明书》)进行审核,意见或建议如下:(如果不特指三个系统的某一个,就表示对三个系统共同的评审结果)

一、需求目标:《OA系统需求规格说明书》中“需求目标”部分,对系统的性能有较充分的描述,系统的功能描述少,具体要“做什么”在目标中没有很明白的描述。《网站需求规格说明书》中“需求目标”对功能和性能都有描述。《业务系统需求规格说明书》中“需求目标”较为明确。

二、内容完整性方面:(1)需求分析结构内容方面:包括了“编制目的”、“适用范围”、“术语说明”、“参考资料”、“系统目标”、“运行环境”、“需求描述”、“功能模块详细需求”、“数据库性能要求”、“应用平台性能要求”等文档结构上较完整,文档结构没有大的遗漏项,但某些要素不详细或不完整,具体见下面的内容。(2)需求业务内容方面:以业主方意见(《用户需求说明书》)为准。

三、系统的功能需求:(1)各业务模块都有业务流程描述,但没有业务流程的细节和可选流程及处理;(2)数据流程的描述不是很清晰;(3)页面需求描述清晰到位;(4)数据项的描述较为详细;符合要求;(5)对权限的描述较为简单,有些不清晰;(6)部分功能的描述过于简单,如:《OA系统需求规格说明书》中8.1.2 功能概述中的描述:“包括信息浏览、发布、修改、删除的功能。”就没有说明“信息”指的是什么。(7)对组合查询中,没有对“查询条件”进行描述。

四、系统的性能需求:性能需求描述的较为清晰,包括:“运行环境”、“硬件要求”、“软件要求”等,但对安全性和内、外网的需求方面的需求描述较少。

五、系统的数据需求:《OA系统需求规格说明书》中功能方面在各子项需求中描述的较为清晰,性能的需求方面也有专门的章节描述,但对数据保密性和备份方面描述较少。《网站需求规格说明书》中功能方面数据没有描述,性能的需求方面也有专门的章节描述。《业务系统需求规格说明书》中功能方面在各子项需求中描述的较为清晰,性能的需求方面也有专门的章节描述,但对数据保密性和备份方面描述较少。

六、系统的接口需求:《OA系统需求规格说明书》中有接口的说明部分,但各模块之间的接口关系描述的较弱。《网站需求规格说明书》中有接口的说明部分,但各模块之间的接口关系描述的较弱。《业务系统需求规格说明书》中有接口的说明部分,但各模块之间的接口关系描述的较弱。

八、系统的设计约束:《OA系统需求规格说明书》中设计约束方面表现较弱。《网站需求规格说明书》中有该方面的描述,但表现较弱。《业务系统需求规格说明书》中有该方面的描述,但表现较弱。

结论:《需求规格说明书》的文档结构基本符合规范,但某些要素需要进一步细化、完善。

XXXX监理公司

今天的文章需求规格说明书评审分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/9545.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注