软件开发部工作流程设计方案

1、软件开发部工作流程设计方案一、新项目工作流程1 .相关负责人提出新的项目，编写立项建议书（对项目可省略）和用户需求报告 （必备），提交软件开发部；2 .开发人员根据用户需求报告制作需求规格说明书交由相关项目负责人确认后，根据规格说明进行概要和详细设计，然后开始编写代码；3 .开发人员根据立项建议书中的进度安排，做出项目原始原型后，交由测试人员测试；期间，开发人员修改 BUG并逐步完善系统功能；4 .最终完善后，正式发布1.0版本，相关项目负责人接收并安排用户测试，新项目由此终、项目维护流程1 .由相关项目负责人（可以是负责跟进此项目的客服或测试人员）分类整理用户和测试人员 意见，制作维护更新报

2、告，提出维护申请；2 .开发人员根据维护更新报告进行可行性评估，修改需求规格说明书 ，并修改源程 序，将测试版交由测试人员测试，并根据测试回馈修正程序，发布新版本；3 .相关人员安排用户进行新版本更新。备注：上述文档模板请见附录 1附录1实用软件工程文档汇编1立项建议书 32软件项目投标书 83软件产品开发任务书 84软件开发计划书 115用户需求报告 156需求规格说明书 197需求报告/需求规格说明书评审记录表 238 ”图书馆信息系统” 259概要设计说明书 2610详细设计说明书 3111用户使用手册 3512用户安装手册 3613测试报告 371立项建议书立项建议书编写参考指南1 .

3、弓I言 (Introduction )1.1 目的(Purpose)本文档是软件立项书，目的是代替可行性分析。1.2 围(Scope)本文档只适应于软件立项。1.3 术语定义(Terms Glossary )对软件组织部和外部有关的行业术语、专用名词进行定义。121.4 参考资料(References )对书写该立项书所用到的有关资料进行说明。121.5 相关文档(Related Documents )当该文档变更时，可能对其他文档产生影响，受影响的文档叫做相关文档，需将它们一一列出。121.6 版本更新记录(Version Updated Record )任何一次版本创建或维护更新，都要追加

4、一条记录。一个版本创建只有一次，但对它的维护更新可能有多次。大版本升级一次，定义为创建一次，如 V1.0到V2.0。而V1.0到V1.1 ,只是维护更新一次。版本更新记录格 式，如表3-2所小。表3-2版本更新记录版本号创建者创建日期维护者维护日期维护纪要V1.0王大林2001/01/03一一一V1.0.1王小林2001/02/10网络版功能维护2 .项目概述及架构 (Project Summary and Framework )2.1 项目概述(Project Summary )宏观上说明该项目是什么、能干什么、要求干得怎么样。2.2 项目架构(Project Framework )宏观上描

5、述该项目的架构：单机结构、C/S结构、B/S结构。并说明结构具体详细的运行平台：硬件的要求、操作系统的要求、数据库管理系统的要求、对外接口的要求。3 .客户群分析 (Client Analysis )3.1 客户群定位(Client Orientation )单机结构、C/S结构、B/S结构对应哪三种客户群，每种客户群的数量、素质、市场前景等。3.2 当前客户群分析(Current Client Analysis )当前客户群是指已签订合作协议或将要签订合作协议的客户群，分析他们的数量、素质、市场前景等。3.3 潜在客户群分析(Latency Client Analysis )潜在客户群是指将

6、来可能发展的客户群，分析他们的数量、素质、市场前景等。4 .项目功能 (Project Function )4.1 单机版功能(Stand-alone Function )单机版功能，如表3-3所示。表3-3 单机版功能编号功能名称功能描述输入容输出容124.2 网络版功能(Network Function ) 网络版功能，如表3-4所示。表3-4网络版功能编号功能名称功能描述输入容输出容124.3 互联网络版功能(Internet Function )互联网络版功能，如表 3-5所示。表3-5互联网络版功能编号功能名称功能描述输入容输出容125 .项目性能 (Project Performa

7、nce )5.1 响应时间(Response Time)单机结构(包括主机多用户结构，即 H/T结构)、C/S结构、B/S结构三种架构的终端数量，要求响应时间小于0.XX秒。5.2 处理速度(Disposal Speed )C/S结构、B/S结构两种架构的后台结算方式，结算速度分析。5.3 最大终端负载(The Highest Terminal Load )C/S结构、B/S结构两种架构的并发处理最大终端(用户)负载数量分析。以上性能要求，最好也用列表的形式给出。6 .项目接口 (Project Inteface )6.1 金融接 口( Finance Interface ) 金融接口列表，如

