百胜道闸出入口管理软件.doc

百胜道闸出入口管理软件实用文档
(实用文档，可以直接使用，可编辑 优秀版资料，欢迎下载）

名称
v1.0
百
胜
道
闸
出
入
口
管
理
软
件
说
明
书

目录
一、概述3
1。1参考标准或资料3
1.2 设计特点3
1。3技术优势3
二、体系结构4
三、软件描述5
四、功能模块5
4。1计算机管理系统5
4。2出入口读卡控制功能5
4。3临时卡自动出卡功能5
4.4防砸车感应功能5
4。5中文显示功能5
4。6语音提示功能5
4.7对讲功能5
4。8图象抓拍对比功能5
4。9 ups电源5
4。10防雷功能6

一、概述
1。1参考标准或资料
GB8566-88 计算机软件开发规范;
GB8567-88 计算机软件产品开发文件编制指南;
GB8568-88 计算机软件产品用户手册编制指南；
GB9385—88 计算机软件需求说明编制指南；
GB9386—88 计算机软件测试文件编制规范;
GB/T12504-90 计算机软件质量保证计划规范；
GB/T12505-90计算机软件配置管理计划规范；

1。2设计特点
1。2。1集成功能
开放式结构可以集成企业现有的系统,轻松做到数据共享，一体化管理，处理高度复杂的企业对企业集成需求。
1.2。2快速的实施
通过脚本化配置功能实现系统的快速部署，有效地降低实施成本，充分地发挥企业电脑人员的作用。
1。2。3低维护成本
采用统一集中管理，标准有效地降低系统的管理和维护成本.
1.2.4可控的成本
采用脚本化配置功能来创建一个高度可配置的解决方案，企业电脑人员可以自行配置以满足业务流程的调整和增加，有效地控制系统的成本。

1。3技术优势
1.3.1主流的体系结构
软件系统支持MSSQL 和Oracle数据库，充分利用MSSQL 和Oracle的各种优点，支持服务器和数据库群集，妥善的解决了各类数据瓶颈问题，系统的可靠性、健壮性、高效性达到最高标准。
1.3.2丰富的客户端支持
支持从不同设备访问,可定制的客户端数据查询，升级零安装,数据可导出到不同格式的文件。
1。3.3系统实现模块化技术,具有更高的开放性和标准化
软件设计依照信息工程理论为指导方针,系统实现采用模块化最小化技术，积木式搭建适合需求的软件系统
1.3.4安全的用户访问
根据工作流程和需求，配置用户组和角色。不同的角色设置不同的权限。对用户密码进行了严格的加密,保障软件系统的安全运行。内置软件系统日志监控系统状态。
1.3.5统一管理的基础数据
软件系统设置灵活，可适应业务发展需求,可定制的数据输入格式，输入数据的验证,数据操作定义。
1。3.6报表功能
图形化设计，导入和导出报表自定义，支持多种数据导出格式.
1.3。7动态数据仓库
可访问或导入其它系统的数据,多维的数据分析功能。
1。3。8易于部署
软件系统的实施,可以通过适当的系统配置和少量的编程来完成，便于快速实施，可自行开发的数据集成接口
满足现有和未来扩展的需求。
二、体系结构
平台
VIEW
BO
DAO
数据查询
数据操作
界面设计
动态设计
数据映射
SQL脚本
C#脚本

三、软件描述
随着社会的不断进步，其主要功能包括临时车自动发卡机、临时车收费等功能。固定车辆凭一张经授权发行的感应式IC卡,只需在车库入出口读卡控制机上的读卡区内感应一下，便可自由进出泊车。临时车辆进入地下车库时,只需在入口读卡控制机上自动取一张IC卡，便可进入车库停车，出口由电脑自动计费，并进行图象对比,符合“一车一卡”，更加有效的保证车辆的安全。
四、功能模块
4。1计算机管理系统  该系统是整个道闸停车场管理的核心，由计算机、打印机、通讯线路和管理软件组成.主要完成IC卡验证、月卡管理、控制信号的接收和发送、停车时间和停车费的计算、图像的抓拍和显示以及数据统计、打印报表等功能。4。2出入口读卡控制功能  此部分是每个道闸出入口必须的基本功能，也是每个道闸出入口的主要和核心部分.4.3临时卡自动出卡功能  此出卡机双层出卡,方便大小车辆。 临时停车用户在读卡机箱上按“取卡"按钮即可取卡进场停车，此功能也可由道闸管理人员手动发卡代替。自动出卡严格控制一车一卡，无车不能取卡,出卡的同时完成读卡，卡片过时未取自动收回。自动吞卡功能临时卡车辆出场时系统自动回收卡片放行。4。4防砸车感应功能  道闸配合车辆检测器实现防砸车功能，当道闸下有车闸杆不会下落,即便当闸杆下落时有车开到其下面，闸杆也会止落上抬，车辆离开后，闸杆自动下落。同时可结合压力电波安全装置实现双重防砸车保护处理。4.5中文显示功能  出入口控制机箱的LED显示屏全中文显示欢迎词语、收费金额、卡中余额、卡有效期、充值提醒、车位已满以及停车场其他相关信息等。也可以外接独立的显示屏发布相关信息便于车主不同角度远处阅读。4。6语音提示功能   正常操作可提示请读卡、收费元等相关信息，误操作或非法操作作出相应提示。4.7对讲功能  在监控室管理中心安装对讲主机,各出入口安装对讲分机，按对讲按钮即可保证各出入口与监控室管理中心的联络。4.8图象抓拍对比功能  出入口安装摄像机，车辆从道闸入场时自动抓拍车辆的图像并连同持卡人和刷卡时间等信息存入电脑,出场时将系统自动调出持该卡的车入场图像,经出场车辆图像与从道闸入口图象进行对比确认为同一辆车后，才予放行，确保车辆安全。4.9 ups电源
提高供电质量，减少因停电、断的而引起的问题.当市电电网瞬间断电或停电，ups能将蓄电池自动启动，保证道闸系统的正常运行。
4。10防雷功能
为保障道闸系统的正常运行，防止和减少因雷击供电线路、信号线路造成的设备损坏,对道闸系统做好防雷保证设备正常运行。

项目管理软件PROJECT 2021操作实例

Project工具一般用来管理一个项目，制定项目的执行计划。项目的三要素到底是时间，成本和范围.如何使用Project，必须明确如下几项：
A，做什么事？
B,这些事的时间有什么要求？
C，要做的事之间有什么关系？
D，做这些事的人员有谁？
E，人员有特别的时间要求?
下面举一个具体例子，了解一下项目管理软件的操作过程。
项目名称：电石炉主体安装工程
项目的开始日期：2016年2月1日
项目的结束日期：2016年6月11日
日程排定方法：从项目的开始之日起
项目日历：标准日历
工作时间：每周工作7天，每天8小时
项目目标：确保设备按期投产.
可衡量结果:达到业主产量要求。

一、任务清单列表:
大纲级别
任务名称
工期(工作日)
1（摘要）
电石炉主体安装进度计划
90
1.1
机械设备安装
77
1.1。1
安装炉底板
4
1。1.2
安装炉壳体
4
1.1。3
焊接炉壳体
13

安装水分配器及其管路
34
1。1。5
安装炉盖
2

安装水冷密封套
2
1。1.7
安装下料槽
4
1。1。8
安装底部装置
3
1。1。9
安装铜母线
9
1.1。10
安装黄铜管
3

安装电极壳
3
1。1.12
安装电极柱
2
1。1。13
安装下料仓
2

安装下料管
4

安装环形加料机
10
1。1.16
安装炉顶加料皮带
10
1。1.17
。。。。.。。。。。.

1.2
电气安装
57
1.2。1
安装低压配电室电气柜
4
1.2。2
安装中控室电气柜、控制台
5
1.2。3
安装3－4层电气柜
3
1.2。4
安装电缆槽
30
1。2.5
。。。。。.。。。。

1.3
液压安装
29
1.4
调试
27
2
配合投料

3
投产保驾

4
设备验收

5
结束

二、资源可使用情况：
资源名称
最大单位
标准工资率
每次使用成本
成本累算方式
钳工
4
￥4.00/工时

按比例
电工
4
￥5。00/工时

按比例
管工
6
￥10.00/工时

按比例
电焊工
12
￥5。00/工时

按比例
起重工
2
￥150.00/工作日

按比例
力工
42
￥120.00/工作日

按比例
电动葫芦

卷扬机
3

￥20。00

自卸车
1

￥500.00

三、任务之间的相关性：
l 放线→设备机、电、液安装→调试→投产保驾→竣工验收→结束
四、具体操作步骤
（一)、启动阶段
1。新建项目文件
选择文件-新建，点击右下角的创建图标，或安装软件后直接点击文件图标

