执法案件管理系统开发管理方案.docx

执法案件管理系统
开发管理方案

目录
执法案件管理系统 1
开发管理方案 1
1. 引言 3
1.1 编写此文档目的 3
2. 拓普应用生命周期管理（）构成 3
3. 统一变更控制（） 6
3.1 统一变更控制（）平台的构建 6
3.2.1 的特点及优势 7
3.2.2 软件开发过程中的变更 8
3.2.3 统一变更控制管理 10
3.2.4 活动和工件 10
3.2.5 活动管理 11
3.2.6 工件管理 13
3.2 需求管理 30
3.2.1 需求管理概述 30
3.2.2 需求管理的工作流程 35
3.2.3 需求管理的原则与实现 38
3.2.4 管理变更请求与控制 48

1. 引言
1.1 编写此文档目的
此文档主要为指导执法案件管理系统的开发进行统一、规范的管理。
2. 拓普应用生命周期管理（）构成
拓普公司根据多年的软件开发和系统运维经验，在软件开发过程管理上采用统一过程管理最佳实践，在运行维护管理上遵从治理的最佳实践，建立了以统一变更控制过程管理、统一开发过程管理和运维及问题管理为基础的拓普应用生命周期管理（）体系。将以往单纯的软件开发过程管理拓展到整个应用的生命周期管理，在环节上包含需求、设计、编码、测试、发布和维护等工作，在过程管理上涵盖了需求管理、配置管理、变更管理、开发过程管理和运维及问题管理等项内容，其构成如下图所示：
需求提出人员
提出需求
验证需求

开发/测试组长
打开任务
分配活动

开发人员
代码开发
活动提交
集成构建人员
创建基线
构建版本
测试人员
执行测试
关闭任务
项目管理人员
§ 划分优先级
§ 计划和分配

高层管理人员
§ 监控
§ 决策

问题受理人员
受理故障
受理需求
项目启动

在应用开发项目确立并启动后，开始进入了大规模软件开发阶段，由此，应用掀开了其生命周期的序幕，的管理流程如下：
⑴应用单位业务人员与公司分析人员的需求采集过程
⑵项目管理人员启动开发项目过程管理流程，制定产品开发计划
⑶配置管理人员启动配置管理流程，制定配置管理计划
⑷需求管理人员启动需求管理流程，建立需求跟踪机制
⑸分析人员依照采集的需求进行需求分析
⑹测试设计人员与分析人员协调，同步进行测试设计，
⑺设计人员依照需求分析结果进行设计
⑻开发人员依照设计进行编码
⑼测试人员依照测试设计进行测试
⑽按照迭代计划，重复执行⑸—⑼，直到开发结束
⑾集成人员按产品形式进行集成
⑿质量控制人员进行产品质量审验
⒀公司将产品发布到用户环境
⒁运维人员在知识库的支撑下为用户解答问题
⒂运维人员无法处理的问题将以问题报告单的形式记录在运维系统
⒃问题分析人员将问题报告单分类，提取缺陷和需求，申请变更
⒄变更控制委员会审核变更申请，确定变更方案
⒅需求进入需求管理流程，然后进入⑸
由上述流程描述可见，在管理流程中，形成了“需求—开发—维护—需求”这样一个闭环管理流程，其中的流程控制如下：

