需求管理流程
需求管理规范
需求管理规范一、引言需求管理是软件开辟过程中至关重要的一环。
良好的需求管理可以确保软件开辟项目的顺利进行，减少项目风险，提高开辟效率和质量。
本文旨在规范需求管理的流程和方法，以确保需求的准确性、完整性和一致性。
二、需求管理流程1. 需求采集需求采集是需求管理的起点，通过与项目相关的各方沟通和交流，采集和整理项目需求。
可以采用面对面会议、问卷调查、访谈等方式进行需求采集，确保获取到准确、全面的需求信息。
2. 需求分析需求分析是对采集到的需求进行细致的分析和梳理的过程。
通过对需求的分类、排序和优先级划分，明确需求的重要性和紧急程度。
同时，需求分析还包括对需求的可行性评估和风险分析，以确保项目可行性和风险可控。
3. 需求确认需求确认是与项目相关方共同确认需求的过程。
在需求确认阶段，需求管理团队与项目相关方进行深入的讨论和沟通，确保需求的准确性和一致性。
通过会议记要和需求文档的编写，将需求明确记录下来，为后续的开辟工作提供基础。
4. 需求变更管理需求变更是不可避免的，在项目开辟过程中，可能会浮现需求的变更和调整。
需求变更管理是对需求变更进行评估、审批和控制的过程。
通过建立变更管理流程和机制，确保需求变更的合理性和可控性，避免对项目进度和质量造成不良影响。
5. 需求跟踪和验证需求跟踪和验证是确保需求实现的过程。
通过建立需求跟踪矩阵和需求验证计划，对需求的实现情况进行监控和验证。
及时发现和解决需求实现过程中的问题和风险，确保需求的准确性和一致性。
三、需求管理方法1. 需求文档化将采集到的需求进行文档化，包括需求描述、需求优先级、需求关联性等信息。
需求文档应具备清晰、简洁、易读的特点，并且要与项目相关方进行共享和确认。
2. 需求跟踪工具借助需求跟踪工具，对需求的变更、实现和验证进行跟踪和管理。
需求跟踪工具可以匡助需求管理团队及时掌握需求的状态和发展，提高需求管理的效率和准确性。
3. 需求评审在需求确认阶段，组织需求评审会议，邀请项目相关方参预需求的评审和讨论。
需求管理规范
需求管理规范一、背景介绍需求管理是指在项目开发过程中，对需求进行有效的收集、分析、确认、跟踪和变更控制的过程。
良好的需求管理能够确保项目的目标和范围得到准确定义，并能够满足客户的需求。
本文旨在规范需求管理的流程和方法，以提高项目的成功率和客户满意度。
二、需求管理流程1. 需求收集需求收集是指通过与客户、用户、业务代表等进行沟通和交流，获取项目需求的过程。
可以采用面谈、问卷调查、观察等方法进行需求收集。
在需求收集阶段，应该确保收集到的需求具有可行性和一致性，并进行合理的分类和整理。
2. 需求分析需求分析是指对收集到的需求进行详细的分析和理解，以确定需求的优先级和可行性。
在需求分析阶段，应该明确需求的功能、性能、界面、安全性等方面的要求，并与相关利益相关方进行确认和讨论。
3. 需求确认需求确认是指将需求与客户进行沟通和确认，确保需求的准确性和一致性。
在需求确认阶段，应该向客户提供详细的需求文档，并与客户进行面对面的讨论和解释。
确认后的需求应该经过客户的签字确认，以便后续的开发和测试工作。
4. 需求跟踪需求跟踪是指对需求的变更和实现情况进行跟踪和管理。
在需求跟踪阶段，应该建立需求跟踪矩阵，记录每个需求的状态、进度和责任人，并及时更新和通知相关人员。
同时，应该建立变更控制机制，对需求变更进行评估和批准，确保变更的合理性和影响范围的控制。
5. 需求评审需求评审是指对需求文档进行全面的审查和评估，以确保需求的完整性和一致性。
在需求评审阶段，应该邀请项目组成员、客户代表和领导参与，对需求文档进行逐条的审查和讨论。
评审结果应该及时记录和反馈，以便后续的修改和调整。
6. 需求变更控制需求变更控制是指对需求变更进行管理和控制，以确保变更的合理性和影响范围的控制。
在需求变更控制阶段，应该建立变更申请流程和评审机制，对变更进行评估和批准。
同时，应该及时通知相关人员，并更新需求文档和跟踪矩阵。
三、需求管理方法1. 使用需求管理工具可以使用专业的需求管理工具，如JIRA、TFS等，对需求进行收集、分析、确认和跟踪。
需求管理规范
需求管理规范一、引言需求管理是软件开发过程中至关重要的一环，它涉及到对需求的收集、分析、确认、跟踪和变更控制等方面的工作。
规范的需求管理能够提高软件开发过程的效率和质量，确保软件能够准确地满足用户的需求。
本文将介绍需求管理的规范流程和相关要求。
二、需求管理流程1. 需求收集需求收集是需求管理的第一步，它包括与用户、业务代表等相关方沟通，了解用户需求的具体内容和期望。
需求收集可以通过面对面的会议、问卷调查、用户访谈等方式进行。
在需求收集过程中，应确保收集到的需求具有清晰的描述和明确的优先级。
2. 需求分析需求分析是对收集到的需求进行深入理解和分析的过程。
在需求分析阶段，需求管理团队应该将需求进行分类和整理，并与用户进行确认和反馈。
需求分析的结果应该包括需求的功能描述、性能要求、界面设计等内容。
3. 需求确认需求确认是指与用户达成一致，确保用户需求的准确性和完整性。
在需求确认过程中，需求管理团队应该与用户进行沟通和反馈，以确保用户对需求的理解和认可。
需求确认的结果应该由用户签字确认，并作为后续开发的依据。
4. 需求跟踪需求跟踪是指在软件开发过程中，对需求进行追踪和管理的过程。
需求管理团队应该建立需求跟踪矩阵，记录每个需求的状态、优先级、进度等信息。
同时，需求管理团队应该及时与开发团队进行沟通，确保需求的实现和变更控制。
5. 需求变更控制需求变更是软件开发过程中常见的情况，需求管理团队应该建立完善的变更控制机制，确保变更的合理性和可行性。
需求变更应该经过严格的评审和批准，同时需要及时通知相关人员，并进行相应的文档更新和版本控制。
三、需求管理的要求1. 需求文档的编写需求管理团队应该编写清晰、准确、完整的需求文档，包括需求的功能描述、性能要求、界面设计等内容。
需求文档应该具有统一的格式和命名规范，方便后续的管理和维护。
2. 需求的优先级管理需求管理团队应该与用户进行充分的沟通和协商，确定需求的优先级。
优先级的确定应该考虑到用户的实际需求、业务价值和开发资源等因素，以确保开发工作的有序进行。
需求管理流程
需求管理流程需求管理是指对项目或产品的需求进行有效管理和控制的过程，以确保项目或产品能够满足用户的期望和要求。
需求管理流程是指在整个项目或产品生命周期中，从需求收集到需求评审、需求分析、需求确认，再到需求变更控制和验收，一系列有序的活动和步骤。
下面将详细介绍需求管理流程。
1. 需求收集：需求收集是需求管理的第一步，它通过与用户和利益相关者的沟通和访谈，收集到用户的期望和需求。
可以通过面对面交流、问卷调查、用户故事等方式进行需求收集。
2. 需求评审：在需求收集完成之后，需求评审是对需求的一次全面审查和评估。
评审团队通常由项目经理、产品经理、开发人员和用户代表组成，通过讨论和辩论，评估需求的合理性和可行性。
3. 需求分析：需求分析是对需求进行深入剖析和理解的过程。
分析人员需要将收集到的需求进行整理和分类，明确需求的优先级和重要性，并进行具体的细化和拆解，将需求转化成可执行的任务和功能。
4. 需求确认：需求确认是把经过分析和细化的需求与用户进行确认，确保用户对需求的理解和认可。
这个过程通常通过与用户的反复反馈和沟通来实现，包括演示原型、进行用户测试和验证等。
5. 需求变更控制：在项目或产品开发过程中，可能会出现需求变更的情况。
需求变更控制是对需求变更进行管理和控制的过程，以防止无限制的需求变更对项目造成的负面影响。
需要通过评审和审批机制，对需求变更进行评估和决策。
6. 需求验收：需求验收是对项目或产品最终交付结果的确认和验证。
在验收过程中，用户和开发团队进行最后的测试和评估，确保项目或产品能够满足用户的需求和要求。
需要注意的是，需求管理流程是一个不断循环和迭代的过程，而不是线性进行的。
在需求收集、分析和确认过程中，可能会不断发现新的需求或改变已有的需求，需要及时进行调整和变更控制。
总结起来，需求管理流程是一个关键的项目管理活动，它通过有效的需求收集、评审、分析、确认、变更控制和验收等步骤，确保项目或产品能够满足用户的期望和需求。
需求管理的流程和步骤
需求管理的流程和步骤需求管理是指在项目或产品开发过程中，对需求进行有效管理和控制的一系列流程和步骤。
它确保项目团队和利益相关者对需求的理解一致，以便能够按照既定目标和计划开展工作。
下面将按照流程和步骤的顺序，详细介绍需求管理的过程。
一、需求收集需求收集是需求管理的第一步。
在这一阶段，项目团队需要与利益相关者进行沟通，了解他们的需求和期望。
可以采用面谈、问卷调查、座谈会等方式收集需求信息。
此外，还可以参考类似项目的经验教训，以及行业标准和法规等，获取更全面的需求。
二、需求分析需求分析是将收集到的需求进行分析和整理，以便更好地理解需求的本质和特点。
在这一过程中，项目团队需要将需求进行分类、去重、细化，并与项目目标进行对比和验证。
同时，还需要与利益相关者进行反复确认，确保对需求的理解无误。
三、需求规划需求规划是将需求分解为可管理的任务和阶段，以便更好地组织和跟踪工作进展。
在这一过程中，项目团队需要制定需求开发计划、分配工作任务、确定需求优先级等。
同时，还需要考虑资源和时间的限制，确保需求开发能够按计划进行。
四、需求跟踪需求跟踪是对需求开发和实现过程进行监控和管理，以确保项目进展按照预期进行。
在这一过程中，项目团队需要记录需求状态、更新需求进展、追踪需求变更等。
通过及时跟踪需求，可以及早发现和解决问题，避免需求漏掉或失控。
五、需求验证需求验证是对已开发的需求进行确认和验证，以确保需求符合利益相关者的期望和要求。
在这一过程中，项目团队需要与利益相关者进行沟通和协商，确认需求的准确性和完整性。
同时，还需要进行需求测试和评估，确保需求能够满足项目目标和质量要求。
六、需求变更管理需求变更管理是对需求变更进行控制和管理，以确保变更能够被合理地评估、决策和实施。
在这一过程中，项目团队需要建立变更管理流程和机制，明确变更的提交、审批和实施程序。
同时，还需要评估变更对项目目标、进度和成本的影响，做出明智的决策。
七、需求文档管理需求文档管理是对需求文档进行管理和控制，以确保需求文档的准确性、可靠性和可追溯性。
软件运维管理系统产品需求流程图(附流程图)
软件运维管理系统-需求管理流程一、软件运维管理系统需求管理流程图
二、流程说明
1.创建需求
需求提出人：编写需求内容、所属系统、紧急程度、需求类型、预期完成时间、上传原始需求等。
2.需求评估
项目经理：对需求做可行性评估，需求拆解分析，工作量评估，制定总体计划目标，指定开发负责人。
3.制定计划
开发负责人：任务、开发维度对需求进行拆解，并对拆分后的需求进行任务分配，制定开发、测试人员、开发起止时间等。
4.需求开发
开发人员：接收任务，每天更新开发进度，开发进度达到100%系统自动创建测试任务，并将测试任务推送给测试人员。
5.功能测试
测试人员：接收测试任务，执行测试工作，填写测试结果，如有BUG，填写BUG票并推送给开发人员。
6.发布申请
需求提出人：选择要发布的任务，提交发布申请。
7.环境部署
开发负责人：根据发布申请，部署交付测试换进，填写发布申请单，包括数据库发布内容、前后端发布内容等。
8.交付测试
需求提出人：需求提出人对发布需求进行测试，验证需求实现度，反馈测试结果。
9.产品发布
开发负责人：根据发布清单，执行产品发布任务，并反馈发布结果。
超全需求管理指南
超全需求管理指南，教你如何避免翻车编辑导读：需求管理对于项目来说很重要，甚至会影响到项目的成功与否。
我们应该如何进行需求管理？本文作者将从实际的工作中体会，以实践和理论相结合的角度对产品经理日常中需求管理的流程方法进行了总结，与大家分享。
需求管理不同于产品验收：产品验收，一般指的是产品同学在测试完成后，验证产品交互物是否符合自己的产品设计预期。
但产品的工作目标是顺利产出，拒绝翻车。
因此，需求评审完后，等到测试完成才验收是不够的，产品同学应该对整个产研过程进行过程管理，在各个节点进行阶段性验收，即需求管理。
需求管理一条龙：全流程介绍：01 需求输出（PRD）自查1.1 功能逻辑逻辑闭环，不遗漏判断；描述清楚，无歧义。
（1）PRD是否有按照需求文档规范编写？一般公司内部都会有需求文档规范，这个PRD规范就是一个非常基本的需求思考框架和信息传递框架，而且是在公司内部经过磨合以及实操验证的。
按规范来写，至少需求的框架是成型的，在信息传输上需要达成共识的模块也会考虑进去了。
（如果小团队没有需求文档规范，可以自己总结一份。
）（2）是否有异常状态的处理?正向过程是相对容易考虑全面，因此功能逻辑自查的重点是逆向过程，异常状态。
可以从以下几方面着手：1）业务异常•逆向流程：如订单取消，退货退款，优惠券退回•不可用：如账号未注册，账号被冻结，校验未通过•超时效：如优惠券过期•无权限：常见2B产品，不同角色权限不同2）数据异常•输入异常：不符合输入要求；输入错误•返回异常：无搜索结果•显示异常：空数据；加载异常；排序异常3）网络异常•无网络：无网络权限；没有联网•网络慢4）服务器异常•接口调用超时•收不到回调（3）与产品其他模块是否有关联影响？•如涉及功能消息通知：短信/push/Email•如需求涉及到的管理后台系统改造1.2 交互体验：交互稿验收/自查记住，用户是很懒很懒很懒的。
懒得想，懒得动，懒得等！•用户路径是否清晰？用户能很轻松知道当前自己在哪，从哪来，可以去哪，如何能完成目标。
需求管理流程和项目变更管理流程
需求管理流程和项目变更管理流程
需求管理流程和项目变更管理流程是项目管理中非常重要的两个环节，它们确保了项目的成功交付。
需求管理流程是确保项目满足客户需求的关键步骤。
该流程包括以下几个阶段：
1. 需求收集：与利益相关者合作，确定项目的业务和技术需求。
2. 需求分析：对收集的需求进行分析和评估，以确保其清晰、完整和可行。
3. 需求定义：将需求转化为明确的规格说明，包括功能、性能和其他要求。
4. 需求评审：与利益相关者审查和批准需求，以确保他们对项目目标和期望有一致的理解。
5. 需求跟踪：跟踪需求的状态，确保在整个项目生命周期中得到满足。
6. 需求变更管理：管理需求的变更，确保变更经过适当的审批和沟通。
项目变更管理流程用于有效地管理项目范围、时间、成本或其他方面的变更。
该流程包括以下步骤：
1. 变更请求：识别和记录变更的需求，包括变更的原因、影响和建议的解决方案。
2. 变更评估：评估变更对项目的影响，包括时间、成本、风险和资源等方面。
3. 变更审批：根据变更的影响，确定是否需要经过项目发起人或其他相关方的审批。
4. 变更实施：在获得批准后，协调团队实施变更，并确保对项目计划和相关文档进行更新。
5. 变更跟踪：跟踪变更的实施情况，确保变更按预期完成。
6. 沟通和报告：与利益相关者沟通变更的情况，并提供有关变更的报告。
通过有效的需求管理流程和项目变更管理流程，项目团队可以更好地理解客户需求，管理变更，并确保项目按时、按质、按预算完成。
这有助于提高项目的成功率和客户满意度。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用户需求
原始
类 系统需求：用详细的术语给出系统要提
别
供的服务及受到的约束
系统需求
解决
软件设计描述：在系统需求的基础上加 入更详细的内容，它是软件详细设计和 软件设计描述
实现的基础
aCAD中心
提
交 需
• 语句和段落尽量简短
求 • 语句要完整，语法、标点等要正确
的 • 使用的术语与词汇表中的定义保持一致
1. 需求不总是显而易见的，它可来自各个方面。
求
2. 需求并不总是容易用文字明白无误地表达。
管
3. 存在不同种类的需求，其详细程度各不相同。
理 存
4. 如果不加以控制，需求是无止境的，需求数量 将难以管理。
5. 需求相互之间以及与流程的其他可交付工件之
在
间以多种方式相关联。
的
6. 需求既非同等重要，处理的难度也不同。
委
• 二、会议制度：
员
• 每周定期召开需求管理会议
会
aCAD中心
18
• 产品研发步骤：
• 一、产品需求文档：
职
• 二、讨论（发散思维），排列出优先等级
能 和
测试人员参与，按照实现效果、目的测试— —测试用例
• 三、功能设计→详细设计→测试→日常维护
规
• 四、根据客户反馈，搜集新一轮需求；
定 • 会议决议：
作
定的变更控制过程来实现
用 • 系统测试过程：需求是测试的重要参考文档编制过程：需求是
编写文档的重要参考
• 系统构建过程：需求决定模块设计，模块设计是代码实现的依 据
aCAD中心
10
需 原始问题描述：对要解决问题的叙述， 它是软件需求的基础
原始问题描述
求 用户需求：用自然语言和图表给出的关
的
于系统需要提供的服务及操作的约束
程
系统软件、接口等的具体要求；
➢其他要求包括：安全保密、可靠性、可维护
性、可移植性、可扩展性等等。
aCAD中心
7
（2）分析系统的数据要求
需 数据定义、数据逻辑关系、输入/出数据定义、 求 数据采集方式等
分 （3）抽象出并确立目标系统的逻辑模型
析 如用例图、设计模型、实施模型和实现模型等
过 （4）编写需求规格说明书 程 如数据流图、面向对象的分析等。
需求管理流程
人人都是产品经理
a
1
项目需求管理
什么是需求：
Rational 把需求定义为“（正在构建的）系统必 须符合的条件或具备的功能”。
著名的需求工程设计师 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义， 它特指软件方面 - 但不仅仅限于软件：
aCAD中心
15
需
进行需求管理的第一步是建立需求管理规划：
求
• 需求识别：给需求以惟一的标识
管
• 变更过程管理：确定一个选择、分析和决策需求变更的
理
过程
的
• 需求跟踪：定义需求之间的关系及需求和设计之间的关
规
系，记录并维护这些关系
划
• 自动化工具：即选择使用何种CASE工具
aCAD中心
16
变 更 控 制 流 程
需求的控制。
需求管理处于软件项目管理开发周期的最上游；
小
软件需求主要来源于业务分析的结果，在充分考虑用
结
户的自身特性与要求的前提下，项目经理在用户与项 目组之间达成共识，建立了需求基线；在项目开发过
程中，通过需求范围认定、需求形式化记录、需求数
据库建立、需求状态跟踪、需求变更分析和波动评估、
需求评审控制等程序，通过使用需求管理工具等手段，
aCAD中心
14
需 • 一定要分类管理：
求 • 目标性需求、具体业务流程需求和操作性的需求等
管 • 必须分优先级
理 • 必须文档化：
的 原 则
• 文档必须是正确的、最新的、可管理的、可理解和经过验证的 • 需求一旦变化，就必须对需求变更的影响进行评估，每个项目
都必须有需求管理员或组
• 需求管理必须与需求工程的其他活动机密结合：需求管理是 形式，需求获取、需求分析、需求验证等是内容
• 1、在不影响重大需求的前提下，新的紧急需求会 尽快上线。
• 2、如果计划做新版本，需要重新做出新规划
aCAD中心
19
•
需 求• 跟 踪
目的：建立和维护从用户需求到测试的一致性与完整性，确 保实现都以客户需求为基础，实现的需求覆盖了预期的需求， 并确保输出与用户需求的符合性 需求跟踪就要追溯需求间以及需求与系统设计间的联系，可 追溯性是需求描述的一个总体特性，反映了发现相关需求的 能力。三类可追溯性信息：
述或使用实例基础上的
aCAD中心
22
需•
求•
验•
证•
的•
内 容
• • •
•
•
有效性检查： 每项需求都是正确有效的，能解决用户面对的问题 一致性检查：需求不应该冲突 完备性检查：应包含所有用户想要的功能和约束 现实性检查：保证能利用现有技术实现 可检验性检查：描述的需求能够实际测试 可跟踪性检查：需求的出处被清晰记录 可调节性检查： 需求变更不会对其它部分造成大规模影响 可读性检查：能够被读懂
aCAD中心
21
需求验证过程
需 • 审查需求文档：由分析人员、客户、设计人员和测
求
试人员等组成的审查小组
质 • 编写测试用例：根据用户要求的产品功能写出测试
量 保 证
用例。如果测试的设计很可能或不可能，说明需求 的实现很困难
• 编写用户手册：用户手册初稿 • 确定合格的标准：合格的测试是建立在使用情景描
“软件需求可定义为： 用户解决某一问题或达到某 一目标所需的软件功能。系统或系统构件为了满足合同、 规约、标准或其他正式实行的文档而必须满足 进 行 需 求 管 理?
评测和验证有效的软件开发流程标准得到了推广 和普及 ➢为什么现在仍然频繁发生的软件项目失败的事件？ ➢为什么仍有那么多的项目受到延期、预算超支和 质量问题的困扰？ ➢如何才能提高系统的质量？
么 是
提供一种机制，以分析需求、评估可行性、协商 合理的解决方案、无歧义地规约解决方案、确认规约
需 以及在开发过程中管理这些被确认的需求规约。包括6
求 个步骤：
管
获取（需求诱导）
理？ 分析（需求分析和谈判）
规定（规约）
系统建模
验证（需求确认）
需求管理（控制与变aCA更D中管心 理）
5
需
基 本
• 避免使用模糊、主观的术语，如性能“优越”
原 • 避免使用比较性词汇，尽量给出定量的说明，
则 • 含糊的表达将引起需求的不可验证
•…
aCAD中心
12
需求开发与管理的界限
客户 市场 管理
项目环境
需求获取及分析 需求记录 需求验证 基准需求规格 需求变更 版本控制 需求状态及跟踪
需求开发
需求管理
aCAD中心
13
需
需求管理是一种获取、组织并记录软件需求的系统化
求
方案，也是使客户与项目团队对不断变更的软件需求
管 保持一致的过程
理
需求管理的目的：在客户和处理客户需求的软件项目
的 组之间建立对客户需求的共同理解
目 标
1. 使软件受控，并建立供软件工程和管理使用的需求基线 2. 使软件计划、产品和活动与软件需求保持一致
不是问题 不接受
客户或开发人员 提出变更请求
项目经理
分流处理 应重视的问题 变需更求控管制 理委员员会会
不接受
接受
小问题 自行解决
变更影响分析报告
修改SRS
修改开发计划
aCAD中心
修改其它相关文档
17
需
• 一、职能：
求 管 理
• 评审——需求分析及讨论 • 跟踪——需求修改进度 • 监督——需求整改质量保证
aCAD中心
8
跟踪控制过程
需
项目计划过程
变更控制过程
求
的
软件需求过程
作
系统构建过程
用
系统测试过程
文档编制过程
aCAD中心
9
• 项目计划过程：需求是项目计划的基础
需 • 跟踪控制过程：监控每项需求的状态，以发现设计是否达到了
求
预期的要求
的 • 变更控制过程：需求文档确定并制定基线后的变更都要通过确
问
7. 需求涉及众多相关利益责任方，这意味着需求
题
要由跨职能的各组人员来管理。
8. 需求会发生变更。
9. 需求可能对时间敏感。
aCAD中心
6
需 求
（1）对系统的综合要求： ➢功能要求:包括系统应该实现的功能；
分
➢性能要求:包括系统响应时间、资源限制、
析
数据精确性、系统适应性等；
过
➢运行要求:包括系统硬件环境、网络环境、
实现对项目需求按基线的控制和管理。
需求管理的好坏，对产品项目的成败起决定性作
用，项目经理的资质、技能要求非同一般，责任心更
是保证。
aCAD中心
25
– 源可追溯性信息：连接需求与提出需求的人员及产生需求的原因 – 需求可追溯性信息：连接需求文档中彼此依赖的信息 – 设计可追溯性信息：连接需求到其实现的设计模块
aCAD中心
20
需
求 • 在需求验证中，便于确保所有需求被应用
跟 • 有助于变更影响分析
踪 的 作 用
• 便于需求的维护 • 便于测试时找出问题所在 • 便于项目跟踪和减少项目风险 • 简化了系统再设计，易于软件重用