ERP监理方法系列③：企业调研、需求分析阶段监理-信息化专区

ERP监理方法系列③：企业调研、需求分析阶段监理

作者：北京利玛信息技术有限公司王希跃编辑：叶明 2007-01-08 01:12

　　【IT168 专稿】由于信息ERP应用系统建设针对的行业广泛，因此在需求分析阶段可能存在着承建单位对业主单位的业务需求理解不全面不准确的情况，常发生承建单位认为某一个业务功能的实现非常简单，而实际上业主单位业务标准的要求很复杂的情况。在这种情况下，如果不在监理单位的协调下进行业主单位与承建单位充分的沟通，往往造成承建单位按照自己的理解进行开发的情况，如果在测试阶段没有发现此类问题则给系统造成重大隐患，如果发现问题则造成工程建设返工与延期。

　　因此，在此阶段监理单位的工作重点是监督承建单位的分析人员、设计人员和测试人员对需求说明书的审查，并协调业主单位与承建单位需求说明书的评审确认。需求分析阶段工作落实的情况，直接决定了后续开发工作的质量、进度、投资与变更的情况，因此必须在监理过程中给予足够的重视。

需求说明书评审监理

　　一、需求说明书评审原则

　　原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”

　　原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。

　　原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其它系统元素交互的方式。

　　原则4：规格说明必须包括系统运行的环境。

　　原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。

　　原则6：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。

　　原则7：规格说明必须容许不完备性并允许扩充。

　　原则8：规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规格说明应被松散地构造（即耦合），以便能够很容易地加入和删去一些段落。

　　这是由Balzer和Goldman提出的8条原则，主要用于基于形式化规格说明语言之上的需求定义的完备性，但这些原则对于其它各种形式的规格说明都适用。当然要结合实际来应用上述的原则。

　　二、需求说明书评审框架

　　需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。软件需求说明书的框架：

　　Ⅰ. 引言 A.系统参考文献 B.整体描述 C.软件项目约束

　　Ⅱ. 信息描述 A.信息内容表示 B.信息流表示 C数据流 D控制流

　　Ⅲ. 功能描述 A.功能划分 B.功能描述 C处理说明 D限制∕局限 E 性能需求

　　ⅳ 设计约束

　　ⅴ 支撑图

　　Ⅳ. 行为描述 A.系统状态 B.事件和响应 C.控制描述

　　Ⅴ. 检验标准 A.性能范围 B.测试种类 C.期望的软件响应 D.特殊的考虑

　　Ⅵ. 参考书目

　　Ⅶ. 附录

　　三、需求说明书评审内容

　　作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其它需求给予评价。评审的主要内容是：

　　 系统定义的目标是否与用户的要求一致；

　　 系统需求分析阶段提供的文档资料是否齐全；

　　 文档中的所有描述是否完整、清晰、准确反映用户要求；

　　 与所有其它系统成分的重要接口是否都已经描述；

　　 被开发项目的数据流与数据结构是否足够，确定；

　　 所有图表是否清楚，在不补充说明时能否理解；

　　 主要功能是否已包括在规定的软件范围之内，是否都已充分说明；

　　 软件的行为和它必须处理的信息、必须完成的功能是否一致；

　　 设计的约束条件或限制条件是否符合实际；

　　 是否考虑了开发的技术风险；

　　 是否考虑过软件需求的其它方案；

　　 是否考虑过将来可能会提出的软件需求；

　　 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；

　　 有没有遗漏，重复或不一致的地方；

　　 用户是否审查了初步的用户手册或原型；

　　 项目开发计划中的估算是否受到了影响。

　　四、需求说明书评审检查

＃	检查项	Y/TBD/N/NA
	清晰性
	系统的目标是否已定义？
	是否对关键术语和缩略语进行定义和描述？
	所使用的术语是否和用户/客户使用的一致？
	需求的描述是否清晰，不含糊？
	是否有对整套系统进行功能概述？
	是否已详细说明了软件环境 (共存的软件) 和硬件环境 (特定的配置)？
	如果有会影响实施的假设情况，是否已经声明？
	是否已经对每个业务逻辑进行输入、输出以及过程的详细说明？
	完整性
	是否列出了系统所必须的依赖、假设以及约束？
	是否对每个提交物或阶段实施都进行了需求说明？
	需求说明书是否已包括了主要的质量属性，例如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测试性。
	依从性
	该文档是否遵守了该项目的文档编写标准？
	一致性
	需求说明是否存在直接相互矛盾的条目？
	本需求说明书是否与相关需求素材一致？
	可行性
	所描述的所有功能是否必要并充分地满足了客户/系统目标？
	需求说明书的描述的详细程度是否足以进行详细的设计？
	已知的限制（局限）是否已经详细说明？
	是否已确定每个需求的优先级别？
	可管理性
	是否将需求分别陈述，因此它们是独立的并且是可检查的？
	是否所有需求都可以回溯到相应的需求素材，反之亦然？
	是否已详细说明需求变更的过程？

需求说明书评审报告

　　在需求说明书评审结束后，监理单位应将评审意见以专题监理报告形式提交业主单位。

关注我们