系统需求和需求分析说明书
文件状态：
[ ] 草稿[√] 正式发布[ ] 正在修改文件标识
当前版本房屋租赁管理系统1.0 作者王延翔
完成日期2011-06-11
版本历史
版本/状态修订人修改日期备注
房屋租赁管理系统1.0 王延翔2011-06-11 正式发布
第一部分概述
1.1项目名称及背景
项目名称
房屋租赁管理系统
开发背景
为了更好的方便房源管理者对房屋租赁信息的管理，我们开发了房屋租赁管理系统。它主要包括：管理员登录、房屋信息与房屋租赁记录三大模块。
1.2文档说明
本规格说明描述了房屋租赁管理系统的要求，详细列出了系统中各个环节的功能以及各个环节之间紧密的练习，并且作为各方面沟通的依据，也为下一步项目开发提供基准。软件开发小组的每一位成员应该阅读本需求说明，以明确项目最后要求完成的软件产品的特点。
1.3术语与缩写解释
缩写、术语及符号解释
RoomRent 房屋租赁
Login 登录
Room 房间
Rent 租赁
Add 添加
Update 修改
Query 查询
Delete 删除
第二部分任务说明
2.1功能概述
2.1.1管理员登陆
2.1.1.1功能描述
在登录页面，输入用户名、密码，实现登录功能。
2.1.1.2数据项描述
?用户名：必填项，由字母、数字组成，最长20个字符；
?密码：必填项，由字母、数字组成，最长20个字符；
2.1.2房屋信息
房屋信息主要是对房间的信息进行管理，包括对房间信息的添加、修改、删除、查询功能。
添加房屋信息
对房价信息进行添加，并对必要的字段进行数据校验；
?roomNo(房间编号)：必填项，由字母、数字、中划线组成，最长20
个字符，格式如：ROOM-0001；
?roomName(房间名称)：必填项，最长40个字符；
?direction(房间方位)：必填项，最长20个字符；
?roomType(房间用途)：必填项，最长20个字符；
?state(房间状态)：必填项，默认值为“空置”，最长20个字符；
?remark(备注)：非必填项，最长100个字符；
修改房屋信息
对添加的房屋信息进行修改，区分可修改字段与不可修改字段；
?roomNo(房间编号)、roomName(房间名称) 、direction(房间方位)三
个字段不可以修改；
?roomType(房间用途)、state(房间状态)、remark(备注) 三个字段可以
修改；
查询房屋信息
将所有房屋以列表的形式展示出来，查询不带任何条件；
删除房屋信息
可以删除任意选中的房屋信息记录，若该房屋处于“出租”状态，则不
可以删除该房屋信息记录；
2.1.3房屋租赁记录
房屋租赁记录主要是对房间进行租赁，包括对房间租赁记录的添加、修改、删除、查询功能。
添加房屋租赁记录
对房屋租赁记录进行添加，并对必要的字段进行数据校验；
?contractNo(合同编号)：必填项，由字母、数字组成，最长20个字符，
格式如：C-0001；
?contractName(合同名称)：必填项，最长20个字符；
?roomId(房间Id)：必填项，roomId对应的房间名称；
?startTime(合同起始时间)：必填项，日期类型；
?endTime(合同终止时间)：必填项，日期类型；
?contractState(合同状态)：必填项，默认值为“正常”，最长10个字
符；
?remark(备注)：非必填项，最长100个字符；
修改房屋租赁记录
对添加的房屋租赁记录进行修改，区分可修改字段与不可修改字段；
?contractNo(合同编号)、contractName(合同名称)、roomId(房间Id)、
startTime(合同起始时间)、endTime(合同终止时间)五个字段不可以
修改；
?contractState(合同状态)、remark(备注)两个字段可以修改；
查询房屋租赁记录
将所有的房屋租赁记录以列表的形式展示出来，查询不带任何条件；
删除房屋租赁记录
可以删除任意选中的房屋租赁记录；
2.2用户环境
MyEclipse 6.5；SQL Server 2005；Tomcat6.0.30；JDK1.6。
2.3其他要求
无
第三部分需求分析
3.1实现功能
系统用例图
添加房间信息
修改房间信息
查看房间信息
删除房间信息
登录
房间管理管理
添加租赁记录
删除租赁记录
查看租赁记录
修改租赁记录
管理员租赁记录管理
图3-1系统用例图
功能清单 功能编号
功能名称 文中标题编号
备注
ROOM
房间管理 ROOM_ADD_101 添加房间信息
ROOM_UPDATE_102 修改房间信息 ROOM_DELETE_103 删除房间信息 ROOM_QUERY_104 查看房间信息 RENT
租赁记录管理 RENT_ADD_101 添加租赁记录 RENT_UPDA TE_102 修改租赁记录 RENT_ DELETE_103
删除租赁记录
RENT_QUERY_104 查看租赁记录
3.2用例说明
[用例1]
●用例图
添加房间信息
修改房间信息
房间管理
查看房间信息
删除房间信息
图3-2房间管理用例图
●描述
房间管理主要对房间信息进行添加、删除、修改、查看操作。
●参与者
管理员
[用例2]
●用例图
添加租赁记录
删除租赁记录
查看租赁记录
修改租赁记录
租赁记录管理
图3-3租赁记录管理用例图
●
描述
租赁记录管理对房间租赁记录进行添加、修改、删除、查看操作。
●
参与者
管理员
3.3 数据库设计
用户表(T_USER)
序号 别名 中文名 类型
是否
主键
是否
为空 外建表
备注
1 id 主键 Int Y N 自动增长
2 user_name 用户名 varchar(20) N N 数据唯一
3 user_psd 密码 varchar(20) N N 4
remark
备注
varchar(100)
N
Y
房间表 (T_ROOM)
序号 别名 中文名 类型
是否
主键
是否
为空 外建表
备注 1
id
主键
int
Y
N
自动增长
2 roomNo 房间编号vrchar(20) N N 数据唯一
3 roomName 房间名称varchar(20) N N
4 direction 房间方位varchar(20) N N
5 roomType 房间用途varchar(20) N N
6 state 房间状态varchar(20) N N 默认值“空置”
7 remark 备注V archar(100) N Y
租赁表(T_RENT)
序号别名中文名类型
是否
主键是否
为空
外建表备注
1 id 主键int Y N 自动增长
2 contractNo 合同编号varchar(20) N N 数据唯一
3
contractNa
me
合同名称varchar(40) N N
4 roomId 房间Id int N N T_ROOM
关联T_ROOM
表的id
5 startTime
合同起始
时间
datetime N N
6 endTime
合同终止
时间
datetime N N
7
contractStat
e
合同状态varchar(10) N N 默认值“正常”
8 remark 备注varchar(100) N Y
1. 引言 1.1编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体. 1.2项目背景 1.2.1项目委托单位:****公司 1.2.2开发单位:***公司 1.3定义 1.4参考资料 2. 任务概述 2.1目标: <1> 决策支持:根据公司的要求及时提供所需报表及文件,并在适当时候对各部门领导给予销售及进货等方面的提示 <2>提高效率:利用软件进行管理,避免人工管理的失误以及延迟性,从而实现高效率的管理. 2.2运行环境: <1> 硬件方面:Pentium级处理芯片 1兆显存的兼容显卡 256色,1024*768的兼容显示器 标准兼容打印机 <2>软件方面: WIN XP操作系统 2.3条件与限制: 编程用计算机一台 完成期限2000/7/1 无资金供给 3. 数据概述 数据流程图如下:
3.1静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据3.2 动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间3.3数据库描述: 人事管理数据库:公司内人员的个人详细信息,包括档案信息 3.4 数据字典: <1>数据流词条描述: 1.数据流名:登录信息 来源:用户的输入 去向:系统内部检验部分 组成:用户名,密码 流通量:每次登录输入一次 2.数据流名:登录结果 来源:系统 去向:用户 组成:返回信息 流通量:每次登录返回一次 3.数据流名:输入修改信息 来源:用户 去向:系统判断部分 组成:根据各数据库内容而不同 流通量:依用户输入而定 4.数据流名:反馈信息 来源:系统判断部分 去向:用户 组成:系统经判断后发回的字符数据 流通量: 依系统当前信息而定 5.数据流名:识别信息 来源:系统内部检验部分 去向:系统判断部分 组成:系统各数据库的标识信息 流通量:用户每次输入流通一次 6.数据流名:处理信息 来源:系统判断部分
租赁房屋管理制度 为加强公司房屋租赁的管理，发挥房屋资产的最大效益，特制定本制度。 第一条适用范围：公司所属范围内的所有房屋租赁业务。 第二条出租房屋的条件：闲置房屋或公司经营的预期收益小于外租收益；出租的房屋不能影响公司的总体规划和有损公司的经济效益。 第三条对承租方的条件要求：宿舍区内的房屋应能够为居民提供服务，方便职工生活。 第四条对外租赁房屋的管理部门，除公司经理的特别授权外，任何单位和个人不得以任何理由对本单位的房屋进行出租。 第五条房屋出租收益列入单位收入；任何单位和个人不得利用租赁机会，从中私自获利，一经查出，按所获非法收入3—5倍罚款。 第六条房屋出租时，必须认真查验承租户主的身份证原件，并要求提供证明承租单位存续性的有关资料。承租人为个人的，须留存身份证复印件备案。承租人为单位的，须留存营业执照复印件备案。同时房屋出租时原则上需要收取一
定额度的风险金。 第七条单位所有临街门面不需要使用的，可以租赁给他人使用，经营范围以承租方营业执照为准。 第八条门面租赁每次合同期限最长不能超过3年，如需要超过3年，应当报经理办公会研究决定。 第九条单位出租房产或卖场柜台应有明确的月租金标准，出租单位应保证出租房产租金标准不低于同地段相当条件的市场平均租金。 第十条月租金确定后，出租单位不得随意降低标准，确因市场发生变法需要下调标准的，必须书面报公司经理批准。 第十一条租赁合同的签订：公司各单位对外签订的租赁合同必须严格按照公司固定格式《房屋租赁合同》文本签订（一式三份，公司两份），否则造成的一切责任，由本单位负责。 第十二条租赁期限：除非对公司非常有利，房屋租赁期限一般不超过三年。如遇特殊情况需报请公司经理批准后，方可签订长期租赁合同。 第十三条合同的提前解除。公司或承租方如果提前解除合同，需提前以书面形式报告，经同意后提前一个月通知对方，对方提出解除合同，应写明理由，按照合同约定的条件进行，解除后立即注销原合同。
酒店管理系统 需求说明书 [V1.0(版本号)] 拟制人田纯明 审核人______________________ 批准人______________________ [二零一四年三月二十八日]
酒店管理系统 需求说明书 1．引言 1.1 编写的目的 本文档是针对酒店管理系统而编写的，文档中将会对软件系统的开发需求进行详细的分析，主要包括系统的需求分析、功能划分、数据库中数据项的描述与设计等等。文档详尽说明了这一软件产品的需求和规格，这些规格说明是进行设计的基础，也是编写测试用例和进行系统测试的主要依据。同时，该文档也是用户确定软件功能需求的主要依据。 1.2 预期读者 本文档面向多种读者对象： （1）项目经理：项目经理可以根据该文档了解预期产品的功能，并据此进行系统设计。 （2）设计员：对需求进行分析，并设计出系统，包括数据库的设计。 （3）程序员：配合《酒店管理系统设计报告》，了解系统功能，编写《酒店管理系统用户手册》。 （4）测试员：根据本文档对软件产品进行功能性测试和非功能性测试。 （5）销售人员：了解预期产品的功能和性能。 （6）用户：了解预期产品的功能和性能，并与分析人员一起对整个需求进行讨论和协商。 （7）其他人员：如部门领导、公司领导等可以据此了解产品的功能和性能。 在阅读本文档时，首先要了解产品的功能概貌，然后可以根据自身的需要对每一功能进行适当的了解。 1.3 背景 开发的软件系统的名称：酒店管理系统 项目的任务提出者：软件工程酒店管理系统设计小组 项目的任务开发者：软件工程酒店管理系统开发小组 项目的用户：进行酒店管理业务的相关行业 本系统为管理者提供了完整的管理平台，具体功能包括用户管理、客房类型管理、房间信息管理（房间号、房间类型、价格和位置等）以及对房间的经营管理（订房、退房等）。此外，为了方便对整个系统中的数据进行查找，系统为管理员提供了相对完善的查询功能，可以迅速地定位到客户的信息和客房的使用情况。 1.4 参考资料 1、殷锋,《软件工程》，天津科学技术出版社,2011.5 2、王珊、萨师煊，《数据库系统概论（第4版）》，高等教育出版社，2006.5 3、沈士根、汪承焱、许小东，《Web程序设计https://www.doczj.com/doc/585170204.html,使用网站开发》，清华大学出版
软件需求规格说明书集团文件版本号：（M928-T898-M248-WU2669-I2896-DQ586-M1988）
软件需求规格说明书模版
文件变化记录单 *变化状态：A——增加，M——修改，D——删除 文件批准单
1.引言 提出对软件需求规格说明书的纵览，帮助读者理解文档如何编写并且如何阅读和解释。 1.1编写目的 对产品（也可能是项目，但是我们统称为产品）进行定义，在该文档中详尽说明这个产品的软件需求，包括修正或发行版本号。如果这个软件需求规格说明书只与整个系统的一部分有关，那么只定义文档中说明的部分或子系统。 1.2文档约定 描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。例如，说明高层需求的优先级是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有优先级。 1.3预期的读者和阅读建议 列举软件需求规格说明书所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员等。描述文档中剩余部分的内容及其组织结构。提出最适合每一类型读者阅读文档的建议。 1.4产品的范围 提供对指定的软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目范围文档，而不是将其内容复制到这里。 1.5参考资料 列举编写软件需求规格说明书时所参考的资料或其它来源。可能包括用户界面风格指导、合同、标准、系统需求规格说明书、用户需求、相关产品的软件需求规格说明书。这
里应该给出详细的信息，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。 2.综合描述 这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。 2.1产品的前景 描述软件需求规格说明书中所定义的产品的背景和起源。说明该产品是否是产品系列中的下一个成员，是否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品，或者是否是一个全新的产品。 如果软件需求规格说明书定义了大系统的一个组成部分，那么就要说明这部分软件是怎样与整个系统相关联的，并且要定义出两者之间的接口。建议使用系统结构图或者实体关系图表示。 2.2产品的功能 概述产品所具有的主要功能，详细内容在第4节描述，所以这里只需要概括总结，例如用列表的方法给出。很好地组织产品的功能，使每个读者都易于理解。用图形表示主要的需求分组以及它们之间的联系。 建议使用数据流程图（DFD）的顶层图或功能层次图来实现图形化。 2.3用户类和特征 确定可能使用该产品的不同用户类并描述它们相关的特征。有一些需求可能只与特定的用户类相关。将该产品的重要用户类与那些不太重要的用户类区分开。 2.4运行环境
厦漳大桥养护管理系统 V1.0 软件需求说明书 二〇一七年七月 2017.07
修改记录
目录
第一章引言 1.1编写目的 本文档作为甲乙双方就厦漳大桥养护管理系统需求理解达成一致共识的基础文件，作为双方界定项目范围、签定合同的主要基础，也作为本项目验收的主要依据。同时，本文档也作为后继工作开展的基础，供双方项目主管负责人、项目经理、技术开发人员、测试人员等理解需求之用。 1.2适用范围 本文档适用于所有与本项目有关的软件开发阶段及其相关人员，其中：项目负责人、公司方项目经理、技术开发人员（包括分析人员、设计人员、程序人员）、测试人员应重点阅读本文档各部分，其他人员可选择性阅读本文档。 1.3文档概述 本文档主要描述了厦漳大桥养护管理系统的软件需求。 本文档首先从业务背景、系统功能、运行环境等方面概要描述系统，其次从软件接口等方面描述系统的外部接口需求，然后进一步详细描述功能性需求和非功能性需求以及待确定的问题。 1.4参考资料 甲方提供的原型图、需求资料、项目背景资料等。 1.5业务背景 厦漳跨海大桥2013年5月28日正式投入运营，工程起点在主线K1+065处与厦门至成都国家高速公路海沧枢纽立交相接，途经青礁村、海门岛，止于漳州龙海市沙坛村后宅处，终点里程桩号K10+400.390，与招银疏港高速公路相连。路线长度为9335.390m，其中桥梁长度为8669.9m。大桥工程主要包括北汊桥、海门岛立交及收费服务区、南汊桥、海平互通立交等几个部分，双向6车道，设计时速100km/h。 全桥共打下桩基1441根、墩身322座、主塔4座，共296根斜拉索，用材11.5万吨钢筋、 68.7万立方米混凝土。能抗14级台风和7度地震。北汊主桥为连续半漂浮体系双塔双索面斜拉桥，主跨780m，可满足3万吨级船舶安全通航，在同类型桥梁中居全国第六、世界第
文件编号： 受控状态：■受控□非受控 保密级别：■公司级□部门级□项目级□普通级 记录编号： 分发编号： xxx公司云平台 需求规格说明书 Version 1.0 2014.07.23
需求规格说明书模板
目录 1前言 (4) 1.1编写目的 (4) 1.2文档约定 (4) 1.3读者对象 (4) 1.4术语和缩略词 (5) 1.5参考文档 (5) 2项目概述 (5) 2.1项目背景 (5) 2.2项目目标 (5) 2.3需求范围 (6) 2.4总体框架 (6) 2.5组织机构 (6) 2.6用户特点 (6) 2.7设计约束 (6) 3功能性需求 (6) 3.1总体流程 (6) 3.2角色定义 (7) 3.3系统功能 (7) 3.4功能描述 (7) 4非功能性需求 (11) 4.1软件需求 (11) 4.2硬件需求 (12) 5外围系统和接口 (13) 5.1系统A (13) 5.2系统B (13) 6其他需求 (14) 7数据字典 (14) 8附件 (14)
1 前言 1.1 编写目的 [说明编写这份需求规格说明书的目的，指出预期的读者（一般包括评审人员、软件设计人员、软件开发人员，针对具体情况，还可能包括客户），它是软件开发的基础。] 1.2 文档约定 [描述编写文档时所采用的字体标准或排版约定，包括标题和正文的字体和字号约定。完成文档编写后，文档编写完成后本部分须裁剪] 字体大小约定： 标题1 宋体三号加粗 标题2 宋体小三号加粗 标题3 宋体四号加粗 标题4 宋体小四号加粗 标题5 宋体小四号 正文宋体五号 段落约定：文章中每段落需抬头，即段落开头需有两字元的缩排，单倍行距。 表与图编号约定：文中所有表、图须按章节编号，如：第四章节第二个表，编号为：表4-2。裁剪约定：如标注可裁剪提示信息，表示该部分内容可以裁剪或删除。 1.3 读者对象 [描述本需求规格说明书的主要读者。建议将不同读者的阅读重点与建议以列表方式表现，]
房屋出租管理制度 为加强房屋租赁管理，保护房屋租赁当事人的合法权益，维护社会治安秩序，根据中共中央、国务院、全国人大常务会《关于加强社会治安综合治理的决定》、《中华人民共和国城市房地产管理法》和公安部《关于租赁房屋治安管理规定》及有关法律、法规，结合本辖区实际，制定本制度。 1、租赁房屋是指旅馆业以外的、以营利为目的、公民私有和单位所有出租用于他人居住的房屋。 2、房屋租赁实行属地管理的原则，“谁主管谁负责，谁租赁谁负责”。 3、房地产管理部门负责住宅和非住宅房屋的租赁登记备案；公安机关负责租赁房屋的治安管理。 4、房屋租赁管理实行租赁许可证制度。房屋出租持房地产管理部门核发的《房屋租赁证》到公安机关办理《租赁房屋暂住管理许可证》后，方可从事租赁活动。 5、房屋租赁人应当与房屋所在地的公安派出所签订治安责任保证书。 6、私有房屋出租的出租人必须持房屋所有权或其他合法证明、居民身份证、户口本到辖区派出所进行登记。 7、不准将房屋出租给无合法有效证件的承祖人。 8、与承租人签订租赁合同，承租人是外来暂住人员的，应当带领其到辖区派出所申报暂住户口登记，并办理暂住证。 9、对承祖人的姓名、性别、年龄、常住户口所在地、职业或者主要经济来源、服务处所在地等情况进行登记。 10、发现承租人有违法犯罪活动或者有违法犯罪嫌疑的，应当及时报告公安机关。 11、出租的房屋不准用于生产、储存、经常易燃、易爆有毒等危害物品。 12、出租房屋的出租人与承租人应配合社区和上级部门组织的稽查、查验。社区对暂住人口进行日常规范管理，对出租房屋的出租人与承租人经常开展安全防范、法制教育。 13、社区要随时掌握辖区内出租房屋情况，每月核查一遍，认真做好登记工作，积极协助派出所民警对出租房屋每季度清查一次。
教学管理信息系统需求规格说明书
1.引言 1.1编写目的 1.2项目背景 1.3定义 1.4参考资料 2.任务概述 2.1目标 2.1.1理念目标 2.1.2功能目标 2.2运行环境 2.3条件与限制 2.3.1技术限制 2.3.2使用限制 3.数据描述 3.1静态数据 3.2动态数据 3.3数据库介绍 3.4数据字典 3.4.1数据流词条描述 3.4.2数据文件词条描述 3.4.3加工逻辑词条描述 3.4.4源点及汇点词条描述 4.功能需求 4.1功能划分 4.2功能描述 5.性能需求 5.1数据精确度 5.2时间特性 5.3适应性 6.运行需求 6.1硬件接口 6.2软件接口 6.3故障处理 7.其它需求
1.引言 1.1编写目的 本软件需求规格说明书是系统分析人员与用户进行了大量的交流后写成的，比较全面的描述了用户的各种需求。该文档确定了待开发软件的功能、性能、数据、界面等要求，并确定了系统的逻辑结构。为今后的开发人员进行系统开发提供了依据，也为项目经理、设计人员、营销人员、用户、测试文档的编写人员提供了参考。 1.2项目背景 项目名称：教学管理信息系统 项目任务提出者：齐鲁工业大学 项目开发者：张云、张丽梅、邓蓓蓓、陈瑞红、林慧萍、郑惠 项目用户：齐鲁工业大学所有管理人员和学生 随着学校教育水平的不断提高，学校规模不断扩大，传统的C/S结构的信息管理软件已经远远不能够满足学校的需求，已经成为学校进一步发展的瓶颈。经总结，这类信息系统存在如下的缺陷：①软件维护的费用高。②信息查询不方便。③不利与远程管理。④软件的可操作性不高。 为了眤补这些缺陷，消除影响进一步发展的瓶颈，降低学校的信息软件维护成本，进一步方便学生使用，方便教职工管理，我们项目组决定在这次软件开发过程中，开发基于B/S架构的教学管理信息系统。 1.3 定义 JavaWeb：是用Java技术来解决相关Web互联网邻域的技术总和 MySQL：MySQL是一个小型关系型数据库管理系统 MVC：模型，视图和控制。目的是实现Web系统的职能分工。 主键：数据库表中的关键域，值互不相同。 外部主键：数据库表中与其他表主键关联的域。 1.4 参考资料 1.张海藩.软件工程导论.北京：清华出版社，2008.2 2.王珊.数据库系统原理教程.北京：高等教育出版社，2006.5 3.刘利民.《软件工程综合设计》指导书.XX工业大学，2009.3 2.任务概述 2.1 目标 用户对系统的具体要求，摸清相关业务的具体流程，收集相关的信息、表格和文本，并对这些信息进行分析处理，制定面向现实世界的系统模型，如绘制业务流程图和E??—R图，制作数据字典等，为系统设计做好前期准备工作。 2.1.1理念目标 进一步提高学校的信息化管理水平，方便学生对个人基本信息及成绩的查询，方便教职工的管理，降低学校信息管理软件的维护成本。 2.12功能目标
移动计划建设管理系统一期建设需求说明 微软（中国） 2010年04月16日
目录 第1章概述 (1) 1.1 需求背景 (1) 1.2 建设目标 (1) 1.3 名词和术语 (2) 第2章需求说明 (4) 2.1 规划管理模块 (4) 2.1.1 业务描述 (4) 2.1.2 业务流程............................................. 错误!未定义书签。 2.1.3 业务功能需求汇总 (5) 2.2 计划管理模块 (12) 2.2.1 业务描述 (12) 2.2.2 业务流程 (15) 2.2.3 业务功能需求汇总 (23) 2.2.4 主要页面效果设计 (24) 2.3 共建共享管理模块 (30) 2.3.1 业务描述 (30) 2.3.2 业务流程............................................. 错误!未定义书签。 2.3.3 业务功能需求汇总 (31) 附件:原始业务资料附件 (43)
第1章概述 1.1需求背景 为满足移动投资管理、规划管理、共建共享、工程项目管理等各方面的业务数据与信息管理需要，计划启动计划建设管理平台建设项目。从业务层面上，该系统将根据实际业务需要，满足从领导到业务员工不同层次的个性化需求；从系统层面，该系统将与已投产的EIP、PMS、MIS、财务集中化管理平台、EOMS和BOSS等支撑平台形成有效的信息共享和数据接口，为各个层面的用户提供决策支持和管理支撑。该项目将从投资资金控，工程项目管理的角度实现投资规划、计划、执行、分解、工程项目立项、设计、实施、审计验收、后评估等业务流程的全面贯通，建成服务于省公司及各地市州分公司的集业务支撑与投资分析于一体的综合性业务管理支撑平台，进一步提升投资管理精细化水平，继续保持行业领先的资本开支回报率，更好地支撑公司业务发展。 1.2建设目标 计划建设管理平台总体 目标如右图所示：支撑投资 建设管理全业务流程贯通， 提升企业投资精细化管理水 平。总体目标的实现划分成 三个阶段：部管理精细化、 外部管理精细化与全流程贯 通，每个阶段根据资源配备 及业务发展情况又可分为多期建设来实现。 一期建设目标：搭建系统基础框架，包括规划管理、计划管理、共建共享管理三大模块，优先支撑省公司计划部部业务运作需要，并与PMS系统整合，实现项目数据共享。 业务问题及解决方式如下：
WebOA管理系统需求规格说明书 2009/11/20
1 概述错误!未指定书签。 1.1编写目的错误!未指定书签。 1.2参考资料错误!未指定书签。 1.3术语和标记错误!未指定书签。 2项目概述错误!未指定书签。 2.1项目总体目标错误!未指定书签。 2.2系统开发背景错误!未指定书签。 2.3主要限制和开发风险分析错误!未指定书签。 3功能需求错误!未指定书签。 3.1功能模型错误!未指定书签。 3.1.1个人办公模块........................................................... 错误!未指定书签。 3.1.2公文管理模块........................................................... 错误!未指定书签。 3.1.3公共信息模块........................................................... 错误!未指定书签。 3.1.4行政办公模块........................................................... 错误!未指定书签。 3.1.5消息管理模块........................................................... 错误!未指定书签。 3.1.6工作流程模块........................................................... 错误!未指定书签。 3.1.7组织管理模块........................................................... 错误!未指定书签。 3.1.8权限管理模块........................................................... 错误!未指定书签。 3.1.9系统管理模块........................................................... 错误!未指定书签。 人事档案模块........................................................... 错误!未指定书签。 3.2性能需求错误!未指定书签。 3.3非功能需求错误!未指定书签。 3.4故障处理错误!未指定书签。 4数据需求错误!未指定书签。 4.1数据项错误!未指定书签。 4.2数据间关系(E-R图)错误!未指定书签。 5行为需求错误!未指定书签。 5.1控制模型错误!未指定书签。 6接口需求错误!未指定书签。 6.1用户界面错误!未指定书签。 6.2软硬件接口错误!未指定书签。 7环境错误!未指定书签。 7.1运行环境错误!未指定书签。 7.2开发环境错误!未指定书签。 附录：项目成员介绍及组内评分错误!未指定书签。
软件需求规格说明书(案例) 1. 引言 1.1编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体. 1.2项目背景 1.2.1项目委托单位:****公司 1.2.2开发单位:***公司 1.3定义 1.4参考资料 2. 任务概述 2.1目标: <1> 决策支持:根据公司的要求及时提供所需报表及文件,并在适当时候对各部门领导给予销售及进货等方面的提示 <2>提高效率:利用软件进行管理,避免人工管理的失误以及延迟性,从而实现高效率的管理. 2.2运行环境: <1> 硬件方面:Pentium级处理芯片 1兆显存的兼容显卡 256色,800*600的兼容显示器 标准兼容打印机 <2>软件方面: WIN95操作系统 2.3条件与限制: 编程用计算机一台 完成期限2000/7/1 无资金供给 3. 数据概述 数据流程图如下: 3.1静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据 3.2 动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间 3.3数据库描述: 人事管理数据库:公司内人员的个人详细信息,包括档案信息 销售管理数据库:当日销售记录及以前的销售统计,用于销售分析 财务管理数据库:公司内部账目及收支情况详表 技术管理数据库:公司所需各技术档案的详细记录(包括文档) 3.4 数据字典: <1>数据流词条描述: 1.数据流名:登录信息 来源:用户的输入 去向:系统内部检验部分 组成:用户名,密码 流通量:每次登录输入一次 2.数据流名:登录结果 来源:系统 去向:用户
Web OA管理系统需求规格说明书 RY0921121 江舟 RY0921126 李康 GS0921A08 刘雄伟 GS0921111 岑毅 GS0921A12 李博 2009/11/20
目录 1 概述 (1) 1.1 编写目的 (1) 1.2 参考资料 (1) 1.3 术语和标记 (1) 2 项目概述 (2) 2.1 项目总体目标 (2) 2.2 系统开发背景 (2) 2.3 主要限制和开发风险分析 (4) 3 功能需求 (4) 3.1 功能模型 (6) 3.1.1 个人办公模块 (6) 3.1.2 公文管理模块 (9) 3.1.3 公共信息模块 (10) 3.1.4 行政办公模块 (12) 3.1.5 消息管理模块 (15) 3.1.6 工作流程模块 (17) 3.1.7 组织管理模块 (18) 3.1.8 权限管理模块 (20) 3.1.9 系统管理模块 (22) 3.1.10 人事档案模块 (24) 3.2 性能需求 (27) 3.3 非功能需求 (27) 3.4 故障处理 (27) 4 数据需求 (27) 4.1 数据项 (27) 4.2 数据间关系(E-R图) (33) 5 行为需求 (35) 5.1 控制模型 (35) 6 接口需求 (36) 6.1 用户界面 (36) 6.2 软硬件接口 (37) 7 环境 (37)
7.1 运行环境 (37) 7.2 开发环境 (37) 附录：项目成员介绍及组内评分..............................................错误！未定义书签。
1概述 1.1编写目的 本文档的编写目的是为Web OA管理系统项目的开发提供： a)软件总体要求，作为用户和软件开发人员之间了解的基础； b)功能、性能、接口和可靠性的要求，作为软件人员进行设计和编码的 基础； c)验收标准，作为用户确认测试的依据。 1.2参考资料 a)王长富，罗晓沛.基于Web和J2EE的办公自动化系统的设计[D].中国 科学院.2007. b)刘蕾，刘厚泉.基于工作流的B/S模式OA系统设计与实现[J]．微计算 机信息，2008. c)程家华．基于B/S模式的办公自动化系统设计与实现[M]．北京：同济 出版社，2005． d)杨永健，韩鸿雁．办公自动化中工作流过程定义的设计与实现[J]．四 川大学学报，2007. e)方旭华，颜慧佳．基于工作流的办公自动化系统的设计方案[J]．计算 机时代，2008. f)刘明臻，魏长军．OA系统公文流转模块的设计和实现[J]．吉林师范 大学学报,自然科学版，2008. 1.3术语和标记 a)Web OA管理系统：网络办公管理系统； b)OA：Office Automation c)Apache：是世界使用排名第一的Web服务器软件； d)J2EE：是一套不同于传统应用开发的技术架构，包含许多组件，主要 可简化并规范应用系统的开发与部署，进而提高可移植性、安全与再 用价值； e)ACL：Access Control List（访问控制列表）是路由器和交换机接
需求规格说明书范例 需求规格说明书 目录 这一块是目录条目 1 前言 1.1 项目背景 目前，珠江流域水资源保护局水质监测数据上报的主要是EXCEL形式保存，并且对水质分析只要是通过人工判断和处理，如果需要查找数据或制作相关报表及其不方便。同时，数据的表现形式不够丰富，不能直观表现所监测流域、断面、功能区等方面的水质信息。 为解决上述问题，需要建立一套基于GIS可利用网络，不受时间和地点限制的系统，可任意时间、地点进行数据编辑和数据查看，并通过电子地图和统计图标直观展示各监测对象的空间位置和水质现状的系统。 1.2 编写目的 该需求规格说明书是针对珠江流域水质监测数据库系统编写的，编写该需求书的目的是为了把调研了解到的用户对未来系统的需求做一个规范的描述，是对调研纪要和提供的原始资料的进一步加工和整理，并且要结合整个系统的整体需求，根据实际情况，对原来的系统的固有的业务流程和功能设计做适当的调整，为系统的设计和开发提供依据，也为系统的最终验收提供依据。 该需求规格说明书详细描述了系统业务需求、功能需求、外部接口需求、性能需求、安全需求等需求，方便开发人员了解业务，增进与客户的交流，记录需求的变更情况。 1.3 编写原则
(1) 可验证性 该需求书的中描述的每一个具体需求都是可以验证的，针对系统中某一处理过程或具体功能，人或机器能通过该过程检查该功能是否满足需求。 (2) 正确性 该需求书的编写内容是在对用户进行多次调研后记录和整理得来的，其中的内容都要经过相关业务人员的确认，并且最终由相关负责人签字认可。 (3) 完整性 本需求包括了信息中心的各个部门的需求，从内容上分为编写概述、总体说明、功能需求、接口需求等内容，基本满足了需求书的完整性要求。 (4) 一致性 本需求书与其他部门的需求编写规格和内容一致，需求的描述和业务的具体需求一致，系统的功能需求与整体需求一致。 (5) 无二义性 本需求书的各个概念和专业术语都有相应的详细说明和解释，用到的原始资料都有编号记载，本需求书的内容尽量避免使用模糊的概念和摸棱两可的词汇，表达尽量要求准确，可以直接用于系统的设计和开发，并且在和业务人员多次交流后，最终由各负责领导审核确认。 1.4 读者对象 本需求书的读者对象为该项目的开发人员，珠江流域水资源保护局相关领导和办公人员。 1.5 应用范围 该需求适用于珠江流域水质监测数据库系统，系统使用者范围为珠江流域水资源保护局相关领导和办公人员。 1.6 定义、首字母缩写词和缩略语
房屋租赁管理制度
` 1.0职责 1.1 行政人事部 1.1.1 对设有行政人事部行政专员专职管理的区域（如深圳办公 区及宿舍）：负责房屋租赁申请、费用报销及日常管理； 1.1.2对未设有行政人事部行政专员专职管理的区域（如各分公 司、办事处常驻办公区、宿舍）：负责监督房屋租赁申请、费用报销，以及环境卫生。 1.1.3 汇总各分公司、办事处的租赁情况，每个月定期对租赁房 屋做检视，视入住情况安排退租或者续租。 1.2 营销中心各分公司、办事处销售岗 1.2.1负责本管辖区域办公区房屋租赁申请、费用报销及日常管 理； 1.2.2负责本管辖区域办公区环境卫生管理.
1.3 宿舍长（销售岗或服务岗） 1.3.1负责本管辖区域宿舍房屋租赁申请、费用报销及日常管 理； 1.3.2负责本管辖区域宿舍环境卫生管理。 2.0房屋租赁类型 房屋租赁类型 3.0房屋租赁申请 3.1房屋租赁申请原则： 3.1.1原则上本地招聘人员不承诺解决住宿； 3.1.2对于入住人员少或者承诺解决住宿人员较少的区域，确有保 留办事处必要的，应考虑租赁办公室而不是宿舍。 3.2行政人事部管辖办公区/宿舍租赁申请 3.2.1新租房或续租（更换地址按新租处理）：由行政人事部以邮 件形式提供《租房申请表》（包括地址、周边环境、面
积、类型、租房原因、预算、预住人数），报部门主管、 总监审核，总经理批准。 3.2.2对新租办公区，若需工程装修、购置固定资产、办公用品， 应在《固定资产申购单》或《办公用品申购单》提供装修 预算、固定资产、办公用品预算。 3.2.3涉及备用金申请和报销按《费用管理制度》审批权限实施。 3.2.4租赁合同和押金各一式三份，一份留存财务、一份由房东保 管、一份由租赁方保管。租赁合同和押金另需将扫描件发 送行政人事部备档。 3.3营销中心管辖办公区/宿舍租赁申请 3.3.1新租房或续租（更换地址按新租处理）：由租赁人以邮 件形式提供《租房申请表》（包括地址、周边环境、面 积、类型、租房原因、预算、预住人数），报部门主管、 总监审核，分管副总批准，报备行政人事部。
学生信息管理系统需求规格说明书 班级：计1301 ：晓雨学号：06 ：婉彤学号：02
目录 3 3 8 12 14 14 14 15 15
15 16 16 17 17 17 17 1.引言 1.1.目的 随着高校招生规模的逐步扩大和人事制度的改革，在校学生人数将不断增加，而
学生管理人员则相对减少。加上我国高等学校基层学生管理工作的头绪多、容杂、管理细、要求高，传统管理办法已基本不适应新形势的要求。在计算机飞速发展的今天，应用数据库技术实现学生成绩的计算机管理是可行而必要的工作。实现高校学生管理信息系统，既能够提高工作效率，又可以提高工作水平。 1.2.定义 Workflow：工作流 1.3.参考资料 《软件工程导论》海藩清华大学 《软件使用工程》人杰清华大学 1.4.软件标识 软件全称：学生信息管理系统 软件简称：XSXXGLXT 1.5.软件描述 1.5.1.系统属性 行政服务中心是改革开放进程中一项新生事物，是实践江总书记“三个代表”重要思想的具体表现，是改善投资环境，扩大开放，吸收外来投资，加快发展的重要举措。为了实现行政服务中心“一站式集中，一条龙服务”，为全社会提供平等竞争的市场条件和长期稳定的投资环境，塑造廉洁，规，高效的政府形象的目标，充分利用信息化技术，建设先进实用的可扩展性强的行政服务信息系统，实现行政服务信息处理的智能化、网络化、“无纸化”成为一项迫切的工作。为此，托普集团根据行政服务中心的业务需求，设计了行政服务中心政务平台。
1.5. 2.开发背景 开发目的：学校管理 应用目标：全体学生 使用围：公众 用软件的功能结构图加以说明如下： （l）主要功能 管理和信息查询。数据更新功能分为三部分：学生相关信息的添加、删除和修改。 数据添加功能提供便捷的录入界面，通过应用程序将学生数据添加到数据库中。数据删除功能将不满足要求的相相关记录从数据库中删除。数据修改功允许管理员对他所指定记录的相关信息进行修改。数据查询功能允许管理员进行两种方式的查询：记录浏览（不构造任何查询条件）和条件查询。记录浏览功能可以方便快捷地浏览全部记录。条件查询允许用户构造各种组合条件来查询所需信息。密码管理功能允许用户对密码进行修改。 （2）性能要求 方便快捷有效地完成学生信息管理的各项工作，录入数据合法性的校验程度高，数据查询速度快,能够快速的对学生信息进行管理。 （3）系统的输入、输出 输入：学生的个人信息。 输出：所要查询的所有学生的信息。 （4）安全和要求 用户只能以管理员的身份进入系统后，才可以对学生相关信息进行查询及修改，安全和行高 （5）组织结构图
车辆管理系统需求说明书 中国电信安徽公司 二00九年三月
目录 1. 需求功能点阐述 (3) 1.1.车辆档案管理 (3) 1.2.车辆保险合同管理 (4) 1.3.人员档案管理 (5) 1.3.1.驾驶员档案管理 (5) 1.3.2.车队管理人员档案管理 (6) 1.4.出车管理 (7) 1.4.1.派车流程管理 (7) 1.4.2.出车费用管理 (9) 1.5.车辆维修管理 (10) 1.5.1.车辆维修申请流程 (10) 1.5.2.维修单信息管理 (12) 1.6.车辆统计 (12) 1.7.车辆信息提醒 (14) 1.8.人工成本 (15) 1.9.管理成本 (15) 1.10.车辆管理文件 (16)
1. 概述 为精确车辆管理，细化车辆运行费用，准确管控油料消耗等成本开支，进一步加强对外包车辆的日常规范管理，掌握车辆运行基本情况，实现省、市、县一体化车辆管理。 车辆管理系统主要实现省、市、县车辆档案管理，人员档案管理，派车管理，车辆维修管理，车辆各项费用的管理及统计，车辆信息提醒。具体的包括： 1)车辆档案管理：实现车辆基本档案的基础数据的录入、维护及分级查询的需求； 2)人员档案管理：实现驾驶员档案及车队管理员人员档案的基础数据的录入、维护及 分级查询的需求； 3)派车管理：实现用车人提请派车申请，从申请审批到返程确认的闭环电子管理，记 录车辆的使用及油耗数据的需求； 4)车辆维修管理：实现车队人员提请送修申请电子审批流程，维修记录录入、维护及 分级查询的需求； 5)车辆统计：实现省、市、县分级车用费用的日、月、年度统计，部门用车公里数统 计，维修统计； 6)车辆信息提醒：各种待办信息提醒，车辆年审提醒，车辆保险到期提示，驾驶 员年审提醒，车辆报废提醒，油耗超标提示； 2. 需求功能点阐述 2.1.车辆档案管理 1)车辆档案录入与维护由各车队人员录入、维护所辖车辆的信息。数据项：车辆号牌，厂牌车型，座位 /吨位，排气量（升），燃油种类，发动机号码，车架号码，购置日期，注册日期，行驶公里数，耗油标准市内（公升），耗油长途标准（公升），使用单位，产权单位，年审日期，年审期限，报废公里数，报废年限，车辆状态＜是否报废＞，投保日期，保单终止期，分配驾驶员，车辆照片。 2）车辆档案查询省、市、县分级查询。省综合管理部人员及车队管理人员可以查看到
软件需求规格说明书 文件编号： QMS—PROC－RD02 版本：1.0 受控签章
修改历史
目录 1引言 (2) 1.1目的 (2) 1.2背景 (2) 1.3术语 (2) 1.4预期读者与阅读建议 (2) 1.5参考资料 (2) 1.6需求描述约定 (2) 2.项目概述 (2) 2.1系统功能 (2) 2.2业务描述 (2) 2.3数据流程描述(可选) (2) 2.4用户的特点 (2) 2.5运行环境要求 (2) 2.6设计和实现上的限制 (2) 3.功能需求的描述 (2) 4.非功能需求 (2) 4.1系统性能要求 (2) 4.2系统安全及保密要求 (2) 4.3系统备份与恢复要求 (2) 4.4系统日志 (2) 5.外部接口说明 (2) 6.其他需求 (2) 7 需求变更识别 (2) 8.功能列表 (2) 9.附件 (2)
1引言 1.1 目的 说明编写这份软件需求规格说明书的目的，如：通过本文档定义ＸＸＸ产品的需求，以求在项目组员与相关成员之间达成一致的需求描述。 1.2 背景 描述系统产生的背景，包括： a．需开发的软件系统的名称，和英文缩写（可选），项目编号（可选）； b．列出此项目的任务提出者、开发者 c．软件系统应用范围、用户。 d．产生该系统需求的原因或起源，如社会背景、市场发展、政策趋势、原有系统局限性 1.3 术语 列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。也可用附件说明。或放到本文件的最后。 1.4 预期读者与阅读建议 描述本文档的主要读者，以及这些读者在阅读时的阅读重点与建议。可用列表的方式列 1.5 参考资料 列出有关的参考资料，如： a．本项目经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 d．行业标准和规范。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
`
1.0职责 1.1 行政人事部 1.1.1 对设有行政人事部行政专员专职管理的区域（如深圳办公区及宿舍）：负责房屋租赁 申请、费用报销及日常管理； 1.1.2对未设有行政人事部行政专员专职管理的区域（如各分公司、办事处常驻办公区、 宿舍）：负责监督房屋租赁申请、费用报销，以及环境卫生。 1.1.3 汇总各分公司、办事处的租赁情况，每个月定期对租赁房屋做检视，视入住情况安 排退租或者续租。 1.2 营销中心各分公司、办事处销售岗 1.2.1负责本管辖区域办公区房屋租赁申请、费用报销及日常管理； 1.2.2负责本管辖区域办公区环境卫生管理. 1.3 宿舍长（销售岗或服务岗） 1.3.1负责本管辖区域宿舍房屋租赁申请、费用报销及日常管理； 1.3.2负责本管辖区域宿舍环境卫生管理。 2.0房屋租赁类型 3.0房屋租赁申请 3.1房屋租赁申请原则： 3.1.1原则上本地招聘人员不承诺解决住宿； 3.1.2对于入住人员少或者承诺解决住宿人员较少的区域，确有保留办事处必要的，应考 虑租赁办公室而不是宿舍。 3.2行政人事部管辖办公区/宿舍租赁申请 3.2.1新租房或续租（更换地址按新租处理）：由行政人事部以邮件形式提供《租房申请 表》（包括地址、周边环境、面积、类型、租房原因、预算、预住人数），报部门主 管、总监审核，总经理批准。 3.2.2对新租办公区，若需工程装修、购置固定资产、办公用品，应在《固定资产申购单》 或《办公用品申购单》提供装修预算、固定资产、办公用品预算。
3.2.3涉及备用金申请和报销按《费用管理制度》审批权限实施。 3.2.4租赁合同和押金各一式三份，一份留存财务、一份由房东保管、一份由租赁方保管。 租赁合同和押金另需将扫描件发送行政人事部备档。 3.3营销中心管辖办公区/宿舍租赁申请 3.3.1新租房或续租（更换地址按新租处理）：由租赁人以邮件形式提供《租房申请表》（包 括地址、周边环境、面积、类型、租房原因、预算、预住人数），报部门主管、总 监审核，分管副总批准，报备行政人事部。 3.3.2对新租办公区，若需工程装修、购置固定资产、办公用品，应在《固定资产申购单》 或《办公用品申购单》提供装修预算、固定资产、办公用品预算。 3.3.3涉及备用金申请和报销按《费用管理制度》审批权限实施。 3.3.4租赁合同和押金各一式三份，一份留存财务、一份由房东保管、一份由租赁方保管。 租赁合同和押金另需将扫描件发送行政人事部备档。 3.4押金与租金的支付 3.4.1押金支付额度：最多不超过2个月房租。 3.4.2租金支付频率：深圳房屋租金一律采用月付。异地房屋租金原则上月付或季付，一 律不超过（含）季付。 4.0租赁房屋固定资产管理 4.1办公区/宿舍标准配置
品高项目管理系统 软件开发需求
目录 1引言 (2) 1.1编写目的 (2) 2功能性需求 (2) 2.1系统登录 (3) 2.2对内项目管理子系统 (6) 2.3对外项目交流系统 (22)
1 引言 1.1 编写目的 本文档可作为 1. 设计人员进行系统设计的输入源。 2. 开发人员对系统功能开发的依据。 3. 测试人员编写系统测试计划，测试案例编写的输入源。 4. 产品经理检查系统实现程度的依据。 5. 项目团队外人员进行沟通的外部接口，用于他们评审和理解系统。 6. 项目需求阶段的主要交付物。 7. 收集并记录所有的外部接口，以用于作为完成设计和实现系统的参考。 2 系统概貌 2.1 系统背景 随着公司发展，客户范围不断增长,项目数量多且繁杂,给公司的和客户了解项目实际情况带来很大不便,公司及客户之间缺乏有效快速的沟通交流环境. 基于上诉背景，我们提出需建立一套完善的项目管理系统，作为公司及客户之间对项目信息的了解及在线交流, 以满足公司发展的需求。 2.2 用户描述 本系统用户为我们公司业务人员、项目成员、项目经理、管理中心、财务合同管理员、部门经理，项目管理层等。 2.3 系统角色权限 系统的不同角色对信息的权限见附件表 角色权限表.xlsx 2.4 一般限制 ? 应用系统应采用B/S 结构，客户端支持IE6.0 以上的版本。 ? 应用系统的开发工具与技术应采用Microsoft .NET 的技术体系。 ? 应用系统中所有数据统一保存到SQL Server 数据库。
2.5出错处理 ?所有的应用系统错误都应记录到系统日志文件中。 ?所有的Windows服务错误都应记录到Windows服务日志文件中。 ?所有的Web服务错误都应记录到Web服务日志文件中。 2.6假设和依赖条件 ?本系统假设.Net Framework 4.0平台稳定可靠，性能满足实际需求。系统构建在Microsoft .Net Framework平台中，严重依赖于该平台的可靠性，稳定性和性能。 ?本系统假设Microsoft SQL Server数据库稳定可靠，性能满足实际需求。系统数据存储于Microsoft SQL Server数据库中，依赖Microsoft SQL Server数据库的可靠性，稳定性和性能。 ?本系统假设涉及的外部接口可靠运行，提供正确数据。系统部分数据展现依赖于外部接口，当外部接口不能正确工作时，可能会导致部分展示数据不正确或无法显示。 ?本系统假设网络状态良好。本系统和客户端交互时依赖于网络状况，当网络故障或者性能低下时，可能会造成系统无法访问，系统响应速度变慢，数据无法提交等现象。但不应出现数据完整性和一致性的损坏。 ?本系统假设工作流引擎稳定可靠，性能满足要求。 ?本系统假设硬件服务器工作状态良好。 3功能性需求 3.1系统登录 【REQ_1】使用系统的用户分2类,内部用户及外部用户 【REQ_2】内部用户访问系统的时候,需要输入AD帐号密码进行身份验证检查 【REQ_3】外部用户访问系统的时候,需要输入用户名和密码进行身份验证检查 3.2首页 【REQ_4】每个用户登录后都可进入自己所属角色的首页 3.2.1.1业务人员 【REQ_5】列出业务人员本人的预立项的项目列表，已完成的合同列表，个人待办事宜，如下图示：