8、表 3-6所示。表3-6 金融接口列表编号接口名称接口规接口标准入口参数出口参数传输频率126.2 政府接 口( Government Interface )政府接口列表，如表 3-7所示。表3-7 政府接口列表编号接口名称接口规接口标准入口参数出口参数传输频率126.3 互联网接口( Internet Interface )互联网接口列表，如表 3-8所示。表3-8 互联网接口列表编号接口名称接口规接口标准入口参数出口参数传输频率127,投入产出分析A Analysis of the Devotion and the Output )1.1 人力资源投入(Manpower Devotion

9、)人力资源投入，如表 3-9所示。表3-9人力资源投入阶段名称需求岗位需求人数工作量(人/月)到岗日期需求分析分析师概要设计设计师详细设计设计师/高级程序员编码程序员测试测试员包装与发布包装师总人数：总工作量(人/月)：1.2 设备资源投入(Facility Devotion ) 设备资源投入，如表 3-10所示。表3-10 设备资源投入设备名称规格型号数量单价(元)金额(元)到位日期1.3 其他经费资源投入(Other Outlay Devotion ) 其他经费资源投入，如表3-11所示。表3-11其他经费资源投入开支项目开支金额(元)支付日期支付方式(现金/支票)备注项目总投入(人力费用

10、+ 设备费用+其他经费资源投入)经费(元)：1.4 产出分析(Output Analysis ) 产出分析，如表3-12所示。表3-12 产出分析单机版单价(元)单机版 数量C/S版单价(元)C/S版数量B/S版单价(元)B/S版数量年产出合计金额(元)第1年第2年第3年8 .开发计划 (Development Scheme)8.1 进度计划(Plan Scheme)开发进度计划，如表 3-13所示。表3-13 进度计划阶段名称需求分析概要设计详细设计编码测试包装与发布第1周进度第2周进度第3周进度第4周进度第5周进度8.2 评审计戈Li ( Review Scheme)各里程碑的评审计划，如

11、表 3-14所示。表3-14 评审计划阶段名称评审日期评审地点主持人参加人应交文档需求分析概要设计详细设计测试报告包装9 .案例分析 (Cases Analysis )案例分析包括成功案例和失败案例分析。9.1 国外案例分析(Cases Analysis in Foreign Countries )案例1：案例2:9.2 国案例分析(Cases Analysis in China )案例1：案例2:10 .风险分析 (Risk Analysis )10.1 需求风险(Risk of Requirement )指项目组对用户需求获取的途径和能力有何风险，用户主动配合需求的程度。10.2 政策风险

12、(Risk of Policy )指国家政策、行业政策、企业部政策的变化对项目将会产生有利或不利的影响。10.3 资源风险(Risk of Resource )指开发和运行所需资源的风险程度。10.4 技术风险 R Risk of Technology ）指项目组采用新技术的风险程度。如最新开发工具的风险程度、最新设计思想的风险程度。10.5 技能风险（Risk of Skill ）指项目组成员掌握新技术的风险程度。2软件项目投标书表3-15软件项目投标书编写参考指南序号章节名称章节容1项目概况按照招标书的容，述项目概况2总体解决方案按照招标书的要求，提出项目的总体解决方案：网络结构总体方案系

13、统软件配置方案应用软件设计方案系统实施方案3项目功能、性能和接口描述应用软件的具体功能点列表 应用软件的具体性能点列表 应用软件的具体接口列表续表序号章节名称章节容4项目工期、进度和经费估算项目工期（单位：人月）估算项目进度估算：需求、设计、编程、测试、验收的时间表项目经费（单位：人民币元）估算5项目质量管理控制质量标准质量管理控制方法项目开发和管理的组织结构及人员配备6附录附录1:本软件公司的特点与强项简介附录2:本软件公司的成功案例附录3:本软件公司的资质证明材料3软件产品开发任务书软件产品开发任务书正文样本任务书名称：大型商业 MIS产品开发任务书。下达日期：1999/04/01 。发出

