信息化项目需求说明书

信息化项目需求说明书（通用9篇）

篇1：信息化项目需求说明书

附件2

信息化项目需求说明书（模板）

一、概述

1.提出本业务（或工作）相关信息化建设和应用情况现状。

2.给出项目的提出背景和项目建设（改造）的必要性。

3.如有公司决策依据，请进行说明并提供相应材料（文件或会议纪要）。

二、需求内容

1.结合业务特点，提出项目建设的目标，满足业务的实际需要。

2.提出项目建设的功能及内容，包括软硬件采购需求和开发实施需求。

3.提出项目的总体实施方案，包括实施计划、实施内容和实施范围。

4.给出投资估算，进行分项说明。

篇2：信息化项目需求说明书

办公信息系统项目

信息管理与办公系统

研发需求说明书

二O一六年三月

信息管理与办公系统研发需求说明书

信息管理与办公系统研发需求说明书

1.3.1.易用性

对于信息办公系统，要求工作人员可以通过鼠标选择、拖拉等操作就能够完成大部分任务，系统使用不需要复杂的培训，即可使每个用户方便、灵活地使用，做到真正的办公自动化。

1.3.2.稳定性

保证系统的不间断运行和出现错误时能够及时恢复并没有数据丢失、系统崩溃等现象出现，避免因停电、操作失误、机器硬件错误等造成的数据丢失或系统崩溃现象。

1.3.3.安全保密性

贵单位信息办公系统是涉及重要的信息，因此，安全保密性是对新信息系统的最起码要求。

1.3.4.先进性与发展性

对于系统，最好采用当前最先进的Internet/Intranet技术，也充分考虑系统的可伸缩性、可扩展性和可继承性，让系统能够随所选择的平台不断升级而得到进一步的继承和发展。

1.3.5.标准化和开放性

对于系统公文资料参考国家公文标准和用户系统内公文标准进行设计。开放性是指系统提供给本单位内部其他系统和外部其他相关单位对信息办公系统的访问。当然，这些访问是有条件的，同时也有相当的安全和权限设置。

信息管理与办公系统研发需求说明书

‘用户名’和登录‘密码’是否正确，如果输入正确，将进入系统的主界面（个人桌面）。

2.系统管理

组织机构、人员、职位是基本信息组成部分，在各个机构下设置相应的职位，每个职位可以具有不同的操作权限，通过建立人员与相应职位的对应关系，实现对人员操作权限的统一管理。

3.公文流转

公文流转以用于处理日常工作中的单位内外部的各种公文，利用计算机网络的高速迅捷和计算机控制的严格准确性实现公文的处理。公文管理模块相对传统公文处理而言，在很大程度上提高了公文处理效率和准确性，用户操作简便易行。公文流转包括了公文的发文拟制、发文签发、发文传阅、收文签收登记、公文查询等。

4.收文登记

收文登记用于外部来文的签收、登记处理，包括：新增公文、录入、编辑公文信息。

综合查询系统

综合查询系统是整个信息管理与信息办公系统中的核心系统。在此系统中，系统可以根据各种需求和查询条件。

系统维护系统

系统维护系统主要负责数据备份、系统参数设置、用户角色管理等辅助功能。系统维护系统为数据库管理员和用户权限管理员两种角色服务。

 数据备份管理包括：数据定期备份、备份数据恢复、备份历史记录查询、历史备份数据删除等功能，其中数据备份包括对数据库中数据定期系统备份和人工不定期备份，同时包括对报表文件的备份处理等； 

用户角色管理：管理用户信息，设定角色名称，及权限等功能；

篇3：信息系统项目需求的开发与管理

一、需求开发

需求开发是通过调查分析, 获得用户的需求并定义产品或服务。信息系统需求开发的结果是一系列通过评审的需求文档 (如范围文档、用例文档、需求规格说明书等) , 这些文档构成了项目日后工作的需求基线, 是用户和项目承建方之间就项目产生的产品或服务的一个约定。一个完整的需求开发, 一般要经过以下四个过程。

(一) 需求获取。需求获取是通过与用户的交流, 或对现有系统的观察及对任务进行分析, 从而捕捉、分析和修正用户对信息系统的需求, 它主要包括用户、业务和系统功能三个方面, 最终提炼出符合实际并能得到实现的用户需求, 其结果是产生出《用户需求说明书》。

需求获取应该以系统分析师和项目经理为主导, 依据他们掌握的专业知识和技能开展工作, 最后编写出有关需求文档。

(二) 需求分析。需求分析也称为需求建模, 它是根据《用户需求说明书》对各种需求信息进行分析抽象, 为信息系统建立起一个概念模型, 其目的是解决系统要“做什么”的问题。需求分析常用的方法有:原型分析法、结构化分析法、用例分析法等。其中用例分析法采用的统一建模语言 (Unified Modeling Language, UML) 是近几年最常用的需求分析方法, 它几乎成了行业需求分析的标准。

(三) 需求定义。需求定义是根据需求获取、分析的结果, 进一步定义准确无误的产品或服务的需求, 目的是使用户和项目承建方双方对该项目的初始规格有一个共同的理解, 从而使之成为整个项目工作的基础, 其结果是最终产生《需求规格说明书》, 信息系统的设计人员将依据它来开展系统设计工作。

以信息系统的软件开发项目为例, 其需求定义可以按层次来说明, 包括业务需求、用户需求、功能需求、性能需求、系统需求、约束与假设等层次, 这些不同层次的需求最终体现在软件需求规格说明书中, 它是软件开发的蓝图。此外, 软件需求规格说明书没有统一的标准, 可以根据项目的具体情况采取不同的格式, 但可参考IEEE推荐的软件需求规格说明的方法 (IEEE 830-1998) , 或者参考《GB9385-88计算机软件需求说明编制指南》。

