CHP02_需求分析.ppt

1、软件工程第2章需求分析，IBM缺陷放大模型，需求： 1，设计： 5，代码3360 10，测试： 20-50，操作和维护： 200，概要，2.1软件需求的概念什么是软件需求的分类需求分析过程2.2需求分析技术2.3需求(2)系统或系统组件应满足合同、标准、规范或其他正式规定的文件所要求的条件或能力。(3)反映上述(1)或(2)所述条件或能力的文件说明。软件需求的基本任务是准确回答“系统必须做什么”的问题。2.1软件需求的概念，软件需求按层次划分，业务需求反映组织或客户对系统和产品的高层次目标需求，在项目视图和范围文件中有所解释。业务需求描述了企业的一组概要目标，这些目标可能取决于要实现的多个用户

2、目标。用户需求文档描述了用户在使用产品时必须完成的任务，这在用例文档或场景描述中有所解释。用户需求描述了用户目标，这是特定的任务，但不是详细的细节。功能需求定义了开发人员必须实现的软件功能，这样用户就可以完成他们的任务，从而满足业务需求。2.1软件需求的概念，三类需求之间的关系，业务需求，项目视图和范围文档，用户需求，用例文档，功能需求，软件需求规范，非功能需求，2.1软件需求的概念，概要目标层，用户目标层，功能层，软件需求的非功能需求，非功能需求3360定义外部接口的具体细节；性能要求。设计或实施的约束和质量属性。2.1软件需求的概念，非功能需求，过程需求，产品需求，外部需求，软件交付，互操

3、作性，实现方法，标准，法规，成本，可用性，软件性能，存储空间，可靠性，可移植性，安全性，软件需求分析的困难，(1)客户不能说清楚，有些客户只是对需求有一种朦胧的感觉，当然，农民和牛的故事有些客户确切地知道他们想要什么，但他们不明白。我的鞋子是什么样的？“不知道如何假装理解”或“半懂如何成为专家”的客户是可怕的，2.1软件需求的概念，软件需求的复杂性，(2)需求本身经常变化，2.1软件需求的概念，需求变化的原因客户方：对信息系统的理解不足，业务需求表达不清晰，对自身业务的抽象不够，对需求的关注不够，与开发人员的合作不够，业务范围不断扩大，业务流程不断变化， 管理模式的不断创新，软件需求的复杂性，

4、(2)需求的频繁变化，2.1软件需求的概念，需求变化的原因软件人员：沟通能力低，对工程技术的需求差，需求人员的知识储备不足，对客户的业务流程研究范围缺乏了解，需求不确定，项目管理不清晰，需求描述不明确，对客户的合同约束不足，个人能力或经验不足。 软件需求分析的基本过程需求工程，2.1软件需求的概念，需求工程是指应用成熟的技术和方法来分析需求、确定客户需求、帮助分析师理解问题和定义目标系统的所有外部特征的学科。需求工程通过适当的工具和标记系统地描述要开发的系统、其行为特征和相关约束，形成需求文档，并支持用户不断发展的需求。需求工程的活动可以分为两类：一类属于需求开发，另一类属于需求管理。、需求工

5、程、软件需求工程、2.1软件需求概念、需求获取通过与用户沟通，观察现有系统并分析任务，从而开发、捕获和修改用户需求；需求建模(需求分析)为最终用户视为需求的抽象描述的系统建立一个概念模型；形成一个需求规范，以生成需求模型组件的准确的正式描述，作为用户和开发人员之间的协议；需求验证(requirement confirmation)以需求规格说明为输入，通过符号执行、模拟或快速原型等方式分析需求规格说明的正确性和可行性；需求管理支持系统需求演化，如需求变更和可追溯性。1.1软件需求的概念1.2需求分析技术功能分析数据分析1.4需求规范1.5需求确认1.6需求管理，功能分析工具，用例图序列图活动图

6、接口定义原型开发，2.3需求分析技术：功能分析，用例图，用例图是一种从系统外部黑盒视图描述系统的组织方法。用例是抽象使用系统的一种方式，用户通过用例与系统交互。用例图有三个主要功能：获取需求、在其他链接中扮演指导角色、指导测试、参与者、用例和连接，它们指的是在系统外部使用系统或与系统交互时扮演的角色。用例是参与者和系统之间的交互。用于通过相互发送信号或消息来表达参与者和系统之间的关联关系。箭头的末端用于指示发起交互的一方，其中用例总是由参与者发起的。需求分析技术：功能分析、用例图、用户、包含关系：用例A的行为包含用例b的行为。用例b描述了存在于多个用例中的共同行为。扩展关系：扩展关系是从扩展用