14、部门：XX公司研发中心。接受部门：研发中心商业软件部。1 .目标（1）做成商业MIS产品，其产品化程度要求很高。因此，一切信息都要规化、标准化、代码化。保证在 产品实施时，其客户化工作只需录入代码和修改代码，绝对不允许修改数据结构和表结构；（2）配合市场销售部门、全国各地的分支机构和产品代理商，第一年开拓市场35个客户，第二年占领10%的商业MIS市场。2 .功能模块划分及要求大型商业MIS软件产品拟分为以下 6个功能模块，要求每个功能模块具有高聚、低耦合、信息隐蔽的性质， 如表3-16所小。表3-16 大型商业MIS产品的6个功能模块序号模块名称功能要求1商业物流配送中心管理商业物流采购、配

15、送2大型商场（大型连锁超市）管理商品零售3便利店（小型连锁超市）管理商品零售4远程数据交换管理点对点通信5电子商务模块网上订货、销售6商业类库管理基础类库、商业类库、构件库管理3 .功能模块详述大型商业MIS软件，从组织结构上来说包括三个层次：（1）物流配送中心（2）大型商场（大型连锁超市）（3）便利店（小型连锁超市）作为一个完整的商业 MIS系统来说，物流配送中心与大型商场（大型连锁超市）之间会发生物流、资金流、 信息流的关系；大型商场（大型连锁超市）与便利店（小型连锁超市）之间也会发生物流、资金流、信息流 的关系；而物流配送中心与便利店（小型连锁超市）之间没有任何关联。若将这三个模块分开来

16、看，它们又 可以各自独立成为一个单独的小型商业系统来使用。实际上，本大型商业MIS系统完成后，可以对功能模块进行组合或拆分，使其成为如下 5个不同的小型商业 MIS系统，供用户选择：（1）物流配送中心 十大型商场（大型连锁超市）十 便利店（小型连锁超市）的完整的商业MIS软件。（2）物流配送中心 十 大型商场（大型连锁超市）的商业MIS软件。（3）大型商场（大型连锁超市）十 便利店（小型连锁超市）的商业 MIS系统。（4）物流配送中心MIS系统。（5）大型商场的商业 MIS系统。作为本软件的第一层，物流配送中心可以具有多个配送仓库，它根据大型商场（大型连锁超市）的需要以及 各个仓库库存情况，向

17、供应商订货，进行货物采购；并根据订货的情况进行配货，组织运输工具进行发货； 期间，还伴随着向供应商付款、索取发票，以及向客户催款、开出发票等等。大型商场（大型连锁超市）作 为本软件的第二层，除了要进行本商场的各种业务管理外，还要向上级物流配送中心订货、付款、索取发票， 向下级便利店（小型连锁超市）送货，收取钱款等等。便利店（小型连锁超市）作为本软件的第三层，一要 进行本商场的各种业务管理；二要根据库存情况，向大型商场（大型连锁超市）要货，并定期将销售金额上 交给大型商场（大型连锁超市）。考虑到目前有些商场，已经有了其他的商业管理软件，虽然软件还有不完善的地方，但已经购买前台POSao为了给客户

18、节省开支，有效地将前台 POSM利用好，所以，本系统的前台销售软件就要做两个版本：Windows版本与DOS版本。由于配送中心与大型商场（大型连锁超市）之间、大型商场（大型连锁超市）与便利店（小型连锁超市）之 间在物理位置上有一定的距离，所以，它们之间的网络连接也是一个需要重视的大问题。本系统考虑采用两 种解决方案：一是采用 DDN?线（或光缆），本方案数据传输速度快，性能高，程序设计、实现都很简单，但 用户每月都要支付价格不低的线路费用，这种方案比较适合那些经济实力比较雄厚的用户；二是采用线，用 X25通信协议，此方案数据传输速度稍慢，但也能满足用户需要，程序设计和实现要复杂许多，用户每月支