(四) 需求验证。需求验证是项目承建方与用户对需求文档进行评审, 达成共识并做出书面承诺, 使《需求规格说明书》等需求文档具有合同效应。通过评审的需求文档就构成了需求基线, 它是用户和项目人员之间就项目产生的产品或服务的一个约定。一般应对需求文档的正确性、一致性、完整性、可行性、必要性、可跟踪性等内容进行验证。

二、需求管理

需求管理贯穿需求开发, 并延续整个项目建设过程。依据集成的能力成熟度模型 (Capability maturity model integration, CMMI) 中对需求管理的划分, 信息系统项目的需求管理可划分为6个方面。

(一) 需求管理计划。制定需求管理计划的目的是便于管理人员按计划开展需求管理工作, 并保持需求管理工作的一致性。需求管理计划一般包含:确定需求管理所需要的资源;制定需求跟踪性矩阵;制定需求变更审批规程;需求变更请求表制定等工作。需求管理计划一般由项目经理审批后执行。

(二) 需求确认。需求确认首先需要建立一些准则, 以便指明接受需求的适当渠道和正式来源;其次, 项目需求分析人员在与客户沟通过程中, 对双方未能达成一致的需求进行剔除;再者, 对于双方达成共识, 并获得用户认可的需求, 双方需要做出书面承诺。并且, 如果需求是在需求基线确定之后做出变更的, 那么由变更引起项目其它方面 (如时间计划、最终产品和服务等) 的变化, 亦应得到用户的书面承诺。

(三) 需求承诺。需求承诺是指项目承建方和用户的责任人, 对需求开发阶段通过需求验证的《用户需求说明书》, 做出书面承诺 (签字) , 该承诺具有商业合同的等同效应。需求承诺的范例如下:

(四) 版本控制。版本控制是为了使项目组内的每个成员都能够得到需求的最新版本, 且必须将变更的需求写成文档, 及时通知到项目建设所涉及的人员。版本控制应指定专人负责, 并常借助于配置管理软件来完成。在版本控制过程中, 对历史版本仍需要进行记录。

(五) 变更管理。统计数据显示, 一个信息系统需求的改动很少少于三次, 需求变更可以发生在任何阶段, 即使到项目后期, 因此, 人们必须接受“需求会变动”这个事实。但是, 没有控制的需求变更会对项目进度、成本、质量等产生严重的影响, 需求变更在成本上可以占到项目的40%, 因而必须对需求变更进行妥善管理, 需求变更是项目管理中非常重要的工作。

目前, 信息系统项目中控制需求变更的最佳实践是成立变更控制委员会 (有时也称配置控制委员会, 英文缩写CCB) , 它一般由项目组成员和用户等人员组成, 其人员应该能够代表需求变更所涉及的组织。CCB一般的工作流程为:接收到新的需求变更请求后对其进行技术可行性、成本、风险等方面的评估→CCB决定采纳或拒绝需求变更请求→对采纳的需求变更请求确定优先级别或实现日期→CCB向项目承建人员及用户传达被采纳的需求变更请求的内容→相关人员根据被采纳的需求变更请求的内容, 修改各自的工作产品及有关文档。

(六) 需求跟踪。需求链是指需要上传下达, 从客户传达到需求过程, 并从需求过程传达到需求过程的下游开发链, 它是一个双向传达的过程, 如下图示:

需求跟踪就是对需求上传下达的跟踪, 它提供了一个表明与合同或说明一致的方法。需求跟踪可以改善产品质量, 降低维护成本, 而且很容易实现重用。需求跟踪最普遍采用的是需求跟踪能力矩阵, 用于表示需求和别的系统元素之间的联系链关系。但是, 在一个拥有多个子系统的信息系统项目中, 建立需求跟踪管理能力是一项艰巨的工程, 项目团队在实施这项能力的时候应循序渐进, 逐步实施。

三、结语

篇4：信息化项目需求说明书

此次奖学金信息说明会采用统一宣讲与展位介绍两种方式并行的做法,所有外方院校均同时参加。在统一宣讲会中,留学基金委向参会研究生详细介绍了2010年国家公派留学生计划,包括选派的重点领域、申请条件、申请程序等。同时,多所国外院校介绍了自己的专业设置、研究生培养、申请留学的条件和手续、奖学金的申请以及学校的学习条件和生活环境等情况。

据了解,2010年国家建设高水平大学公派研究生项目计划选派5 000人,其中,攻读博士学位研究生2 500人,联合培养博士研究生2 500人。重点选派领域为能源、资源、环境、农业、制造、信息等关键领域及生命、空间、海洋、纳米、新材料等战略领域和人文及应用社会科学。应届本科毕业生、在读硕士生(含应届硕士毕业生)和博士一年级学生可申请攻读学位;全日制在读博士研究生可申请联合培养。2010年将分两批选拨,第一批提交申请的时间为2010年2月20日~3月20日,选拔赴国外攻读博士学位研究生、联合培养博士研究生;第二批提交申请的时间为5月20日~30日,仅选拔赴国外攻读博士学位研究生。有关项目的详细信息及申请程序可通过国家留学网查询(www.csc.edu.cn)。

参会的研究生反映,与资助方及留学目的国院校直接接触的方式非常好,可以集中了解大量信息,并与相关负责人直接交流,为今后的出国留学做好信息储备。同时,他们也表示,希望今后能够增加参加现场展示的国外院校数量,并希望参展院校提供更多学科专业发展情况和项目开展情况的信息,以便为他们申请公派出国留学提供更多参考。

(文·摄影/本刊记者,2009年10月16日)

篇5：仓储网络布局规划项目需求说明书

一、概述 1 项目背景

加快进行仓储网络优化布局规划，是建设物资全面供应体系的前提。

合理的仓储网络布局可以在保障物资供应的要求下，需要综合考虑“成本、效率、服务”的约束，在总体配送服务水平优化的前提下，应用运筹学思想，理论结合实际，建立可行的数学模型，充分依据实地调研数据进行区域规划降低总体仓储成本。

