[指南]需求分析过程.doc

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