19、 付的线路费用将大幅度下降。随着计算机网络技术的飞速发展，电子商务在流通领域的应用也越来越多。本MIS系统也准备在电子商务方面有所扩展，条件允许，可以实现网上订货、网上销售，甚至网上货币支付。作为一个软件企业，应该不断地提取、积累自己的软件资源。不同开发平台的开发规、商业类库、应用框架、构件、中间件等都是十分重要的软件资源，是软件公司的基础建设。因此，在设计、编码之前，要制订相应 的开发规，要组织开发、设计、管理一些类库和构件库。软件产品是软件公司的财富来源，而软件的有效加密是保护公司产品、产权的有效手段，更是保障公司效益的有效途径。所以，还要考虑软件加密算法设计。4 .功能模块任务分配根据研

20、发中心商业软件部目前的人员情况，本系统的项目经理由商业软件部副经理亲自担任，负责整个系统的规划、设计、协调与实施；商业软件部主任工程师担任产品经理， 负责项目的整体需求、数据库设计与Alpha 测试。整个项目分为 4个任务组，各个任务组组长在项目实施阶段，承担小项目经理职责。4个任务组的人数及开发任务，如表 3-17所示。表3-17任务组的人数及开发任务任务组人数具体开发任务第1任务组41 ） POSM模块改造2 ）利用X 25协议进行远程数据交换3 ）电子商务模块第2任务组6物流配送中心管理模块。本模块的主要功能包括：货物的采购管理，配送中心的库存管 理，货物的销售管理三大部分1 ）货物的采

21、购管理包括：供应商管理，采购计划管理，订货管理，货物验收管理，退货管理，应付账款管理，应收发票管理，往来账管理等2 ）库存管理包括：货位管理，入库管理，出库管理，盘库管理等3 ）销售管理包括：客户管理，销售定单管理，配货管理，运输工具管理，发货管理，退货管理，应收账款管理，应付发票管理，往来账管理等第3任务组61 ）全局数据库设计2 ）商业管理模块（包括大型商场与便利店的管理）。本模块的主要功能包括：货物的 采购管理，退货管理（退给供应商），价格管理，库存管理，销售管理，前台销售管理， 退货管理（客户退货管理），应付、应收账款管理，发票管理，送货管理（给便利店送货）， 收款管理（便利店上交金额

22、）等等第4任务组21 ） PowerBuilder 开发规2 ） PowerBuilder 类库建设3 ）构件的提取和构件库的管理4 ）产品的加密处理5）安装盘的制作5 .数据库与开发工具的选择考虑到数据库的性能与价格比，数据库首选Sybase,其次是MSSQL Server。由于这两个数据库的天然联系，使得两个版本的程序设计的差异将十分微小。数据库设计工具采用PowerDesigner ,程序开发工具选择为PowerBuilder 。某些 PowerBuilder 不宜实现的功能，可由 VC+去完成。文档制作工具为Office 和PowerDesigner。6 .开发进度计划研发中心商业软件

23、部现有18人进入了本项目组。根据以往的实际工作经验，下面列出研发进度，如表 3-18所示。表 3-18进度计戈U ( 1999/04/01-1999/10/15 )阶段名称需求分析概要设计详细设计编码测试包装发布第1周进度需求培训第2周进度需求获取第3周进度需求获取第4周进度需求获取第5周进度需求确认第6周进度.概要设计第7周进度概要设计第8周进度概要设计第9周进度详细设计第10周进度详细设计第11周进度详细设计第12周进度详细设计第13周进度编码第14周进度编码第15周进度编码第16周进度编码第17周进度编码第18周进度编码第19周进度编码第20周进度Alpha测试第21周进度Alpha测试

24、第22周进度Alpha测试第23周进度Alpha测试第24周进度Beta测试第25周进度Beta测试第26周进度包装第27周进度发布第28周进度机动7 .评审计划各里程碑的评审计划，如表 3-19所示。表3-19 里程碑评审计划阶段名称评审日期评审地点主持人参加人应交文档需求分析1999/05/05公司第一会议室部门经理项目组成员用户需求报告/需求规格说明书概要设计1999/05/26公司第一会议室部门经理项目组成员概要设计说明书详细设计1999/06/25公司第一会议室项目经理项目组成员详细设计说明书Alpha测试1999/09/12公司第一会议室项目经理测试人员Alpha测试报告Beta测

