软件工程教学课件第3章需求分析

第3章 需求分析,3.1 需求分析基础,3.1.1 需求分析的任务与原则 3.1.2 获取需求的方法 3.1.3 需求建模 3.1.4 需求规约与验证3.1.5 开发原型系统,3.1.1 需求分析的任务与原则,1需求分析的任务2需求分析的原则,1需求分析的任务,软件需求分析的任务是：深入描述软件的功能和性能，确定软件设计的约束和软件和其它系统元素的接口细节，定义软件的其他有效性需求，借助于当前系统的逻辑模型导出目标系统逻辑模型，解决目标系统“做什么”的问题。需求分析可以分为需求获取、需求分析与协商、需求建模、需求规约、需求验证。,2需求分析的原则,需求分析过程的具体实现，在实践中有很多方法，不同的分析方法有自己独特的观点。然而，这些分析方法都遵循一组操作原则，这些原则包括以下内容：（1）必须能够表示和理解问题的信息域。（2）必须能够定义软件将完成的功能，把一个复杂问题按功能分解并可逐层细化。 （3）必须能够表示软件的行为。 （4）必须划分描述信息、功能和行为的模型，从而可以分层次地揭示细节。 （5）分析过程应该从要素信息移向细节信息。,3.1.2 获取需求的方法,在实际的软件开发中，需求获取是一个十分困难的过程，其主要原因在于：通常用户并不真正知道自己希望计算机系统做什么；通常用户使用业务语言表达需求，开发人员缺乏相关的领域知识和经验，难以准确理解这些需求；不同的用户提出不同的需求，可能存在矛盾和冲突；管理者可能出于增加影响力的原因而提出特别的需求；由于经济和业务环境的动态性，需求经常发生变更。为了完成软件需求任务，分析人员必须掌握一些基本技术，包括初步需求获取技术、需求建模以及用于需求分析的快速原型技术。,1建立顺畅的通信途径,需求获取首先要建立所需要的通信途径，以保证能顺利地对问题进行分析。分析人员必须与用户、软件开发机构的管理部门、软件开发组的人员建立联系。项目负责人在此过程中起协调人的作用。分析人员通过这种通信途径与各方商讨，以便能按照用户的要求去识别问题的基本内容。,2用户访谈与调查,用户访谈是一种十分直接而常用的需求获取方法，也经常与其它获取技术一起使用，以便更好地澄清和理解一些细节问题。访谈通常分为结构化和非结构化的访谈。前者主要讨论一组事先计划好的问题，并要求按计划进行访谈；而后者对将要讨论的主题只有一个粗略的想法，依赖于需求获取者在访谈进行时的“临场发挥”。, 确定访谈目的 确定参加访谈的相关人员 建立要讨论的问题和要点列表 通知访谈相关人员,（1）访谈之前,一般按照以下原则进行：所提的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化；不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；提问和回答在汇总后应能够反映用户需求的全貌。,（2）进行访谈,（3）访谈之后 复查记录的准确性、完整性和可理解性，把所收集的信息转化为适当的模型和文档，确定需求进一步澄清的未回答条目和未解决问题。,3观察用户操作流程,在观察过程中，需要注意的是：未来的软件系统并不是完全模拟用户现有的工作流程，分析人员要结合原有的开发经验和应用经验，分析其中哪些环节应该由软件系统完成，哪些环节应该由人来完成，并且主动剔除现有系统不合理的部分，改进现有的工作流程、寻找潜在的用户需求，这些需求的实现在将来软件应用的过程中一定会得到用户的赞同。,4实例分析,实例分析中常用“用况”的概念。用况常称为用例，分析员创建一组标识一串待建造系统的使用场景，这些场景被称为用况的实例，用况提供了系统将会被如何使用的描述。,4实例分析,创建用况模型的主要步骤如下： 确定谁会直接使用该系统，即执行者。 选取其中一个执行者 定义该执行者希望系统做什么，执行者希望系统所做的每件事将成为一个用况。 对每件事来说，何时执行者会使用系统，通常会发生什么，这就是用况的基本过程。 描述该用况的基本过程。,3.1.3 需求建模,创建模型是需求分析阶段的重要活动。模型以一种简洁、准确、结构清晰的方式系统地描述了软件需求，从而帮助分析员理解系统的信息、功能和行为，使得需求分析任务更容易实现，结果更系统化，同时易于发现用户描述中的模糊性和不一致性；,3.1.3 需求建模,模型将成为复审的焦点，也将成为确定规约的完整性、一致性和精确性的重要依据。模型还将成为软件设计的基础，为设计者提供软件要素的表示视图，这些表示可被转化到实现的语境中去；更重要的是，模型还可以在分析人员和用户之间建立更便捷的沟通方式，使两者可以用相同的工具分析和理解问题。,3.1.3 需求建模,在软件需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做。目标软件的需求模型不应涉及软件的实现细节。通常情形下，分析人员使用图形符号来创建模型，将信息、处理、系统行为和其它相关特征描述为各种可识别的图形符号，同时在图形符号旁边辅助以文字描述，可使用自然语言或某特殊的专门用于描述需求的语言来提供辅助的信息描述。,3.1.3 需求建模,常用的分析和建模方法有面向数据流的结构化分析方法、面向数据结构的分析方法和面向对象的分析方法。其中结构化的分析方法和面向对象的分析方法应用非常广泛，具有较好的发展潜力。,3.1.4需求规约与验证,需求分析的输出就是需求规约。本节介绍书写规约的原则，规约的主要内容和需求验证的标准。,1需求规约的原则,从现实中分离功能，即描述要“做什么”而不是“怎样实现”。要求使用面向处理的规约语言（或称系统定义语言），讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规约。如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也应包括在规格说明的描述之中。规约必须包括系统运行环境。,1需求规约的原则,规约必须是一个认识模型，而不是设计或实现的模型。规约必须是可操作的，利用它能够通过测试用例判断已提出的解决方案是否都能满足规约。 规约必须允许不完备性并允许扩充。 规约必须局部化和松散耦合。,2需求规约,软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。,表3-1,软件需求规约的框架,3.1.5 开发原型系统,为避免造成人力、物力、财力上的巨大浪费，人们提出在分析阶段使用快速原型方法。其核心思想是：在软件开发的早期快速建立目标软件的原型，让用户对原型进行评估并提出修改意见，当原型几经改进最终确定后，它将由软件设计和编码阶段进化成软件产品；或者设计和编码人员遵循原型所确立的外部特征实现软件产品。,3.2 结构化分析方法,3.2.1 数据流图3.2.2 分层数据流图的画法3.2.3 数据字典,3.2.1 数据流图,数据流图（Data Flow Diagram，DFD）描述系统的逻辑模型，图中没有任何具体的物理元素，只是描述信息在系统中流动和处理的情况。数据流图的特点是：它是逻辑系统的图形表示，容易理解，是极好的通信工具，设计数据流图只需考虑系统必须完成的基本逻辑功能，不需要考虑如何实现这些功能，是软件设计很好的出发点。,1符号,（1）数据流图的基本符号（2）数据流图的附加符号,（1）数据流图的基本符号,（2）数据流图的附加符号,数据流图有3种附加符号，一个加工可以有多个输入数据流和多个输出数据流，此时可以加上一些附加符号来描述多个数据流之间的关系。* 表示数据流之间是“与”关系（同时存在）。+ 表示数据流之间是“或”关系。表示只能从几个数据流中选一个（互斥关系）。,（2）数据流图的附加符号,2数据流图的层次结构,（1）层次结构（2）图和加工的编号,（1）层次结构,分层数据流图的顶层只是一张图，其中只有一个加工，代表整个软件系统，该加工描述了软件系统与外界（源点或终点）之间的数据流，称为顶层图。顶层图中的加工（即系统）经分解后的图称为0层图，也只有一张。处于分层数据流图最底层的图称为底层图，在底层图中，所有的加工不再进行分解。分层数据流图中的其他图称为中间层图，其中至少有一个加工（也可以是所有加工）被分解成一张子图。在整套分层数据流图中，凡是不再分解成子图的加工称为基本加工。,（2）图和加工的编号,对数据流图中的图和加工编号：顶层图只有一个加工（代表整个软件系统），该加工不必编号；0层图中的加工编号分别为1、2、3；对于子图号，若父图中的加工号x分解成某一子图，则该子图号记为“图x”；对于子图中加工的编号若父图中的加工号为x的加工分解成某一子图，则该子图中的加工编号分别为x.1、x.2、x.3。,3几点注意事项,（1）一张数据流图中所含的处理不要太多 数据流图可分为高层总体数据流图和多张细化的数据流图。调查研究表明，如果一张数据流图中包含的处理多于59个时，人们将难以理解其含义。此时数据流图应该分层绘制，把复杂的功能分解为子功能来细化数据流图。,3几点注意事项,（2）数据流图细化原则 数据流图分层细化时必须保持信息的连续性。细化前、后，对应功能的输入/输出数据必须相同。也就是说，子图的输入/输出数据流同父图相应加工的输入/输出数据流必须一致，即父图与子图的平衡。如果把一个功能细化为子功能时需要写出程序代码，就不应进行细化了。,3.2.2 分层数据流图的画法,以软件专业技术资格和水平考试（简称为资格和水平考试）的考务处理系统为例，画出考务处理系统的数据流图，详细给出分层数据流图的画法。,3.2.2 分层数据流图的画法,首先明确该考务处理系统的功能需求（工作过程）：（1）对考生提交的报名单进行检查（2）对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站（3）对阅卷站送来的成绩清单进行检查，并根据考试中心制定的合格标准审定合格者（4）制作考生通知单并发送给考生（5）进行成绩分类统计（按地区、文化程度、职业、考试级别等分类）和试题难度分析，产生统计分析表。,3.2.2 分层数据流图的画法,1画出系统的输入和输出2画出系统内部3画出加工内部4重复第3步，直至每个尚未分解的加工都足够简单（即不必再分解）,1画出系统的输入和输出,（1）确定数据源点和终点 分析系统的功能说明，系统外部的人或组织有考生、阅卷站和考试中心，他们都向系统提供信息（数据流）并接收系统输出的信息（数据流），因此，他们都既是数据源点又是数据终点。,1画出系统的输入和输出,（2）确定加工 顶层图只有一个加工，即软件系统，根据本例的实际含义可取名为考务处理系统。,1画出系统的输入和输出,（3）确定数据流 顶层图中的数据流就是系统的输入输出信息。分析系统的功能说明，可以确定以下输入数据流和输出数据流。输入数据流：报名单（来自考生）、成绩清单（来自阅卷站）、合格标准（来自考试中心）。输出数据流：准考证（送往考生）、考生名单（送往阅卷站）、考生通知书（送往考生）、统计分析表（送往考试中心）。,1画出系统的输入和输出,（4）顶层图通常没有文件,2画出系统内部,（1）确定加工 根据功能分解来确定加工 根据业务处理流程确定加工,2画出系统内部,（2）确定数据流 当用户把若干数据作为一个单位来处理（即一起到达，一起加工）时，则把这些数据看作一个数据流。,2画出系统内部,（3）确定文件 在父图中某加工分解而成的子图中，如果父图中该加工存在流向文件的数据流（写文件），或者存在从文件流向该加工的数据流（读文件），则这种文件和相关的数据流都应画在子图中。,2画出系统内部,（3）确定数据源点和终点 通常在0层图和其他子图中不必画出数据源点和终点。有时为了提高可读性，可以将顶层图中的数据源点和终点画在0层图中。,2画出系统内部,图3-9 考务处理系统0层图,3画出加工内部,在数据流图中存在某个比较复杂的加工时，可以将它分解成一张数据流图子图。分解的方法是：将该加工看作一个小系统，该加工的输入输出数据流就是这个假设的小系统的输入输出数据流，然后采用画0层图的方法，画出该加工的子图。,3画出加工内部,图3-10 考务处理系统加工1子图,3画出加工内部,图3-11 考务处理系统加工2子图,4重复第3步,重复第3步，直至每个尚未分解的加工都足够简单（即不必再分解）,3.2.3 数据字典,数据字典（Data Dictionary，DD）用于定义数据流图中的各个成分的具体含义。它以一种准确的、无二义性的说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述。数据字典的任务是对于数据流图中出现的所有被命名的图形元素在数据字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。,1字典条目的种类,数据字典由字典条目组成，每个条目描述数据流图的一个元素。字典条目可分成如下4类：数据流、文件、数据项（组成数据流和文件的数据）、加工。数据字典可以按上述的种类进行分类组织。,2字典条目,数据流图中的每个元素（数据流、文件、加工数据源点和终点等）都对应于一个数据字典条目的描述，不同种类的条目有不同的描述内容。字典条目中的描述内容主要包括：数据流图元素的基本信息（名称、别名、简述、注解）、定义（数据类型、数据组成）、使用特点（取值范围、使用频率、激发条件）、控制信息（来源、去向、访问权限）等。,（1）数据流条目,数据流条目给出了数据流图中数据流的定义，通常列出该数据流的各组成数据项。在定义数据流或数据存储组成时，使用的符号见表3-2。,表3-2,数据字典符号,（1）数据流条目,数据流条目的描述内容如下。名称：数据流名（可以是中文名或英文名）。别名：名称的另一个名字。简述：对数据流的简单说明。数据流组成：描述数据流由哪些数据项组成。数据流来源：描述数据流从哪个加工或源点流出。数据流去向：描述数据流流入哪个加工或终点。数据量：系统中该数据流的总量，如考务处理系统中“报名单”的总量是100000张；或者单位时间处理的数据流数量，如80000张/天。峰值：某时段处理的最大数量，如每天上午9：00-11：00处理60000张表单。注解：对该数据流的其他补充说明。,（2）文件条目,文件条目是对数据存储的定义，其描述内容如下。名称：文件名。别名：同数据流条目。简述：对文件的简单说明。文件组成：描述文件的记录由哪些数据项组成。写文件的加工：描述哪些加工写文件。读文件的加工：描述哪些加工读文件。文件组织：描述文件的存储方法（顺序、索引），排序的关键字。使用权限：描述各类用户对文件读、写、修改的使用权限。数据量：文件的最大记录个数。存取频率：描述对该文件的读写频率。注解：对该文件的其他补充说明。,（3）数据项条目,数据项条目是不可再分解的数据单位，其描述内容如下。名称：数据项名。别名：同数据流条目。简述：对数据项的简单描述。数据类型：描述数据项的类型，如整型、实型、字符串等。计量单位：指明数据项指的计量单位，如公斤、吨等。取值范围：描述数据项允许的值域，如1.100。编辑方式：描述数据项外部表示的编辑方式，如23，345.67.与其他数据项的关系：描述该数据项与数据字典中其他数据项的关系。名称、数据类型、计量单位、取值范围是数据项条目必须描述的内容，其他内容由开发者选用。,（4）加工条目,加工条目用于说明数据流图中基本加工的处理逻辑。其描述内容如下。名称：加工名。别名：同数据流条目。加工号：加工数据流图中的编号。简述：对加工功能的简要说明。输入数据流：描述加工的输入数据流，包括读哪些文件名。输出数据流：描述加工的输出数据流，包括写哪些文件名。加工逻辑：简要描述加工逻辑，护着对加工规约的索引。异常处理：描述加工处理过程中可能出现的异常情况，及其处理方式。加工激发条件：描述执行加工的条件，如“身份认证正确”、“收到报名单”。执行频率：描述加工的执行频率，如每月执行一次、每天0点执行。,3.3 面向对象分析方法,3.3.1 面向对象分析简介3.3.2 基于用例的分析建模3.3.3 评审分析模型,3.3.1 面向对象分析简介,1分析建模过程2面向对象分析模型,1分析建模过程,在面向对象分析阶段，开发人员应该首先理解在需求获取阶段产生的用例模型，找出描述问题域和系统责任所需的对象和类，将用例行为映射到对象上，进一步分析它们的内部构成和外部关系，从而建立面向对象分析模型。最后，开发人员和用户一起检查模型，保证模型的正确性、一致性、完整性和可行性。,图3-15 面向对象分析建模过程,2面向对象分析模型,面向对象的分析模型由功能模型、分析对象模型和动态模型3个独立模型组成。获取用户需求将其描述成用例和场景，从而形成系统的功能模型；将功能模型进一步细化，从而产生分析对象模型和动态模型。在分析阶段，分析类立足于软件功能需求的描述，划分为实体类、边界类和控制类3种类型。,3.3.2 基于用例的分析建模,1识别分析类2定义交互行为3建立分析类图,1识别分析类,为了识别分析类，通常需要充分地理解系统内部的行为，补充与这些内部行为相关的一些其他信息，即系统内部是如何响应外部请求的。这些信息在用户功能建模时通常是被忽略的，但在进一步细化的分析模型中则有助于进行用例职责的分配。在图书馆管理系统的“登记还书”用例中，图书管理员需要“系统同时向现有的预订者发出通知”。显然，这个描述没有涉及系统内部所发生的具体细节。,在每一个用例中，每一个参与者至少与一个边界类进行交互，这个边界类担负着协调参与者与用例之间的交互职责。因此，我们初步给每一对参与者和用例确定一个边界类，并在进一步分析的过程中，进行分解和合并。边界类是对用户界面行为进行建模，它通常关注参与者与用例之间交互的信息或者响应的事件，而不是描述窗口组件等界面的可见元素。,（1）识别边界类,控制类负责协调边界类和实体类，通常在现实世界中没有对应的事物。它负责接收边界类的信息，并将其分发给实体类。,（2）识别控制类,实体类通常是用例中的参与对象，对应着现实世界中的“事物”。识别实体类需要开发人员进一步理解应用领域，可以通过分析用例描述和词汇表等发现备选的实体对象。,（3）识别实体类,2定义交互行为,定义交互行为是从需求向设计过渡的一个重要环节，其关键在于通过描述分析类实例之间的消息传递将用例的职责分配到分析类中。在初步找出一些分析类之后，我们可以借助于顺序图将用例和分析对象联系在一起，描述用例的行为是怎样在它的参与对象之间分布的。顺序图可以将用例的行为分配到所识别的分析类中，并且帮助开发人员发现和补充前面遗漏的分析类。,3建立分析类图,在分析了对象之间的交互行为之后，开发人员需要建立分析类图，即定义分析类之间的关系和分析类的属性。,关联存在着多重性，用以描述一个关联的实例中有多少个相互连接的对象。关联的多重性是一个取值范围的表达式或者一个具体值，可以精确地表示多重性为1、0或1（0.1）、多个（0.n）、一个或多个（1.n）等，如果需要还可以标明精确的数值。,（1）概念：关联多重性, 按照一般常识，找出对象的某些属性，如读者的姓名、地址等。 认真研究问题域，找出对象的某些属性，如商品的条形码、读者的编号等。 根据系统责任的要求，找出对象的某些属性。 考虑对象需要系统保存和管理的信息，找出对象的相应属性，如“图书资料”需要保存和管理的信息。 对象为了在服务中实现其功能，需要增设一些属性。 识别对象需要区别的状态，考虑是否需要增加一个属性来区别这些状态。 确定属性表示整体与部分结构和实例连接。,（2）定义属性, 查看一个类的属性与服务是否适合这个类的全部对象，如果某些属性或服务只适合该类的一部分对象，说明应该从这个类中划分出一部分特殊类，建立泛化关系。 检查是否某些类具有相同的属性和服务，如果把这些相同的属性和服务提取出来，能否在概念上构成这些类的父类，形成泛化关系。,（3）发现泛化关系, 物理上的整