“十二五”期间，国网公司要建设国际先进物资供应体系，提供公司供应链决策支撑。2012年物资集约化管理信息系统二期建设项目主要在提高管理效率及管理水平、深化物资供应体系建设工作、推进物资全面应用。2 规划原则 2.1 仓储规划原则

 仓储规划必须与国家及省市的经济发展方针、政策相适应，与国民经济和社会发展相适应。 仓库规划要与地方整个物流网络体系相协调。2.2 网点规划原则

 网点规划要考虑便于集中管理原则。

 网点数量的规划要考虑仓储物资供应的便捷性。2.3 选址规划原则

 仓储选址首先要遵循接近客户原则尽可能在有限  范围内选择覆盖面积最大的城市或地区

 长期发展原则，选址工作要考虑未来经济发展情况

二、需求内容 1 项目建设的目标

 立足现状与发展，建立仓储网络优化模型，精细测算网络节点，科学规划、合理设置全省范围内的中心库、区域库和周转库位置和数量，计算配送范围，合理规划物流配送资源，从而降低仓储成本，提高配送效率，满足服务要求。

 根据需求分析，给出各类库储备定额建议。2 实施需求和内容。2.1 实施需求：

 仓储网络布局规划在省电力公司推广实施，并根据仓储网络布局规划进行仓储网络布局调整； 2.2 实施内容：

 项目启动：完成项目内容、组织、计划和实施办法；  调研：对宁夏电力所属区域库、周转库进行调研，内容包括：位置、仓储容量、业务范围、业务量、资源、区域经济等；

 数据分析：包括电子地图、基础业务数据加工和仓储规划两方面内容。仓库数量数据、仓库规模数据、库址数据、特殊位置应急库数据、道路网络数据集是进行网络分析、实现网络布局优化的前提。首先，根据经济、行政区面积、组织结构、库址数据和道路交通信息，进行拓扑分析并创建网络数据集，得出电力物资需求、仓库辐射半径、特殊区域应急方案等数据；其次，使用网络分析算模型，进行仓储节点的选址规划、规模规划、应急预案、建议数量等结论；

 方案确定：将几套不同的选址方案，按照不同的指标（如人力资源、里程、仓储容量、成本、平均服务时间等）进行对比分析，从中选择最佳的仓储节点布局，综合考虑配送距离最短、服务响应最快、费用成本最低、仓储网点数量最优。2.3 实施范围：

安徽全省所属地市中心库、区域库、周转库网络规划

三、电网物资资料 1 分类 1.1 项目物资

主要包括主网工程物资和配网工程物资，该类物资主要用于电网工程建设 1.2 运维物资 该类物资主要用于日常电网运行维修和年度大修等 1.3 应急物资

劳保、冲锋舟、等物资 2 特点

2.1 采购量大、周转慢

平均年库存周转约1.1次。

 传统的采购、储运模式下，周转慢造成库存资金占用成本大。

2.2 物资品种多、形状、尺寸、重量不规整，标准化存储难度大

 1万多个品规，小到螺钉、螺母，大到5-8吨的线缆、设备，物资的形状、尺寸、重量不规整。

 不同于其它行业，电力物资同品种、同规格，不同厂家的产品尺寸、重量都不相同，标准化程度不高。 传统的平置堆放方式库容利用率低。

2.3 仓库数量多，管理体系尚不健全，各单位仓储管理不规范

 50平方米以下的微型库有占总量的30%多。 各仓库资产属性、隶属关系不同，管理模式不同、管理水平参差不齐。

2.4 仓储设备、设施老旧，自动化程度不高

 多数物资仓库为上世纪7、80年代建设，设备、设施老旧。

 传统的人工作业方式效率低、成本高。2.5 计量单位复杂，库存管理手段落后，账实一致难以保障

 储运收发作业以重量、数量、长度等为单位。 传统的账-卡-物人工管理方式难以保障库存物资账实一致性。

2.6 传统的运输配送方式运输成本高

 传统的被动服务方式空载率高，运输成本高；  区域性班车化主动配送服务模式受信息系统和运输装载容器的限制，难以实施。2.7 项目物资必须实行批次号追踪管理

 SG ERP系统上线运行后，项目物资实行批次号追踪管理。同品种不同批次号物资不得混储混发，对物资储运提出了新的挑战。2.8 承担应急保障的社会责任

篇6：信息化项目需求说明书

需求说明书是一个项目至关重要的部分，是一个项目的开头，做好一个项目的需求说明书就是完美的给这个项目做了一个美好开始。好了，说了这么多，那么我就来说如何写一个合格项目需求说明书吧。

一般分为6点：

首先是引言：

写出该项目需求说明书的编写目的、背景以及用处。

第二点是项目的任务概括 ：

写的是编写该项目的要达到的目的以及该项目适合的用户，还可以适当的加上项目的一些展示图片

第三点是项目需求的细节：

这一部分写的是对该项目的一系列规定，比如对功能的规定、对可维护性的规定、对项目过程的规定。说清楚一点就是对于将来要做的项目的一些需求都分层次的写在这里。

第四点就是要写出对运行环境的需求：

说白了就是编写之前所需要准备的东西，比如硬件设备、需要的平台等。这样好可以预算出成本，虽然不是很准，但是这个是必须的，没有哪个公司是不需要预算，要钱就给的。

第五点项目心的：

这个就是昨晚项目之后来写的，将做这个项目时自己的感想写进去，总结一下这个项目。

第六点分工：

篇7：信息化项目需求说明书

1.1.系统简述

本系统是为了给图书管理人员和读者借、还书带来便利，除了图书馆内管理的一般功能还外，还包括网上在线查询图书信息、查询本人的借阅情况和续借等功能。

系统名称 ：XX大学图书馆信息管理系统 项目委托单位 ：XX大学图书馆

项目开发单位 ：XX大学管理学院信息管理与信息系统专业 系统最终用户 ：XX大学图书馆工作人员

1.2.编写目的

系统功能需求有：

编目

：分类，标注主题词；录入所有图书的目录及部分图书的内容 借书证管理

