（管理知识）企业管理软件的需求描述方法

(管理知识)企业管理软件户沟通；从开发者的角系统的实现；从实于系统的发布与实施。 ，它可用来搞清各部门之间的领导关系,每个部门内部的人员配备情况,职责分工等也应进行简单的对分析人员理解是需求获取步骤中的基础工作之一。述，建议采用表格的形式，如： 别不全，对以后的功能识别会造成盲区。 的作业流程首先要有一个来，然后对每来。详细业务来描述，便于管理。 图的过程,实际上是作业流程条理化的过程调研的结果,需要得到用户的认同,这就需要和用户交流调研的结果,档要通俗、易懂,不能采用专业术语。■可以作为培训实施人员与技术服务人员的文档■对高层管理人员的实际需求调查的不清楚.这一方面是由于用户没有接触过计算机,对采用计算机后的管理会是工操作的哪些内容?能够作哪些现在手工无法完成的工作等等没有清楚的概念,因此用户无法将这些问题反应出来.另一方面说明分析人员没有经验,对原始材料挖掘不深,不能从用户提供的材料中提炼处来用户的真正需求,不能找到当前管理中的问题。■对各种业务之间的总体关系没有表达出来.采用直式业务流程图可以将企业的每一种业务的处理流程清楚地表达出来,但是各业务之间的联系却没有表示出来,单看一种业务的流程图很清楚,但是却不能综合在一起,没有整体的概念,作为需求分析的文档,在这方面表达的不够完整。■在不利用工具的情况下,画法烦琐。如关流程图中描述出的内容，需要用文字进行详细描述。 ，应该将单据的描述格式化，需要描述的内容包括：体直观地说明问题；填那些数据项。单据中哪些数据是必填的，哪些是可以不用填的。平均每天产生多少条记录，高峰期的数量；购/销售/生产)，按生成的方式来分类(手工录入型/自动生成型)，按格式变化的频繁程度来分类(易变型/稳定型)，按表现形式来分类 (列表型/卡片型)等等。单据之间的关系：引用关系等等。面的条目进行详细的刻画。 。商务规则一般是隐，但是有些复杂的商 文将用户的需求描述地完整、准确、易于理解即可。对功能需求比较复杂的系统(如超方法应便于用户部门的需求，这样也便于组织用户进行评审。以下是分类方法的举例：产车间、财务科、统计科、总经理等；据查询、记帐、帐本查询、统计报表、系统维护等；........对功能需求的分类在不同的层次可以采用不同的方法。进行对应。对每一项功能的描述，应指明用户的输入(input)、处理方法(process)、系统的输出(output)及对此项功能的其他要求。功用户权限可分级，要有操作日志等。 功能需求与性能需求是密不可分的，笼统的性能需求没有任何意思，的一项。们习惯于从组织维来看与了哪些流程的哪些活动(功能)，在某个功能上操作了哪些数据，对这些数据进行了哪些待系统，即某个功能操理，这个功能属于哪个以做哪些处理，这之间关系的刻画可以采用矩阵的方式： 对于上表中列的排列顺序可以根据面向的读者的不同而改变。容有： (1)新系统对应用模式带来的变化则等的改变。 许，可将界面原型与数据库表、字段连接起来，真正做出系统雏形，即快速原型法。客户与用户业务高层；；IT主管与开发人员，包括设计人员、编码人员、同行的专家；不同的读者对文档的阅读需求是不同的，他们关注的信息是不同的。我见过了很多次需求评审的失败(如果做好需求评审我会另外再撰文描述)，总结下来我认为和需求描述没有区分读者群是很有关系的。 求是不关心的，所以度抽象。由于他们的所以要简短明了，能求，而忽略系统的目报告的编写上往往没的问题，在给企业的高层汇报时当然很难通过评审。 总体的了解，能够和其他的子系统衔接的很好，关注的焦点更具细的文档来描述能从开发人员的呢？一是开发人去描述，不符合动的角度来考虑问题，而不是功能；二是太多了，用户也没有时间静下心来去消化、吸收如此多的文档，需求毕竟不是小说，能够那么吸引读者。 T家述了。 项目经理、质量保证人员、测试人员、需也是分析人员常犯的。管理人员实际上最关心的是需求列表，如下表所示： 在此基础上项目经理、质量保证人员可以据此来进入项目策划过程，管理员可以识很难高效地开理的平衡决策是很重要的，实际上需求的优先级可能比需求本身更重要。档，而是多 个很重要的方面，为了提高文档的可读性可以借鉴下面的一些做法：在文档的描述中，适当运用