2.设置项目信息
2.1自定义日历
菜单栏下的项目—更改工作时间，点击此按钮。
将周六、周日设置为工作时间。
在例外日期状态下,输入周末，在开始完成时间中按工程总工期调好，选择右侧的“详细信息”按钮，将非工作日调整成工作日，选择下方的重复发生方式为每周，将周日、周六选上，点确定.项目工作日由5天变为7天。
2.2确定项目信息
项目栏—项目信息——开始日期，调为项目的计划开始日期,如：2016年2月1日

（二)计划阶段
2.1定义资源
视图——资源工作表中，输入资源的基本信息。

2.2建立任务
回到任务栏的甘特图表，输入任务名称中建立任务。使用升级和降级的按钮设定任务级别，形成层次关系,从而展示任务分解结构，完整的项目见下图.
2.3任务信息
双击任务名称，出现任务信息对话框，可调整任务工期、修改任务名称，设置前置任务，建立任务的限制条件、给任务分配资源等功能。

2。4任务相关性
任务的相关性有完成-开始类型FS
开始-完成类型SF
开始-开始类型SS
完成—完成类型FF
FS是最常用的任务相关性类型，是A任务完成后,B任务才能开始。
SF是任务B取决于任务A,A开始之后B才能完成。不要求B任务要在A任务开始时马上完成。如下一个人接到接力棒后，前一个人才能完成任务。
SS是A任务开始之后，B任务才能开始，不要求两个任务同时开始，机械开始之后一段时间，才能进行电气的安装.
FF是A完成之后B才能完成，强调前一个任务完成的必要，后一个任务可以隋朝完成，不要求两个任务同时完成。提出问题和回答问题，回答问题任务要在提出问题之后随时可以完成。