将应用生命周期中的各个工作环节和管理过程进行了如下的划分：
统一开发过程管理
应用项目确立后初始的需求采集和管理
需求分析
设计
编码
测试
发布
统一变更控制管理
需求管理，主要针对开发过程中的需求变化和运维过程中产生的新需求
缺陷管理
配置管理
变更管理、
运维及问题管理
问题解答：运维过程中的操作性指导
知识管理：将运维出现的问题进入知识库
运维受理：故障受理和问题报告单受理
3. 统一变更控制（）
3.1 统一变更控制（）平台的构建
统一变更控制（）又叫统一配置管理，是在大量软件工程实践经验和用户反馈的基础上提出的第三代配置管理解决方案。是用于管理软件开发过程（包括从需求到版本发布）中所有变更的“最佳实践”流程。定义了一个可以立即用于软件开发项目的一致并基于活动的变更管理流程。
河南拓普网络计算机工程有限公司采用公司的产品 和 构建了自己的运行平台。通过 和 的支持，已成为拓普公司支持统一开发过程管理体系和运维及问题管理体系的关键组成部分和基础支撑平台。
通过抽象层次的提升简化了软件开发和系统维护，从而使得软件开发团队和运维团队从更高的层次根据活动（）来管理变更。通过，一个开发活动可以自动地同其变更集（封装了所有用于实现该活动的项目工件）相关联，这样避免了管理人员手动跟踪所有文件变更。
3.2.1 的特点及优势
支持软件开发和运行维护一体化管理
通过工作流程，将软件开发流程和运行维护流程有机地结合，形成一个可以贯穿应用生命周期的统一管理流程。
预定义的工作流程
可以直接采用预定义的工作流程，快速提升开发和运维组织的软件配置管理水平；
项目的跟踪和组织
项目管理人员可以实时掌握项目的最新动态，合理分配资源和调度开发活动，跟踪软件运行状况；
协作自动化
通过将许多耗时较多的任务自动化处理，使得开发人员更多地将注意力集中在更高层次的开发活动上；
轻松管理基线
将开发活动嵌入到各个基线中，这样测试人员确切地知道他们将测试什么，而开发人员则确切地知道其他开发人员做了什么；
支持跨功能开发组
已成为产品中的核心部分，从而可以将从需求到测试各个阶段的工件（例如需求文档、设计模型、应用源代码、测试用例以及及内容等）在框架下进行统一集成，简化了贯穿整个软件开发周期的变更过程；
基于同一代码构件可以进行多项目开发，简化了多项目开发管理，增大了代码共享，节省了开发资源；
可扩展性
小型团队可以从和开始，而大型团队可以结合的高级构建管理（）功能，以及和跨地域的使用。
3.2.2 软件开发过程中的变更
变更是非常频繁并且是不可避免的！
应用开发团队面临着巨大的挑战：一方面市场要求以空前的速度来开发高质量的软件应用；另一方面，软件应用需求随着开发环境和结构的日趋复杂而变得更加复杂；加上分布式开发、高性能要求、多平台、更短和连续的发布周期要求，这些及其他一些因素加重了软件开发一直承受的压力，实际上现在许多软件开发团队经常在能否成功开发一个新型应用上“赌博”。
由于软件开发不同于传统意义的工程技术（如建筑、机械等），市场变化以及技术上的高速更新都注定了软件变更是非常频繁并且是不可避免的，可以说变更是软件开发的基石。一方面在软件开发环境下的内部活动以新特性、新功能增强以及缺陷修复等方式不停地制造着变更；另一方面外部因素，例如新操作环境，新工具的集成，工程技术和市场条件的改善等以另一种力量驱动着变更。
管理变更的能力是项目成败的关键！
既然变更是不可避免的，那么如何管理、追踪和控制变更就显得尤为重要。尽管有多种方式可以帮助开发团队提高变更处理能力，但其中最重要的一点是整个团队的协作性，这是因为以一种可重复和可预测的方式进行高质量软件的开发需要一组开发人员相互协作。随着系统变得越来越大和越来越复杂，尽管个人生产率依然十分重要，但是决定项目成败更多的是作为一个整体的开发团队的生产率。
而软件开发团队的生产率很大程度上是由其相互协作和组织活动的能力决定的，并且开发团队的成功同其如何高效地响应不断变化的环境因素紧密相连。
对在竞争激烈的市场下想占有一席之地的开发团队而言拒绝变更无疑是行不通的，只有积极面对变更，采取有效的工具、方法和流程有机地管理、追踪和控制变更才是保证开发团队成功的关键。另外，由于各种因素的变更，原来采用的工具、方法和流程也会随着组织的成长和不停变化的需求而逐步演化，因此对软件开发团队来说另一个关键的成功因素是其扩展能力。
3.2.3 统一变更控制管理
随着开发团队的成长、产品发布周期的加速以及对软件资产（包括代码、文档等）控制的加强，对基于第三代配置管理工具和过程的需要变得越来越大。软件的统一变更管理（）通过，以及所提供的开发平台实现了贯穿整个软件开发周期的配置管理过程，即基于活动对软件构件和项目进行变更管理。
3.2.4 活动和工件
随着软件系统和开发团队在规模和复杂性上的不断增长，对开发团队来说如何围绕周期性的版本发布来合理地组织开发活动以及高效地管理用于实现这些活动的工件变得日益重要。活动（）可以是在现有产品中修复一个缺陷或者新加一个增强功能。工件（）可以是在开发生命周期中涉及的任何东西，例如需求文档，源代码，设计模型或者测试脚本等。实际上软件开发过程就是软件开发团队执行活动并生产工件。集成了由提供的变更请求活动管理和提供的工件管理功能。集成了提供的活动管理能力和提供的工件管理功能，如下图所示：