：办新证、换证、清理借书证（注、吊销）提供检索服务 ：查图书的目录、在馆状态；查图书内容 流通服务

：借、还、续借、罚款、冻结借书证

图书清理

：遗失、损坏、过时图书及相应目录的清理 统计分析

：分类统计图书、读者、借阅等信息

该文档是为了明确系统需求，规划设计进度，更好地安排系统开发测试，在开发过程中防止错误的出现，本文档供项目经理、开发人员和设计人员参考。

1.3.参考资料

UML基础与Rose建模教程

蔡敏 徐慧慧 黄炳强编著 信息系统分析与设计教程

陈佳

谷锐 李朝辉编著

1.4修订版本记录

本版本为第一版本，暂无修订版本记录

2.术语表

读者信息注销：采集学生或教师的离校信息，对相关借阅信息进行注销，并收回借阅证。

借阅证办理：根据新生入校时技术部采集的新生信息或新进教师信息进行借阅证办理

图书借阅：对读者的借书进行登记，并将资源的状态改为借出，同时修改读者的借阅信息。

图书归还：根据读者的还书，将资源信息改为在馆，修改读者的借阅信息。冻结借阅证：根据读者是否有过分的行为达到冻结借阅证的地步，然后冻结借阅证收回读者借阅书籍的权利。

图书编目：根据图书的ISBN号将图书编码，规放到特定的位置中的一个编码。罚款：读者由于借阅的书籍或者光盘超出规定的时间，超出的时间将要收取一定的现金作为处罚。

3.系统业务流程

3.1概述

图书馆管理系统业务主要是对读者和图书的管理，将具体业务分到分到3个部门来进行管理，分别是：办公室、流通管理部和采编部，各个部门管理相关的业务，并通过相互配合，来完成实现系统的各种功能。

3.2概要调查

采编部门图书目录采购员购进图书名单1图书编目分类3检索服务所需图书信息表读者信息办公室图书管理员借阅证图书管理员借阅证4流通服务图书记录5图书清理图书信息读者读者管理2借阅证管理读者信息借阅证办公室分析报表6统计分析图书管理员读者办公室办公室读者

总体业务流程图

3.3详细调查

3.3.1.办公室业务的详细调查

图书管理员借阅证管理员提交凭证2.1发新证借阅证办公室读者读者登记入馆读者档案图书管理员2.2读者信息变更处理读者登记表2.4注销借阅证注销卡号报表办公室管理员申请挂失表管理员读者退卡申请2.3卡回收管理员办公室

借阅证管理业务流程图

描述：办公室的主要任务是对读者信息以及借阅证的管理，借阅证的办理、挂失、注销等处理。

3.3.2.图书流通管理部业务的详细调查

图书信息借阅证3.1图书借阅所借图书信息读者管理员读者管理员借阅证3.2图书归还所还图书信息图书信息

图书活动业务流程图 描述：

图书借阅：读者从图书馆中找到所需图书拿到图书流通管理部的管理员处，管理员根据读者的借阅信息和图书的基本信息来处理读者的借阅请求。

图书归还：读者将借阅到的图书拿到图书流通管理部管理员处，管理员根据读者的借阅信息处理归还业务，如果读者借阅超期则通知读者缴纳罚款，否则将无法借阅图书。

遗失图书分析报告5.1遗失图书处理遗失图书处理报告管理员3管理员2管理员1损坏图书分析报告5.2损坏图书处理损坏图书处理报告5.4更新报告图书目录更新流通管理部管理员2过时图书分析报告5.3过时图书处理过时图书处理报告

图书管理业务流程图 描述：

3.3.3.采编部业务的详细调查

图书采购业务流程图

3.3.4.详细业务流程描述

1.购书业务管理 1.1清单讨论 采编部根据近期出版的图书和比较典型的书籍，列出一个预采购图书的清单，流通管理部门的职工也可以根据情况提出相应的购书方案，然后通过讨论确定最终的购书方案。

1.2购买图书 通过会议的讨论确定购书清单，采编部将购书清单发送给商家，并交纳购书的金额

1.3派送购买图书 2.编目图书 2.1编目图书 编目部将从出版社购得的图书，根据ISBN号，以及图书馆图书存放的位置，将图书进行编目输入到图书的数据库中，并商家根据采编部的购书清单和交纳的金额，将相应的书本通过邮递的方式发送到采编部

采编部 采编部

商家 采编部 采编部 编目部，流通管

理部 将编目过的图书交予流通部上架

3.读者请求处理 3.1请求借书 读者在图书馆中找到自己想借阅的图书，将图书和自己的借阅证交到流通部的借阅管理员处，由管理员处理借阅事务

3.2处理借阅请通过读者提交的图书和借阅证，先判断读者的借阅信息，是求 否有超期的图书或者借阅的图书数量是否达到上限，如果条件都达到，就修改读者的信息和书籍的信息

3.3请求归还 读者将自己借阅的书本交予流通部归还处的管理员，向管理员提出归还图书的请求

3.4处理归还请流通部管理员通过读者提交的书本，判断所借图书是否超期，求 是否有污损，提醒读者是否要缴纳罚款，并处理书籍的信息 3.5缴纳罚款 由于读者所借图书超期或者图书有破损，处罚读者的行为，读者将相应金额的罚款和自己的借阅证交到罚款处的管理员，由管理员处理

3.6处理罚款 根据读者提交的借阅证，查询读者所需缴纳罚款的信息，并收取读者相应的金额罚款，处理读者罚款的信息

4.办公室职能 4.1请求信息处读者提出自己办证入馆、挂失或者注销信息的请求，并填写理 表格提交自己的个人信息，交予办公室的管理员

4.2处理请求 办公室的管理员根据读者提交的请求以及相应的信息，判断是否能够处理请求的信息，若能处理便处理，否则提醒提交信息者。

4.系统用例模型

4.1参与者描述

流通管理部 读者，流通管理

部 流通管理部