“FS类型 ”SS“类型

“SF”类型“FF"类型

2。5取消任务链接
选择任务栏中的“取消链接任务按钮”.

2.6资源分配
选定一个任务，在资源名称列中，选择所需要的资源。
2.7资源信息
视图-资源工作表，双击资源名称，出现资源信息对话框，调整资源使用时间，资源使用成本。

（三）跟踪阶段
3。1设置比较基准
选中项目开始时间完成时间两列，点击项目项下的设置比较基准按钮，将计划时间设为比较基准1。并插入两列

3。2跟踪完成进度
将实际开始和完成时间调整好，点击视图—跟踪甘特图,可以查看进度的差异。

软件开发管理制度
第一节 总则
第一条 为规范自主软件研发以及外包软件的管理工作，特制定本制度。本制度适用于集团软件研发与管理.
第二条 本制度中软件开发包含新系统开发和现有系统升级改造，此类工作均需要以项目制管理.
第三条 本制度中自主开发是指主要依赖信息中心自身的管理、业务和技术力量进行系统设计、软件开发、集成和相关的技术支持工作；合作开发是信息中心与专业IT 公司（合作商)共同协作完成IT 应用的项目实施和技术支持工作,双方组成开发团队进行项目实施，IT 系统的日常支持由信息中心软件研发部承担；外包开发是指将IT 应用项目的设计、开发、集成、培训等任务承包给某家专业公司（可以是专业的IT 公司或咨询公司等），由该公司(承包商)负责应用项目的实施。
第四条 软件开发遵循项目管理和软件工程的基本原则.项目管理涉及立项管理、项目计划和监控、配置管理、合作开发管理和结项管理。软件工程涉及需求管理、系统设计、系统实现、系统测试、用户接受测试、试运行、系统验收、系统上线。
第五条 除特别指定，本制度中项目组包括业务组（或需求提出组）、开发组(可能包括合作开发商）。
第二节 立项管理
第六条提出项目需求的部门参与立项，信息中心提供立项的技术可行性分析，编写《立项分析报告》（附件一），开展前期筹备工作。《立项分析报告》应明确项目的范围和边界。
第七条 信息中心将《立项分析报告》交相关部门会签后，上交集团总经理进行立项审批，以保证系统项目与集团整体策略相一致。
第八条 《立项分析报告》得到批准后，成立项目组（如果是外包开发，则成立外包商项目组；如果是合作开发，则与外包商共同成立合作开发项目组,以下统称“项目组”），项目组应包括业务组（由信息中心需求管理组和相关业务部门组成）和开发组（自主开发为技术研发部开发组;外包开发为技术研发部指定的开发组长和外包商成员;合作开发为技术研发部开发组指定人员和外包商成员）。信息中心委派一名项目经理负责监督项目的进度，进行项目管理工作,确保开发能及时完成并能满足业务需要。项目组人员的选择应满足项目对业务及技术要求,项目组人员应有足够的业务和IT技术方面的专业知识来胜任项目各方面的工作.
第三节 需求分析
第九条 立项后业务组对单位具体需求进行汇总整理，出具《业务需求说明书》（附件二），并确保《业务需求说明书》中包含了所有的业务需求.经系统使用部门确认，作为业务需求基线。
第十条 业务组在获得《业务需求说明书》后,提出技术需求和解决方案,并对系统进行定义，出具《系统需求规格说明书》（附件三）.《系统需求规格说明书》需详细列出业务对系统的要求（界面、输入、输出、管理功能、安全需求、运作模式、关键指标（KPI)等），最好是采用原型方式表达。《系统需求规格说明书》需要由业务组提交给相关业务部门负责人确认。
第十一条 业务需求发生变更时，业务组应提交《需求变更申请》(附件四），需求部门签字确认，项目经理确认技术方案后交给业务组组长和开发组组长执行。
第十二条 项目组应对需求文档及时更新。
第四节 项目计划和监控
第十三条 软件开发采用项目形式进行管理.项目经理负责整个项目的计划、组织、领导和控制.
第十四条 需求分析过程中，项目经理组织制定详细的《项目计划书》（附件五），包括具体任务描述和项目进度表等。
第十五条 在项目的各个阶段，业务组组长和开发组组长需配合项目经理制定阶段性项目计划.业务组组长和开发组组长需配合项目经理对项目计划执行情况进行监控，确保项目按计划完成。
第十六条 项目计划需要变更时，项目经理填写《项目计划变更说明》（附件六），并提交集团相关领导审批后,交给业务组组长和开发组组长执行.

第五节 系统设计
第十七条 系统设计应分为概要设计和详细设计，系统设计要遵循完备性、一致性、扩展性、可靠性、安全性、可维护性等原则.
第十八条 在系统设计阶段中,需求部门应充分参与，确保系统设计能满足系统需求。
第十九条 项目组进行设计，出具《设计说明书》（附件七）和《单元测试用例》（附件八）。《设计说明书》中需要定义系统输入输出说明和接口设计说明。
第二十条 《设计说明书》以《业务需求说明书》和《系统需求规格说明书》为依据，确保系统设计满足全部需求。
第二十一条 对已确认通过的系统设计进行修改需获得项目经理、业务组组长和开发组组长的审批后方可进行.
第二十二条 对系统设计的修改的文档须由文档管理人员进行归档管理。

第六节 系统实现
第二十三条 开发组根据《设计说明书》制定系统实现计划，并提交项目经理对计划可行性进行审批.
第二十四条 系统实现包括程序编码、单元测试.
第二十五条 开发组保证开发、测试和生产环境独立，为各环境建立访问权限控制机制，并明确项目成员的职责分工。对开发环境、测试环境与生产环境在物理或逻辑方面应该做到隔离；如果环境的分隔是通过逻辑形式实现的,应定期检查网络设置.项目组对已授权访问生产环境的人员进行详细记录,并对该记录进行定期检查，确保只有经授权的人员才能访问到生产环境。

第七节 系统测试和用户测试
第二十六条 测试组制定《系统测试计划》（附件九），并提交项目经理对计划可行性进行审批.
第二十七条 《系统测试计划》必须定义测试标准，并明确各种测试的测试步骤和需要的系统设置要求。
第二十八条 开发组向数据拥有部门申请获取测试用业务数据的使用权，对获取的数据进行严格的访问控制,确保只有相关项目人员才能访问及使用。
第二十九条 开发组负责测试数据准备，测试用数据要足够模拟生产环境中的实际数据。对已评定为敏感信息的数据进行敏感性处理和保护。
第三十条 开发组或合作开发商协助技术研发部测试组建立测试环境进行系统测试.在系统测试中对新系统内部各模块之间的接口和与其他系统的接口进行充分测试。技术研发部测试组出具《系统/用户测试报告》（附件十)，测试人员签字确认测试结果。
第三十一条 系统测试通过后,开发组配合业务组建立用户测试环境，业务组根据用户测试用例进行用户测试，出具《系统/用户测试报告》，业务组组长和开发组组长应在用户测试报告中签字确认.
第三十二条 项目组完成系统帮助文档（其中包括《用户操作手册》和《安装维护手册》)。凡涉及应用系统的变更，应对系统帮助文档及时更新。

