五步走：软件需求的管理过程

《五步走：软件需求的管理过程》由会员分享，可在线阅读，更多相关《五步走：软件需求的管理过程（7页珍藏版）》请在金锄头文库上搜索。

1、五步走：软件需求的管理过程 摘要 当今，经济和社会生活对软件的依赖程度急剧增长，软件需求日益复杂，软件开发成 为一项跨越技能，职责范围和时间阶段的综合团队活动。实践证明，良好的需求管理过程 对于降低开发成本和保障项目成功至关重要。 我们将需求管理过程分为三个大的阶段： Discover 阶段， define 阶段， 和需求维护阶段。 本文的内容罗列如下：第一部分：软件需求管理过程涉及到的角色第二部分：软件需求管理过程的概貌。第三部分：Discover 阶段的具体活动。第四部分：Define 阶段的具体活动。第五部分：需求维护阶段的具体活动。1、 角色及职责角色职责描述市场人员负责 discov

2、er 阶段所有工作，并帮助开发项目经理在 define 阶段初期 很快地了解业务和客户开发项目经理协调 discover 阶段的所有活动；负责完成需求文档；维护 scope matrix。行业专家提供行业咨询高层团队指导 discover 和 define 阶段的工作SEPGSoftware Engineering Process Group 负责过程的培训，提供过 程支持，负责过程的跟进和改进2、软件需求管理过程的概貌 需求可定义为“（正在构建的）系统必须符合的条件或具备的功能” ，也有人定义为 “用户解决某一问题或达到某一目标所需的软件功能” 。 而需求管理是一种获取、组织并记录系统需求的

3、系统化方案，以及一个使客户与项目 团队对不断变更的系统需求达成并保持一致的过程。需求管理的目的是在顾客和将处理顾 客需求的软件项目组之间建立对顾客需求的共同理解。需求管理的目标是： 使软件需求受控，并建立供软件工程和管理使用的基线。 使软件计划、产品和活动与软件需求保持一致。Discover 阶段 本阶段的目的是了解客户的问题，分析并确定公司是否开展此行业的项目。这里的客 户不一定针对一个企业，有可能是一个行业。在进行具体的调研时，目标是本行业的一个 或几个典型用户。市场人员主要对客户的问题，客户的现状，和客户的业务模式三方面进 行了解，然后对照公司的业务发展方向和实际现状进行可行性分析，并负

4、责编写可行性分 析报告。 然后发起可行性分析会议，邀请公司高层，行业专家和利益相关者一起来商议公司是 否开展此项目。一旦决定做此项目，下来将寻找有意向的用户。找到合适的用户后，就可 以正式开始创建开发团队进行开发系统的定义，设计，编码等工作。 Define 阶段 目的是得到一套客户认可的详细的需求说明文档，用来指导后期的软件开发工作。开 发项目经理通过与客户沟通交流，分析项目目标和成功因素，识别项目风险和假设，以及 系统的功能需求和技术需求，最终整理出一套详细的需求说明文档，包括总体系统的需求 信息，每个子系统的需求信息，数据字典，等。 为了指导后期的开发和跟踪需求实现的状态和范围，项目经理需

5、要根据需求来建立本 项目的 Scope Matrix。在 Scope Matrix 中随时跟踪每项功能的 In 或 Out，以及现在处于开 发的什么阶段。 所有需求文档完成之后，由项目经理发起并组织阶段审核会议，并邀请客户和行业专 家参加。审核的内容包括所有需求文档和 Scope Matrix。一旦审核通过，则开始制定下阶 段的计划，准备进入概念阶段。 需求维护阶段 目的是管理需求的变更。在软件开发过程中，需求不可避免会有大或小的更改。为了 更有效地管理需求的变更，这里规范了需求变更，需求跟踪，和需求配置管理的要求。对 每项内容的详细内容，将在后面进行介绍。3、Discover 阶段3.1 理

6、解客户的需求 活动：与客户沟通交流，了解他们的原始需求。并分析公司开发此项目的业务机 遇，业务目标，客户和市场的需求，以及业务风险等问题。 职责：由公司高层负责，市场人员具体执行。 3.2 了解客户的现状 活动：评估客户的现状，如信息化程度，人员的计算机技能水平，业务模式等。 职责：由公司高层负责，市场人员具体执行。 3.3 了解客户的业务模式 活动：了解客户当前的业务模式，包括业务角色及其关系。 职责：由公司高层负责，市场人员具体执行。 3.4 编写可行性分析报告 活动：根据前面三项内容，对本项目做评估，分析是否开展此项目 职责：由公司高层负责，市场人员具体执行 模板：依据提供的“可行性分析