3.2.5 活动管理
中的活动管理是由提供的，是一个高度灵活和可扩展的缺陷及变更跟踪系统，它可以捕获和跟踪所有类型的变更请求（例如产品缺陷、增强请求、文档变动等）。在中这些变更均以活动出现。
为活动的跟踪和管理提供了可定制的工作流，这使得开发团队可以更容易地：
将活动分配给某个具体的开发人员
标识同活动相关的优先级、当前状态和其他信息（如负责人、估计工期、影响程度等）
自动产生查询、报告和图表
根据开发团队或开发过程需求可以灵活地调整工作流引擎：如果开发团队需要快速部署，那么也可以不进行定制，直接使用预定义的变更过程、表单和相关规则；当开发团队需要在预定义的过程上进行定制时，可以使用对他们的变更过程的各个方面包括缺陷和变更请求的状态转移生命周期，数据库字段，用户界面（表单）布局，报告，图表和查询等进行定制。
贯穿整个开发过程用于管理和跟踪缺陷和其他变更的一个高效工作流对于满足当今高质量标准及紧迫的产品工期的需要是非常重要的。提升了这些变更的抽象层次以便可以从活动的角度来观察变更，然后工作流引擎将活动同相关的开发工件连接在一起。提供了一个现成的过程框架用于缺陷和变更跟踪工作流，如下图所示

3.2.6 工件管理
提供了一个软件工件管理（）框架，开发团队可以使用这一框架来管理贯穿项目生命周期的所有工件。将基础框架同中的活动管理结合在一起，从而提供了对工件和活动的集成管理。提供了：
安全的工件存储和版本化
并行开发基础框架无限分支能力和强大的合并功能
自动代码共享
用于选择正确工件版本的工作空间管理
完全的可延展性从小型本地项目工作组到大型全球分布式开发团队
另外，提供了灵活的的基础框架，通过使用灵活的元数据，如标签、分支、属性、触发器（）和超级链接（）等，开发团队可以定制他们自己的过程。
由此可见，不同开发团队和项目可以通过使用不同的策略，开发团队可以从这种灵活性中受益。而是基于一个经过验证的、成功的开发过程，因此为希望快速启动高效的开发团队也可以直接使用这一过程来自动实现项目策略。具体在以下六个方面提供了开发过程。
3.1.6.1 的六个过程领域
在六个具体领域提供了所定义的过程：
开发人员在共享及公共代码工件上的隔离和协作；
将一起开发、集成和发布的相关工件组按构件（）进行组织；
在项目里程碑创建构件基线（）并根据所建立的质量标准来提升基线；
将变更组织为变更集（）；
将活动管理和工件管理集成在一起；
按项目来组织软件开发并支持多项目之间的代码共享；
3.1.6.2 开发人员的隔离和协作
开发人员需要相互隔离的工作环境以隔离彼此的工作，避免其他组成员的变更潜在地影响其工作的稳定性。提供了两种方式来访问工件的正确版本并在私有工作空间中在这些工件上进行工作。这两种方式是静态视图和独特的基于的动态视图，它们可以据本地或网络使用而分别进行实施。
静态视图为开发人员提供了在断开网络连接的情况下进行工作的灵活性，另外开发人员也可以容易地将他们的工作同开发主线进行同步。动态视图则通过一个独特的虚拟文件系统（）来实现，它使得开发人员可以透明地访问正确工件的正确版本而无需将这些工件版本复制到本地硬盘驱动器上。另外由于动态视图可以实时进行自动更新，因此紧密工作在同一分支上的开发团队无需手动更新/复制文件即可立即看到其他人员所做的变动。不管使用何种方式，开发人员都可以并行工作在多个发布版本上。例如，一个开发人员工作在发布版本2上，同时他也可以修复发布版本1中的一个缺陷，而不用担心自己的两个活动涉及的代码互相干扰或受其他开发人员的干扰。
隔离不稳定的变更对于将错误最小化是非常关键的，但是将所有的变更集成到一个所有开发团队成员均可访问的公共工作区域却是团队开发环境下的一个基本要求。今天基于构件的软件开发方法论的广泛应用以及代码变更频率和幅度的增加都要求开发团队能经常和较早地将各个开发人员的工作进行集成。以便在尽早解决可能出现的问题。
使用，开发团队可以实现多种项目策略来同时进行工作的隔离和协作。通过强大的分支和合并功能可以支持大规模的并行开发。
在中可以根据不同用途来建立分支，如开发人员分支，新特性分支、缺陷修复分支、新需求分支等等，从而开发团队可以根据需要建立适于自身情况的分支模型，灵活实现软件配置管理流程。但对于希望能快速利用成熟的软件开发流程的开发团队而言，则提供了一个直接可用的分支模型。实际上在中，在分支基础上对其在更高层次上进行了抽象，从而形成了一个新概念流（）。流表示一个私有或共享的工作空间，它定义了项目版本的一致配置并在项目中的隔离和有效协作之间提供了一种平衡。熟悉的读者可以将流理解为开发人员分支，中既有为每个开发人员配置的私有开发流，同时为负责集成所有交付工作的集成人员配置的公共集成流（图3）。由于紧密结合了活动管理，因此其他分支用途，如特性分支、缺陷修复分支等将作为活动出现并附加到相应的工作流中。提供了公共集成工作区和私有工作区，如下图所示：

