需求模型总结范文.docVIP

　　 　　需求模型总结一:我用到的需求分析方法总结 　　用例分析法 　　用例分析法，是来自面向对象的分析方法。用例描述系统的用户和系统本身之间的交互过程，从而对如何使用系统提供了一种详细的陈述，获得对系统需求的了解。用例分析，是获取系统功能需求的一个重要技术。 　　用例中，用户术语叫actor。用户不必是真的人，如果要开发的系统系统对另外一个计算机系统提供服务，那么，另一个系统就是这个系统的用户。 　　一个用例有多个场景组成，一个用例中，所有的场景有着相同的用户目标。一般包括一个主成功场景和几个附加的扩展场景，例如在一个网上超市系统，“购物过程”是一个用例，这个用例中，共同的用户目标就是完成购物。但这个目标可能成功完成，也可能因为什么原因而失败。这样，就有成功实现购物的主场景，还有多个购物失败的场景如信用卡失败，货物售空等等。 　　用例中的一个复杂的步骤可能是另一个用例。这就是用例之间的包含关系。 　　UML用例图重点说明两种关系 　　用户和用例的关系。就是那个用户启动了哪个用例。 　　多个用例之间的关系。比如，一个用例包含了其他的用例 　　用例的几乎全部的价值在于内容。用例图本身的价值不大。你在使用用例进行分析的时候，不必过多的致力与用例图，应该关注与用例的正文内容。这才是这种技术的真正价值所在。 　　除了简单的包含关系，UML中还定义了其他的许多关系。但我认为，除了包含关系，以外的其他关系都可以忽略。其他关系除了导致混乱和复杂，几乎没有什么价值。 　　千万不要把用例做的太复杂，通常做的过少比做的过多危害要小。如果做的太少，一个短小易读的文档，构成发问的起点。如果做的更多，任何人对它将难以阅读，难以理解。 　　用例可以按照等级划分，分为系统用例和业务用例。系统用例重点说明软件系统的交互，业务用例讨论的是一种业务如何响应来自客户的事件。 　　还有一种更详细的分级方法海级用例，鱼级用例和风筝级用例。海级用例描述主参与者和系统之间的一次完整交互，不是任何其他交互过程中的一个步骤。包含在海级内的用例是鱼级用例。更高级别的风筝级用例，风筝级用例就是上面的业务用例。如果适应更广泛的业务交互。 　　数据流分析法 　　这个方法来自传统的结构化分析方法。使用数据流图描述系统的数据处理模型。 　　注意数据流图描绘的是系统的逻辑模型，图中没有具体的物理元素，只是描述信息在系统中流动和处理的情况。 　　数据流图在分析和设计的前期使用，数据流图中的处理，是逻辑上存在的一个过程，开始时不要考虑对应任何具体的软件实体（不要把处理当成了模块）。在输入数据和输出数据确定的情况下，需要什么样的处理，才能由输入产生输出？--通过这种思路获得对系统功能需求的理解。最终究竟由哪个软件实体来承担一个处理，是设计阶段的事情。最终，有可能一个处理最终由多个软件实体承担，也由可能，多个处理由一个软件实体承担。甚至可能，某些处理是人工的过程，最终不对应任何的软件实体---哪部分处理通过用户手工完成，也是设计的内容。 　　数据流图中的数据存储也不是实际存在的物理实体。 　　数据流图的基本要点是描述“做什么”而不是“如何做”。数据流图的意义在于分析，而不在于设计。避免数据流图中的设计的味道。 　　许多人画不好数据流图，是因为在画数据流图的过程中。因为他们把数据处理想象成模块或者对象，把数据存储看成了具体的数据文件或者数据库。 　　另外不要在数据流图中，表现分支和循环，这样会造成混乱，画不出正确的数据流图。数据流图中，描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。--有时候你可把判断条件当成是输入的数据。 　　面向对象与数据流分析 　　是否可以在面向对象设计中使用数据流分析法，是一个有争议的话题。大部分讲面向对象设计方法的书，都反对在面向对象的方法中使用传统的结构化的方法。我个人认为，可以使用，但要小心使用。有下面的理由 　　数据流图，涉及了系统内部的分析。而用例分析方法不涉及系统的内部。只通过用例分析系统，总是觉得分析的不够彻底。 　　有些系统，本身就是一数据处理为主要任务的，应用的逻辑集中在数据的处理上而不是交互的过程上，不适合使用用例分析法。 　　数据流图流传很久，容易被人看懂，容易在交流中使用。而用例图使用的人少，许多人对它不熟悉。 　　在面向对象的设计方法中，使用数据流图分析后，就要在数据流图的基础上抽象对象，数据流图上的每种元素数据流，数据存储;外部实体和数据处理，都可能用来抽象对象。 　　一般的意义下，在面向对象的程序中，对象或类构成了系统的逻辑结构。而模块反应了系统的物理结构。模块的概念往往和具体的编程语言相关，比如在C++中，模块对应独立的编译单元。一个编译单元中，包含一个或多个紧密相关的类实现。 　　模块是一个很不精确的概念。在实际的交流中，甚至在一