第八节 试运行
第三十三条 系统主要应用部门根据项目规模及影响决定试运行策略。
第三十四条 项目组制定《试运行计划》（附件十一）,并制定试运行验收指标，《试运行计划》中应包含问题应对机制，明确问题沟通渠道和职责分工。
第三十五条 项目组联合试运行单位进行相关系统部署工作，准备培训资料，对相关使用人和信息技术人员进行培训。培训的完成度应为实施后评估的指标之一。
第三十六条 项目组根据《试运行计划》进行系统转换和数据迁移.系统转换前,检查系统环境,确保运行环境能满足新应用系统的需要.系统转换时必须详细记录原系统中的重要参数、设置等系统信息，并填写试运行报告相关内容。系统参数、设置的转换工作作为系统上线的验收的评估指标之一。
第三十七条 试运行达到计划规定的终止条件时，项目组编写《试运行报告》(附件十二）。此报告应由项目组和试运行单位签字确认，并提交公司主管领导审阅.公司主管领导审阅试运行结果,决定试运行结束或延期.

第九节 系统验收
第三十八条 系统主要应用部门及技术研发部联合组成独立系统验收小组，也可授权原项目组作为验收小组。验收小组从功能需求及技术需求层面对系统进行综合评估。
第三十九条 验收小组应根据验收情况整理形成《系统验收报告》（附件十三）提交系统主要应用部门和技术研发部审阅。
第四十条 系统主要使用部门和信息中心负责人根据系统测试、试运行情况签署验收意见。
第四十一条 在系统验收通过后,项目组对运维组进行系统维护培训后交付运维组。

第十节 系统上线
第四十二条 系统上线应遵循稳妥、可控、安全的原则。
第四十三条项目组发起《通知公告申请流程（集团）》,填写系统上线内容，得到批准后才能开始部署上线工作。
第四十四条 上线初期需加强日常运行状态监控，出现问题时应及时处理，对重大问题应启动紧急预案。
第四十五条 上线单位管理层要对《系统验收报告》进行审批签字。
第四十六条 集团相关领导批准结项后,业务组和开发组将整理的系统文档提交各自部门统一管理.

第十一节 合作开发管理
第四十七条 合作开发商的选择应遵循集团相关规定.
第四十八条 合作开发商必须遵循信息中心《软件开发管理制度》。
第四十九条 项目经理同合作开发商明确规定项目变更的范围和处理方式,重点关注需求和设计变更。
第五十条 项目经理负责监控合作开发商的项目管理及软件开发活动.合作开发商应按计划定期向项目经理报告进展状态，并提交阶段性成果文档。发生重大问题时，合作开发商需及时向项目经理汇报。
第五十一条 开发组组长派专人监控合作开发商的质量保证过程。
第五十二条 项目组同合作开发商商定验收的标准和方法。
第五十三条 以上各要求需要在开发合同中明确。

第十二节 外包开发管理
第五十四条 立项申请得到集团领导的审批后，选定开发商，签订外包开发合同。
第五十五条 项目经理负责监控外包开发商的项目管理及软件开发活动。外包开发商应按计划定期向项目经理报告进展状态，并提交阶段性成果文档。发生重大问题时，外包开发商需及时向项目经理汇报。
第五十六条 项目经理监控外包开发商的质量保证过程。
第五十七条 项目组同外包开发商商定验收的标准和方法。
第五十八条 以上各要求需要在开发合同中明确。

第十三节 附则
第五十九条 本制度由信息中心负责解释和修订。
第六十条 本制度自发布之日起开始执行。

附件一 立项分析报告
文件状态:
[√］ 草稿
［ ］ 正式发布
[ ］ 正在修改
文件标识：
ProjectName-
当前版本：
X.Y
作 者:

完成日期：
Year—Month—Day

版 本 历 史
版本/状态
作者
参与者
起止日期
备注

1. 项目介绍
1.1. 项目目的
提示：用简练的语言说明本项目“是什么”，“实现什么目的”。描述简练且清晰。
1.2. 项目背景
提示：阐述项目背景，重点说明“为什么”会提出本项目.
（1）公司的短期、长期发展战略;
（2）业务需求及发展趋势；
（3)技术状况及发展趋势；
(4）特殊的业务需求等。
1.3. 项目范围
提示：根据对现有需求的了解来确定项目基本范围，说明本系统“应当包含的内容”和“不包含的内容”。
2. 项目计划
2.1. 项目团队
提示:说明项目团队的角色、知识技能要求、建议人选、人数、工作时间，如下表所示。
角色
知识技能要求
建议人选、人数
工作时间
项目经理

需求开发人员

系统设计人员

编程人员

测试人员

维护人员

……

2.2. 成本估计
内容
成本（人民币)
备注
人力资源

软硬件资源

…

2.3. 进度表
提示：制定项目开发的进度表（建议给出项目里程碑计划）.例如：
编号
里程碑名称
预计结束时间
备注

需求调研完成

项目计划完成

需求分析完成

概要设计完成

详细设计完成

实现完成

集成测试完成

系统测试完成

验收测试完成

试运行结束

项目验收

3. 总结
提示:给出清晰的建议结论，便于集团领导决策。
附件二 业务需求说明书
文件状态：
［√］ 草稿
[ ] 正式发布
［ ] 正在修改
文件标识：
ProjectName-
当前版本：
X。Y
作 者:

完成日期：
Year-Month—Day

版 本 历 史
版本/状态
作者
参与者
起止日期
备注

1概述
1。1 业务调研人员名单
【可选】
序号
职能部门
姓名
主管
联系
备注

1。2业务范围
此处描写总体业务的概要分类。
1。3 业务目标
从集团利益的角度提出本业务系统的期望目标，以及评价标准。
1。4 相关文档
说明：列出本文档的所有参考文献（可以是非正式出版物)，包括现有规范、标准、批文、引用到的文件、资料等。
1。5 业务词汇表
说明：列出本文档的所引用的专属领域词汇、术语等，以便于业务需求的提供者和接收者是建立在一致的业务理解基础之上的。
2 组织结构及业务
2.1 业务相关组织结构、人员组织结构
说明:如果单位岗位设置复杂可分别设置，业务组织结构和人员组织结构
2.2 组织机构描述
2.3 角色职责
说明：将业务涉及的具体人员进行一定程度的分类和抽象，描述该抽象角色的操作职责。
2。4 管理综述
【可选】
说明：主要描述该业务的管理特点和管理模式。例如：
典型按库存生产模式。生产计划以年度销售计划为指导，并综合考虑设备能力、生产天数、库存、历史销售记录。采购计划的制订以生产计划为依据.
2.5 现有业务流程清单
【可选】
说明：现有业务流程需要考虑，很多新的业务是在已有业务流程基础上进行重组的。
流程编号
流程名称
责任部门
辅助部门