读者，流通管理

部 流通管理部 读者，流通管理

部 流通管理部 办公室 读者 办公室

描述：系统的参与者主要是按照部门划分的，每个部门可以有多个员工，但每个部门的员工只能处理本部门的业务。

4.2高层用例模型 4.2.1.总体用例图

描述：系统中各个参与者与系统功能的关系

4.2.2.办公室高层用例图

描述：办公室的主要功能就是对读者信息的增删改查

4.2.3.流通管理部高层用例图

描述：流通部处理读者图书的借阅归还、图书信息处理和罚款处理

4.2.4.采编部高层用例图

描述：采编部的主要功能就是采购图书、编目图书和更新图书信息

4.2.5.读者高层用例图

描述：读者在系统中的功能主要就是查询个人信息、借阅图书、归还图书、缴纳罚款

4.3 分层用例模型

4.3.1.办公室工作的子用例图

用例说明：

（1）简要说明：在操作界面上选择需要的功能选项，包括登记办证入馆、借阅证挂失、借阅证挂失的取消、借阅证注销、，选择特定的功能后进入相应的操作界面，界面内主要包括查询、新增、修改、删除、退出功能。

（2）前提条件：操作者拥有操作权限。

（3）事件流

打开办公室管理员操作界面 登录管理界面

显示权限内的功能选项

提供查询、新增、修改、删除、退出操作选项

选择查询功能

获得读者的借阅证号或者学号

按读者借阅证号或者学号以及其他重要信息查询 判断是否得到查询结果 如果未得到查询结果

则提示：“无符合条件的读者信息” 否则

显示查询结果

选择新增功能

获得读者的学号，姓名等重要必须的信息 输入相应的信息并提交存盘 判断是否成功 如果存盘成功 则提示：“新增读者成功”

否则

提示：“新增读者操作失败”

选择修改功能

获得读者的借阅证号或者学号 显示查询出的结果 输入相应的修改信息 提交并保存修改信息 判断是否修改成功 如果修改成功

则提示：“修改读者信息成功” 否则

提示：“修改读者信息失败”

选择删除功能

获得读者的借阅证号或者学号 显示查询出的结果 选择删除操作

判断删除操作是否成功 如果删除成功

则提示：“删除读者信息成功”

否则

提示：“删除读者信息失败”

选择退出功能

终止管理者的用例

（4）事后条件：正确的信息保存在数据库中（5）非功能性需求：

在输入和修改操作中，对输入的错误信息要迅速提示

4.3.2.采编部工作的子用例图

用例说明：

（1）简要说明：在操作界面上实现图书编目的处理

（2）前提条件：获得图书的关键信息，操作者拥有操作权限

（3）事件流：

打开图书编目界面 输入图书的重要信息 进行图书编目 判断处理是否成功 如果处理成功

显示处理后图书的编号 并提示：“处理成功” 否则

提示：“处理失败，请确定输入信息的正确性” 返回至图书编目界面

（4）事后条件：正确的图书编号保存在数据库中（5）非功能性需求

在输入和修改操作中，对输入的错误信息要迅速提示

4.3.3.流通管理部子用例图 4.3.3.1.图书借阅用例图

用例说明：

（1）简要说明：在操作界面上显示处理图书借阅

（2）前提条件：获得借阅图书的编号和读者的借阅证号，操作者

拥有操作权限

（3）事件流：

打开借阅处理的界面 输入读者的借阅证号 显示读者的借阅信息 如果有图书超期、拖欠罚款未交或借阅已达上限

提示读者未能借书的信息，不能借阅图书

否则

输入图书的编号

显示图书的信息

处理借阅请求

判断借阅操作是否成功 如果处理成功

提示：“借阅图书处理成功”

显示读者借阅的信息 否则

提示：“借阅处理失败，请确定所输入信息的正确性”

返回至借阅处理界面

（4）事后条件：正确的借阅处理信息保存在相应的数据库中（5）非功能性需求：

在输入和修改操作中，对输入的错误信息要迅速提示 4.3.3.2.图书归还用例图

用例说明：

（1）简要说明：在操作界面上显示处理归还图书信息

（2）前提条件：获得归还图书的编号，操作者拥有操作权限（3）事件流：

打开归还处理的界面 输入图书的编号

显示图书借阅的信息以及借阅者信息 如果图书超期

提示读者超期信息 处理归还图书操作 判断归还操作是否成功 如果处理成功

提示：“归还处理成功” 显示归还后读者的借阅信息

否则

提示：“归还处理失败，请确定输入信息的正确性” 返回至归还处理界面

（4）事后条件：正确的罚款处理信息保存在数据库中（5）非功能性需求：

在输入和修改操作中，对输入的错误信息要迅速提示

4.3.3.3.罚款处理用例图

用例说明：

（1）简要说明：在操作界面上显示处理罚款处理信息

（2）前提条件：获得读者的借阅证号，操作者拥有操作权限（3）事件流：

打开罚款处理的界面 输入读者的借阅证信息 显示读者的超期记录 处理读者的罚款信息 判断罚款处理是否成功 如果处理成功

提示：“罚款处理成功” 显示处理后的罚款记录 否则

提示：“罚款处理失败，请确定输入信息的正确性” 返回至罚款处理界面

（4）事后条件：正确的罚款处理信息保存在数据库中（5）非功能性需求：

在输入和修改操作中，对输入的错误信息要迅速提示

4.3.3.4.图书处理用例图

用例说明：

（1）简要说明：在操作界面上实现图书信息的处理

（2）前提条件：获得图书的关键信息，操作者拥有操作权限

（3）事件流：

打开图书处理界面 输入图书的重要信息 修改或删除图书的信息 判断处理是否成功

如果处理成功

显示处理后图书的信息 并提示：“处理成功” 否则

提示：“处理失败，请确定输入图书信息的正确性” 返回至图书处理界面

（4）事后条件：正确的图书信息保存在数据库中（5）非功能性需求