25、试1999/09/26客户单位项目经理客户代表Beta测试报告包装1999/09/31公司第一会议室部门经理销售人员包装光盘，用户指南，广告材料附件：商业MIS立项建议书，此处省略8 软件开发计划书软件开发计划书编写参考指南1 .弓I言(Introduction )1.1 目的(Purpose)本章提供整个软件开发计划的综述。主要是确定以下容：(1)软件生存周期的选取及裁剪(2)软件规、方法和标准的选择。(3)软件工作产品的规模估计。(4)软件工作量和成本的估计。(5)软件进度表的制定。(6)软件风险的估计。(7)软件项目培训计划。1.2 围(Scope)说明该软件开发计划的围，简要描述软件开

26、发计划的容。一般而言，对于一个较大的软件项目(工期6个人月以上)，计划书包括如下容：(1)软件规模估计(2)工作模块计划(3)人力资源计划(4)其他资源计划(5)进度安排计划(6)配置管理计划(可单独做一个计划)(7)质量保证计划(可单独做一个计划)1.3 术语定义(Terms Glossary )将该软件开发计划中的术语、缩写词进行定义。包括用户应用领域与计算机领域的术语与缩写词等。例如：1软件相关组：指软件配置管理组、文档支持组、测试组。2软件质量保证组：指计划和实施软件质量保证活动的人员的集合。1.4 参考资料(References )说明该软件开发计划使用的参考资料，如项目的用户需求报

27、告、商务合同、用户领域的资料等，每一个文件、文献要有标题、索引号或文件号，发布或发表日期以及出版单位。121.5 相关文档(Related Documents )当该文档变更时，可能对其他文档产生影响，受影响的文档叫相关文档，需将它们列出。121.6 版本更新记录(Version Updated Record )版本更新记录格式，如表 4-8所示。表4-8 版本更新记录版本号创建者创建日期维护者维护日期维护纪要V1.0王大林2001/02/06V1.0.1王小林2001/02/25成本估算维护2.项目概述 (Project Summary )2.1 项目的目的(Project Purpose

28、)说明该软件项目的目的。2.2 项目的围(Project Scope )本章的容，主要参照立项建议书 /合同与用户需求报告中相关章节，简要描述该软件项目的实现围：(1)主要功能点列表(2)主要性能点列表(3)主要接口列表（ 4）本软件项目与其他软件项目之间的关系（ 5）项目实施方面的限制等容2.3 项目的使用对象（Project Reader ）在本章节中，要识别出顾客与最终用户，对顾客与最终用户的情况要有简单描述，如最终用户的教育水平、技术水平及本系统的使用频度等。3项目组织（ Project Organization ）项目组织是为开发项目而组建的队伍。建议以框图的方式表示项目的组织结构，

29、并对每一组织的负责人和职责加以说明。可能的项目组织单元，如：（ 1）项目管理组（ 2）质量保证组（ 3）配置管理组（ 4）软件工程组（ 5）测试组（ 6）需求管理组各组织说明如下：（1）项目管理组，执行 SPP和SPTO±程，对项目实施负全部责任。（2）质量保证组，执行 SQA过程，负责项目过程与产品的质量控制和报告。（3）配置管理组，执行 SCM过程，负责项目产品的版本、配置管理以及配置库状态报告。（ 4）软件工程组，执行软件项目工程过程，负责项目产品的开发和维护工作。（ 5）测试组，执行软件项目测试过程，负责项目产品的测试。（ 6）需求管理组，负责对需求基线和需求变更进行管理。4

30、软件生存周期（ Software Life Cycle ）本章节记录项目策划生存期定义的工作结果，需要描述的主要容：（ 1）项目生存期框图（ 2）项目生存期说明5规、方法和标准（ Criterion ， Means， Standard ）本章节中需要描述采用的供开发和维护软件用的规、方法和标准。6任务与工作产品（ Task and Work Products ）项目任务和工作产品，是指根据项目生存期阶段划分的任务，和相应阶段的工作产品。记录项目生存期各阶段确定的需重点控制的阶段任务和工作产品。建议以表格的形式，列出生存期各阶段的任务和工作产品。项目包含的任务，如：（ 1）需求分析（ 2）系统设