3 业务流程及业务处理描述
说明:针对每一项具体的目标业务，描述具体的业务流程,以及相关业务的具体描述.
3.1 具体业务流程（系统名称+编号）
对于具体业务流程的命名有规范，对具体流程进行编号，便于形成需求矩阵,同时形成需求的管理和跟踪。
3。1。1业务流程
3。1.2业务描述
说明:描述具体的业务流程。
3.1。3相关业务对象
说明:业务对象：业务流程中涉及的单据、报表等.
业务对象
使用部门
对应电子档案编号

3。1.4业务规则及关键算法
说明：描述业务环节关键算法体系。
4 假定和约束
说明：列出进行本软件开发工作的假定和约束，例如开发期限等。
4.1 运行环境约束
4。2 设计约束
【可选】
说明：开发过程中必须使用的软件语言、软件进程需求、主要开发工具、核心技术、第三方产品等.
4.3 产品应当遵循的标准或规范
【可选】
说明：阐述本产品应当遵循什么标准、规范或业务规则,违反标准、规范或业务规则的产品通常不太可能被接受。
5 其他
5.1 目前核心问题和困难
5。2 业务对项目实施的需求和期望
【可选】
5。3 其他未尽事宜

附件三 系统需求规格说明书
文件状态：
[√］ 草稿
[ ］ 正式发布
［ ] 正在修改
文件标识：
ProjectName—
当前版本:
X。Y
作 者：

完成日期：
Year-Month—Day

版 本 历 史
版本/状态
作者
参与者
起止日期
备注

1 引言
1.1 目的
例如：规定系统的边界和目标,描述系统的功能性需求和非功能性需求。
1.2读者对象及阅读建议
说明：指明本文档面向的读者群,及相应的阅读意见。
1.3文档范围
【可选】
说明:对本文的范围做阐述，本文档改动时，受到影响的范围,例如，本文引用到的用例模型，系统原型，系统测试用例等文档。
1。4 参考文档
说明:列出本文档的所有参考文献(可以是非正式出版物),包括计划任务书、合同、批文、引用到的文件、资料及软件开发标准等.
1。5 术语与缩写解释
说明：列出本文件中用到的专门术语的定义和缩写词的原词组,并给予解释,以便于所有读者达成共识。
2 综合描述
2.1 系统背景
【可选】
说明：介绍系统的预期效果、历史原因。
2。2 问题说明
【可选】
提供一段说明,总结此项目需要解决的问题.可以采用以下格式:
问题是
[对问题进行说明]
影响
［问题的影响］
问题的后果
[该问题会导致什么后果]
成功的解决方案
［应列出成功解决方案的一些主要优点]
2。3系统范围
说明:阐述本项目“适用的业务范围”和“不适用的业务范围”,本产品“应当包含的内容"和“不包含的内容"。说清楚系统范围的好处是：(1）有助于判断什么是需求，什么不是需求；(2）可以将开发精力集中在需求范围之内；（3）有助于控制需求的变更。
l 完整而准确的定义本产品的相关人员；
l 明确本产品所影响到的部门和业务；
l 用图表或者文字描述产品的范围，概要的定义产品的功能。
2。4 干系人与用户说明
【可选】
2.4。1用户环境
【可选】
详细说明目标用户的工作环境。以下是几项建议：
该任务由多少人来完成？是否总在变化？
一个任务周期需要多长时间?执行每项活动要用多长时间？是否总在变化?
是否有特殊的环境约束：移动、户外、乘机旅行等？
目前使用的是哪些系统平台?以后会使用哪些平台?
还在使用哪些应用程序?您的应用程序是否需要和这些应用程序集成？
在此处可以从业务模型中摘录一些内容来概述所涉及的任务和角色等等.
2.4。2 干系人简档
【可选】
通过在下表中填写各干系人的相关信息来说明系统中的各个干系人，详尽的简档应包括各种干系人在以下方面的信息：
代表
［谁是此产品的干系人代表？(如在他处已作记录，则此处为可选。）此处只需填写姓名。］
说明
[对干系人类型的简要说明.］
类型
［介绍干系人的技能特长、技术背景和熟练程度（即权威用户、业务用户、专家用户、初级用户等）］
职责
［列出干系人对所开发的系统负有的关键职责,即他们作为干系人的利益。］
使用频率
[该干系人使用系统的频率］
意见/问题
[在此处列出会阻碍成功的问题以及任何其他相关信息。］

2。4。3关键的干系人/用户需要
列出干系人认为现有解决方案存在的关键问题。对于列出的每个问题，需澄清以下要点：
•为什么会出现这一问题？
•目前如何解决该问题?
•干系人需要什么样的解决方案？
务必要了解干系人或用户对解决各个问题的相对重视程度。分级和累积投票方法表明,必须解决的问题与干系人或用户希望解决的问题大有不同。
2.5 目标业务模型
【可选】
说明:新系统业务模型描述，如有相应业务模型材料了,可作为需求规格说明书的输入参考资料。
2。6 功能摘要
总结该产品将提供的主要优点和特性,而不必涉及每个功能的细节.对功能加以组织，使客户或初次阅读该文档的其他人能够理解此功能列表。
2.7 功能清单及重要程度说明
说明：功能名称、功能描述、重要程度。
重要程度，以ABC三类来表示:A：核心功能；B：辅助功能；C：外围功能；
级别，按照继承关系分为：一级，二级,三级;
编号
级别
重要程度
功能名称
功能描述
备注

2.8 功能与业务对照关系表
说明:业务组为主编写业务需求，业务需求提交至信息技术组后,由信息技术组建立目标系统业务模型并与业务组进行确认（本操作可选，也可由信息技术组与开发商合作建立），目标业务模型作为系统需求的输入，由信息技术组与开发商合作撰写和评审《系统需求规格书明书》。
业务需求
目标系统业务活动(可选）
功能名称

2.9 假定和约束
说明：列出进行本软件开发工作的假定和约束，例如：开发语言、开发期限等。
格式限制说明:本项将指定由现有的标准或规则派生的要求。例如：
报表格式；数据命名；财务处理；审计追踪，等等。
硬件限制说明：本项包括在各种硬件约束下运行的软件要求，例如,应该包括：
硬件配置的特点（接口数，指令系统等）；内存储器和辅助存储器的容量。
2.9.1运行环境约束
说明：硬件设备、支持软件、接口、控制等方面的约束
名称
详细要求

2。9。2设计约束
【可选】
说明：开发过程中必须使用的软件语言、软件进程需求、主要开发工具、核心技术、第三方产品等.
2。9.3产品应当遵循的标准或规范
说明：阐述本产品应当遵循什么标准、规范或业务规则，违反标准、规范或业务规则的产品通常不太可能被接受。
3 具体需求
3.1功能需求
3。1.1具体功能
3。1。1。1内容
说明:对于每一类功能或者有时对于每一个功能，需要具体描述其输入、加工和输出的需求。
3.2 非功能需求
3。2.1 外部接口
3.2。1。1用户接口
说明：提供用户使用软件产品时的接口需求.例如，如果系统的用户通过显示终端进行操作,就必须指定如下要求:
a对屏幕格式的要求
说明:对界面上的各对象、类型、宽度、取值范围、数据来源、能否为空等属性进行描述。
b报表或菜单的页面打印格式和内容
c输入输出的需求
说明：解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等.对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述.
d程序功能键的可用性
说明：快捷键定义等。
3。2.1。2 硬件接口
【可选】
说明:要指出软件产品和系统硬部件之间每一个接口的逻辑特点。还可能包括如下事宜：支撑什么样的设备，如何支撑这些设备，有何约定。
3。2。1。3软件接口
【可选】
说明：在此要指定需使用的其他软件产品（例如，数据管理系统、操作系统或数学软件包)，以及同其他应用系统之间的接口。对每一个所需的软件产品，要提供如下内容：名字、助记符、规格说明号、版本号、来源。
对于每一个接口，这部分应说明与软件产品相关的接口软件的目的，并根据信息的内容和格式定义接口，但不必详细描述任何已有完整文件的接口,只要引用定义该接口的文件即可。
【接口定义】
下表是对一些接口的具体描述:
接口名称

接口描述
填写接口完成的任务
接口类型
填写是输入接口(inbound）还是输出接口（outbound）
源系统
填写接口输入方系统或部件
目标系统
填写接口输出方系统或部件
厂商提供/客户化开发

文件类型
填写文件类型;若通过数据库表来交互，请指明数据库及表名
文件数量

峰值数据量

频度
填写数据处理的频度
复杂度

批处理 /人工
填写接口数据的驱动模式是人工（manual）还是自动(automatic），还是都支持
接口类型
填写是实时接口还是批量接口等

【其他系统详细信息】
说明:列出所有与接口交互的外围系统的详细信息。包括输入、输出系统等
系统
填写与接口交互的系统名称
系统类型
填写是接口的数据源系统（source)还是目标系统(object）
数据库
填写交互系统使用的数据库及版本
软件
填写交互系统的软件名称
架构类型
交互系统的架构类型是B/S 还是C/S.
位置
填写该软件在交互软件体系中所出的位置
技术支持
填写交互系统的开发商和支持商
功能支持
填写具体的支持商或技术团队
数据归属

【接口隶属系统的详细信息［可选] 】
系统
填写接口隶属系统的名称
模块
隶属于具体的模块名称
数据库
隶属系统的数据库及版本
负责人

控制报告

【接口配置】
(1）接口基础信息配置
说明：接口基础信息的配置项目，描述配置的方式。
（2）接口运行参数配置
说明：接口运行参数的配置方式和步骤。
【其他配置［可选] 】
说明