在输入和修改操作中，对输入的错误信息要迅速提示

4.3.4.读者子用例图 4.3.4.1.借阅图书用例图

用例说明

（1）简要说明：在操作界面上显示借阅图书处理的信息

（2）前提条件：获得读者的借阅证号和所借图书的信息、操作者拥有权限

（3）事件流：

打开读者借阅图书处理的界面 输入读者的借阅证号 判断读者能否借书 如果能够借书

则提示：“读者已借X本书，可借Y本书，无罚款信息” 输入所借图书信息 处理借阅

判断借阅处理是否成功 如果成功

则提示：“读者借阅图书处理成功”

返回至功能选择界面 否则

提示：“读者借阅处理失败，请确定读者信息的正确性”

返回至借阅处理界面

否则

提示：“读者借书已满”或者“有图书逾期记录”

返回至功能选择界面

（4）事后条件：正确的借阅处理信息保存在数据库中（5）非功能性需求：

在输入和修改操作中，对输入的错误信息要迅速提示

4.3.4.2.图书归还用例图

用例说明：

（1）简要说明：在操作界面上显示归还图书处理的信息

（2）前提条件：获得读者借阅证号和归还图书的信息，操作者拥有处理归还图书的权限

（3）事件流

打开读者归还图书的操作界面

输入读者借阅证号显示读者的借阅信息 显示读者图书是否超期并提醒读者 处理归还操作 判断操作是否成功 如果成功

则提示：“读者归还图书成功”

选择返回功能

界面返回至管理员登陆成功后的功能选择界面 否则

提示：“归还图书失败，请确定输入信息的正确性”

返回至归还图书界面

（4）事后条件：正确的图书归还后保存在数据库中（5）非功能性需求：

在输入和修改操作中，对输入的错误信息要迅速提示

4.3.4.3 个人信息查询用例图

用例说明：

（1）简要说明：在登录后显示具体的详细信息（2）前提条件：了解个人的借阅证号和密码（3）事件流

打开读者登录的页面 输入借阅证号及密码 判断是否登录成功 如果登录成功

则提示：“登录成功” 显示读者的个人信息 选择退出功能

退出读者查询 否则

提示：“密码错误”、“借阅证号错误”和“查询不到相应的结果”

（4）非功能性需求：

在输入信息操作时，对输入的错误信息要立即提示

4.4主要用例间的活动描述 4.4.1 采编部活动图

4.4.2流通管理部活动图

4.4.3 借书活动图

4.4.4 还书活动图

4.4.5 办公室活动图

4.5核心对象的状态变迁描述 4.5.1借阅证状态图

4.5.2图书状态图

5.需求原型系统

5.1需求原型总体结构

5.2各用例的需求原型

5.2.1流通管理部门的用例情景描述 5.2.1.1借阅图书的情景描述

5.2.1.2还书处理的情景描述

5.2.1.3罚款处理的情景描述

5.2.1.4图书处理的情景描述

5.2.1.5删除图书的信息情景描述

5.2.2读者的情景描述 5.2.2.1查询借阅书籍信息

5.2.3采编部门的情景用例描述 5.2.3.1图书编目入馆的情景描述

5.2.4办公室的情景描述

5.2.4.1读者信息的添加情景描述

5.2.4.2读者借阅证的挂失情景描述

5.2.4.3读者信息的删除情景描述

6.其他需求

篇8：信息化项目需求说明书

一、需求管理的概念

要说需求管理, 首先要知道什么是需求。IBMRational把需求定义为“ (正在构建的) 系统必须符合的条件或具备的功能”。电气和电子工程师学会使用的定义与此类似。著名的需求工程设计师Merlin Dorfm an和Richard H·Thaye r提出了一个包容且更为精练的定义, 它特指软件方面———但不仅仅限于软件:“软件需求可定义为:用户解决某一问题或达到某一目标所需的软件功能。系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。”

需求是构建系统的基础, 而且符合某些需求决定了项目的成功或失败, 因此找出需求是什么, 将它们记下来, 进行组织, 并在发生变化时对它们进行追踪, 这些活动都是有意义的。

二、需求管理的复杂性

软件需求是整个软件开发项目的最关键的一个输入, 与传统的生产企业相比较, 软件需求具有模糊性、不确定性、变化性和主观性的特点, 是软件项目中最难把握的问题, 它的复杂性体现在以下方面:

1) 需求的描述问题。有时候用户对需求只有朦胧的感觉, 根本说不清楚具体的需求, 而且, 烟草公司不同层次的用户关心的问题是不一样的。2) 需求的范围界定问题。需求如何做到没有遗漏, 如何准确划定系统的范围?这确实是一个两难问题, 烟草公司每次开需求评审会时, 总会冒出新的需求, 以至于系统没有一个准确的范围界定。即使是这样, 系统还是要开发, 系统的范围还要硬性的划定一个, 从而建立一个基线。3) 需求开发的工期问题。为了确保需求的正确性、完备性, 项目经理往往坚持要在需求阶段花费大量的时间, 但是烟草公司与承建商的高层领导却会为项目迟迟看不到实际可运行的软件担心不已。他们往往会逼迫项目组尽快往前推进, 而项目组的成员往往也会被复杂的、善变的需求折腾的筋疲力尽。4) 需求的细致程度问题。需求到底描述到多细, 才算合适?仁者见仁, 智者见智, 如果时间允许, 要想细总可以细下去的。但是, 需求的周期越长, 可能的变化越多, 对设计的限制越严格, 对需求的共性提取要求越高, 所以只要双方认为需求描述清楚了, 就可以进入设计阶段了。

三、需求变更的控制

按照现代项目管理的概念, 一个项目的生命周期分为启动、实施、收尾三个过程。需求变更的控制不应该只是项目实施过程考虑的事情, 而是要分布在整个项目生命周期的全过程。成功项目和失败项目的区别就在于项目的整个过程是否是可控的。为保证需求变更的规范和有效实施, 项目组应当有一套变更控制的措施:

(一) 项目启动阶段的变更预防

对于任何软件项目, 变更都无可避免, 也无从逃避, 只能积极应对, 这个应对应该是从项目启动的需求分析阶段就开始了。对一个需求分析做得很好的项目来说, 需求范围界定的越详细清晰, 烟草公司跟承建商扯皮的机会就越少。

(二) 项目实施阶段的需求变更

项目实施阶段的变更控制需要做的是分析变更请求, 评估变更可能带来的风险和修改基准文件。控制需求变更需要注意以下几点:

1) 需求一定要与投入有联系。在项目的开始, 无论是承建商还是烟草公司都要明确这一条:需求变, 软件开发的投入也要变。需求的变更要经过出资者的认可, 这样才会对需求的变更有成本的概念, 能够慎重地对待需求的变更。2) 需求变更要经过正规的需求管理流程。不管多小的变更都要经过流程, 否则会积少成多。在实践中, 人们往往不愿意为小的需求变更去执行正规的需求管理过程, 认为降低了效率, 浪费了时间。但正是由于这种观念才使需求逐渐变为不可控, 最终导致项目的失败。3) 精确的需求与范围定义并不会阻止需求的变更。并非对需求定义得越细, 就越能避免需求的变更, 这是两个层面的问题。因为需求的变化是永恒的, 并非需求细化了, 它就不会变化了。

四、需求管理的执行者

根据烟草商业企业近些年信息系统建设的经验, 在项目建设中需求管理的职责必然由某个部门承担。信息中心作为烟草公司从事信息化管理的部门, 应当承担需求管理的职责, 这样有利于信息系统保质保量建成, 也有利于系统的健康发展。理由如下:

1) 信息中心能够准确把握需求。信息中心作为信息化部门, 既懂信息化技术, 又懂经营管理, 不仅把握着信息技术的发展脉搏, 也对烟草公司的各项经营管理工作全面了解, 对于业务部门提出的需求能够准确把握, 这样能够保障信息系统建设朝着正确的方向迈进。2) 信息中心能够实现烟草公司与系统承建商的良好沟通。如前所述, 需求变更是在所难免的。在信息系统项目实施过程中, 业务部门的需求可能会层出不穷, 有些需求是适时的、合理的, 但也有些需求可能是不恰当的、甚至是矛盾的, 信息中心能够用信息化的视角重新审视需求、梳理细化, 并从信息化的角度提出更深的见解, 从而保证需求的准确性、完整性与系统性;同时将业务部门的需求转化成软件开发人员能够理解的语言提交给系统承建商, 与承建商进行良好的沟通, 避免因为对需求理解有误影响项目质量。3) 信息中心能够发挥系统维护职责, 保障系统健康运行。作为信息化部门, 信息中心承担着信息系统建设和维护的职责, 如果全程参与了信息系统建设, 对于需求有准确的把握, 对于系统架构有全面的了解, 这样有利于系统的维护工作, 保障系统稳定运行, 便于烟草公司业务部门日常工作的开展。

五、结论

在信息系统建设过程中, 需求分析处于最上游, 也是最关键的环节。需求管理的好坏, 对项目的成败起决定性作用。需求管理好了, 信息系统建设就成功了一半。随着烟草行业的不断改革, 信息系统的需求变更是不可避免的, 需要信息中心切实履行需求管理的职责, 准确把握需求, 与系统承建商建立良好的沟通机制, 保障信息系统保质保量建成, 支撑经营管理工作的需要, 促进烟草商业企业信息系统建设的良性发展。

摘要：本文介绍了需求和需求管理的概念, 描述了需求管理的复杂性, 阐述了如何控制需求变更, 最后提出信息中心应当作为烟草商业企业需求管理的执行者并阐述了理由。

关键词：信息系统,需求管理,需求变更

参考文献

[1]柳纯录.信息系统项目管理师教程[M].清华大学出版社, 2005.

篇9：软件项目的需求变更管理

需求管理的常见误区

软件项目的范围控制应该是在需求分析阶段就开始的，然而很多项目经理针对需求分析存在不少认识误区。

误区1：开发商和用户仅就软件需求的基本轮廓达成一致即可，具体细节准备日后协商。

从项目管理角度分析，这是非常危险的，许多软件项目失败的最主要原因就是需求分析阶段对问题、流程、细节的描述不够准确，导致后期预算超支或者工期延误。

正确的方法是：在需求分析阶段，双方必须对项目的应用背景、功能需求、性能需求、可靠性需求、可用性需求、操作界面需求、外部接口需求，以及项目评审的方法、标准、过程进行全面、细致地研究讨论，逐一进行明确。

误区2：软件需求是软件必需向用户提供的功能和界面，功能上满足需求就足够了。

从软件需求工程角度分析，这只是认识到了软件系统的功能需求，忽略了软件的非功能需求和设计约束，需求捕获不够全面。软件需求工程理论认为，软件需求包括功能需求、非功能需求和设计约束三方面内容。

正确的方法是：除了要明确软件的功能需求，还需要进一步明确非功能需求（即软件产品所必备的属性和品质，包括可靠性、可用性、安全性、可扩展性、可移植性等）和设计约束（即软件研发必须遵守的特定规约、限制条件、政策标准,如软件必须采用国内自主知识产权的数据库产品）。

误区3：需求调研的对象是用户，用户就是软件产品的最终使用人员。

从项目管理角度分析，该观点缺乏对项目相关人全面、系统的认识，对用户的概念理解不到位。“用户”是一种泛称，它可细分为客户、最终用户和间接用户三种类型。例如，很多企业的一把手并不直接参与软件的采购和操作，但是其对于软件项目实际上起到了关键意义的决定作用，属于最重要的间接用户。

正确的方法是：要充分认识用户的多重性、层次性、复杂性，在进行需求调研时应首先对用户进行分析、分类，根据重要性、优先级、特殊性对各类用户进行排序；其次，是针对不同类别的用户分别制订不同的需求调研计划，全面开展需求调研。需要重点指出的是，对于由多个业务部门共同参与的软件项目，在确认软件需求时一定要得到全部参与部门的共同认可。