私有开发流为开发人员提供了相互隔离的工作空间，该空间在最开始由满足一定质量标准的公共工件进行初始化。开发人员使用这些私有工作空间来进行工件的变更，构建和测试。当开发人员对他们的变更感到满意时，他们可以将这些变更交付（）到公共集成流上。为了使开发人员同其他人员的进度同步，开发人员也可以用来自项目公共集成流上最新的稳定基线来变基（）他们的私有工作流。使用，开发人员可以选择什么时候进行交付和变基。
实际上项目集成流充当了所有开发人员的所有变更的协调点。为了更好地协调所有开发人员的变更集成，引入了基线（）的概念作为对项目进度的度量。基线是一次构建（）或配置的抽象表示，它实际上是构件的一个版本，而构件是相关工件的集合。项目开发团队在开发过程期间不断地创建和提升基线。随着不同开发人员交付变更给集成流，他们交付的变更将被逐一收集到项目基线中。随着基线的构建、测试和批准，它们可以被逐步提升到不同的基线级别。
基线提升级别具有两方面的功能：第一，它使项目经理或项目管理人员可以建立软件质量标准。由于当基线达到某种预定义的质量标准时就可以被标以某种基线级别，因此项目经理可以设置项目策略，标识出在哪一个基线级别（如"通过测试的"）开发人员可以执行变基操作。第二，基线提升级别就具体的开发人员应该如何同其所开发的工件进行交互提供了指导。例如，根据某条基线通过某些冒烟测试的时间可以帮助测试人员确定什么时候开始测试。
3.1.6.3 构件基线
第二个过程领域是将工件组织为构件。在第二代配置管理中，大多以文件版本形式来管理所有的文件，当一个复杂项目中包含成千个文件上万个版本时，整个项目的开发控制将变得相当复杂，因此对众多的文件进行合理分类以呈现系统的设计要素可以大大简化项目开发控制。
通过将多个工件组织为构件（在中构件指一个的根目录或的某个第一层子目录）从而扩展了软件工件管理的版本控制能力，并且还提供了用于自动化构件管理的工具和过程。即用基线对构件而不是构件中众多的版本进行标识，然后用这一基线作为新的开发起点并更新开发人员的工作空间。
构件基线是在标签（）的基础上结合活动管理所做的扩展，即您可以知道一个构件基线中包含了哪些开发活动，例如一条基线可能包含了三个开发活动，如的修复、用户登录界面汉化以及新增打印特性的支持。
对于包含多个构件的复杂系统，提供了基于多个构件的组合基线，即多个构件之间可以建立依赖关系，一旦底层构件的基线发生变化，例如生成一条新基线，其上层构件相应地也自动建立起一条基线，该基线自动包含底层构件基线。例如，一个较为复杂的系统包含“数据库访问”，“业务逻辑处理”和“前端图形界面”三个构件，其中“前端图形界面”构件依赖于“业务逻辑处理”构件，而“业务逻辑处理”构件依赖于“数据库访问”构件。这样当“数据库访问”构件发生了变化并新建了一条新基线后，在“业务逻辑处理”构件和“前端图形界面”构件各自动建立了一条新基线。这样上层构件的最新基线可以自动跟踪底层构件的最新基线。
构件管理的自动化对于高效无误地开发可能包含数千个源代码工件（还有其他相关的工件，如内容，设计模型，需求说明和测试脚本等）的复杂软件系统而言意义重大。
3.1.6.4 构件基线提升
项目开发团队的成员工作在一个项目（）中，项目经理通过配置软件构件从而使项目成为由构件构成的体系结构。大多数组织将管理的构件设计为可以反映出他们软件体系结构的方式，即将所有相关工件按体系结构组织为有意义的子系统，进而放入不同的构件中。用构件可以直接对软件体系结构建模，如下图所示：

