统一用户以及权限管理系统需求分析报告

统一用户以及权限管理系统需求分析报告,统一用户及权限管理系统,
软件需求说明书
作者: 完成日期: 签收人：签收日期：
修改情况记录:
软件需求说明书。

.....。

.。

.。

.。

....。

.。

.。

.。

.。

.。

...。

.。

.。

.。

.。

1
1。

引言。

..。

..。

...。

...。

.。

.。

..。

.。

..。

.。

.。

.。

..。

.。

..。

. (3)
1.1 编写的目的。

.。

..。

.。

.。

....。

.。

.。

.。

.。

.。

..。

...。

..。

.。

.. 3
1。

2 背景。

.。

.。

.。

.。

.。

.。

.。

..。

.。

.。

..。

...。

(3)
1.3 参考资
料 .。

.....。

.。

.。

.。

...。

.。

.。

.。

.。

.。

.。

.。

.。

.。

..。

.。

.。

.。

3
2 项目概述..。

...。

.。

.。

.。

.。

.。

.。

....。

.。

.。

..。

...。

.。

.。

.。

. 4
2.1 待开发软件产品描述。

.。

.。

.。

.。

..。

...。

.。

.。

.。

.。

.。

...。

.。

4
2。

2总体需求。

.。

.。

..。

.。

..。

.。

..。

.。

...。

..。

.。

.。

.。

..。

.。

4
2。

3 用户特点。

.。

.。

.。

..。

.。

.。

.。

.。

.。

..。

.。

.。

.。

.。

..。

. 4
3 具体需求.。

..。

.。

..。

....。

.。

.....。

.。

.。

.。

.。

...。

.。

..。

. 4
统一用户及权限管理系统的主要功能模块为：。

..。

.。

.。

..。

....。

..。

4
3.1.1登录。

...。

...。

.。

..。

.。

.。

..。

.。

.....。

.。

.。

.。

...。

. 5
3。

1.2用户授权管理。

..。

..。

..。

...。

..。

.。

..。

..。

5
3。

1。

3组织机构管理。

.。

.。

.。

.。

.。

.。

...。

....。

.。

6
3.1。

4应用权限定制。

.。

.。

.。

.。

.。

.。

..。

.。

..。

.。

..。

7
3。

1。

5系统维
护 ..。

..。

..。

.。

.。

..。

.。

..。

...。

..。

.。

.。

.。

.。

7
3.2 接口说明。

.。

..。

...。

..。

.。

.。

.。

...。

.。

.。

.。

.。

. 7
3。

2。

1用户界面。

.。

.。

.。

..。

..。

.。

.。

.。

.。

.。

.。

8
3。

2。

3 软件接口。

.。

.。

.。

.。

..。

.。

.。

....。

.。

..。

..。

. 10
3。

2。

4硬件接口。

...。

..。

.。

.。

.。

......。

.。

.。

...。

.。

.。

..。

. 11
3.3 性能需求。

.。

.。

....。

.。

...。

.。

...。

...。

.。

...。

..。

.。

11
3.3。

1 可用性。

.。

......。

..。

.。

.。

.。

.。

.... .。

..。

11
3。

3.2 安全性。

.。

..。

.。

....。

.。

...。

.。

..。

.。

...。

.。

11
3.3。

3 可维护性。

.。

.。

.。

..。

.。

..。

.。

...。

.。

.。

.。

.。

.。

..。

11
3。

3。

5 警
告 .....。

.。

...。

..。

.。

..。

.。

.。

.。

.。

..。

.。

.。

11
3.5 设计约束。

..。

.。

.。

..。

.。

.。

..。

.。

...。

.。

..。

.。

.。

...。

.。

. 11
3。

5。

1 其他标准的约束。

.。

.。

.。

.。

.。

.。

.。

.。

..。

.。

11
3.6 其他需求。

.。

.。

.。

.。

.。

..。

...。

..。

..。

.。

..。

..。

.。

.。

.。

.。

.。

12
4 任务概述.。

..。

..。

.。

.。

.。

...。

.。

.。

. ...。

.。

.。

..。

.。

.. 12
4。

1 目标。

.。

.。

..。

.。

.。

..。

.。

.。

.。

.。

....。

.。

.。

13
4。

2 运行环
境 .。

..。

.。

.。

...。

..。

.。

.....。

..。

..。

.。

..。

.。

.。

...。

13
4.3 支持软
件 ..。

.。

..。

.。

.。

.。

.。

..。

.。

.。

.。

.。

.。

.。

.。

13
5解决方
案 .。