误区4：按照“需求、设计、编程、测试”步骤研发出的软件不必考虑需求跟踪问题。

从软件工程角度分析，这是对于需求变更过程缺乏系统的认识的表现，严格线性顺序的开发模型并不能保证各个开发阶段的工作成果与需求保持一致。实际上，由于需求变更的不可预见性和必然性，各个阶段往往以螺旋的方式渐进。

正确的方法是：需求跟踪应该贯穿于整个软件需求管理阶段，需求跟踪的目标是实现《产品需求规格说明书》和软件产品之间的双向可追溯。

做好需求工程

需求分析是软件工程项目最重要、最基础的起始阶段，为后续的规划设计阶段提供参照依据。在软件研发项目过程中一定要树立需求工程的意识，将需求视为一项系统工程。为了能够全面做好需求管理，应根据项目实际情况严格划分项目阶段，清晰界定、定义项目阶段的基线，在每个项目阶段制订、执行阶段性需求管理计划，逐一认真落实。

1．需求工程的结构及目标任务

需求工程是一个包括创建和维护系统需求文档所必需的一切活动的过程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工程结构如图1所示，需求开发与需求管理的流程如图2所示。

需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求开发过程有3个主要活动：需求调查、需求分析、需求定义。需求开发过程可分为两个阶段：用户需求调查阶段和产品需求定义阶段，两个阶段在逻辑上通常是以迭代的形式进行的。需求开发过程产生的主要文档有《用户需求说明书》、《产品需求规格说明书》（对于软件产品而言就是《软件需求规格说明书》）。

需求管理的目的是在用户与开发商之间建立对需求的共同理解，维护需求与软件工作成果的一致性，并控制需求的变更。需求管理过程有三项主要活动：

（1）需求确认:开发商和用户共同对需求文档进行评审，双方就需求达成共识后做出书面承诺，使需求文档具有商业合同效果。

（2）需求跟踪:通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。

（3）需求变更控制:依据“变更申请、审批、实施、重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。

需求管理过程产生的主要文档有《需求评审报告》、《需求跟踪报告》、《需求变更控制报告》等。

2．需求的跟踪

需求跟踪的目的是建立与维护“需求、设计、编程、测试”过程的一致性，确保所有的工作成果符合用户需求。需求跟踪有两种方式：

（1）正向跟踪：检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。

（2）逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。

正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵。

组建变更控制管理机构

项目变更是指项目实施过程中由于环境或者其他因素的变化而对项目部分或者全部功能、性能、架构、技术指标、集成方案、进度、质量等方面做出改变。

1．变更控制管理的任务及目标

信息系统项目实施过程中变更是无法避免的。变更控制管理的任务是：建立规范、严格、可行、高效的变更控制体系机制，组建变更控制管理机构，出台变更管理制度；对用户提交的变更请求进行快速的响应、受理；及时分析、研究、评估变更的可行性、成本、代价、范围；对于确定接受的变更请求制订变更实施计划方案及配套应对措施，实施变更任务，进行变更测试检查，做好变更记录。需求变更控制的最终目标是：通过建立严格规范的变更控制管理流程,拒绝不切合实际的变更，减少变更带来的风险，防止变更范围扩大、蔓延，杜绝随意的变更申请及受理过程等。

2．变更控制管理机构的建立

组建有效的变更控制管理机构和制订配套的变更控制管理制度，是进行变更控制管理的重要基础和前提保障，否则变更控制管理将成为一纸空文。变更控制管理机构（形式上可以是“变更控制管理委员会”、“变更控制管理办公室”、“变更控制管理组”等）是一个特殊组织，对项目负责人直接负责，它不受现存的职能组织结构的束缚,可由来自不同机构、不同部门、不同专业、不同岗位的人员组成，各成员划分权限岗位、明确职责、落实责任、协同工作。一般情况下，变更控制管理机构内部应至少配备以下四种角色的成员：

项目管理人员（类似于“项目经理”）：主要负责制订项目管理制度和项目管理计划，督促、检查、落实、考核项目执行过程，做好项目干系人之间的沟通协调工作。

技术负责人员（类似于“总工程师”）：主要负责项目中信息技术平台的分析、建模、设计、测试、实现。

业务管理人员（类似于“业务经理”）：主要负责收集整理业务需求、编写需求说明书、验证和评审需求、管理和控制需求变更。

通信联络人员：主要负责项目组织内部成员之间的信息发布。

需求变更控制 管理工作程序

需求变更的目的是希望软件产品更加符合用户的需求，但是变更涉及的人员多、范围广、影响大，在进行变更控制管理时必须建立严格、规范的变更控制管理工作程序，这样才能使项目始终按照预定的方向、模式、进度进行。

需求变更控制过程中最难办的事情不是“满足用户提出的变更请求”，而是“在用户认同支持、追加项目投资经费的前提下尽快完成变更任务”。用户往往认为提出变更需求是基本权利，而软件开发商往往认为只有义务解决在《用户需求说明书》、《产品需求规格说明书》中预先定义的各类需求，除此以外都应该拒绝或者在用户追加投资的前提下解决。

现实中信息系统项目的目标是具有一定弹性的，这一点尤其重要，用户和软件开发商之间为了达成共同目标不可能针锋相对，项目管理人员需要利用高超的管理艺术、沟通技巧、人格魅力，在对立博弈的关系之中寻求最佳的平衡点。

另外，有必要强调的是，在项目实施过程中，变更处理越早，难度越小，损失越小；变更处理越迟，难度越大，损失也越大。而且，任何变更都必须经过项目建设全部相关方（建设单位、承建单位和监理单位）多方确认后才能计划实施，严禁任何一方擅自变更。对项目变更的范围要有明确的界定，而且项目建设全部相关方对变更范围的理解上都没有任何异议。