软件项目需求列表

项目编号项目名称

序

号需求说明当前状态（是否完成；问题和

难点列举）需求分类类别紧急程度提出人提出时间审批通过时

间

1防火墙策略集中管理未完成，在一期只采集和表示

策略是由于什么方式建设等情

况，二期需要策略下发的功

能，是否在调研的阶段限定只

做此次4A系统集成的安全设

备？项目要求新增紧急用户

2程序帐号管理待确定项目要求很紧急用户

3审计集中管理功能定制开发此需求来源于2008年天津想做

一套话务网交换机日志审计系

统，应对非法提取原单，但是

一直没启动，此次天津希望能

建设，主要采用FTp方式获取，

建议一期建设只接入部分话务

交换机的日志项目要求很紧急用户

4EOMS系统接入按照集采要求的流程实现EOMS

流程接入：流程系统为神州泰

岳EOMS项目要求一般用户

5审计关联分析完成项目要求一般用户

6数据库访问代理完成？项目要求一般用户文件编号：PMO-CM-07天津移动网络安全管控平台工程需求跟踪列表

需求跟踪列表 第 1 页，共 6 页

7告警策略配置模块类似于SOC的事件管理和查询

（天津已经建立了安氏SOC系

统，目前正处在二期澄清阶

段，二期将把SOC系统扩展到所

有的网络部的系统），前期跟

客户宣传ISMF的观念，客户比

较认可项目要求很紧急用户

8应用模块运行情况监控完成项目要求很紧急用户

9VPN认证及功能深信服VPN项目要求很紧急用户

104A系统应急模块完成项目要求很紧急用户

11分级权限控制模块完成？客户再交流时提到客户

转部门的问题项目要求很紧急用户

12集中应用发布系统集成citrix完成项目要求很紧急用户

13SOX报表定制开发项目要求很紧急用户

14功能定制开发

看数量、明细等；

、按系统、按责任人、按部门

等方法统计，可查看数量、比

例、明细等；

按系统、按责任人、按部门等

多种方法统计，可查看次数、

比例、明细等；

可按账号、按部门、按功能模

块等多种方式统计登录次数、

点击次数等，可查看次数、比

例、明细等。未完成项目要求很紧急用户

需求跟踪列表 第 2 页，共 6 页

关于组织和完整性:

1. 所有对其它需求的内部交叉引用是否正确？

2. 所有需求的编写在细节上是否都一致或者合适？

3. 需求是否能为设计提供足够的基础？

4. 是否包括了每个需求的实现优先级？

5. 是否定义了所有外部硬件、软件和通信接口？

6. 是否定义了功能需求内在的算法？

7. 软件需求规格说明中是否包括了所有客户代表或系统的需求？

8. 是否在需求中遗漏了必要的信息？如果有的话，就把它们标记为待确定的问题。

9. 是否记录了所有可能的错误条件所产生的系统行为？

关于正确性:

1. 是否有需求与其它需求相冲突或重复？

2.是否简明、简洁、无二义性地表达了每个需求？

3.是否每个需求都能通过测试、演示、审查得以验证或分析？

4.是否每个需求都在项目的范围内？

5.是否每个需求都没有内容上和语法上的错误？

6.在现有的资源限制内，是否能实现所有的需求？

7.是否任一个特定的错误信息都具有唯一性和明确的意义？

关于质量属性:

1.是否合理地确定了性能目标？

2.是否合理地确定了安全与保密方面的考虑？

3.在确定了合理的折中情况下，是否详实地记录了其它相关的质量属性？

关于可跟踪性:

1.是否每个需求都具有唯一性并且可以正确地识别它？

2.是否可以根据高层需求（如系统需求或使用案例（用例））跟踪到软件功能需求？

关于特殊的问题:

1.是否所有的需求都是名副其实的需求而不是设计或实现方案？

2.是否确定了对时间要求很高的功能并且定义了它们的时间标准？

3.是否已经明确地阐述了国际化问题？

