........项目管理者联盟
对功能需求的分类在不同的层次可以采用不同的方法。项目管理者联盟
对每一项功能应有一个功能编号，以便于与功能规格说明书中的章节进行对应。对每一项功能的描述，应指明用户的输入(input)、处理方法（process）、系统的输出(output)及对此项功能的其他要求。功能需求还应注明使用此功能的岗位。对系统管理员要求的特殊功能可以在此注明，非特殊要求可以在需求分析规格说明书中详细论述。如用户权限可分级，要有操作日志等。项目管理论坛
对具体功能需求采用USE CASE的描述方式不失为一种好的方法，如：
 项目管理者联盟
（表3）项目管理者联盟
功能需求与性能需求是密不可分的，笼统的性能需求没有任何意思，必须具体到某项功能需求上来，这是分析人员在分析系统时容易忽略的一项。
对上述的5个基本元素可以将他们描述为一个五元组〈组织，流程，功能，数据，业务逻辑〉，对于用户来讲，他们习惯于从组织维来看待系统，即某个部门有哪些岗位，每个岗位参与了哪些流程的哪些活动（功能），在某个功能上操作了哪些数据，对这些数据进行了哪些逻辑处理；对于开发人员习惯于从功能维来看待系统，即某个功能操作了哪些数据，对这些数据进行了哪些逻辑处理，这个功能属于哪个流程，可以由哪些岗位来使用；对于设计人员可能习惯于从数据维来看待系统：即系统中有哪些数据，在这些数据上可以做哪些处理，这些处理用OO的思想来看即是对数据对象的操作。对此五个基本元素之间关系的刻画可以采用矩阵的方式：
（表4）项目经理圈子
对于上表中列的排列顺序可以根据面向的读者的不同而改变。
项目管理者联盟
对以上的5个基本元素进行描述实际上就是系统建模的过程，为确保模型的可操作性，除了上面的5个基本要素外，还需要重点描述的内容有：项目管理者联盟
（1） 新系统对应用模式带来的变化pmp.mypm.net
包括对企业的组织结构、作业流程、单据帐本报表等的格式、商务规则等的改变。pmp.mypm.net
（2） 新系统的界面模型项目经理博客
用开发工具将用户操作界面快速画出来，使用户心中有数。若时间允许，可将界面原型与数据库表、字段连接起来，真正做出系统雏形，即快速原型法。
项目管理者联盟
2 阅读需求文档的4类读者
pmp.mypm.net
需求报告的最终目的是给人来阅读的，所以一定要考虑需求报告的读者群，有4类角色可能阅读企业管理系统的需求文档：项目管理者联盟
客户与用户业务高层；项目管理者联盟
用户的中层管理人员与具体人员；项目管理者联盟文章
用户IT主管与开发人员，包括设计人员、编码人员、同行的专家；项目管理者联盟
项目管理人员：包括项目经理、质量保证人员、测试人员、需求管理员、配置管理员、计划人员等等；转自项目管理者联盟
不同的读者对文档的阅读需求是不同的，他们关注的信息是不同的。我见过了很多次需求评审的失败（如果做好需求评审我会另外再撰文描述），总结下来我认为和需求描述没有区分读者群是很有关系的。针对上述的4种分类，我们具体的来分析一下每类读者的特点：
（1） 客户与用户业务高层项目经理博客
他们关心的企业是系统的目标性需求，关心的是系统总体的功能框架，关心的是系统解决了哪些管理问题，对具体的需求是不关心的，所以给他们阅读的文档应该是从总体上来描述，要高度抽象。由于他们的工作很忙，很难有比较长的时间来读这些材料，所以要简短明了，能够用1页纸说明问题的就要不要用2页纸，而且一般都要给高层进行需求汇报，需要配上语言说明，因此采用PowerPiont片子也就成了一种常用的方法，讲解需求与讨论一般应掌握不要超过1小时。需求人员常犯的毛病是过多地关注了企业的细节性需求，而忽略系统的目标性需求，所以在安排需求获取的步骤上、需求报告的编写上往往没有抓住企业高层最关心的问题、没有抓住根本性的问题，在给企业的高层汇报时当然很难通过评审。
项目管理者联盟
（2）用户的中层管理人员与具体人员PgMp.mypm.net
企业的中层管理人员关注的是企业的局部需求，他们要求对自己的负责的局部系统能够有总体的了解，能够和其他的子系统衔接的很好，业务流程很流畅，覆盖了自己需要的所有业务流程，能够通过系统起到控制作用就行了。具体的操作人员更关心自己的的哪些活动是否在系统中都能处理，软件是否可以很容易地操作，他们关注的焦点更具体，要求更直观。所以对这类的读者可以通过比较详细的文档来描述需求了，当然应该以他们习惯的思维方式来描述，不能从开发人员的角度来描述。我看到过很多几百页的需求文档给用户去阅读、去评审，结果要么用户不置可否，要么直接讲看不懂，为什么呢？一是开发人员在文档中分子系统、分模块、分功能点一层深入下去描述，不符合用户的思维习惯，他们希望能够从业务流程、业务活动的角度来考虑问题，而不是功能；二是太多了，用户也没有时间静下心来去消化、吸收如此多的文档，需求毕竟不是小说，能够那么吸引读者。
项目管理者联盟文章
（3）用户IT主管与开发人员，包括设计人员、编码人员、同行的专家项目经理圈子
大多数分析人员可能最擅长的就是些写这类的文档了，往往也是那这类的文档给所有的读者看，其问题我们上边都说了，这里我们就不赘述了。项目管理者联盟
需要注意的是在描述需求时候传统的做法是以功能为主线，来展开描述，实际上如果是以数据为主线来描述需求也是一种很好的办法，在我们上面谈到的五元组中，从数据的角度来分析系统可以更容易实现向OOA、OOD的切换。
项目管理者联盟
（4） 项目管理人员：包括项目经理、质量保证人员、测试人员、需求管理员、配置管理员、计划人员等等项目管理者联盟
把拿给开发人员看的需求文档给管理人员看，这也是分析人员常犯的毛病。管理人员实际上最关心的是需求列表，如下表所示：pmp.mypm.net
（表5）项目管理者联盟
在此基础上项目经理、质量保证人员可以据此来进入项目策划过程，测试人员可据此进入测试策划过程，需求管理员、配置管理员可以识别配置项制定相关的活动计划。没有这张表管理人员就很难高效地开展他们的管理活动，也就谈不到最基本的需求复用了。在上述的表中，需求的优先级是很重要的一列，对项目经理进行项目管理的平衡决策是很重要的，实际上需求的优先级可能比需求本身更重要。
根据上面描述的论述，我们可以看出需求文档不是一个文档，而是多个文档，如：项目管理者联盟
（表6）
3 需求描述的表示技巧
项目管理者联盟
上面我们谈到了，需求文档是人与人之间交互的文档，是不同类型的人之间交互的文档，因此需求文档的可读性是一个很重要的方面，为了提高文档的可读性可以借鉴下面的一些做法：项目经理博客
在文档的描述中，适当运用链接，增强文档的可读性；bbs.mypm.net
多用图表，如某企业的业务与票据之间的关联关系可以用矩阵的方式描述为：
（表7）service.mypm.net
多用穷举的方式，以便于发现遗漏的需求；项目管理者联盟
通过适当的换行来提高可读性 ；项目管理者联盟
采用黑体、斜体、下划线、颜色等多种方式来突出重要内容；项目管理者联盟
定义标准的术语，以减少二义性，减少文档的页数；项目管理培训
在功能需求的描述中，对于类似的、统一的功能可以单独地进行详细描述，其他地方进行引用，或做为术语进行定义，以简化文档，减少重复。如；bbs.mypm.net
2 录入功能项目管理者联盟
2 打印功能
2 条件查询功能PgMp.mypm.net
2 排序功能等等
项目管理者联盟
结 语
尽管你按照上述的方法去做了，也不要期望能够编写出一份能体现需求应具备的所有特性的文档，无论你如何去细化、分析、评论和优化需求，都不可能达到完美，但是你能够做到“可接受”，写一份客户、用户、开发人员、管理人员都认可的一份需求，而不是完美的需求！
作者简介：blog.mypm.net
任甲林，9年软件工程经验，曾任浪潮集团山东通用软件公司过程改善部经理、开发部经理、总裁助理等职，现工作于普安联盟软件技术（北京）有限公司。参与或主管了近50多个项目，包括MRP系统、商业MIS系统、虚拟POS机、旅游ERP系统、企业DRP系统、可复用软件框架系统等，在工作中积累了大量的研发管理经验，对CMM、软件复用技术有较深的理解。 项目管理者联盟
|
