指南需求分析过程

需求分析过程指南Version0.1修订历史日期版本描述作者2010-09-110.1需求分析过程指南初稿谭勇

目录TOC\o"1-3"\h\z1 绪言和目标 31.1 目的 31.2 范围 31.3 定义及缩写 31.4 参考 32 角色和职责 33 进入标准 34 输入 35 过程 45.1 需求研发 45.2 变更控制 46 输出 47 退出标准 48 控制机制 49 度量 4

绪言和目标目的本文档为软件项目开发中需求分析工作提供了一个可遵循的规范标准，通过本规范的使用可以提高需求分析工作的质量、可管理性、可跟踪性和可维护性，促进在业务部门、技术部门和开发商之间的对系统需求的充分的共同理解，提高项目的质量和用户满意度。范围本文档主要面向的读者和使用人员是：管理应用开发的有关人员，开发商的设计开发人员。文档概述本文档描述了软件项目开发中，需求分析工作应遵循的过程规范、基本原则和可选择的需求分析方法。定义及缩写缩写定义需求系统必须满足的条件和实现的功能需求管理对系统需求进行引入、组织和文档化的一种系统化的方法与步骤，以及建立和维护开发人员与业务部门之间关于系统需求变更的确认的过程参考文档名标题《软件工程——实践者的研究方法》需求分析过程标准需求管理流程分为四个阶段：阶段工作内容提交成果责任人确认人1业务需求调研《业务需求说明书》需求管理人员业务部门负责人2确定系统需求《系统需求说明书》需求管理人员、系统架构管理人员技术管理部门负责人3详细需求调研和需求分析《系统需求规格说明书》需求管理人员、系统架构管理人员、系统开发商业务部门项目经理、技术管理部门项目经理4需求变更管理《系统变更单》需求管理人员、系统架构管理人员、系统开发商业务部门负责人、技术管理部门负责人第一阶段主要对应于业务部门确定的业务需求。第二阶段主要对应于技术管理部门确定的系统范围和系统需求。前两个阶段对应于项目合同签订前的活动，需求管理人员必须完成制定系统的高层需求的工作。第三阶段主要对应于系统开发商对业务需求和系统需求的细化和分析，是项目合同签订后的活动。第四阶段主要对应于前三阶段的提交成果产生基线版本后需要对需求内容进行修改时的活动，是贯穿于系统整个生命周期的活动。因为需求涉及从高到低的不同的概括层次，出于分工的需要，需求管理人员将持续维护的高层需求，并管理开发商维护系统的详细需求。业务需求调研业务需求反映：业务部门对系统高层次的目标要求；用户对系统使用和运行方式的重要规定；业务涉及的组织机构；主要的业务流程和参与角色；重要的影响到系统的外部约束和假设（如必须遵从的标准、规范，与其他部门的接口，其它关联的系统，和业务有关的法律、法规等）。业务需求调研阶段产生的提交成果为《业务需求说明书》。需求管理人员制订需求调研计划需求管理人员与业务部门有关人员会谈，了解业务部门对系统高层次的目标要求，并共同确定：1）需求信息（包括组织机构信息、标准、规范、法律、法规、与其他部门和业务的接口、其它关联的系统等）的获得途径和时间进度，这部分信息的获取一般采用资料收集的手段；2）要进行调研的主要业务流程、指定的描述流程的业务人员和时间安排，提供这部分调研一般采用与有关业务人员面谈的手段。3）需求调研计划纳入到《项目工作计划》中。需求管理人员调研业务流程将要涉及到的业务流程明确下来之后，需求管理人员在业务部门的协调下，按计划调研确定每一个业务流程中的参与人员角色、每个角色所执行的活动、在活动中所使用的业务实体、以及在活动中要遵循的一些业务规则。调研结果填写在《需求调研表》中。需求管理人员撰写《业务需求说明书》需求管理人员通过对前一阶段业务需求调研结果的整理，形成《业务需求说明书》。业务部门负责人确认《业务需求说明书》业务部门负责人审阅（或安排相关业务人员审阅）并签字确认《业务需求说明书》后，作为一个基线版本，将不允许直接改动，除非通过正规的变更流程。当有较大的变更时，应创建新的基线版本。确定系统需求需求管理人员、系统架构管理人员，根据用户业务需求，结合相关技术约束条件，确定将来系统所要提供的高层的、概括的功能特性，将来系统所要具有的非功能特性，系统的用户界面特性，系统的运行环境，系统设计需遵循的技术标准和原则，系统必须提供的接口等。通过《系统需求说明书》，参与各方都能理解将来系统的概况，并且一致同意将来系统就按照《系统需求说明书》的要求来开发。非功能特性可包括：性能指标；可靠性指标；可维护性；可用性；灵活性；可移植性；可重用性；可测试性；易用性。确定系统需求阶段产生的提交成果为《系统需求说明书》。需求管理人员和系统架构管理人员根据业务需求，规划新系统需求管理人员和系统架构管理人员根据《业务需求说明书》的内容，结合技术条件的约束和要求，分析需要并可能构建一个什么样的系统来解决业务部门的问题和实现业务部门的目标，将系统的主要的功能特性、非功能性需求以及其它一些约束条件明确定义下来，作为对系统的完整定义。这一定义是高层的、概括的，偏重于整体架构和关键特性。需求管理人员和系统架构管理人员编写《系统需求说明书》在《系统需求说明书》中，可包括问题说明、系统定位、系统功能特性、系统非功能性需求等。主要业务部门和技术管理部门确认《系统需求说明书》《系统需求说明书》的内容须经由其涉及到的主要业务部门和技术管理部门负责人的确认后，作为一个基线版本，将不允许直接改动，除非通过正规的变更流程。当有较大的变更时，应创建新的基线版本。《系统需求说明书》和《业务需求说明书》一起，定义了系统开发商必须满足的要求。详细需求调研和需求分析系统开发合同签订后，开发商在理解了《业务需求说明书》和《系统需求说明书》的内容以后，为了进行系统设计，一般还需要进行详细的业务需求调研，并进行需求分析，撰写《系统需求规格说明书》。这一阶段的工作在需求管理人员的管理下进行。用户项目经理和开发商项目经理讨论《业务需求说明书》和《系统需求说明书》的内容用户方（包括业务部门和技术部门）与开发方须对《业务需求说明书》和《系统需求说明书》达成一致的理解，尽早发现问题并经过探讨后可进行必要的变更。由此双方形成对要开发的系统的进一步的共识。用户项目经理和开发商项目经理制订详细需求调研计划需求管理人员、开发商项目经理共同确定：详细需求信息（包括组织机构信息、标准、规范、法律、法规、与其他部门和业务的接口、其它关联的系统等）的获得途径和时间进度，这部分信息的获取一般采用资料收集的手段；要进行调研的主要业务流程、指定的描述流程的业务人员和时间安排，提供这部分调研一般采用与有关业务人员面谈的手段。详细需求调研计划纳入到《项目工作计划》中。开发商详细需求定义人员调研业务流程将要涉及到的业务流程明确下来之后，开发商详细需求定义人员在业务部门的协调下，按计划调研确定每一个业务流程中的参与人员角色、每个角色所执行的活动、在活动中所使用的业务实体、以及在活动中要遵循的一些业务规则。调研结果填写在《需求调研表》中。开发商整理详细需求调研结果，初步确定《系统需求规格说明书》的框架内容根据对《业务需求说明书》和《系统需求说明书》的共同理解，并整理详细需求调研的结果，开发商可由此提出发现的问题，并提出变更《系统需求说明书》的有关内容。开发商并初步确定《系统需求规格说明书》的框架内容，包括建立用例模型。开发商开发界面原型开发商根据当前对业务需求和系统需求的理解，开发完成初步的界面原型，以反映出要开发的系统的概念框架和使用模式。开发商详细需求定义人员用例模型和界面原型为基础与业务部门用户沟通开发商详细需求定义人员用例模型和界面原型为基础与业务部门用户沟通，进一步了解业务部门的要求和期望。开发商详细需求定义人员细化《系统需求规格说明书》的内容详细需求定义人员根据对业务部门的调研结果，对软件需求和界面原型进行完善，最终明确定义以用例表达的功能性需求和非功能性需求，细化《系统需求规格说明书》的内容。业务部门、技术管理部门评审《系统需求规格说明书》召开评审会议，《系统需求规格说明书》的内容须经由其涉及到的业务部门以及技术管理部门的一致确认后，作为一个基线版本将不允许直接改动，除非通过正规的变更流程。当有较大的变更时，应创建新的基线版本。《系统需求规格说明书》的内容完整地定义了软件开发商必须满足的要求。需求变更管理需求变更的目的是保证对需求提出的变更申请以一种可控的、受管理的方式纳入到软件开发活动中。需求变更通过《系统变更单》来管理。需求变更申请人提出变更申请需求变更申请人可以是业务部门用户、系统维护人员、设计人员、开发人员或测试人员等任何发现系统的问题或改进的机会的人，通过填写《系统变更单》，来提交变更申请给需求管理人员。需求管理人员和系统架构管理人员分析需求变更的影响和可行性需求管理人员和系统架构管理人员评估变更对系统性能、成本、进度和风险的影响，判断变更的合理性、可行性，并核定工作量影响。将有关信息填写到《系统变更单》。业务部门负责人、技术管理部门负责人审核变更申请业务部门负责人、技术管理部门负责人根据需求变更申请人、需求管理人员和系统架构管理人员在《系统变更单》中提供的信息，审核变更的必要性、合理性和可行性，决定是否执行变更，并填写审核意见到《系统变更单》。执行变更变更通过审核后，需求管理人员根据跟踪关系，组织开发商执行对《系统需求规格说明书》以及设计文档、测试文档和用户手册等受影响的内容的修改，并提交新版本给文档管理人员。开发商并执行对软件代码或系统配置的修改，在测试管理人员的组织下对新系统进行测试，并部署到生产环境中。需求分析原则必须表示和理解问题的信息域在开始建立分析模型前先理解问题。人们通常总存在急于求成的倾向，甚至在问题被很好地理解前，这经常会导致产生一个解决错误问题的优美软件的诞生。必须定义软件将完成的功能必须表示软件的行为(作为外部事件的结果必须划分描述信息、功能和行为的模型，从而使得可以以层次的方式揭示细节分析过程应该从要素信息移向细节实现开发原型使得用户能够了解将如何发生人机交互。因为人们一般对软件质量的感觉经常基于对界面“友好性”的感觉，因此，强力推荐使用原型方法(以及相应产生的迭代)记录每个需求的起源及原因这是建立回溯到客户的可追踪性的第一步。使用多个需求视图建立数据、功能和行为模型，为软件工程师提供三种不同的视图，这将减少忽视某些东西的可能性，并增加识别不一致性的可能性。给需求赋予优先级过短的时限可能使每个软件需求得于实现的可能性减小，如果采用增量过程模型(第2章)，必须标识那些将在第一个增量中要交付的需求。努力删除含糊性因为大多数需求以自然语言描述，存在含糊性的可能，正式的技术复审是发现并删除含糊性的一种方法。需求分析方法结构化分析创建实体—关系图实体—关系图使得软件工程师可以完整地刻划系统输入和输出的数据对象、定义这些对象的性质的属性、以及对象间的关系。与分析模型中的其他元素一样，ERD是以迭代的方式构造的。可以采用以下的方法：在需求搜集的过程中，要求客户列出应用软件或业务过程涉及到的“事物”。这些“事物”演化为一组输入和输出的数据对象，以及生产和消费信息的外部实体。一次考虑一个对象，分析员和客户定义这个对象和其他对象间是否存在连接(在这个阶段没有命名)。当连接存在时，分析员和客户应创建一个或多个对象—关系对。对每个对象—关系对，考察其基数和形态。迭代地进行步骤2到步骤4，直至定义了所有的对象—关系对。在这个过程进展中发现遗漏是很正常的。当进行若干次迭代时，将总是不断地增加新的对象和关系。定义每个实体的属性。形式化并复审实体—关系图。重复步骤1到步骤7，直到数据建模完成。创建数据流图(DFD)数据流图(DFD)使得软件工程师可以同时开发信息域和功能域的模型。当DFD被精化到较细的级别时，分析员对系统进行了隐式的功能分解，这样完成了第四条操作性分析原则。同时，当数据流过体现应用的加工时，DFD的精化导致了数据的相应精化。第0层的数据流图应将软件/系统描述为一个泡泡；应仔细地标记主要的输入和输出；通过隔离要表示在下一层中的候选加工、数据对象和存储而开始精化过程；所有的箭头和泡泡应使用有意义的名称标记；当从一个级别到另一个级别时要维护“信息流连续性”；一次精化一个泡泡。经常存在一种使数据流图过分复杂的自然趋势，当分析员试图过早地显示过多的细节或在信息流中表示软件的过程时，会发生这种情况。DFD的精化可以连续进行，直至每个泡泡只执行一个简单的操作，即直至每个泡泡所代表的加工执行一个可以很容易地实现为程序组成部分的功能。创建控制流模型对于事件驱动的应用软件，产生控制信息，而不是报告或显示值；处理信息时非常关注时间和性能。这些应用软件在数据流建模以外还需要使用控制流建模。创建CFD的方法，从数据流模型中“剥去”所有的数据流箭头，然后向图中加入事件和控制项(虚线箭头)，并显示一个到控制规约的“窗口”(竖短线)。以以下方法选择潜在的候选事件：·列出所有被软件“读取”的传感器。·列出所有的中断条件。·列出所有被操作者开动的“开关”。·列出所有的数据条件。·回忆对加工叙述进行的名词—动词扫描，回顾所有作为可能的CSPEC的输入/输出的“控制项”。·通过标识其状态描述系统的行为；标识这些状态是如何达到的，并定义状态间的变迁。·关注可能的省略——这是在刻划控制时非常普遍的错误(例如，问“有什么其他的途径可以达到这个状态或从它离开吗？”)。控制规约(CSPEC)控制规约(CSPEC)在两个不同的方面表示系统的行为(在它被引用的层次上)，CSPEC包括一个状态变迁图(STD)，它是行为的“顺序规约”；CSPEC还包括加工激活表(PAT)——行为的“组合规约。通过研究STD，软件工程师可以确定系统的行为，更重要的是，可以确定被描述的行为中是否存在“空洞(ho1e)”。一种不同的表示行为的模式是“加工激活表”(PAT)，PAT在加工的语境中，而不是在状态的语境中，表示STD中包含的信息，即这张表指明当事件发生时，流模型中的哪些加工(泡泡)被激活。PAT可以作为那些必须确立执行者来控制在该层次上表示的加工的设计者的指南。加工规约(PSPEC)加工规约(PSPEC)用来描述出现在求精过程的最终层次的所有流模型加工。加工规约的内容可以包括叙述性正文、加工算法的“程序设计语言”(PDL)描述①、数学方程、表、图或图表。为流模型中的每个泡泡提供了PSPEC，软件工程师就创建了一个“小规约”，它可以作为创建软件需求规约的第一步，并作为对实现加工的程序成分进行设计的指南。数据字典分析模型中包含对