关于使用实例:

1.使用实例是否是独立的分散任务?

2.使用实例的目标或价值度量是否明确? 3．使用实例给操作者带来的益处是否明确?

4.使用实例是否处于抽象级别上，而不具有详细的情节?

5.使用实例中是否不包含设计和实现的细节?

6.是否记录了所有可能的可选过程?

软件项目需求管理简述

需求的概念

从根本上说，需求来源于用户的“需要”和“要求”，这些“需要”和“要求”被分析、整理、确认后形成完整的文档，该文档详细地说明了产品“应当”实现的功能。

需求的重要性

需求是整个产品链的源头，需求工作的优劣将直接影响到产品的设计，生产，销售和维护的全过程。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。目前国内很多软件业普遍存在这样一个现象：人们并不真正清楚到底该做什么，却一直忙碌不停地开发。

Frederick Brooks在他的经典文章“No Silver Bullet”是这样描述需求的重要性的：

开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。

什么是需求管理

把所有与需求直接相关的活动通称为需求管理。

需求管理中的活动可分为两大类，

需求分析：对用户的需求进行整理、分析和完善，形成文档

需求维护：需求确认，需求跟踪和需求变更

需求工程贯穿产品生命周期的全过程。

需求管理的主要内容

需求分析流程

需求调查

首先需求分析员起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。问题表可以是层次化的，随着调查的深入，问题表将不断地被细化。问题表应当以“选择题”和“是非题”为主。 其次，需求分析员应当确定需求调查的方式，例如： 与用户交谈，向用户提问题。向用户群体发调查问卷等。

还可以从用户的工作流程，相关文档以及行业标准、规则中提取需求。分析已经存在的同类软件产品，提取需求。

最后，需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，进行需求调查。

细化用户需求

根据用户需求调查，对用户的需求进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。例如采用Rational 的Rose工具进行需求的建模分析。

中央国家机关住房资金管理中心

管理信息系统

需求说明书

（范本）

文件状态：

[ ] 草稿

[ ] 正在修改

[ ] 正式签收 文件标识： MIS

当前版本：

作 者：

完成日期：

签 收 人：

签收日期：

中央国家机关住房资金管理中心

二○一○年 月 日 文档修改历史记录

版本状态 修改日期 备注

目 录 1概述

1.1引言

（本需求说明书的编写目的以及阅读对象）

1.1.1 软件项目名称

（说明软件项目全称和简称）

1.1.2软件项目开发背景和目的

（简述软件项目开发背景和目的以及实现了哪些大的功能）

1.1.3软件项目应用范围

（叙述软件项目主要使用的范围、使用者等）

1.2参考资料

（本需求说明书的参考资料，包括法律法规、政策文件、国家标准、制度规范等）

1.3术语定义

（逐个定义重要术语，没有可以不写本条）

2 功能一

（定义本软件项目实现的一级功能及其内涵，一个软件项目由多个一级功能组成）

2.1功能分解一

2.1.1定义

（说明功能分解一的含义以及实现过程）

2.1.2功能表述

（逐一列出对本功能分解一的各项功能表述，每项功能均需详细描述，并使读者没有歧义，描述方式可以为：输入什么、输出什么、需要系统如何加工等）

2.1.3性能要求

（详细列出对本功能分解一的系统性能要求，如：系统数据校验、缺省项判断、系统反应时间、操作的便捷性、错误或故障的处理、系统的接口等）

2.1.4相关表单

（详细列出本功能分解一涉及的相关表单）

2.1.5流程图

（功能分解一实现过程的流程图） 2.1.6特殊要求

（详细列出功能分解一的特殊要求，如无，可以不列）

2.2功能分解二

……

2.3特殊要求

（详细列出功能一的特殊要求，如无，可以不列）

3 附录

示例：

中央国家机关住房资金管理中心

售房款 管理信息系统

需求说明书

文件状态：

[ ] 草稿

[√] 正在修改