7、例到基本用例的关系，它解释了为扩展用例定义的行为如何被插入到为基本用例定义的行为中。在下列情况下，可以使用扩展用例：a .它表明用例的一部分是可选的系统行为；指明仅在特定条件下(如特殊条件)执行的分支流程。泛化关系：a指向b，表明b是a的一种.2.3需求分析技术：功能分析、如何识别参与者？在系统之外，任何通过系统边界与系统有意义地交互的东西都是参与者。对于一般规模的软件系统，参与者并不多。通常，有几种类型的参与者：与系统交互的用户、与系统交互的外部系统以及与系统交互的外部硬件。特别注意：有时时间触发器也可以被视为参与者。如何识别用例？用例实例是在系统中执行的一系列操作，这些操作将为特定的参与者

8、生成可见的价值结果。用例定义了一组用例实例。通俗地说，用例是参与者希望通过使用系统、用户、用例的关键点和价值结果来实现的目标。用例的结果形成了有意义的目标。执行者可以使用业务语言从用户的角度描述一组用例。用例也称为场景：它们是执行者使用系统的一个特定的情节或执行路径。例如，建立了用例模型的参考原则。用例是一个简短的文本。用例可以是一个场景，包括动作和交互。用例可以是一组场景，描述不同场景中的行为。这种书写格式可以描述任何时候变化的行为，比如黑盒需求、业务流程和系统设计规范。用例中不应该有系统设计，用例中不应该有接口设计，用例中不应该有测试用例，它们应该描述行为需求。用例的主要场景不应该超过9个

9、步骤。用例的最大价值不在于主场景，而在于替代行为。，用例建模步骤，确定系统的范围和边界，确定用例，描述用例，定义用例之间的关系和审查用例模型，用例是一个文档，而不是一个绘图！用例的文本描述应该包括以下内容：用例的目的(功能)；在什么情况下用例是由哪个参与者发起和执行的；用例和参与者之间交换什么消息来通知另一方做出决定；交互式主消息流和相应使用或修改的实体；用例中的备选异常事件流；用例的结束标志：一个可识别的值被返回给参与者。示例：使用案例名称：学生选修课执行者：学生用途：完成学生选修课的流程类型：主要和基本级别：第1级，流程描述：学生输入学号/密码，系统识别账户的有效性；注册和识别学生；浏览本

10、学期的开学前课程；选择学生想学的课程并确认；退出系统后，系统给出所选课程列表和相应的总学分异常事件流：账户有效性检查失败，允许学生重新进入(最多机会)注册标识失败，未注册(未支付学费)的学生不能选择课程，确认失败，若干所选课程及时冲突，系统提示重新选择，用例之间的关系-包含，将包含用例的行为插入到基本用例中的某个位置。当遵循基本用例描述的用例实例到达基本用例中定义包含关系的位置时，它将遵循包含用例的描述。一旦包含用例被执行，用例实例将从它在基本用例中停止的地方重新开始。用例包含关系的要点：1 .包含用例本身是不完整的，它必须有基本的用例来确保它的完整性。2.包含用例本身不知道它何时或者是否被包

11、含。因此，它不能依赖于包含它的任何用例。3.所包含的用例可以被其他用例所包含(即，通用性和独立性)。4.从工程角度来看，包含关系用于合并和提取系统分析中的公共函数。5.包含关系通常在用例建模的后期而不是早期被发现。描述包含关系，并定义在基本用例的行为序列中插入包含用例的位置。要定义这个位置，您可以引用基本用例事件流中的特定步骤或分支流。用例扩展了关系的概念。一些额外的行为可以被添加到用例的实例中。这些附加行为在另一个用例中定义，扩展定义了两个用例之间的关系。一个基本用例可以单独存在，但是在某些条件下，它的行为可以被另一个用例的行为扩展。当一个用例有多个可选的系统行为时，可以通过扩展关系进行扩展

