如何定义需求.docx

、确定组织和角色确定角色的时候要从查阅需求来源开始。角色可能是人或物。寻找句子的主语；查阅规格说明书的术语表；简单阅读规格说明和建立“名单”：做与系统相关工作的人员和事件的列表。好的检查程序和健全的原则：在最终分析中如果候选角色没有任何用例，那他根本不可能是角色；并且如果在用例中也没有任何交流，也显示不是角色；如果候选角色没有做任何事情，但是拥有信息，那他可能是候选对象，而不是角色；如果角色名称太过特殊，应该设法确定名字背后的角色；如果角色名称太过普通，应该将这些角色在各自特殊角色的基础上划分为更为详细的角色名。、确定组织和域对象每个必须被表示或维护的实体都是一个潜在域对象。从规格说明出发。寻找不是主语的名词、回顾术语表。域对象分层：表示对象和维护对象（时间计划表、约定、任务、事件）、文档和报告、通知、用户界面。、为每个角色确定和编制用例采用用例分层模式。不要被表面的业务流程所迷惑，透过表面，看到背后的商业需求，你会发现需求原来非常稳定，这么多年来其实变化不多。也不需要急于知道所有的细节性的需求，只要了解比较重要的20的需求，其实就可以开始进行系统的设计和编码了。把眼光放在商业需求上，最终的业务流程才能最大限度的满足需要，IT系统也能面临少一点的“需求变更”。从商业需求中提取重要的元素，分析这些元素的行为和相互之间的关系，我们就可以得到一个重要的东西：领域模型。领域模型应该来源于企业的商业活动，而不应该是IT系统的业务流程。实际上，在业务流程的背后，有一个更加根本的因素商业需求。商业需求才是真正的需求，业务流程只是一种实现手段而已。其次，我觉得那就是一些规章制度，如果没有这些限制，说明业务流程是可以由我们开发人员进行定制的。那么在进行调查用户的需求的时候，就要问他们的主要业务是做什么？业务目标是什么？为了达到这个目标，他们都必须要做的事情有哪些？而不是去追问他们的业务流程。如果有规章制度，那么就要随后问，哪些业务目标是在规章制度的限制下，有一定的流程的？这样进行需求的分类，可以很快了解系统的真正目的是什么。企业的数据模型即企业中的信息载体有哪些？以及对这些信息载体的详细刻画，包括企业的各种单据、帐本、报表的描述。在需求报告中，应该将单据的描述格式化，需要描述的内容包括：单据的用途，即单据用在什么地方？单据的格式：需要明确的画出来，并有实际的有数据的样例，能够具体直观地说明问题；单据中的数据项的具体描述：长度、类型、计算生成方法、约束条件等；单据的数据项是由哪些不同类型的角色来填写地，包括用计算机可以填那些数据项。单据中哪些数据是必填的，哪些是可以不用填的。单据流量：平均每天产生多少条记录，高峰期的数量；单据的分类：可以从多个角度上进行分类，如：按业务类型来分类（采购/销售/生产），按生成的方式来分类（手工录入型/自动生成型），按格式变化的频繁程度来分类（易变型/稳定型），按表现形式来分类（列表型/卡片型）等等。单据之间的关系：引用关系等等。同样对于需要的报表与帐本也可以参照上面的条目进行详细的刻画。对每一项功能的描述，应指明用户的输入（input）、处理方法（process）、系统的输出（output）及对此项功能的其他要求。五元组组织，流程，功能，数据，业务逻 辑，对于用户来讲，他们习惯于从组织维来看待系统，即某个部门有哪些岗位，每个岗位参与了哪些流程的哪些活动（功能），在某个功能上操作了哪些数据，对这些数据进行了哪些逻辑处理；对于开发人员习惯于从功能维来看待系统，即某个功能操作了哪些数据，对这些数据进行了哪些逻辑处理，这个功能属于哪个流程，可以由哪些岗位来使用；对于设计人员可能习惯于从数据维来看待系统：即系统中有哪些数据，在这些数据上可以做哪些处理，这些处理用OO的思想来看即是对数据对象的操作。对以上的5个基本元素进行描述实际上就是系统建模的过程，为确保模型的可操作性，除了上面的5个基本要素外，还需要重点描述的内容有：（1） 新系统对应用模式带来的变化包括对企业的组织结构、作业流程、单据帐本报表等的格式、商务规则等的改变。（2） 新系统的界面模型用开发工具将用户操作界面快速画出来，使用户心中有数。若时间允许，可将界面原型与数据库表、字段连接起来，真正做出系统雏形，即快速原型法。需求分析应有成果：1、 各业务手工办理流程文字说明；2、 各业务手工办理流程图；3、 各业务手工办理各环节输入输出表单、数据来源；4、 目标软件系统功能划分（示意图及文字说明）；5、 目标软件系统中各业务办理流程文字说明；6、 目标软件系统中各业务办理流程图（模型）；7、 目标软件系统中各业务办理各环节数据、数据采集方式、数据间的内在联系分析。8、 目标软件系统用户界面图、各式系统逻辑模型图及说明UML方法分析步骤一般的应用系统又是各组成部分：问题论域、人机界面、数据管理、任务管理，在OOA阶段重点对问题论域进行分析，对人机界面、数据管理、任务管理等问题，OOA一般较少或没有分析，而是留待OOD阶段解决。1、 调研、识别系统需求；2、 分析问题领域：主要任务是充分理解领域问题和项目投资者及用户的需求，对需求进行抽象，提出高层次的解决方案）；（1） 确定系统范围和系统边界；（2） 确定系统的约束（环境和条件）；（3） 定义活动者；（4） 确定系统的综合要求（功能、性能、运行）；（5） 确定系统的数据要求（名称、范围、类型、数量、特点）；