计算机软件管理制度|技术部软件研发管理制度( 三 )


2.需求需分优先级 。
3.需求必须文档化 。
4.需求一旦变化 , 就必须对需求变更的影响进行评估 。
5.需求管理必须与需求工程的其他活动紧密结合 。
第7条 需求管理的目标 。
1.使软件需求受控 , 并建立供软件工程和管理使用的需求基线 。
2.使软件计划、产品、活动与软件需求保持一致 。
第8条 软件需求的度量要素 。
软件需求的度量包括9个要素 , 即正确性、无歧义、完备性、一致性、分级、可验证、可修改、可跟踪及可理解 。
第3章 需求变更管理
第9条 需求变更的原因 。
1.在软件研发早期所有的问题不可能被完全定义 , 软件需求是不完全的 , 这就注定了需求需要变更以便达到完善的程度 。
2.随着软件的研发进度 , 软件研发人员对问题的理解发生变化 , 这些变化也需反馈到需求中去 。
第10条 变更管理过程 。
1.变更描述 。
2.变更分析 。
3.变更实现 。
第11条 变更影响分析 。
每一项需求变更都必须进行变更影响分析 , 明确它对研发计划和其他需求的影响 , 明确与变更相关的任务并评估完成这些任务需要的工作量 。
第4章 软件需求文档管理
第12条 需求文档的作用 。
在用户和研发人员之间就将要开发的软件系统需要达成一致的协议 , 从而产生正式的需求文档 , 以便为软件的研发和实现提供依据 。
第13条 编写软件需求文档的注意事项 。
1.语句和段落应尽量简短 。
2.表达方式要采用主动语态 。
3.语句要完整 , 且语法、标点等正确无误 。
4.使用的术语要与词汇中的定义保持一致 。
5.避免使用模糊、主观的术语 。
6.避免使用比较性的词汇 , 百思特网尽量给出定量的说明 , 含糊的语句表达将引起需求的不可验证 。
第14条 建立软件需求规格说明书 。
需求文档采用软件需求规格说明书的形式 , 精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件 , 是对外部行为和系统环境接口间接、完整的描述性文档 。
第5章 需求验证管理
第15条 需求验证流程 。
1.审查需求文档 。
2.依据需求编写测试用例 。
3.编写用户手册 。
4.确定合格的标准 。
第16条 需求验证的内容 。
1.有效性检查 。
2.一致性检查 。
3.完备性检查 。
4.现实性检查 。
5.可检验性检查 。
6.可调节性检查 。
7.可读性检查 。
第6章 需求评审
第17条 需求评审人员 。
需求评审人员由软件研发部研发人员与客户方的代表共同组成 。
第18条 需求评审注意事项 。
1.严格控制每一次评审的文档规模及持续时间 。
2.评审工作要分段进行 。
3.对讨论的问题进行控制 。
4.避免无谓的争吵 。
第7章 附则
第19条 本规定由公司软件研发部制定 , 其修改权、解释权归公司软件研发部所有 。
第20条 本规定自颁布之日起执行 。
三、软件设计管理办法软件设计管理办法
第1章 总则
第1条 目的 。
为使软件产品满足规定的需求而确定软件的体系结构、组成模块划分和接口说明等 , 并将上述结果翻译成代码 , 以实现软件所要求的功能 , 特制定本办法 。
第2条 适用范围 。
本办法适用于公司所有的软件产品的设计管理工作 。
第3条 责任部门及职责分工 。
软件研发部是软件设计研发工作的归口管理部门 。
1.软件研发部经理负责软件设计研发工作的日常管理 , 监督软件研发的进度 , 做好费用预算与控制工作 。
2.软件研发高级工程师主要负责带领设计研发人员进行新软件的开发 。
第2章 软件设计与研发
第4条 软件设计的内容 。
1.编写系统的特性规格说明书 , 主要描述系统结构、各组件间的相关性、接口标准等内容 。
2.从系统高层开始着手进行系统设计 , 逐步编写以下内容 。
(1)对整个系统的设计方案作简明扼要的描述 。
(2)绘制系统的结构图 。
(3)确定系统中的风险因素 。
(4)对系统的重用性进行分析 。
3.对系统中的子系统进行细分 , 给出各子系统、各组件的规格说明 。
4.根据产品的特性规格说明书 , 制订产品的开发计划 。