31、计（ 3）系统实现（ 4）测试（ 5）产品交付（ 6）产品维护项目可能包含的产品，如：（ 1）需求分析说明书（ 2）规格分析说明书（ 3）系统设计说明书（ 4）源代码（ 5）各种测试报告（ 6）用户手册（ 7）软件问题维护记录7工作产品、任务规模、工作量估计（ Estimates of Work Product ， Task Size and Workload ） 项目规模估算是为了确定项目所需的人工。需要描述的主要容有：（ 1）对软件工作产品规模估计依据的简要描述。（ 2）每种任务和工作产品规模估计的结果。（ 3）规模估算的结果，建议用任务规模和工作量估算表的形式列出。8成本估计（ Esti

32、mates of Costs ）成本估计，是指对项目完成过程中耗费的人力、物力、财力资源的估算。成本估计应按类别进行估算，可能的成本估算类别，如：（ 1）直接人工（ 2）直接费用（ 3）间接成本（ 4）制造费用（ 5）管理费用（ 6）不可预见费用9关键计算机资源计划（ Critical Computer Resource Plan ）项目的关键计算机资源计划，是指系统在开发环境、测试环境、及用户目标环境中，对关键计算机资源，如计算机存储能力、计算机处理器速度、通信通道容量、服务器处理能力等的估计，使之能满足软件开发、测试、运行的要求。10软件项目进度计划（ Software Project S

33、chedule ）件项目进度计划，是对项目的进度、人员工作分工所做的计划，此计划依据上述各章的估算和分析结果，计划方式建议采用表格的形式。若采用工具制定项目计划，应将工具生成的图表作为项目计划的附件。本章节中需要描述的主要容有：（ 1）软件项目每个阶段的进度时间表（ 2）设定的里程碑（ 3）评审时间（ 4）缓冲时间11 配置管理计划（可单独做一个计划）（ Configuration Management Planning ）本书单独作为一章论述。12质量保证计划（可单独做一个计划）（ Software Quality Assurance Planning ）本书单独作为一章论述。13风险分析（

34、 Risks Analysis ）项目风险分析，是指对可能发生的将会对项目按预期时间、资源和预算完成产生重大影响的事件的分析包括：（ 1）被识别出的重大风险事件：政策风险、技术风险、技能风险等。（ 2）易发生重大风险事件的高风险区域：用户需求、设计、测试、运行平台等。（ 3）重大风险事件的级别：功能不全、性能不稳、迅速受限制等。（ 4）拟采取的预防措施：增加投入、纠错、延时等。（ 5）风险事件发生后建议采用的处理措施：更改计划、降低难度系数等。14设备工具计划（ Equipment and Tools Planning ）项目设备工具计划，是根据项目的工作指派及进度确定项目所需要的设备和工具，

35、以确保设备工具在任务执行前到位，保证项目任务的顺利执行，在本计划中应包含以下几方面的容：（ 1）所需的设备（ 2）基本的要求（ 3）应到位的时间15培训计划（ Training Planning ）项目的培训计划，应根据项目的特点和项目组成员技能情况，制定出项目组成员所需的培训容，培训计划中应包含以下几方面：（ 1）培训容(2)培训时间(3)教员(4)接受培训的人员(5)培训目的(应达到的效果)16 .项目评审 (Project Reviews )项目评审，是对项目策划过程所做的定期性评审。其容可分为：(1)评审点(2)评审周期(3)评审层次(4)评审条款和措施(5)管理评审活动中提交的工作产

36、品(列出被评审的工作产品)17 .度量(Measurement)度量是按规定在项目进行过程中，需要采集的度量数据，以便量化地反映项目的进展情况，为管理者提供对 项目进展的适当的可视性，同时度量数据是项目过程改善的数据基础。应规定项目度量值的记录人(一般为 项目经理或其指定人员)、记录时间(一般以定期评审为基础)和记录的数据。常用的度量数据如：(1)项目过程的评审次数(2)项目计划修改次数(3)项目各阶段的人员投入(各阶段投入的人月数)(4)各类任务耗用时间统计(如设计、编码、测试、文档编写等)(5)工作产品统计(如文档字数、功能点数、用况数、源代码行数等)5用户需求报告用户需求报告编写参考指南