如上节所描述的，开发人员在交付变更到公共集成流时可以周期性地更新他们私有开发流中的构件。然后开发团队可以根据开发过程的当前阶段和质量级别对构件进行评级。项目策略确定了在开发人员变基之前构件基线必须达到的质量级别以及其他开发团队成员（如测试人员）应该如何同构件基线交互。在稍后会对项目以及项目策略做更多描述。提供了五种预定义的基线级别，它们包括被拒绝（），初始（），通过构建（），通过测试（）和已发布（）。另外，允许开发团队用他们自己的命名规范和提升策略对这些预定义基线级别进行定制。
3.1.6.5 变更集
第四个过程领域是将独立的工件变更组织为可作为整体进行交付、跟踪和管理的变更集中。由于通常当开发人员工作在一个活动（例如缺陷修复）上时，他们很少只修改一个文件，因此用变更集可以表示用以完成某个具体活动的工件的所有变更，例如为修改一个编号为63的缺陷变动了50个目录/文件的120个版本，则缺陷63的变更集为相关的120个文件/目录版本。当开发人员同时工作在多个变更请求上的需要使得这一过程更加复杂。例如，一个开发人员在进行一个新发布版本的开发，这时由于当前发布版本的一个错误要求他不得不中断当前的开发工作转而去修复这一缺陷，这样该开发人员必须在同一工件上进行两种不同的变更，一种是在未来发布版本中的增强功能变更，另一种是在前一发布版本中修复缺陷的变更。
通过将同一个开发活动相关的所有变更收集到一个变更集中，简化了管理多个工件变更或者多个工件版本的过程。围绕具体的开发活动来进行工作组织，同时还确保已完成的活动包含所有必要工件上发生的所有变更。
3.1.6.6 活动和工件管理
第五个过程领域是通过使用一个可将活动及其相关工件集链接起来的自动化工作流将活动管理和工件管理集成起来。这给了开发团队极大的灵活性来为不同类型活动的管理指定不同的工作流。提供了最常用活动类型的预定义工作流，包括缺陷修复和增强请求。工作流如下图所示：

开发团队还可以使用这一模块来对这些预定义过程进行定制，项目经理或者项目管理人员可以用它来创建所有需要的活动类型，包括缺陷修复，增强功能请求，文档变动以及网站变动等。使用的图形用户界面，项目经理也可以定义字段，表单以及每个记录类型的状态转移。
为了方便开发人员更容易地标识活动和项目代码库中工件间的关系，自动将活动和其相关的变更集链接起来。当在一个项目中工作时，开发人员所交付的是活动（见开发人员隔离和协作一节）而不是文件形式的工件。类似的，当开发人员变基时，他们根据新构件基线提供的活动（而不是文件形式的工件）来重审将要在他们的私有开发流中接收的变更内容。这样，开发人员不仅可以看到所有相关工件完整的版本历史，而且可以看到实现每个变更的所有活动。这给了开发团队一个项目是如何从一个阶段演进到下一个阶段演进的全面视图，当需要标识出一个工件版本的变更是如何影响另一个版本时，这一优点所带来的价值是无法估计的。
使用一致、可重复的用于活动管理的过程，通过活动管理和工件管理的集成可以帮助开发团队减少错误，开发人员还可以避免许多通常需要手工作业的单调工作，从而更有效率地完成开发任务。可以将活动和相关的工件链接起来，如下图所示：