.。

.。

...。

.。

.。

.。

.。

..。

.。

..。

.。

.。

..。

..。

.。

...。

.。

13
5。

1。

1 物理结构(physical
structure) 。

.。

.。

.。

..。

.。

.。

...。

...。

..。

13 5。

1。

2 逻辑结构(logical
construction) 。

...。

..。

.。

..。

.。

.。

.。

14
5.2概念设计(Conceptual
Design) 。

.。

.。

.。

.。

.。

..。

....。

.。

.
15
5。

2.1系统角色及功能需求。

.。

.。

.。

.。

.。

.。

.。

.。

.。

..。

..。

..。

..。

15
5。

2.2组织结构模型需求分析。

.。

..。

.。

.。

..。

...。

..。

.。

.。

.。

.。

16
5。

3 用例场景(Usage Scenarios）。

.。

..。

.。

..。

...。

.。

.。

.。

.。

. 18
5.3。

1 用户使用认证系统流程图。

.。

.。

.。

.。

.。

..。

..。

..。

..。

.。

18
5.3。

2应用组织结构管理流
程 .。

......。

....。

.......。

.。

.。

..。

.。

18 6（数据。

.。

..。

.。

..。

....。

...。

.。

..。

..。

.。

.。

.。

...。

.。

.。

.。

..。

..。

19
6.1数据描
述 ...。

..。

.。

.。

.。

.。

.。

.。

...。

.。

.。

.。

.。

..。

.。

.。

20
6。

2 数据字典。

..。

.。

..。

..。

.。

.。

.。

......。

.。

.。

.。

.。

.。

.。

.。

20
6.2.1 数据项。

..。

.。

..。

.。

.。

.。

..。

.。

.。

.。

.。

. .。

.。

..。

. 20
6。

2.2数据结构。

.。

....。

.。

...。

.。

.。

........。

.。

.。

.。

.。

.。

...。

21
6.2。

3。

数据
流 .。

.。

......。

...。

.。

....。

.。

...。

.。

.......。

.。

.。

21
6.2.4处理过
程 .。

....。

.。

.。

....。

.。

.。

..。

..。

.。

..。

.。

.。

.。

..。

.。

22
6.3 E—R 图。

.。

..。

.。

.。

.。

..。

.。

..。

.。

.。

..。

.。

.。

.。

.。

.. 22
6。

4数据流
图 .。

.。

.。

.。

.。

..。

....。

...。

..。

.。

.。

.。

..。

.。

24
6.4.1注册模块数据流
图 .。

..。

.。

.。

.。

.。

.。

..。

.。

..。

..。

. 24
6。

4.2用户查、增、改模块数据流图。

.。

.。

.。

.....。

.。

..。

.。

..。

25
6.4.3管理员查、增、改、删模块数据流图。

.。

..。

..。

..。

.。

26 6。

4。

4超级管理员查、增、改、删模块数据流图。

.。

.。

..。

.。

..。

...。

(27)
6.4。

5超级管理员定制岗位权限模块数据流图。

..。

..。

..。

.。

.。

. 33
7其它需要说明的问题。

.。

.。

..。

.。

.。

.......。

..。

.。

.。

.。

..。

.。

33
1。

引言
1.1 编写的目的
本手册作为用户与该系统软件开发维护人员共同遵守的软件需求规范说明.
使用对象：徐汇区政府部门工作人员
1。

2 背景
开发软件名称：统一用户和权限管理系统
项目任务提出者：徐汇区政府
项目开发者:
用户：区政府各部门
本系统应当包括：员工,管理员，超级管理员
1.3 参考资料
《jsp 课程设计案例精编》清华大学出版社申吉红等编著
《软件工程课程设计》李龙澍，郑诚等编著机械工业出版社
《软件工程》清华大学出版社张海藩著
2 项目概述
2。

1 待开发软件产品描述
本产品旨在对政府内部各部门的工作人员使用同一账号访问不同的应用系统进行管理，是一款界面友好,功能实用,可用性，可维护性强的产品.并且易于长期维护与管理，可以对电子政务体系进行很好的管理。

2。

2总体需求
1。

本系统为统一的授权管理和用户统一的身份管理及单点认证支撑平台.
2. 利用此支撑平台可以实现用户一次登录、网内通用，避免多次登录到多个应用的情况.
3。

利用此系统可以对区域内各信息应用系统的权限分配和权限变更进行有效的统一化管理，实现多层次统一授权，审计各种权限的使用情况，防止信息共享后的权限滥用，规范今后的应用系统的建设。

2.3 用户特点
用户主要为政府管理员，政府各部门主管，及对应部门员工.
3 具体需求
3.1系统功能模块:
统一用户及权限管理系统的主要功能模块为：
3。

1。

1登录
用户使用用户登录名以及密码登录，且用户登录名是唯一的。

3。

1。

2用户授权管理
用户授权管理的主要任务是对用户授权进行管理。

3。

1。

2.1用户基本信息管理
用户进行个人信息的操作与更新，包括增、删、查、改四个操作。

3.1。

2。

2用户包含的角色管理
用户具有多种角色，如主任、来宾、管理员、领导等。

用户在不同的系统中担任的角色不同。

如用户A在办公室系统中担任管理员,但在档案系统中,只是普通用户。

3。

1。

2。

3用户包含的权限管理
不同的用户在不同的系统中，拥有的角色不同，所以所具有的权限也不同。

如管理员拥有
的权限比普通用户的权限广。

管理员除了与普通用户一样的权限外,还具有独自的权限如制定计划。

3.1.2。

4用户组织机构管理
系统面向的对象由多分支机构组成，如单位、部门、岗位,用户可以属于不同的组织机构.对用户组织机构的管理,有助于用户权限的统一分配和管理。

3.1。

2。

5用户岗位管理
岗位作为机构的最底层。

不同的岗位所有具有的权限不同,所以需对用户的岗位进行管理。

3.1。

3组织机构管理
组织机构管理的主要功能是对组织机构进行管理.
3.1。

3。

1组织机构基本信息管理
设计的系统使用的对象有多分支机构组成，如单位、部门、岗位。

对于不同的机构,所具有的功能模块不同.如单位由部门组成,所以就可以在其下增加部门,同理部门可以在部门下增加岗位.
3。

1。

3.2岗位基本信息管理
每个岗位具有独立的信息，如岗位编号、岗位名称等.
3。

1。

3.3岗位包含的权限管理
不同的岗位具有不同的权限。

如部门经理这个岗位除了具有普通员工的权限,还有特殊的权限如制定部门策略。

可以参照用户权限管理。

3。

1。

3。

4岗位认证管理
由于不同的岗位拥有的权限不同，有些高层岗位具有的权限大，具有功能操作也就多,有些功能操作具有危险性,只允许部分人操作,所以需对岗位进行认证，防止非法用户.
3。

1。

3。

4拥有岗位的用户管理
一般一个用户对应一个岗位，但有些岗位具有独自的特殊性，有多个用户，如技术岗位，有多个技术人员，有时一个用户可能有多个岗位,需对其统一管理.
3。

1.4应用权限定制
应用权限定制的主要功能为:管理员为用户或用户组定义应用系统权限.
3。

1.4。

1应用系统基本信息管理
本系统内部包含多个应用系统的接口，需要对其他应用系统的基本信息进行管理,如应用系统的名称，提供的功能接口等，方便用户使用.
3。

1。

4.2应用系统权限组管理
管理员可以对个人或者以组的形式对一组用户在应用系统中的权限进行管理。

如办公系统中的邮件收发组的权限管理。

3。

1。

4.3应用系统权限管理
任何合法用户都可以登录应用系统。

由于用户具有的角色不同,所以需对角色在应用系统中的权限进行管理，以防止发生越权操作。

3。

1。

4.4应用系统角色管理
任何用户都可以登录应用系统。

由于用户具有的角色不同,所以需对角色进行管理。

3.1。

5系统维护
3。

1。

5.1查询系统审计
用户可以查询系统中所有的角色以及对应的权限，超级管理员和管理员可以查询所设置的用户权限是否合理。

3.1。

5。

2查询应用审计
用户可以查询应用系统中所有的角色以及对应的权限，超级管理员和管理员可以查询所设置的用户权限是否合理
3。

2 接口说明
系统支持多种灵活的接口,并且借助.NET的开发平台对于网络服务的支持可以灵活的进行扩展。

3。

2。

1用户界面提供基本页面。

3.2。

1.1。

用户登录界面
3.2。

1。

2用户注册界面
3.2.1。

3用户查询界面
3。

2.1。

4管理员设置用户权限界面
3。

2.3 软件接口
统一用户及权限管理系统包括邮件系统、政府内部办公系统、公文管理系统、呼叫系统。

每个系统应提供的接口如下：
（1）邮件系统包括登录接口,收邮件接口，发邮件接口，群发接口,还有消息订阅接口，基本设置接口.
（2）政府内部办公系统包括登录接口，文件传输接口，工作安排接口,政务公开接口，文件查询接口，内部信箱接口,预留栏目接口，扩展栏目接口，系统信息管理接口。

（3)公文管理系统包括公文起草接口，已发公文接口，代办公文接口,已办公文接口，公文委托接口，流程控制接口，类别定制接口。

