2013-07-29 09:51:10 缘，妙不可言
清润老师，我现在要做 SOA服务治理的 建模，但是这个 基本不是企业应用，没有什么业务流程，不知道怎么下手，都是 日志收集分析、服务发布配置、权限控制、流量控制、调用次数统计、分析预警、服务依赖关系 查看 这些
非交互密集型
2013-07-29 10:04:59 青润
这些一般属于非功能性需求。是需要技术人员根据系统功能，特性抽象提炼出来的，其业务模型只能根据情况来分析,忌盲目照搬和完全拍脑袋，要熟悉全系统业务后加上经验才能做的较好
2013-07-29 10:06:17 缘，妙不可言
没有流程可言，不知道怎么建模，怎么把 服务这个核心对象的领域模型搞出来
2013-07-29 11:24:43 青润
这些的业务流相对简单，但逻辑繁杂,比如目志,需要分析所有业务用例中有哪些需要保存日志，日志在用例该点的用途和信息。
2013-07-30 16:06:24 缘，妙不可言
权限控制 属于 非功能性需求么？
2013-07-30 16:36:09 青润
一般不属于。
2013-07-30 16:45:04 缘，妙不可言
为什么呢
2013-07-30 16:45:35 缘，妙不可言
和日志分析 、流量控制 啥区别？ 为啥后两者属于非功能性需求呢？ 清润老师请指点
2013-07-30 23:11:32 缘，妙不可言
清润老师
2013-07-30 23:11:47 缘，妙不可言
我现在负责 SOA服务治理平台的需求建模
2013-07-30 23:20:33 缘，妙不可言
/疑问
2013-07-31 00:59:29 缘，妙不可言
我知道了，对于我这个 SOA平台来说，权限控制、流量控制就是一个功能性需求，因为我这个系统平台就是要做这个的
2013-07-31 07:05:58 青润
实际上是这样的。
这里面涉及到软件系统的使用对现实社会的改变。
在软件出现以前，权限是靠任命和行政力量来规范的，所以，那时候，只有岗位和职位对应的权利，并没有权限管理的概念。
所以在最初的软件系统中，权限管理属于非功能性需求，因为用户是无法提出来这个要求的，也不会描述，只能靠技术人员的分析后获得。
而在现在，软件系统应用了差不多快20年的时间后，用户也可以明确地提出来关于权限的功能要求，这使得一些软件实现从后台走到了前台，一些需求就显性化了。
所以，现在来说，哪怕是普通业务系统，权限管理也属于功能性需求了。
参考wiki百科的说法，也论证了这个过程：
功能需求（functional requirement）为一软件工程用语，功能需求定义一个软件系统或组件的功能，也是一个系统需提供的功能及服务[1]。功能可以用一组输入、行为及输出的组合来表示。功能需求可以是计算、技术细节、数据处理或其他说明系统希望达成功能的内容。功能需求会以非功能性需求（或是质量需求）为其基础，后者会描述设计或实現时的限制条件（例如性能需求、保安性或可靠度等）。
在系统工程及需求工程中，非功能性需求（Non-functional requirement）是指依一些条件判断系统运作情形或其特性，而不是针对系统特定行为的需求。和非功能性需求相对的是功能需求，后者会定义系统特定的行为或功能。非功能性需求也可以视为为了满足客户业务需求而需要符合，但又不在功能需求以外（应该是：内，估计是翻译错了）的特性。
一些非功能性需求在一定阶段会转化为功能性需求，比如说，安全本身是非功能性需求，但是当某个安全模块成为一个标准件的时候，用户要求必须采用某个安全标准使用该模块达到这个安全模块可以做到的诸如文件必须经过安全检查，这时候，一个非功能性需求就变成了功能性需求。
————————————————————————
以上为对话内容。
本文对话，对话人已经把内容整理成blog单独发表为：http://beyondyuefei.iteye.com/blog/1919258
不过，这个话题中，可能会有朋友提出一个疑问：这难道不是显性需求和隐性需求的转换么？
实际上，显性和隐性，功能性和非功能性都是需求的属性类型，功能性需求也可以有显性和隐性之分，非功能性需求也一样有。
至于如何区划分，实际上要看客户是否能明确提出来，而且是否属于功能实现的一部分，有些非功能性需求也许永远不可能变成功能性需求，比如：系统部署时的服务器数量需求以及服务器的部署架构关系需求等，一下子进行描述还真不能举出太多例子来。很多时候，就事论事和遇到问题解决问题才是程序员最应该擅长的，可是僵化的就事论事往往会误入本本主义的误区，所以，很多时候，很多事情都是无法立刻定性的，也许需要经历了才知道什么才是当时最佳的解决方法。
拓展来说，以前曾经批驳过关于最佳实践的说法，现在我仍然认为只有面对具体问题的时候才能找到最佳实践，抽象的最佳实践是不存在的，完全是本本主义的典型案例。