3.1.6.7 项目和项目策略
中的项目可以和实际软件开发中的各种项目对应，每个项目包含一个集成工作流和若干个私有开发流，项目可由一组构件构成。这里需要强调的是一个构件可以被多个项目共享，进而项目A中的开发人员可以对一个构件进行修改，创建新的构件基线；而项目B的开发人员可以参照同一构件以及该构件在项目A中生成的基线，但不能对该构件进行任何改动。因而项目从代码级提供了软件共享及重用的良好基础。部分原有开发人员既可以加入该项目进行原有1.0版的错误修复，又可以互不干扰地在原有项目中进行2.0版的需求分析。
在项目上另一个突出特点是不同项目中的开发流之间可以进行跨项目的工作交付。即一个项目可以将一条构件基线中包含的工件交付给另一个项目，也可以将一个开发流上的活动变更集交付给另一个项目。
可以看出项目从一个更高层次上支持了传统意义上基于分支的并行开发，这对于软件开发组织从面向项目到面向产品的转变，合理利用软件开发人力资源，改善软件产品体系结构从而支持更为复杂的软件开发具有重大意义。
由于同一代码构件上多项目开发的引入，相应地加入了多种项目策略来进行支持，用户可以根据需要灵活定义项目策略。例如上面提到的基线级别，可以定义只有基线级别提升到“”才能作为其他开发工作流的推荐基线。另外，对于多项目间的代码交付和共享，还可以定义是否允许接受其他项目的变更等。除了项目一级的策略以外，在工作流一级也有类似的访问策略，如某个工作流是否允许接受来自本项目或其他项目的工作流上的变更，是否允许向本项目或其他项目的工作流交付变更等等。
3.1.6.8 对开发团队和运维团队的支持
成功的软件配置管理需要同时重视人的活动和得到整个开发团队的全体接受。如果开发团队成员不能或不采用方法论的话，实现将会失败。拓普公司多年来从成功的软件开发团队和自身的软件开发中吸取最佳实践经验，将作为一个可为开发团队采用的优化过程来进行设计。的功能已全部嵌入到统一开发过程管理（，）中，是在软件开发的各个生命周期应用最佳软件开发经验的一个实用框架。软件开发团队通过直接访问并通过，和的工具专家可以得到关于过程及其详细描述。
通过使开发人员可以完成下面的工作而简化了他们的工作：
将运维与开发通过需求的传递和跟踪，有机地结合起来
快速准确地访问正确工件的正确版本
在他们的工作空间中相互隔离地进行各自的工作，但可以选择什么时候交付自己的工作及接收其他人员的变更
使用项目策略来标识什么时候质量达到了可以接受的级别从而可以在自己的私有工作空间中接收其他人员的变更
从他们自己的桌面透明地访问工具。使用可同他们最常使用的工具（如）进行集成的工具来进行他们的工作在开发活动上没有附加不适当约束或增加工作时间
自动而透明地将变更集同活动进行集成
自动进行活动的跟踪、管理和报告。
另外，还减轻了项目经理的负担，从而项目经理可以
通过一个预定义的生命周期工作流在任何时间标识一个具体活动的状态
用统一的报告来监控最新的项目状态
将精力集中在高优先级或紧急的事件（活动）上
确定工作负载并平衡任务分配
3.1.6.9 对应用生命周期的支持
到现在为止，本文主要集中在源代码和其相关工件上，如对象文件和头文件等。但是使用时贯穿生命周期的变更也可以由非开发人员进行管理，这样就最佳实现了统一变更管理的全部好处。这些非开发人员包括分析人员，设计人员、测试人员、运维人员甚至最终用户。相应的工件包括他们在相关领域产生的工件，例如分析人员所创建的需求文档和用例（），设计人员所建立的设计模型和用例，测试人员建立的测试脚本，测试数据和测试结果，问题报告单，等等。
为了高效地通信和协作工作，开发团队成员需要有效地共享这些工件。包含有一个集成平台，通过这一公共平台可以访问贯穿多个领域的所有类型的开发工件，提供了一个用于管理贯穿应用生命周期的信息共享的过程层。非软件开发人员（如分析人员、设计人员以及测试人员）可以应用原理象控制代码变更一样来控制他们生产的工件（如需求文档，用例，设计模型，测试脚本及测试数据、问题报告单）。工作流引擎强化了活动管理，另外一致的工作流使得所有的团队成员都可以容易地标识优先级，而提供的工作列表（）特性可以使每个人均可从他们的桌面透明访问待进行的工作（活动）列表，从而容易地标识出他们下一步需要进行的工作。同样构件基线是新工作（分析、设计、开发及测试）的基础并指导团队成员什么时候更新他们工作空间。开发团队成员在生命周期的不同阶段产生不同的工件，如下图所示：

3.1.6.10 来自分析的工件
分析人员扮演着定义项目范围的重要角色，分析人员需要确定解决方案是什么以及系统边界。在分析期间这些专业人员创建了多种不同的工件来帮助解释说明所建议的解决方案，这些工件包括需求文档，用例以及可视化模型。开发团队在整个开发过程中不断使用这些工件来管理项目变更是必不可少的。
成功的项目依赖于正确的需求管理。高效的需求管理包括减少开发的进度风险和系统的不稳定性，以及跟踪需求变更。项目管理，风险评估以及相关评估标准的产生都依赖于需求管理和需求的可追溯性即开发团队以一种规范过程接受变更并审查需求变更的历史。
通过需求管理的工具的应用，软件开发团队可以使来创建、管理和跟踪分析工件，例如需求属性、需求说明和管理计划，以及用例模型，术语表以及涉众（）请求。
项目以同管理代码相似的方式管理需求，此外还将这些需求工件包含在构件基线中。这样分析人员不仅知道哪些活动构成了一条构件基线中的工件，还知道哪些需求指导着这些工件的开发。
3.1.6.11 来自设计的工件
设计人员对系统基础结构建模并使用用例和设计模型进一步细化系统定义。通过设计工件对系统进行抽象，可以减少整个系统的复杂性。
在实际开发过程中经常会出现这样一种情况：一些开发团队不能继续使用一些设计模型，因为正式的编码工作已经开始。这是一个错误，因为这些设计模型在帮助规划整个工作，另外对于协助新的组成员快速上手，度量正在进行中的变更请求的影响，以及评估整个项目风险都非常有价值。由设计工具提供的双向工程功能可以帮助开发团队保持当前编码进度和这些模型之间的同步，而确保模型与代码是最新的。
在项目中，构件基线包含模型工件和代码工件。比较/合并特性的紧密集成使得开发团队可以尽可能方便地在设计模型的同时进行编码。这时中的变更集（参见变更集部分）可以扩展到模型元素，这样变更集便包含了代码工件上的变更以及模型工件上的变更。交付（）和变基（）操作（参见活动和工件管理部分），使得多个设计人员可以在模型上同时工作，如同开发人员并发工作在代码上一样。并行开发过程中模型和代码之间的交互，如下图所示：