12、，这样基本用例的不同子过程可以在不同的情况下以扩展用例的形式被激活。这样，可选行为就可以从必要行为中分离出来。用例扩展关系的概念、用例之间的关系-扩展和扩展的用例可以有基本事件流和可选事件流。用例实例通过扩展的路径不仅取决于扩展前的事件，还取决于扩展执行时与主角交互时发生的事件。一旦用例执行扩展实例执行了扩展，它将在基本用例的断点处继续执行基本用例。一个扩展用例可以有多个插入段，每个插入段都与基本用例中它自己的扩展点相关。用例实例将继续执行基本用例，直到扩展关系中指定的下一个扩展点。此时，它将执行扩展用例的下一个插入段。这将一直重复，直到执行完最后一个插入段。包含关系与扩展关系的区别，包含关系

13、1。当两个或更多独立的用例重复它们自己并且想要避免重复时。在基本用例上插入额外的行为，并有一个清晰的描述3。作为基本用例行为的一部分的包容性用例4。包容关系是无条件的。扩展关系1。表达对正常行为的改变时。插入一个基本用例3无法解释的扩展部分。扩展用例是基本用例4的增量扩展。扩展用例是根据条件要求执行的，包括关系和扩展关系之间的区别，包括关系1。包含用例是一个常见的用例2。一个基本用例可以有多个包含用例。3.一个包含性用例可以包含在几个基本用例中。4.在包含关系上很难维护和修改系统。1.扩展用例不是共享用例2。可选行为与必要行为是分开的。现有用例的行为是有条件扩展的。4.基本用例可以独立于扩展用

14、例而存在。5.适用于功能需求的增加(基本用例的增量扩展)，注意我的业务语言而不是技术语言，发票，洗衣机，c，字段，net，AJAX，注意用户的观点而不是系统的观点，旅行者，旅行者，注意-用例命名：动词名词应该尽量少用弱动词，弱动词：复制和加载重复的弱名词：数据报表系统注意-把步骤当作用例，用户，用户，注意-避免使用CRUD，管理员，注意-用例背后可能隐藏着许多数据操作。序列图，序列图，描述了一组交互对象之间的交互模式，它指示了完成一个动作的对象的时间顺序以及在这些对象之间传输的消息。序列图将交互表示为二维图。纵轴是时间轴，时间沿着垂直线向下延伸。横轴代表协作中的每个独立角色。角色由生命线表示。

15、当角色对象存在时，角色用虚线表示，当对象的进程被激活时，生命线是双线。2.3需求分析技术：功能分析、活动图(Activity Graph)、活动图(Activity Graph)说明了业务用例实现的工作流程，它由一系列活动组成，这些活动共同为业务主角做一些工作。工作流活动图用于研究实现业务目标时要执行的任务或活动的顺序安排。活动可以是手动执行的任务，也可以是自动执行的任务。它可以完成一个工作单元。2.3需求分析技术：功能分析，活动图，活动意味着执行工作流中的活动或步骤。转移：指明活动的控制流向，连接两个活动，在开始活动完成后开始连接结束活动。决策判断：判断条件被定义为。这些标准决定了活动完成后

16、将执行一组可选转换中的哪一个。您也可以使用决策图标来指示线程在哪里重新组合。决策和警戒条件使您能够在业务用例的工作流中显示备选线程同步条：同步条用于显示并行分支和流。同步栏使您能够在业务用例的工作流中显示并行线程。嵌套活动图：一个活动状态可以引用另一个活动图，因为后者显示了前者的内部结构。泳道：你可以用垂直实线把活动图分成泳道。每个泳道代表整个工作流的某个部分的责任，泳道最终可以由组织单元或业务对象模型中的一组类来实现。车道之间的分类是没有意义的。一个活动状态被分配一个泳道，而一个过渡可以跨越几个泳道。2.3需求分析技术：功能分析，活动图，活动意味着执行工作流中的某个活动或步骤。该活动由一个半圆框表示，并标记了活动名称。一个活动可以是一个组合活动，也就是说，该活动由一系列子活动组成，这些子活动可以用另一个活动图来描述。条件1，条件2，2，转移转移描述了活动之间的关系以及由，矩形的两端是半圆。2.3需求分析技术：功能分析、活动图、活动意味着执行工作流中的某个活动或步骤。该活动用一