标签:
核心思想:使用该方法在需求分析阶段将用户和组织两个与系统紧耦合的要素解耦,使系统针对的资源与资源在系统中的流转过程(权限)在目标系统中高度内聚,最终设计出能够承受更大限度人员机构变动的系统,同时有效防止用户隐含需求不被发现。
方法简述:因为人员在系统中总是扮演某种角色的,同时业务逻辑希望面对的是系统中的角色,而非扮演角色的具体的人或组织,因此调研初期引入角色这一关键要素,调研过程中用这一要素尽可能叠代用户和组织两个要素,从而来削弱或解调耦合关系,使得用户和组织通过角色与系统之间保持一种松散的关系。
本方法分如下步骤:
1.识别主要要素
本方法的核心是用户、部门、角色、权限、资源五个基本要素,分别用U、D、R、P、M (User,Department,Role,Permission, Material)表示。首先要识别这些要素,亦即首先解决“有什么”的问题,可以通过向客户代表询问,象做判断题一样的方式对下列条目确认,然后帮助用户列举出五要素尽可能多的一些实例,最后帮助用户加以抽象,确定目标系统的五个基本要素的内容。
1). 用户U
a.系统管理员:负责分配由软件开发人员开发的权限的管理权限给权限管理员。
b. 权限管理员:负责将分配给自己的管理权限分配给管理员。
c. 管理员:使用权限管理员分给自己的权限将该权限对应的资源授权普通用户使用。
d. 普通用户:在自己拥有的权限范围内使用相应的资源。
e. 软件开发人员:按照已有的资源,开发相应的权限模块,包括分配权限的管理权限给权限管理员;权限管理员 分配权限给管理员;管理员分配资源使用权给普通用户等权限模块。
f.每个用户都隶属于一个部门,是一个或多个角色的成员。
g. 用户对资源的权限表现为拥有一个权限记录的集合,每个记录表示了用户对某范围资源的操作。此权限集合是 由系统管理员、权限管理员或者管理员在行使权限时产生、修改或删除,由用户拥有。
2).部门D
a. 部门在组织内是树形结构。
b. 有且只有一个根部门,根部门就是使用该软件系统的组织。
c. 每个部门都有名称、上级部门(根部门除外)、上级主管、部门负责人(可以是多个)、一定的成员,一般会 有仅隶属于本部门的资源。
e. 部门可以有多个子部门,子部门还可以有多个子部门。
3).角色R
a. 每个角色有一个固定的名称。
b. 每个角色至少有一个用户。
c. 每个角色至少对一种资源有某种权限。
d.每个用户分类[1).a至1).f]是一个角色。
e. 角色常常对应了一个权限集合。用户可以通过加入角色,成为角色的成员,进而拥有权限集合。
4).权限P
a. 每个权限有一个名称,有一个具体的意义,可以表示出谁(角色|部门|具体用户)对什么资源可以进行哪些操 作。
b. 每个权限可以在至少一个资源上使用。
c. 每个权限可以授给某个部门的某个角色,不可以授给单独的一个部门或一个角色,一般不直接授给某一个用户 。如果需要授给单独的一个部门或一个角色某个权限,可以使用“授给根部门的某个角色”,或“授给某个部门的 所有角色”的方式实现。
d. 授权时不指定具体的资源,则此授权是权限管理员授权给管理员
e. 授权时指定具体的资源,则此授权是管理员授权给普通用户。
f. 授权可以拟向执行,即收回授权。
g. 权限记录。
1.权限记录一般是正向权限,这样可以降低权限记录的复杂性。
2.权限记录中确定了资源范围,用户如果拥有该权限记录,则有对该权限记录指定范围内的所有资源的权限,同 时包括对资源进行哪些操作。
3.权限记录能判断包含关系,即一个权限记录是否包含另外一个。
4.为了组织好权限记录,建议采用权限集合的形式。
h. 权限有不同的类型,依据资源类型的种类,权限可以是数据权限,也可以是功能权限,特别地,对数据的管理 权限是一种功能权限,数据权限包括:读、写、添加、删除等,功能权限主要指是否可以使用某功能。
5). 资源m
a. 资源包括数据资源和功能资源。
b. 资源使用树状管理,不同的资源在不同的树上,资源在系统中以森林的形式存在
(在这里引入树丛的概念,管理方式相似的树称为树丛,森林可以由很多树丛构成,也可以由一个树丛构成)。
c. 每种资源对应有一个或多个权限。
e. 在资源树上某一节点授权可以指定是对该节点还是对该节点下的所有分枝。
2.按照5)识别出的每个树丛,按下面的方法进行全排列,分析步骤1中识别出的各要素之间的关系,形成一个列表。
如果说第一个阶段解决"有什么"的问题,那么第二个阶段解决"做什么"的问题。
要素之间的直接和间接关系全排列共有P51+P52+P53+P54=205种,每种排列对应未来软件中的一个可能存在的功能模块或用户界面,这些排列表示的意义通过其它的需求分析方法调研,有些用户是可以能明确地表达出来的,例如P51 +P52表示的是如下表的25类功能需求,如下表:
表1 p51+p52表示的功能需求
|
U |
D |
R |
P |
M |
U |
用户管理需求分析 |
用户与隶属部门 |
用户拥有的角色 |
用户拥有的权限 |
用户可使用的资源 |
D |
部门拥有的用户 |
部门管理需求分析 |
部门中有那些角色 |
部门拥有的权限 |
某部门拥有的资源 |
R |
角色成员 |
某角色的部门分布 |
角色管理需求分析 |
某角色拥有的权限 |
某角色拥有的资源 |
P |
某权限的管理者 |
有某权限的部门 |
拥有某权限的角色 |
权限管理需求分析 |
某权限针对的资源 |
M |
资源拥有者 |
拥有资源的部门 |
拥有资源的角色 |
资源的权限 |
资源管理 |
表中的内容多数用户是可以提出来的,这些排列在具体的系统中对应不同的功能及界面。然而P53,P54表示的是什么需求?在对用户进行调研时用户多数是不能明确提出来的,这一部分往往就是用户的隐含需求,因为其它的需求分析方法多数是挖掘式的,所以很难保证用户这些隐含需求能被调研出来,而本方法是先排列出来这些或许存在的功能,再进行调研,请用户判断是否需要,因此是不容易被忽略的。
标签:
原文地址:http://www.cnblogs.com/cangqiongbingchen/p/4530752.html