3.1.6.12 来自测试的工件
传统的开发方法将测试工作放到开发的末期，在编码工作之后进行。成功的构件开发团队都体会到单元测试（）对于项目成功是非常重要的，使用单元测试就是不将构件的质量保证放到集成阶段，而是预先对单元、子系统和系统进行测试。
所有这些并发测试产生了大量的测试工件包括测试需求、测试脚本、测试数据和大量的测试结果。测试工具为开发团队提供了可持续地生产高质量软件工件所需的集成框架。借助，开发团队可以并发地管理他们的测试工件和相关的开发工件。
今天，大多数开发团队都意识到将这些测试工件和构件基线集成到一起的好处。在项目中，可以在一条构件基线中包含所有的代码工件以及相关的测试需求，测试程序和测试数据。
这样前面描述的变更集就可以扩展到测试用例，测试脚本和测试数据。集成的活动和工件管理将活动的整个范围从对代码变更的测试校验活动到由其活动描述的变更集链接起来。
3.1.6.13 来自运维的工件
使用时，贯穿应用生命周期的变更可以由非开发人员进行管理，这样就最佳实现了统一变更管理的全部好处。这些非开发人员包括分析人员，设计人员、测试人员、运维人员甚至最终用户。来自运行维护的工件主要是问题报告单和衍生出来的需求。
一个用于管理贯穿应用生命周期的信息共享的过程层。非软件开发人员（如分析人员、设计人员以及测试人员）可以应用原理象控制代码变更一样来控制他们生产的工件（如需求文档，用例，设计模型，测试脚本及测试数据、问题报告单）。
提供了成功的项目依赖于正确的需求管理。高效的需求管理包括减少开发的进度风险和系统的不稳定性，以及跟踪需求变更。项目管理，提供了对来自运行维护的工件主要是问题报告单和衍生出来的需求的管理，并将这些工件统一纳入需求管理之中，通过需求管理的工具的应用，软件开发团队可以使来创建、管理和跟踪分析工件，例如需求属性、需求说明和管理计划，以及用例模型，术语表以及涉众（）请求。
3.2 需求管理
3.2.1 需求管理概述
3.2.1.1 需求管理的目标
系统开发团队之所以管理需求，是因为他们想让项目获得成功。满足项目需求即为成功打下了基础。若无法管理需求，达到目标的几率就会降低。 以下最近收集的证据很有说服力：  从 历年的   证实，导致项目失败的最重要的原因与需求有关。  的 报导了该公司的一项研究，该公司对多个项目作调查后发现，百分之七十四的项目是失败的，既这些项目不能按时按预算完成。其中提到最多的导致项目失败的原因就是“变更用户需求”。 
避免失败就是一个很充分的理由。提高项目的成功率和需求管理所带来的其他好处同样也是理由。  的  报告进一步证实了与成功项目关系最大的因素是良好的需求管理。 
理解需求管理的第一步就是对什么是需求管理达成共识。 把需求定义为“(正在构建的)系统必须符合的条件或具备的功能”。电气和电子工程师学会使用的定义与此类似。 著名的需求工程设计师   和  H.  提出了一个包容且更为精练的定义，它特指软件方面 ，但不仅仅限于软件：
“软件需求可定义为：用户解决某一问题或达到某一目标所需的软件功能。 系统或系统构件为了满足合同，规约，标准或其他正式实行的文档而必须满足或具备的软件功能。”
由于需求是正在构建的系统必须符合的事务，而且符合某些需求决定了项目的成功或失败，因此找出需求是什么，将它们记下来，进行组织，并在发生变化时对它们进行追踪，这些活动都是有意义的。 换句话说，需求管理就是：一种获取，组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。 
这个定义与  与  以及  的“软件需求工程”的定义相似。需求工程包括获取，分析，规定，验证和管理软件需求，而"软件需求管理"则是对所有相关活动的规划和控制。这里介绍的以及  提出的需求管理定义包括了所有这些活动。它们的区别主要在于这里选用了“管理”这个词，而不是“工程”。管理这个词更合适用来描述所有涉及到的活动，并且它准确地强调了追踪变更以保持涉众与项目团队之间共识的重要性。 
“引出”这个词可定义为团队用来获取或发现涉众请求，确定请求后隐藏的真正需要，以及为满足这些需要对系统提出的一组适当需求。 
需求管理问题 一个目的在于确保系统符合人们对其期望的流程面临着哪些困难呢 当它真正在实际项目实施时，困难就暴露出来了。
下面列出了更多与需求有关的问题：
需求不总是显而易见的，而且它可来自各个方面。 需求并不总是容易用文字明白无误地表达。 存在不同种类的需求，其详细程度各不相同。 如果不加以控制，需求的数量将难以管理。 需求相互之间以及与流程的其他可交付工件之间以多种方式相关联。 需求有唯一的特征或特征值。例如，它们既非同等重要，处理的难度也不同。 需求涉及众多相关利益责任方，这意味着需求要由跨职能的各组人员来管理。 需求发生变更。 需求可能对时间敏感。 当这些问题与需求管理和处理技能不足以及缺乏易用工具等情况一同出现时，许多团队都对管理好需求不抱希望了。  已经开发出指导团队提高需求管理技能和流程的专业技术，并使用相应的工具使得上述的流程和专业技术得以实现。 
3.2.1.2 需求捕获 
从上述的分析可以看出，需求的捕获是需求管理的基础和前提。在这里，将介绍一种为业界所广泛采用并经验证的需求捕获方法，即用例模型。 用例模型是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契约。
用例模型用作分析，设计和测试活动的基本输入。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。参与者()和用例()是用例模型中的主要元素。 
用例图用于显示包含参与者和用例的用例模型示例。系统建模有许多种方法，每种建模方法可以满足不同的目的。然而，用例模型最重要的作用是将系统行为传达给客户或最终用户。可能与该系统交互的用户和任何其他系统都是参与者。由于参与者代表了系统用户，它们协助界定系统并提供十分明确的系统用途说明。编写用例依据参与者的需求来进行。这样就确保该系统成为用户期望得到的系统。 
参与者和用例都是通过将客户需求及潜在用户当作重要的信息查找到的。找到这些用例和参与者后，应对它们作简要说明。在详细说明这些用例之前，客户应复审该用例模型以核实所有的用例和参与者都已经找到，并且它们可以提供客户所需要的东西。 在迭代开发环境中，您可以选择用例的子集以便在每个迭代中详细描述。参与者和用例找到后，需要详细说明每个用例的事件流。这些说明指出系统与参与者交互的方式以及在各个独立用例中系统执行的有关操作。 
最后，对已完成的用例模型(包括用例说明)进行复审，开发人员和客户使用该模型对系统应执行的操作达成一致意见。 
3.2.1.3 需求管理模型
在需求管理的流程中，需求的捕获手段固然重要，但在需求的捕获和需求最终成型的过程中，我们会面临各种和需求相关的信息和资料(也可以把这些信息笼统地称做"需求")，如何发现这些信息之间的关系并有效组织，更为关键。 需求类型 在中，我们采用一种金字塔方式的管理办法，来组织和管理我们获取的信息乃至最终的需求。 
为了建立一个真正满足客户需求的系统，项目团队首先必须确定系统要解决的问题。然后，团队必须确定涉众，从中获得业务和用户需要，对其进行描述，并区分它们的优先级。从这一组高层期望或需求出发，对产品或系统特性集达成一致意见。而后，由产品特性来抽取软件需求，在我们的模型中，软件需求是以用例模型的方式来描述。从测试的角度来看，测试项一定来自于软件需求，即软件需求中确定了哪些需求项，测试就要根据这些需求项来制定和实现。 
系统越大越复杂，出现的需求类型就越多。一个需求类型不过是指需求的一个类。通过确定需求类型，团队可以把大量需求组织成意义明确且更容易管理的组。在一个项目中建立不同类型的需求有助于团队成员对变更请求进行分类，并使相互之间的沟通更为清楚明确。从上述的分析中我们可以看到，通常，一类需求可以细分即分解成其他类型的需求。这里，我们就把需求分解为几种类型，并在他们之间建立相应的关联。业务规则和前景声明包括高层次的需求，团队可以从中导出用户需要，特性和产品需求类型。用例和其他建模形式驱动设计需求，该需求可分解为软件需求，并可以用分析设计模型来说明。测试需求源于软件需求，它被分解为具体的测试过程。如果既定项目中有成百上千个，甚至上万个需求实例时，对需求进行分类可以使项目更容易管理。上述的这些需求类型同时保存在对应的文档和数据库中。 
3.2.1.4 应用需求类型
通过定义需求类型，以及他们之间的关系，我们就建立了一个需求管理模型的框架。当然，我们建立这样的一个模型，是为了方便我们使用需求，为了达到这一目的，我们还需要在此基础上