37、1 .概述(Summary本文档是进行需求规格定义、项目策划、概要设计的基础，也是用户进行验收的依据。1.1 用户简介(User Synopsis )在本章节中要将用户的基本情况描述清楚，以便于分析人员划定系统围，进行关于功能、进度、成本、性能 等方面的平衡决策。对于产品开发类项目，需要在此将该产品定义的用户群的特点描述清楚。1.2 项目的目的与目标(Purpose and Aim of Project )项目的目的是对开发本系统意图的总概括。项目的目标是将目的细化后的具体描述。项目目标应是明确的、可度量的、可以达到的，项目的围应能确保项目的目标可以达到。对于项目的目标可以逐步细化，以便与系统

38、的需求建立对应关系，检查系统的功能是否覆盖了系统目标。1.3 术语定义(Terms Glossary )将该用户需求报告中的术语、缩写进行定义，包括用户应用领域与计算机领域的术语与缩写等。1.4 参考资料(References )说明该用户需求报告使用的参考资料，如：1商务合同2招标书3用户领域的资料4用户需求调查表5参照的标准每一个文件、文献要有标题、或文件号，发布或发表日期以及出版单位1.5 相关文档(Related Documents )说明用户需求报告的变更，以及可能受变更影响的其他相关文档，如：1项目开发计划2需求规格说明书1.6 版本更新信息(Version Updated Rec

39、ord )版本更新记录格式，如表5-11所示。表5-11 版本更新记录版本号创建者创建日期维护者维护日期维护纪要V1.0王大林2001/02/18一一一V1.0.1一一王小林2001/02/26账本格式维护2,现有系统描述 (System in Existence )2.1 组织结构与职责( Organizing Framework and Function )将用户的组织结构逐层详细描述，建议采用树状的组织结构图进行表达，每个部门的职责也应进行简单的描述。组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务、确定系统围很有帮助。取得 用户的组织结构，是需求获取步骤中的工作任务之一

40、。2.2 岗位定义(Role Definition )用户环境中的企业岗位和组织结构一样，也是分析人员理解企业业务的基础，是需求获取的工作任务，同时也是分析人员提取对象的基础。每个岗位的职责可以进行详细的描述，建议采用表格的形式，如表5-12所示。表5-12 岗位定义编号岗位所在部门职 责相关的业务1008米购员业务部商品采购、合同签订、供应商选择进货、合同管理1009对用户岗位的识别，也包括使用了计算机系统后的系统管理人员岗位。2.3 作业流程(Busywork Flow )企业的作业流程，首先要有一个总的业务流程图，将企业中各种业务之间的关系描述出来，然后对每种业务进行详细的描述，使业务流

41、程与部门职责结合起来。t¥细业务流程图可以采用直式业务流程图、Use case图、程序流程图加上文字说明。图形可以将流程描述得很清楚，但是还要附加一些文字说明，如关于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述的容，需要用文字进行详细描述。2.4 单据、账本、报表(Bill of Document , Account and Report )现行系统中用户正在使用的正式的或非正式的单据、账本、报表等可以收集起来，并进行穷举、分类、归纳。单据、账本、报表是用户系统息的载体，是进行系统需求分析的基础，无论采用哪种分析方法，这都是必不可少的信息源。2.4.1 单据

42、(Bill of Document )单据的格式可用表格描述，如表5-13所示。表5-13 单据的描述格式单据名称用途使用单位制作单位频率高峰时数据流量各数据项的详细说明如下:序号数据项中文名数据项英文名类型、长度、精度数据项的取值围1232.4.2 账本(Account)因为账本上的数据是统计数据，所以一个账本一般对应一中间表，账本的格式可用表格描述，如表5-14所示。表5-14 账本的描述格式账本名称用途使用单位制作单位频率高峰时数据流量各数据项的详细说明如下:序号数据项中文名数据项英文名数据项类型、长度、精度数据来源1232.4.3 寸艮表(Report )因为报表上的数据是统计数据，所

43、以一个报表一般对应一中间表，报表的格式可用表格描述，如表5-15所示。2.5 存在的问题(Existent Question )在现行的系统中，决策层、管理层、操作层各存在哪些方面的问题需要计算机来解决，尤其是决策层、管理层这些问题中包含了用户的需求与期望，有些问题是新系统可以解决的，有些问题则不是。表5-15 报表的描述格式报表名称用途使用单位制作单位频率高峰时数据流量各数据项的详细说明如下:序号数据项中文名数据项英文名数据项类型、长度、精度数据来源1232.6 可能的变化(Possible Change )对于现行的系统，将来可能会有哪些变化，需要在此描述。企业中的变化是永恒的，系统分析员

44、需要描述哪 些变化可能引起系统围变更。3.目标系统功能需求(Function of Target System )3.1 功能需求分析(Function Analysis )决策层、管理层、操作层各有哪些具体功能要求。3.2 功能需求点列表(Function List )在功能需求分析完成后，要详细列出用户需求功能点列表，提供给后续设计、编程、测试中使用，更是为了 用户测试验收中使用。功能需求点列表的格式，如表 5-16所示。表5-16 功能需求点列表编 号功能名称使用部门使用岗位功能描述输入容输出容1234.目标系统性能需求 (Peformance of Target System )4.1

45、 时间要求(Time Request )如：(1)响应时间，如查询的最长等待时间。(2)更新处理时间，如记账的最长时间。(3)数据的转换和传送时间，如远程数据传输的时间要求。(4)解题时间。4.2 空间要求(Space Request)如：(1)支持的终端数。(2)支持的并行操作的使用者数。(3)处理的文件和记录数。(4)表和文件的大小规模(要按可预见的增长，对数据及其分量的存储要求做出估算)。(5)处理任务的数量。(6)在正常情况下和峰值工作条件下，在一定时间周期中要处理的数据总数。(7)对输入和输出数据的精度要求。(8)对处理和传输过程中的精度要求。4.3 性能需求点列表(Performa

46、nce List )详细列出用户性能点列表，提供给后续分析、设计、编程、测试中使用，更是为了用户测试验收中使用。需 求性能点列表的格式，如表 5-17所示。表5-17 性能需求点列表编号性能名称使用部门使用岗位性能描述输入容输出容1235.目标系统界面与接口需求(Inteface of Target System )5.1 界面需求(Interphase Requirement )界面的原则要求，如方便、简洁、美观、一致等。整个系统的界面风格定义，某些功能模块的特殊的界面要 求。(1)输入设备：键盘、鼠标、条码扫描器、扫描仪等；(2)输出设备：显示器、打印机、光盘刻录机、磁带机、音箱等；(3)

47、显示风格：图形界面、字符界面、IE界面等；(4)显示方式：1024*768、640*480 等；(5)输出格式：显示布局、打印格式等。5.2 接口需求(Interface Requirement )与其他系统的接口，如监控系统、控制系统、银行结算系统、税控系统、财务系统、政府网络系统及其他系 统等。(1)与系统特殊外设的接口，如 CT机、磁共振、柜员机(ATM、IC卡、盘点机等。(2)与中间件的接口，要列出接口规、入口参数、出口参数、传输频率等。应在此列举出所有的外部接口名称、接口标准、规。外部接口列表，如表 5-18所示。表5-18 外部接口需求点列表编号接口名称接口规接口标准入口参数出口参

48、数传输频率1236.目标系统其他需求(Other Requirements of Target System )6.1 安全性(Security )6.2 可靠f( Dependability )6.3 灵活卜( Agility )6.4 特殊需求(Special requirements )如：(1)进度需求：系统的阶段进度要求。(2)资金需求：投资额度。(3)运行环境需求：平台、体系结构、设备要求。(4)培训需求：用户对培训的需求，是否提供多媒体教学光盘。(5)推广需求：推广的要求，如在上百个远程部门推广该系统，是否要有推广的支持软件7.目标系统假设与约束条件(Suppose and Re

49、striction of Target System )假设与约定条件是对预计的系统风险的描述，如：(1)法律、法规和政策方面的限制。(2)硬件、软件、运行环境和开发环境方面的条件和限制。(3)可利用的信息和资源。(4)系统投入使用的最晚日期。(5)需求中的风险分析：技术风险、技能风险、时间风险、资源风险。6需求规格说明书需求规格说明书编写参考指南1 .概述(Summary本文档是进行项目策划、概要设计和详细设计的基础，也是软件企业测试部门进行部验收测试的依据。1.1 用户简介(User Synopsis )在本章节中要将用户的基本情况描述清楚，以便于分析人员划定系统围，进行功能、进度、成本、性能等方面的平衡决策。对于产品开发类项目，需要在此将该产品定义的用户群的特点描述清楚。1.2 项目的目的与目标(Purpose and Aim of Project )项目的目的是对开发本系统的意图的总概括。项目的目标是将目的细化后的具体