搜索
1需求分析第3章本章要点理解需求分析的任务；熟悉需求分析的步骤；理解结构化需求分析的基本思想；掌握数据流图和数据词典的用法。23.1需求分析的任务第3章需求分析的任务是要准确地定义新系统的目标，准确回答“系统必须做什么”的问题，并用需求规格说明书规范的形式准确地表达用户的需求。需求分析是理解、分析和表达“系统必须做什么”的过程。虽然在可行性研究阶段虽然在可行性研究阶段，对用户需求有了初步了解，但对需求的了解是概括的、粗略的，对用户需求有了初步了解但对需求的了解是概括的粗略的许多细节被忽略了。可行性研究是决定“做还是不做”，而不是对需求进行定义。而需求分析阶段则需要充分理解用户需求，通过分析得出对新系统完整、准确、清晰、具体的要求。需求分析的结果是否正确，关系到软件开发的成败和软件产品的质量，正确的需求分析是整个系统开发的基础。33.2需求获取的方法第3章在需求分析过程中，需求获取阶段是开发人员和用户交往最多的阶段。一般情况下，用户并不熟悉计算机的相关知识，更不懂得需求分析方法，所以他们不知道如何全面而又准确无误地表达自己的需求。而软件开发人员对相关的业务领域也不甚了解，用户与开发人员之间对同一问题理解的差异和习惯用语的不同往往会给需求分析带来很大困难。所以，开发人员与用户之间要进行充分和有效的沟通，需要采取科学的需求获取方法与技巧，恰当地启发引导用户表达自己的需求，以减少后期重复修改需求的次数。43.2需求获取的方法第3章1．深入浅出需求获取要尽可能全面、细致。调研获取的需求是个全集，而目标系统真正实现的是个子集。分析时的调研内容并不一定都要纳入到新系统中，但全面、细致的调研既有利于弄清系统全局，又有利于以后的扩充。2．以流程为主线在与用户交流的过程中，应该用流程将所有的内容串起来，如单据、信息、组织结构和处理规则等，这样便于交流沟通。流程的描述既要有宏观描述，也要有微观描述。3.2.1需求获取的基本原则53.2需求获取的方法第3章1.问卷调查2.访谈和会议3.市场调查4.实地操作5.建立原型3.2.2获取需求的途径和方法63.2需求获取的方法第3章获取用户需求，就需要深入企业现场调研，需求调研的步骤如下：（1）调研用户领域的组织结构、岗位设置和职责定义，从功能上区分有多少个子系统，划分系统的大致范围，明确系统的目标。（2）调研每个子系统所需的工作流程、功能与处理规则，收集单据、报表和账本等原始调研每个子系统所需的作流程功能与处资料，分析物流、资金流和信息流三者的关系，以及如何用数据流来表示这三者的关系。（3）对调研的内容事先准备，针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层和决策层的需求既联系又区分开来，形成一个金字塔，使下层满足上层的需求。（4）对与用户沟通的情况及时总结归纳，整理调研结果，找出新的疑点，初步构成需求基线。（5）若需求基线符合要求，则需求分析完毕；反之返回到前面某一步。如此循环多次，直到需求分析使双方满意为止。3.2.3需求调研的步骤73.3需求获取的步骤第3章一般来说，需求分析分为需求获取、分析建模、需求建模、需求验证四个步骤，如下图所示：83.3需求获取的步骤第3章此阶段的工作是需求获取、问题识别，即收集并明确用户需求的过程。首先，系统分析员要研究可行性研究报告和软件项目实施计划。主要是从系统的角度来理解软件，确定对目标系统的综合要求，即软件的需求。还要提出这些需求实现的条件，以及需求应达到的标准。也就是解决待开发系统需要“做什么”，“做到什么程度”的问题。这些需求包括：（1）功能需求：（2）性能需求：（3）环境需求：（4）可靠性需求：（5）安全保密性需求：（6）用户界面需求：（7）资源使用需求：（8）软件成本消耗与开发进度需求：（9）预计系统可达到的目标：3.3.1需求获取93.3需求获取的步骤第3章获取到需求后，要把来自用户的信息加以分析，通过“抽象”建立待开发的系统逻辑模型。模型是为了理解事物而对事物做出的一种抽象，通常由一组符号和组织这些符号的规则组成。为待开发系统建立模型，有助于人们更好地理解问题，常用的建模方法有数据流图、实体联系图（E\|R图）、状态转换图、用例图、类图、对象图等。系统分析员根据目标系统的模型，从信息流和信息结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和对设计的限制，剔除需求中不合理的成分，增加需要的部分，最终把各项需求组织起来，提交目标系统的详细逻辑模型。3.3.2分析建模103.3需求获取的步骤第3章需求描述就是指编制需求分析阶段的文档。即将已经过分析的需求清晰、全面、系统、准确地描述成正式的文档——软件需求规格说明书。软件需求规格说明书以开发人员的角度，对开发系统的业务模型、功能模型、数据模型等内容进行描述，明确地表达了用户与系统分析员对软件系统的共同理解，将作为概要设计和详细设计的基线。对于复杂的软件系统，此阶段除产生软件需求规格说明书（称软件需求文档，主要描述软件部分的需求）外，还要产生系统定义文档（即用户需求报告）和系统需求文档（即系统需求规格说明书）。3.3.3需求描述11需求验证就是验证（复查）需求分析的成果，也称综合评审。需求验证就是对需求的正确性进行严格的验证，确保需求的一致性、完整性、清晰性、现实性和有效性，确保设计与实现过程中的需求可回溯性，并进行需求变更管理。一般情况下，需求验证以用户、系统分析员、系统设计人员和管理人员共同参与的会议形式进行，最后由评审负责人签字。3.3.4需求验证3.3需求获取的步骤第3章123.4结构化的需求分析方法第3章3.4.1结构化分析方法概述1.分析策略结构化分析（StructuredAnalysis，简称SA）方法是20世纪70年代由E-Yourdon等人提出的一种面向数据流的分析方法，适用于大型的数据处理系统。由于利用图形来表达需求会使文档清晰、简明、易于学习和掌握，所以软件分析人员仍在广泛使用这种传统的分析方法。结构化分析方法总的指导思想是“自顶向下，逐步求精”，它的两个基本原则是“抽象”和“分解”，即按照功能分解的原则，对系统进行逐层分解，直到找到所有满足功能要求的可实现软件元素为止。133.4结构化的需求分析方法第3章3.4.1结构化分析方法概述142.描述工具结构化分析方法利用图形等半形式化的描述表达需求，用它们形成需求规格说明书的主要部分，主要工具有：（1）数据流图（DFD）。描述系统的分解，即描述系统由哪几部分组成，各部分之间有什么联系等。（2）数据词典（DD）。明确定义数据流图中的数据和加工。它是数据流条目、数据存储条目、数据项条目和基本加工条目的汇集。（3）结构化语言、判定表和判定树。用于详细描述数据流图中不能再分解的每一个基本加工的处理逻辑。3.4结构化的需求分析方法第3章3.4.1结构化分析方法概述153.4结构化的需求分析方法第3章3.4.1结构化分析方法概述163.4结构化的需求分析方法第3章3.4.12数据流图1、数据流图的基本符号172.数据流图的绘制步骤（1）画顶层数据流图列出系统的全部数据源点和终点，将系统加工处理过程作为一个整体，就可能得到顶层图图。具体说就是：画一个圆，在其中写上系统名称，然后在圆的外围画上系统的输入和输出，具体说就是画个圆在其中写上系统名称然后在圆的外围画上系统的输入和输出，这一步工作实际上是决定研究的内容和系统的范围。（2）画各层数据流图对系统处理过程自顶向下，逐步分解，画出各层的数据流图。（3）画总的数据流图这一步对了解整个系统很有好处，但也要根据实际情况来决定总图的布局，不要把数据流图画得太复杂。3.4结构化的需求分析方法第3章3.4.2数据流图183.数据流图中的命名规则（1）数据流数据流表明数据和数据流向，它通常由一组数据项组成。（2）加工加工是对数据的某种操作或变换。（3）文件文件起暂时保存数据的作用。（4）数据源点和终点数据源点和终点是数据的始发点和终止点，是软件系统外部环境中的实体（包括人员、组织或其他软件系统），统称外部实体。3.4结构化的需求分析方法第3章3.4.2数据流图193.4结构化的需求分析方法第3章3.4.2数据流图4.数据流图中分层技术对于比较复杂的实际问题，在数据流图上常常出现十几个乃至几十个、上百个加工，这样的数据流图复杂而且难以理解。为了避免这种情况出现，可以采用数据流图的分层技术。分层技术的基本思想是，不是在一个数据流图中一次引入太多的细节，而是有控制地逐步增加细节，实现从抽象到具体的逐步过渡。201.数据词典的内容一般说来，数据词典的每个条目中应包括以下信息。（1）名字：数据流、数据项、数据存储或外部实体的名称。（2）别名或编号：第（1）项中对象的其他名字。（3）分类：数据流、数据项、加工、数据存储、外部实体等。（4）内容描述：描述内容或数据结构等。（5）何处使用：哪些加工使用该条目。3.4结构化的需求分析方法第3章3.4.3数据词典212、数据词典中使用的符号3.4结构化的需求分析方法第3章3.4.3数据词典223、数据词典书写实例3.4结构化的需求分析方法第3章3.4.3数据词典233、数据词典书写实例3.4结构化的需求分析方法第3章3.4.3数据词典243、数据词典书写实例3.4结构化的需求分析方法第3章3.4.3数据词典254.数据词典的实现通常，实现数据词典有三种途径：(1)人工方法：人工方法实现时，每一词典条目（即每一个数据定义或每一个加工逻辑说明）写在一张卡片上，由专人管理和维护。为了便于搜索，所有卡片按数据名称排序。人工方法的优点是容易实现。(2)自动方法：把词典存在计算机中，用计算机对它搜索和维护。现有多种“词典管理程序”，如PLS/PSA。用计算机管理词典质量高，搜索、维护方便。(3)人工和自动混合的方法：在人工过程中可借助正文编写程序、报告生成程序等工具辅助完成。3.4结构化的需求分析方法第3章3.4.3数据词典264.数据词典的实现不论通过哪种途径实现的数据词典都应尽量做到以下几点：(1)没有冗余：主要指数据定义不能重复。在规格说明书的其他组成部分中已出现的信息不能重复。(2)查阅方便：通过名字可以方便地查阅数据词典中的每个定义。(3)定义的书写方法简单、方便、严谨，而且可读性强。(4)建议采用卡片形式书写。3.4结构化的需求分析方法第3章3.4.3数据词典271、结构化语言3.4结构化的需求分析方法第3章3.4.4加工逻辑的描述282、判定表在一些数据处理中，数据流图的加工需要经过多个逻辑条件组合的取值而确定，此时用自然语言或结构化语言难以描述，而运用判定表描述就比较清晰明了。3.4结构化的需求分析方法第3章3.4.4加工逻辑的描述293、判定树判定树也是用来表达加工逻辑的工具，它是判定表的变形，有时比判定表更直观，更易于理解和使用。图书优惠政策的判定树如图3‐8所示。3.4结构化的需求分析方法第3章3.4.4加工逻辑的描述301．需求规格说明书的编写内容需求分析阶段应交付的主要文档是软件需求规格说明书。它提供了用户与开发人员对开发软件的共同理解，其作用相当于用户与开发单位之间的技术合同，是后续设计和编码的基础，是测试和验收的依据。软件需求规格说明书的内容框架可参阅GB/T8567\|2006《计算机软件文档编制规范》。在编写需求规格说明书时应注意以下几个问题：（1）说明书中的每一部分都非常重要，因此要慎重对待。（2）问题的描述要做到准确无误，没有二义性。（3）说明书的书写形式要规范。（4）允许用户根据项目的具体情况适当的将书写内容进行调整和筛选。3.5需求规格说明书的编写与审评第3章312．需求分析的评审在需求分析规格说明书编写完成后，必须进行需求评审，以验证需求的正确性。如果在评审过程中发现说明书存在错误或缺陷，应及时进行更改或弥补，重新进行相应部分的需求分析、需求建模、修改需求规格说明书，并再行评审。需求分析评审的主要内容如下需求分析评审的主要内容如下：（1）一致性。所有需求必须是一致的，任何一条需求不能和其他需求相