7、报告的模板”整理。根据实际内容，允许对模板 进行裁剪。 3.5 可行性问题的决策 活动：审核可行性分析报告的内容；决定是否开展此项目 参与人：市场人员（发起者和组织者） ，行业专家，公司高层决策人员。 主要沟通内容：可行性分析报告 输出：作出结论的可行性分析报告职责：市场人员发起，组织，和主持会议，做会议记录。负责可行性分析报告的 修订和决策记录。说明：决定开展此项目后，方可进入 define 阶段。在进入 Define 阶段之前，需要 由项目经理确定项目的整体计划和 define 阶段的详细计划。 4、Define 阶段4.1 准备活动：了解 discover 阶段的输出文档，安排交流的客户

8、代表职责：市场人员帮助开发项目经理了解可行性分析报告中的内容，并共同联系客 户代表；开发项目经理理解可行性报告中的相关内容，为后面工作的开展作好准备。 4.2 分析项目目标和成功因素活动：通过与客户的沟通，定义项目目标和成功的关键因素职责：开发项目经理完成，市场人员可协助。 4.3 识别项目的风险和假设活动：通过与客户的沟通，识别项目的风险和假定，并分析他们对项目的影响， 给出风险的减缓方法。职责：开发项目经理同完成，市场人员可协助。 4.4 获取功能需求和技术需求活动：通过与客户的沟通，获取功能需求和技术需求，即明确系统的功能需求和 使用什么样的技术职责：开发项目经理完成，市场人员可协助。

9、4.5 编写需求说明文档活动：根据前面几个步骤的沟通结果，整理项目的需求文档。需求文档不一定是 一个，可以是几个文档。但必须包括内容：总体系统的需求信息，每个子系统的需求信息， 数据字典。公司建议将总体系统的需求信息与每个子系统的需求信息分开写成文档。在总 体系统的需求中，从系统整体出发来阐述，而每个子系统的需求只针对子系统本身来阐述。职责：开发项目经理完成。模板：依据提供的“总体系统的需求说明模板” “子系统的需求说明模板” “数据 字典的模板”整理。根据实际内容，允许对模板进行裁剪。高质量的需求说明文档的关键特点：完整:不应该遗漏要求和必需的信息。发现缺少的信息很难，因为根本不存在。如 果

10、你知道已缺少一些信息，使用 TBD（to be determined）标准标志可以突出这些缺陷，当 你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发 生冲突。可修改性：每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清 晰的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表， 索引，以及前后参考（照） 。 4.6 建立 Scope Matrix活动：根据系统的需求建立 Scope Matrix，以指导后期的开发。Scope Matrix 的所 有内容必须忠实于整理出来的需求

11、文档。如果需求文档的内容不足以得到完整细致的 Scope Matrix，可以回过头来完善需求文档；如果实在确定不下来的内容，可以在 Scope Matrix 中标注出来，待以后确定。职责：开发项目经理完成。模板：依据提供的“Scope matrix 的模板”整理。根据实际内容。 如何在 Scope matrix 中描述功能域：罗列所有的详细功能点，而与流程无关。有关的功能限制也可列入。禁忌用冗长的描述性语言陈述。这样不容易将功能点划开。每个功能点用一句简短的话来描述。如果一个功能点需要两句话才能描述清楚， 则将其划为两个功能点。 4.7 Define 阶段的审核活动：以会议的形式沟通需求的内容

12、，对需求进行 Quality review.参与人：项目经理（发起者和组织者） ，行业专家，和客户审核内容：数据字典，总体系统的需求说明，各子系统的需求说明，Scope matrix输出：Review notes。Review notes 要求填写在公司规定的 Quality review notes 的 模板中。职责：项目经理发起，组织，并主持审核会议，做会议记录。会后总结 review notes.说明：Define 阶段审核通过后，方可进入设计阶段。 5、需求维护需求维护的关键内容是需求变更管理。需求的变更是不可避免的，如何以可控的方 式管理软件的需求，对于项目的顺利进行有着重要的意义。对于需求变更的管理，我们主 要使用需求变更控制流程，需求跟踪矩阵，和需求配置的管理方式。 5.1 变更控制流程 5.2 需求跟踪活动：使用 scope matrix 来跟踪每项需求是否要求实现，以及需求实现的状态职责：由开发项目经理负责维护 scope matrix。 5.3 需求配置管理活动：保存需求方面的所有文档的所有版本职责：每个有关需求的文档以及升级文档均要求保存到配置管理系统中。要求：所有资料均放入配置管理系统。按照规定的目录存放资料。文件的每个修改版本都要求保存。