mySagasoft.MisCore 需求分析说明书
作者：sagahu@163.com，2013-05-07，太原
1. 文档概要
本文分析、总结企业管理类软件在权限管理方面的一些共性需求，包括功能操作权限、菜单权限、部门权限、字段权限几种。
本文归纳的需求模型是针对数据共享式管理软件的，即传统MIS型软件；不涉及工作流/步骤类型软件。
本文面向研讨与审议，所以仅简略、概要，但是明确地定义与说明需求模型，详细说明文字忽略。
2. 术语定义
2.1. 权限管理三个环节
权限管理包括三个环节：（1）登录时的身份认证；（2）使用软件时的界面控制；（3）提交操作请求时的许可验证。
2.1.1. 登录时身份认证
最常见的身份认证就是，操作员输入用户帐号与口令数据，进行登录，系统后台验证帐号/口令对，从而确认操作员身份。其实这是权限管理工作的开始。
传统桌面应用程序，一般会在登录成功后把用户帐号对象缓存在进程空间里；而Web应用程序常常会把用户帐号对象缓存在个人会话里。
最简单的身份缓存的数据内容就是帐号名/口令，常常再增加帐号ID，也有人再增加一些权限与菜单控制数据。高级的有缓存登录身份认证返回的密钥或者passport。
2.1.2. 使用软件时的界面控制
就是在软件使用时，根据当前操作员的许可权限来控制菜单、页面按钮，甚至控制数据行、字段，等等。
2.1.3. 提交操作请求时的许可验证
有了前面的软件界面控制，还不是完善的权限管理。
例如，你向第三方子系统开发者提供中间件功能接口，对方对你的调用是不走你的界面的，人家只是调用你的服务接口。当对方提交操作请求（带着数据）时，你会认为他在半个小时前通过了身份认证，就不需要再验证其操作请求被许可吗？
还有一种情况，就是软件界面控制在某些情况下会被用户的某些特殊数据绕过。虽然这种情况会存在，但是属于少数情况。所以在自己开发自己的应用界面层时，可以偷懒不作提交请求时的验证。
总之，完善的权限管理，需要包含这三个环节，而第三个环节却是容易被初学者忽视。
2.2. RBAC相关
2.2.1. 角色（Role）
Role是RBAC模型中的概念，用来解耦权限许可与用户帐号的直接联系。
角色是权限许可的集合。RBAC模型通过给角色分配权限许可，再把角色赋予用户帐号，从而使得用户帐号间接得到权限许可。这样的解耦使得用户帐号可以灵活地跨职能部门来调动，只需重新赋予角色即可。尽管不少实际应用中允许给帐号直接分配权限许可，但是决不是推荐标准。
在RBAC2中，需要考虑不同的业务资源需要相应的功能权限许可，结合实际的资源范围/职能部门划分，常常需要把角色设计到相应职能部门下面。本方案就为角色设计了隶属部门。
这样，“角色”作为软件系统权限管理范畴的一个概念，一方面负责分类组织相关权限许可；另一方面又负责分门别类相关用户帐号。
2.2.2. 角色（Role）与职务（Job）的关系
岗位、职务、职位、职务级别、职称等级这些概念都是实际业务中来的，都会在企业组织中对应一定的特权与职责，就可能与软件系统的权限管理发生某种对应关系，因而会归入软件需求。
虽然它们并不好区分，但是可以分为两大类：“职”与“级”。例如说“处长”，首先会让人明白是初级干部，应该享受处级干部的待遇，从而在软件系统中对应了处级干部的一些功能许可；然后人们会问是哪个处室部门的处长，当归位到财务处的时候，在软件系统中又需要对应他一些功能许可与业务范围。这里把岗位、职务、职位统称为职务（Job），把职务级别称为等级（Joblevel）。总结二者的区别如下：职务（Job）必然有自己的隶属部门，脱离开隶属部门则只剩下等级（Joblevel）了，有等级不一定有职务。例如“处长”表示处级干部的级别，而“财务处长”表示隶属财务处的职务；并且任命一个人为财务处长并不一定就必须同时把他的职称等级提升为“处长”级别。所以软件系统把它们设计为2个不同的对象。
职务（Job）是实际业务中既包含权限又具有其它业务意义的概念，角色（Role）是软件权限模型中管理权限许可的概念。所以，如果软件系统仅仅需要实现职务（Job）的权限许可，那么用角色（Role）映射前者就可以了，实践中不少系统确实就是这么玩的。否则，再单独实现职务（Job）特有的业务意义就可以了。
2.2.3. 用户帐号（User）
用户帐号（User）代表企业雇员（Employee），前者并不是后者，也不能完全代替后者，但是在实现很多软件功能时代表后者，具有很大的方便性。
例如人力资源管理业务中，登录系统时仅仅需要用户帐号包含的数据，不需要雇员包含的其它很多信息的。这就表明二者不能互相代替。就算有些实践中帐号用雇员姓名，其实也是把雇员默认成帐号了。
不少应用中不需要雇员的太多个人信息，仅仅必须登录数据及联系方式等少量个人信息，就可以省略雇员而只使用用户帐号了。本方案也仅限于用户帐号，以后需要雇员的时候可以再扩展。
2.2.4. 用户组（User group）
用户组的基本功能是要分门别类的管理用户帐号。
尽管可以设计每个用户帐号都有自己唯一隶属的组织结构/部门，但是当需要查看同一类功能相似的用户帐号时，按隶属部门来操作会感到不方便，这就需要使用“用户组”这个概念了。例如，在省、市、县三级的相应保化部门都有承担保化干事这类角色的用户帐号，就可以使用“保化干事组”把相关帐号组织到一起，而得到便利。
所以用户组基本功能设计为分类组织用户帐号，这一点在99%的同类项目中都是没有疑义的。但是肯定有人会发现，角色也是分类组织用户帐号的。如果二者功能完全相同，仅仅概念名称不同，那么就可以合并为一。所以一些简单的系统设计中只有角色，没有用户组。
这里参考一些应用实践，为用户组定义一些其它的功能：
（1）用户组不隶属于某个部门，仅仅组织管理某一类别的用户帐号；这点与角色不同。
（2）可以向用户组分配菜单权限，从而使用户间接得到个性化菜单，这点与角色类似，但是却可以解放向不同部门下类似角色分配菜单权限的麻烦。
（3）可以向用户组分配权限，包括功能权限，甚至字段权限，以及将来可能扩展的其它权限；这一点还是与角色相同。
（4）可以向用户组分配角色，从而使用户间接得到权限。又与角色不同。
（5）最后，当把用户帐号加进用户组时，就间接得到了用户组的菜单及其拥有角色的所有权限并集。
无疑，引进用户组增加了实现的复杂度，使用者也不好同时理解角色与用户组，但是确有其方便性。
2.2.5. 操作权限与资源权限
资源泛指软件系统中一切对象，包括业务实体、菜单/按钮/界面、报表、票据、流程/步骤，甚至数据表、视图、字段等等。
在最初的RBAC中，不考虑对软件系统中各种对象细分范围，只考虑允许/禁止何种操作，就是所谓的“操作权限”。但是当实际业务中需求特定业务对象才能进行某种操作时，就引出了“资源权限”的概念。
资源权限，就是特定资源才许可/禁止的某项操作。例如：批准报销单：（1）首先是保险单；（2）选定目标保险单；（3）可以批准它（它们）。就是说：资源权限包含2个要素：①资源种类、范围或个体、②特有的操作。二者总是绑定在一起的，所以分配时需要一起操作。这样一来，前面的“操作权限”，就可以看作隐式的（不需要特别指出种类、范围或个体）资源权限。
系统中的资源多种多样，因而资源权限也有多种。如菜单权限实现对匹配当前用户帐号的菜单控制。也有某些应用，特别强调从业务数据的角度来分配操作许可，可称为数据权限。
2.2.6. 菜单权限
当用户登录软件系统后，系统应该根据用户具有的操作权限与资源权限，自动为其生成相应的菜单与界面控制，可称为菜单权限或者界面权限。
常见界面权限实现有2种形式：（1）可见/不可见；（2）可用/不可用。
2.2.7. 部门权限
在企业管理软件实践中，最常见的情况可能就是：各项业务对象/数据隶属于各自业务部门，角色/操作员因部门不同而许可操作的数据范围不同。也就是说，企业组织结构，特别是部门，现实地划分了数据范围。这种权限需求可以看成数据权限范畴的横向切割。
所以，这种权限需求的本质是：首先以部门划分数据范围，然后追求将数据范围及操作许可灵活分配，可以称为“部门权限”。
2.2.8. 字段权限
在一些实际的应用中，对某些表格、单据，对不同的角色或者部门，要求可见性/可修改许可各异，可称为“字段权限”。这可以看成数据权限范畴的纵向切割。
2.3. 组织结构
2.3.1. 组织结构树
当前很多行业企业的组织结构是省、市、县几个大级别的多层次、上下级部门关系，或者层次更多一些。有很多的业务应用是全部，或者部分依赖于这棵“树”，其在应用系统中具有关键性的作用。
部门是组织结构树中的基本节点；部门有物理的，也可以为细分业务的虚拟部门。而职务/岗位可以看成一种组织结构节点，而员工是另一种组织结构节点。在软件系统权限管理方面，后二种业务概念常常通过角色与用户帐号来对应。
2.3.2. 对口业务上下级
结合多个行业应用分析，会发现还有这样一种情况。例如：省局保化处在保化业务上直接指导下属各市保化科工作，间接指导各市下辖各县保化办工作。像这种组织结构与上下级关系，仅仅是客户企业组织机构中的一部分，或者看成一个“子树”，却会跨越省、市、县三个大的层次而不局限于 “整个树”基本上下级关系，就可以称为对口业务。
对口有着自己独特的一系列部门及上下级关系，这就是所谓的对口业务上下级关系。开发应用系统，常常需要上级能找到对口下级，下级能找到对口上级。
3. 用例分析
3.1. 产品整体结构需求
3.2. 需求分解
4. 领域模型
4.1. 权限管理核心对象总图
5. 动态流程分析
5.1. 登录系统，自动生成菜单
5.2. 登录过程与身份认证
5.3. 请求操作与许可验证