(4）呼叫系统包括交互式语音应答接口和呼叫中心平台接口。

3。

2。

4硬件接口
本系统可以实现用户一次登录、网内通用,避免多次登录到多个应用的情况。

所以硬件接口为组成局域网的基本硬件，包括路由器,防火墙。

3。

3 性能需求
(1）静态数据：
a本系统支持多个终端，能够运用于对所有员工的管理，并进行联网控制； b 系统支持多管理员对系统管理;
（2)动态数据：95，的事务必须在小于5s的时间内处理完。

3。

3。

1 可用性
适合多部门中型政府对信息的管理。

3。

3。

2 安全性
借助内置的 Windows 身份验证和基于每个应用程序的配置，可以保证应用程序是安全的。

3。

3。

3 可维护性
各个模块完成独立的功能,耦合度低，对一般程序上的错误可进行调试，不会造成系统瘫痪。

3.3。

5 警告
系统的不可用是由于计算机硬件或软件不符要求,或是用户不合理的使用造成的，如泄露个人登录密码，恶意操作等，对于以上情况本系统的研发人员概不负责维修调试或承担相应责任。

3。

5 设计约束
3。

5。

1 其他标准的约束
a（徐汇区政府用户统一及权限管理信息登记表格式;
b（员工编号，部门编号的编号规则。

c( 金钱单位为人民币（元）；
3.5。

2 硬件的限制
服务器应该满足的要求：
a（ Cup 主频在2.0GHz以上;
b（内存在4G以上，硬盘在10T以上。

个人电脑应该满足的要求:
c( Cup 主频在1。

2GHz以上;
d（内存在256M以上，硬盘在80G以上。

3。

6 其他需求
3.6.1 数据库
该系统对数据库规定了一系列的需求,它们包括: a（能够准确标识信息，并且要有助于编程人员识别； b( 能够承受较高的使用频率,每分钟1000次的访问；c( 具有较快
的存取能力；
d（能够对数据进行及时保存;
e( 能够导入导出数据,并进行数据库备份。

3。

6。

2市场合适应性需求
a( 能够在各种政府管理中应用，包括大，中,小型等。

b（降低系统配置需求,使其
能够广泛的应用. 4 任务概述
4。

1 目标
1）规范部门管理.
2）实现较完善的管理体系。

3）实现使用同一账号登录多个系统.
4）系统符合实际生产需求，人机界面友好、操作简便.
4.2 运行环境
操作系统平台：Windows Xp
数据库平台：oracle 11
4。

3 支持软件
操作系统：Windows xp
编译程序：MyEclipse 7.5
测试程序：MyEclipse，IE浏览器
5解决方案
主要解决统一用户及权限管理系统的结构与基本的概念设计.
5。

1系统结构（berkeleydb）系统结构包括物理结构与逻辑结构。

5。

1。

1 物理结构（physical structure) 统一用户及权限管理系统的拓扑结构如下：
5。

1。

2 逻辑结构（logical construction）
统一用户管理系统由统一认证系统和权限管理系统两部分组成。

统一认证系统
统一用户认证系统负责提供用户身份认证服务.
权限管理系统
权限管理系统管理所有用户的信息，为管理员提供操作界面，管理用户、角色、单位、部
门、系统选择等信息。

系统主要由3部分组成:
1、数据库:用户信息与管理员信息分开处理,分别在数据库的不同表中，这样做对系统扩充性更为有利。

2、管理模块：主要包括组织结构及单位管理、部门管理、用户管理、帐号管理、角色管理，角色的权限定制等部分组成。

3、管理端：为管理操作提供可视化管理界面。

5。

2概念设计（Conceptual Design）
主要涉及系统角色及功能.
5。

2.1系统角色及功能需求
系统中所包含的用户及所具有的基本操作。

5。

2。

1。

1普通用户：
(1）注册:新员工可以进入注册页面,填写注册信息,经过管理员认证成功后，
注册信息生效，可以登录系统。

(2）个人信息管理:员工可以查询个人的信息.部分个人信息可以对其修改，如
联系方式，登录密码等，但部分信息，需向管理员（部门负责人）申请，如个人职务.
(3）查询政府以及部门相关文件：员工可以浏览政治文件以及任务安排.
（4）选择其他系统:使用同一账号，登录其他系统如邮件系统等，进行相关操作。

(5）注销：登录成功后，在不需要使用的时候，可以进行注销并自动保存信
息。

注销前动态保存信息.
5.2.1。

2管理员:管理用户认证以及部门信息的维护
(1)注册:新管理员可以进入注册页面,填写注册信息，经过超级管理员认证成
功后，注册信息生效，拥有管理员权限,可以登录系统。

（2）员工信息管理：管理员登陆系统后可以对新的员工进行认证并同意其注
册，可以对现有员工的信息进行修改和查询，可以删除某些员工信息。

（3）部门信息管理:管理员不可以添加和删除部门信息,需向超级管理员申请.
（4)登录其他系统:使用同一账号,登录其他系统如邮件系统等，进行相关操作.
（5）系统管理:查看系统简介，查询系统审计、查询应用审计。

（6)个人信息管理：管理员可以查询个人的信息并对其修改，但部分信息，需
向超级管理员申请,如个人权限。

（7）注销：登录成功后，在不需要使用的时候，可以进行注销并自动保存信
息。

注销前动态保存信息。

5。

2。

1.3超级管理员：管理用户认证与组织结构的创建、对数据库维护
（1）部门信息管理：超级管理员登陆系统后可以添加新的部门，可以对现有
部门的信息进行修改和查询,可以删除某些部门信息，如果部门下存在员工信息，则无法删除该部门.
（2)职能管理：超级管理员登录系统后可以设置所有用户的相关信息,尤其是
管理员信息的相关设置,如权限设置。

（3)登录其他系统：使用同一账号，登录其他系统如邮件系统等,进行相关操作。

因超级管理员用户是系统的内置用户，不可以在软件使用过程中被创建，故超级管理员第一次登录时必须强制其修改密码.
(4）系统管理：查看系统简介，查询系统审计、查询应用审计
(5)个人信息管理:超级管理员可以查询个人的信息并对其修改。

(6）注销：登录成功后，在不需要使用的时候，可以进行注销并自动保存信息.注销前动态保存信息。

5。

2。

2组织结构模型需求分析
本系统的组织结构模型如下图所示：
5.2.2。

1模块划分需求
组织结构管理系统的体系模块可参阅上图所示.对于系统模块划分需求如下:
部门信息的添加、删除、修改、查找；
部门信息中添加、删除对象(人员);
角色信息的添加、删除、修改、查找;
角色中添加、移除对象（人员);
用户的添加、删除、修改、查找；
帐号添加、删除、查找；
系统对外提供的各种接口（综合）.
5.3 用例场景（Usage Scenarios）
5.3。

1 用户使用认证系统流程图
B— S 应
用
从图中可以看出，当用户访问系统时，如果没有认证过，会告诉浏览器转向到登录页面，用户输入登录信息后应用系统将登录信息提交到通用认证接口,通用认证接口通过和数据库中的数据进行认证,认证通过后再返回用户的信息，回传到应用系统中。

图中主要描述了对于B/S情况下的认证流程,对于C/S情况下与此类似，更为简单一些。

5。

3.2应用组织结构管理流程
合法用户对应的组织结构信息统一存放在组织结构管理系统中。

用户在访问应用系统的时候，应用系统通过组织结构管理系统的接口去查询该用户的单位、部门、角色等信息，根据系统返回的结果进行相应的处理.如下图所示：应用组织结构流程如下图所示:
6（数据
6。

1数据描述
员工信息表,部门信息表，管理员表，教育层次信息表，工作职位类型表，超级管理员表，
政府文件信息。

6.2 数据字典
6。

2。

1 数据项
管理员信息数据字典:
部门信息数据字典：
6。

2.2数据结构
6。

2。

3.数据流
6。

2。

4处理过程
6。

3 E-R图
6.4数据流图
6.4.1注册模块数据流图
6。

4。

2用户查、增、改模块数据流图
6。

4。

3管理员查、增、改、删模块数据流图
6。

4.4超级管理员查、增、改、删模块数据流图
列
6。

4.5超级管理员定制岗位权限模块数据流图
7其它需要说明的问题
，、需求报告由甲方提出基本需求，由开发方从技术层面进行认可，经双方认可后,作为正式的项目需求报告。

，、允许甲方(客户)在项目实施过程中，对需求报告的功能进行局部调整,调整需经双方认可后，作为以后开发和验收的依据。

,、如果在开发过程中需要对软件功能进行调整，合作双方应友好协商解决,如果增加费用过大，甲方应支付此项费用。

以保证项目的顺利实施。