CMMI-工程-RD-基于用例的需求调研过程指南.doc

基于用例的需求调研过程指南基于用例的需求调研过程指南文档编号：GZCY_RD_WUI_PRS-V1.0文档信息：文档名称：文档类别：CMMI模板密 级：机密版本信息：V1.0建立日期：创 建 人： 审 核 者：批 准 人： 批准日期：保 管 人：存放位置：编辑软件：Microsoft Office 2003 英文版CONFIDENTIAL文档修订记录版本编号或者更改记录编号变化状态简要说明（变更内容和变更范围）日期变更人批准日期批准人V1.0C初次创建2004-07-21CMM事业部*变化状态：C创建，A增加，M修改，D删除文档审批信息序号审批人角色审批日期签字备注目录需求调研过程指南31目的32适用范围33 参考资料34需求调研指南34.1简介34.2用例分析44.3业务建模44.4需求45需求调研指导55.1简介55.2原则指导55.3过程指导65.3.1开始阶段65.3.2业务建模阶段75.3.3需求阶段85.3.4结束阶段106 相关文件10需求调研过程指南1目的为项目软件需求调研过程提供指导、提高公司需求调研水平。2适用范围 主要适用于公司采用用例作为需求分析技术的项目软件需求调研过程。3 参考资料 Rational Unified Process版本：2000.02.204需求调研指南4.1简介需求调研指南是从理想的状态下说明需求调研过程，未考虑实际操作的情况。该指南主要是希望所有的参与需求调研的人员能够在头脑中对需求调研的体系过程有个大致了解，同时作为一根主线来指导我们进行实际的需求调研，避免因为复杂的实际情况而迷失了方向。需求调研指南包含两部分内容：业务建模和需求。业务建模主要是对系统的业务环境进行建模的过程。需求是针对系统来说的，在此指系统需求，它是对系统需求进行建模的过程。4.2用例分析对于使用用例分析技术来进行需求调研的项目来说，其一般过程如下：1） 寻找角色2） 调研前景3） 寻找用例4） 定义用例5） 确定用例优先级6） 实现用例对于业务建模和需求过程，都遵循以上过程，只是过程针对的内容不同而已。4.3业务建模业务建模过程的主要目的是清楚的说明系统所处的业务环境，推导出支持业务的系统需求。业务建模的过程如下：1） 评估业务状态。主要目的是评估目标组织当前的业务状态，初步确定目标组织的目标。2） 确定业务流程。主要目的是确定业务术语，概述业务用例模型，确定要对哪些业务用例优先进行说明。3） 改进业务流程。主要目的是详细说明业务用例的定义，确保业务用例正确反映业务的进行方式。4） 设计业务流程实现。主要目的是确定业务中的所有角色、产品、可交付工件和事件，说明业务角色和业务实体是如何执行业务用例实现的。5） 改进角色和职责。详细说明业务实体的定义，详细说明业务角色的职责，正式核对业务对象建模的结果是否符合涉众对业务的看法。4.4需求需求过程的主要目的是清楚的说明系统的需求，定义系统的边界。需求是以后所有开发活动的基础。需求的过程如下：1） 理解涉众需要。主要目的是从该项目的涉众中获取信息，以便理解涉众的真实需要。2） 定义系统。主要目的是确定系统用例模型，确定系统用例和系统角色。3） 管理系统规模。主要目的是为所选择的特性和需求确定开发的优先级，定义代表重要核心功能的用例集合。4） 改进系统定义。主要目的是详细说明用例的事件流，详细说明补充规约，建立用户界面原型。5需求调研指导5.1简介需求调研指导是用来指导项目实际进行需求调研的可操作性指导，它是以需求调研指南中的过程为指导进行的。项目组可根据自己的实际情况对需求调研过程指导进行取舍裁减，形成自己的需求调研过程。需求调研指导包含两部分内容：原则指导和过程指导。原则指导主要说明在需求调研过程中必须遵守的原则，是贯穿于需求调研过程始终的，它是一些实际经验的总结。过程指导是实际上进行需求调研的活动，按照时间的顺序来说明实际上的需求调研过程。需求调研过程分为四个阶段，分别是开始阶段、业务建模阶段、需求阶段和结束阶段。5.2原则指导1） 建立客户的主动参与意识，建立客户的责任感。2） 在进行任何调研之前，必须给客户方做相应的培训。主要是培训需求调研方法、需求调研过程等内容。3） 在进行需求调研之前，一定要明确客户方人员对于需求的决定权，即哪些人能够决定那些需求。4） 在每个阶段开始之前，首先评估此阶段的风险，根据风险来做相应的调整。5） 如果需要客户提供文档，必须要给客户方讲解清楚，特别是涉及到技术细节的时候。这样可以避免因为双方理解不一致而导致的差错。6） 要严格按照计划实施调研过程。计划一般提前3天到7天制订，并提前分发给所有的相关人员以作好准备。7） 对调研过程使用的文档需标使其版本，版本号要保证简单明了。推荐使用年、月、日、小时组合做为版本号。8） 项目组内部建立各个流程的活动、各个流程的参与人员。比如，对于更改的流程的活动及人员等都应提前做出规定。9） 客户方也要建立各个流程的活动、各个流程的参与人员。10） 项目组内部需要作好分工。一种是按业务划分，即哪些人负责哪些模块；一种是按职能划分，即哪些人负责那些工件。11） 客户方也要作好分工，要明确客户方哪些人负责哪些业务。12） 对于项目组和客户方来说，双方需要建立接口，定义清楚接口关系。所有双方的交流都通过接口进行。13） 每次和客户开会前，最好提前制订出提问表或者用活动图表示出大致的业务流程。如果是业务流程的调研，最好使用图表、原型演示等直观形象的方式。14） 每次和客户开会前，需要提前和客户沟通，明确会议的目的、时间安排、参加人、会议内容。并提前将会议内容打印出来进行分发。会议结束后，整理会议记录，分发给会议参加人员，对于未参加的高层负责人，项目组必须抄送。15） 所有需要提供给用户的文档，一定要使用符合客户语言习惯的表达方式，尽量不要使用软件中的术语。5.3过程指导5.3.1开始阶段开始阶段主要是进行需求调研前的准备工作。主要活动如下：1） 建立需求调研过程，建立需求文档模版、需求调研的各种规范以及需求调研指导，建立针对需求调研过程的提问表。此过程包括需求调研阶段要采用的过程方法。此过程可以在需求调研计划中体现出来。2） 制订需求调研计划需求调研计划包含需求调研的四个阶段，但是当前阶段的需求调研计划只是包含了开始阶段的详细计划，其它阶段的计划可以只有大致的里程碑，因为其它阶段的具体操作在开始阶段还不能明确。制订需求调研计划可以按照过程来制订，也可以按照业务来制订。一般应按照业务来制订，如果对于业务不明确的话，可以按照过程来制订。3） 建立双方的项目组指定双方的接口联络人。初步确定双方的沟通方式：包括沟通内容、沟通时间等。4） 建立配置管理环境确定需求文档的版本标识，确定需求文档的变更流程。5） 培训项目组主要是向参与需求调研的项目组成员培训本次调研采用的调研技术、调研过程、配置管理机制等内容。除此之外，还可包含客户方业务的培训。6） 获取文档，建立初步的业务流程图或原型系统可以提前向客户方提出要获取的文档，或者需要客户方准备的文档。根据这些文档和经验，建立简单的业务流程图或者原型系统。5.3.2业务建模阶段业务建模阶段主要是调研业务现状。主要活动如下：1） 首次会议需求调研人员到达客户方后，首先和客户方相关人员组织召开首次会议。该会议主要是确定项目的存在，并由客户的高层领导说明业务现状、建立该系统的动机以及大致的业务介绍。同时，项目组介绍软件开发使用的软件过程、软件开发计划的里程碑等与项目相关的内容，另外，项目组还需介绍需求调研计划的里程碑、需求调研使用的过程、需求调研使用的技术等与当前需求调研相关的内容。2） 获取客户组织结构图和人员结构图这是需求调研最容易入手的地方，可防止需求调研中初始的困难性，在获取人员结构图时，应注意图上是角色，而不是职位。3） 确定客户方人员及职责范围根据结构图，首先确定被调研人员，即需求调研都要向哪些人员提问。其次，确定被调研人员的业务分工，即哪些业务该向哪些人员提问。如果可能的话，给被调研人员按职位分类，如：高层负责人、部门级负责人、岗位级负责人。4） 确定项目组人员职责范围根据大致的业务范围，初步确定项目组负责业务的人员范围及负责工件的人员范围。5） 制订业务建模阶段的详细计划制订业务建模详细计划，建立活动，确定参加人员，确定里程碑。详细计划需得到双方确认，并分发给相关人员。 一般制订最近1周的详细计划，大于1周的计划只需要有活动内容即可，对于参与活动的人员和时间可以暂时不指定。6） 对客户方讲解讲解包含两方面内容：一是讲解业务建模阶段的详细的调研计划；二是向客户方讲解业务建模阶段的目的和作用，所使用的过程，所使用的技术。7） 调研业务前景可以采用提问表或者其它形式来进行，主要确定现在的业务状态、客户方对业务的期望和要求。8） 调研业务流程可以采用提问表、原型系统或者其它形式来进行，主要确定各个业务流程的具体的活动，参与各个业务流程操作的人员角色，在业务流程中操作的业务实体。9） 建立业务对象模型根据业务主角、业务角色和业务实体，建立业务对象模型，其中要表示出业务实体的属性、业务实体的关系、业务实体的状态。10） 编写业务建模文档业务建模文档主要包括业务概述、业务需求规约、补充业务规约、业务词汇表，这些文档的编写是贯穿业务建模整个过程的。业务概述文档主要有四部分内容，第一部分是整体介绍，包括目标组织的业务背景、行业、人员规模等介绍；第二部分是目标组织的结构，包括目标组织的组织结构、人员结构；第三部分是业务现状分析，包括外部因素、内部因素和业务流程3个方面的分析；第四部分是涉众分析，主要包括涉众请求。业务需求规约主要包含业务角色、业务活动、业务实体对象和业务规则。补充业务规约主要是指一些需要包含进来的内容，比如一些功能性的需求等。业务词汇表就是业务术语、名词解释等的列表。（业务建模文档编写指南详见附件：业务概述模板、业务需求规约模板、补充业务规约模板、业务词汇表模板、业务用例模板）11）审批业务建模文档业务建模文档编写完成后，公司内部组织对文档进行审批，审批通过后，将其中的业务需求规约、补充业务规约提交用户进行审批，用户确认通过后才可进入下一阶段。（审批流程的具体操作和输出可参照MT/JG704-01软件开发过程）12）制订需求阶段的详细调研计划制订需求详细计划，建立活动，确定参加人员，确定里程碑。详细计划需求得到双方确认，并分发给相关人员。5.3.3需求阶段需求阶段主要是调研系统需求。主要活动如下：1） 对客户方进行讲解讲解包含两方面内容：一是讲解需求阶段的详细的调研计划；二是向客户方讲解需求阶段的目的和作用，所使用的过程，所使用的技术。2） 建立概述性的系统用例模型。根据业务用例模型抽取出大概的系统用例模型，对于流程性业务，还需向客户询问自动化处理规则。3） 调研涉众请求在进行第1步的同时，可以以提问表的形式或者其它形式调研客户方对系统的期望和要求。4） 调研系统用例将第2步获取的系统用例模型和第3步获取的涉众请求的内容合并，得到初步的系统用例模型。此系统用例模型不是完整的，需要继续调研来完善。可以将此系统用例模型展示给客户方，同时辅以提问表、原型系统演示或者其它形式，来完善系统用例模型。5） 确认系统边界根据确认结果及询问结果整理系统用例模型，提交客户方确认系统用例是否完善。6） 确认系统用例优先级根据确认后的系统用例模型，与客户方确认系统用例优先级和重要程度。系统用例的优先级和重要程度是以后迭代计划的基础。 7） 详细定义每个用例详细定义每个用例，采用原型演示、图表等形象的方式与客户方进行讨论，详细描述每个系统用例。同时，可以在此进行一些有关系统用例的整理工作，比如扩展关系、使用关系等。8） 获取非功能需求在进行步骤3、4、5时，可向客户询问系统的非功能需求。9） 编写系统需求文档需求文档文档主要包括系统概述、系统需求规约、系统词汇表，该文档的编写是贯穿需求阶段整个过程的。系统概述文档主要包括涉众分析和产品总体特性两部分内容。系统需求规约主要是系统用例的详细描述，此文档可以结合ROSE中的系统用例模型来说明。系统词汇表主要是名词术语等的列表。（需求文档编写指南详见附件：系统概述模板、系统需求规约模板、系统词汇表模板、系统用例模板）10） 审批系统需求文档需求文档编写完成后，公司内部组织对需求文档中审批，审批通过后，将其中的系统需求规约提交用户进行审批，用户确认通过后才可进入下一阶段。（审批流程的具体操作和输出可参照MT/JG704-01软件开发过程）5.3.4结束阶段结束阶段主要是确定下一步的行动计划，主要活动如下：1） 调整软件开发计划根据调研结果调整软件开发计划，制订迭代计划，更新风险列表。软件开发计划和迭代计划的制订，要求客户方的参与，同时，对于软件开发计划和迭代计划中的里程碑及需交付的文档或程序，双方要达成一致。2） 确认需求管理机制