需求开发与管理过程(Req. Development Mgt. Process)
Req. Development & Mgt. Process 需求开发与管理过程
Prep分配需求ed by
拟制陈刚
Date
日期
2006-05-16
Reviewed by 评审人SEPG team
Date
日期
2007-4-20
Approved by
批准田松涛
Date
日期
2007-4-24
Revision Record 修订记录
Table of Contents 目录
1Purpose 目的 (5)
2Scope 范围 (5)
3Abbreviations and Acronyms 术语和缩略语 (5)
4Policy 方针 (5)
5Process Description 过程描述 (5)
5.1Roles and Responsibilities 角色和职责 (6)
5.2Entrance Criteria 入口准则 (6)
5.3Input 输入 (6)
5.4Activities 活动 (6)
5.4.1Summarize 总述 (6)
5.4.2Flow Chart 流程图 (7)
5.4.3Requirements Development and Validation 需求开发及确认 (8)
5.4.4Trace Requirements and Requirements Management 需求跟踪和管理 (10)
5.5Output 输出 (11)
5.6Exit Criteria 出口准则 (11)
6Resource and Tools 资源与工具 (11)
7Configuration Management and Assets 配置管理和资产 (11)
8Training 培训 (11)
9Process Measurement 过程度量 (11)
10Tailoring Guidelines 裁剪指南 (12)
11Verification 验证 (12)
12Related Process 相关过程 (12)
13Reference Materials 参考文献 (12)
Table List 表目录
表格1术语与缩略语 (5)
表格2角色和职责 (6)
Figure List 图目录
图表1需求开发与管理过程 (7)
1 Purpose 目的
为确保文思创新软件技术有限公司（简称文思创新）在软件开发项目中的工作产品质量稳定，对需求开发和需求管理过程进行规范化描述，特制定本文档。
需求开发是为了准确地获取客户方下发的需求，并对获取到的需求进行正确的理解和分析，最终形成明确的产品需求，以指导后续的设计工作。
需求管理是为了有序地对需求进行管理和控制，并确保需求之间的双向追溯性以及需求与项目计划和工作产品间的一致性。
2 Scope 范围
本文档适用于南京文思创新软件技术有限公司中采用瀑布、迭代软件开发模型的软件项目。
读者为项目组成员、项目管理人员和其它相关人员。
3 Abbreviations and Acronyms 术语和缩略语
4 Policy 方针
1、要确保项目的参与者理解需求，并获得项目的参与者对需求的承诺。
2、要有需求跟踪矩阵来维护需求的双向追溯性，并且当需求发生变更时，及时更新需求跟踪矩阵。
3、在整个需求开发管理过程中，项目经理需时时考虑关键任务和商业驱动，并在必要时调整工作；
5 Process Description 过程描述
5.1 Roles and Responsibilities 角色和职责
5.2 Entrance Criteria 入口准则
项目已启动
5.3 Input 输入（未定）
《项目启动报告》等任何与用户需求相关的材料
《产品设计规格》
5.4 Activities 活动
5.4.1 Summarize 总述
本文档包含需求开发和需求管理两大过程。其中需求开发过程从项目启动初期到所有需求文档开发结束；需求管理过程的启动略晚于需求开发过程，且和需求开发过程迭代进行，并延续至项目结束。两大过程的具体活动描述见如下文档。
5.4.2 Flow Chart 流程图
图表 1 需求开发与管理过程
5.4.3 Requirements Development and Validation 需求开发及确认
项目启动后，项目经理需识别该项目的需求来源并确定提供需求的客户方接口人，并与客户方接口人明确需求下发的方式及需求接收的准则并将其文档化，在获得双方认可之后纳入配置库，以作为我方人员对《产品设计规格》确认的准则。
5.4.3.1 需求澄清活动
项目经理获取《产品设计规格》之后，将其纳入配置库并邮件通知项目组成员。待项目组成员（包括开发、测试、资料）经过初步分析之后，客户方接口人需指定客户方人员进行需求澄清活动，以保证项目组成员对需求理解的正确性，一致性。
需求澄清的方式包含但不限于如下形式：
1）需求澄清会：由客户方人员在需求澄清会议上讲解需求功能点。我方对需求的疑问及需求答疑需以会议纪要的形式记录；
2）需求疑问的文档跟踪：我方人员需定期或事件驱动式整理并文档化需求疑问，并及时将需求疑问的答疑结果和客户方确认。
如上所有的文档需纳入配置库进行管理。
需求澄清活动的内容包含但不限于如下内容：
1）讲解《产品设计规格》中涉及到架构需求，以帮助我方人员理解所需实现的功能对架构需求的影响；
2）讲解功能性需求和质量属性需求（例如性能、效率、安全性、互操作性等）的具体描述，包括其中量化的功能需求是否合理，以保证我方人员对其中的操作概念和场景描述理解的正确性；
3）帮助我方人员理解对于性能、产品架构等有重大影响的关键性需求，并就需求的优先级达成共识；
4）讲解接口需求定义（包含内部接口和外部接口），保证接口定义的完整性和兼容性；
5）对于一些理解较困难或容易产生歧义的需求，客户方需进一步通过原型图，数据模拟图（包括数据流图、实体关系图、状态转换图等）等，来帮助我方进一步理解需求；
对于需求澄清活动中发现的需求类缺陷，待客户方修改完成后，项目经理需及时将最新的《产品设计规格》在配置库上予以更新。
5.4.3.2 评审及确认《产品设计规格》
需求澄清活动结束后，我方人员需对更新后《产品设计规格》进行进一步的评审，以保证需求的完整性，正确性，并确保该文档足以指导后期的需求开发活动。
《产品设计规格》评审活动结束后，项目经理按照项目前期确定的需求接收准则对《产品设计规格》进行确认，确认的内容可以包括但不限于如下内容：
1)《产品设计规格》是否按照双方约定的形式下发；
2)《产品设计规格》下发的时间点是否存在延期，并说明延期存在的相关风险；
3)《产品设计规格》的描述是否达到前期约定的接收标准；
4)《产品设计规格》的评审缺陷是否修改闭环，且该文档是否能够指导下一阶段的
需求开发活动；
项目经理需及时将需求确认的情况反馈给客户方，在得到双方的确认通过之后，项目组配置管理员对定稿后的《产品设计规格》进行基线化。
《产品设计规格》基线化之后下发的需求均作为需求变更进行处理，具体的需求变更的流程请参考《配置管理过程》。
5.4.3.3开发《软件需求规格说明书》
《软件需求规格说明书》是界定客户的最终需求，并用技术语言对《产品设计规格》中的需求描述做进一步的细化描述。编制的目的是为了使客户和软件开发者双方对该软件的初始规定有一个共同的理解，指导后续设计活动。
我方开发人员根据基线后的《产品设计规格》，按照指定的模板撰写《软件需求规格说明书》。开发人员在开发《软件需求规格说明书》的时候需要考虑如下内容：
1)识别需求的逻辑、类似功能或者质量属性、设计限制条件、潜在的衍生需求等，
以此准则来进行进一步的需求划分，并在需求划分的过程中及时与客户接口人进行确认；
2)按照需求划分为每个产品构件分配需求，如有必要还需进行更细化的分配（如子
功能或者支持组件）；
3)随着产品或产品组件的选择，开发详细的操作概念场景，以定义产品、最终用户
及环境的相互作用，以满足操作、维护、支持和处理的需要；
4)识别并文档化功能之间或对象之间的接口需求，包括内部接口、外部接口、软
件、结构件、产品生命周期过程中的接口（比如测试过程需依赖的物理接口、设计过程中受相应技术的影响产生的新接口等等），并持续维护接口需求；
5)定义产品或产品组件的操作环境，产品的相关配置项、网络环境、服务器环境
等；
6)识别并文档化技术性能的度量以便在开发阶段可以对其进行跟踪。
项目经理可以根据项目情况将如上内容纳入评审checklist，作为评审《软件需求规格说明书》的关注点；
5.4.3.4 评审《软件需求规格说明书》
《软件需求规格说明书》完成之后，项目经理组织相关人员进行《软件需求规格说明书》的评审活动，参与评审的人员包括但不限于项目组成员、及客户方相关人员。
《软件需求规格说明书》的评审除了关注评审checklist列的内容之外，还需满足如下要求：
1)需求的说明清楚、恰当，没有二义性；
2)需求的说明完备；
3)需求之间彼此一致；
4)需求不重复；
5)适宜于实现；
6)可以验证（例如，可以测试）；
7)可以跟踪。
此评审过程可能会引起《产品设计规格》评审和开发《软件需求规格说明书》两个活动的反复进行。评审活动结束后，若没有达到项目计划阶段确定的质量要求，则由项目经理及项目骨干人员经过分析之后决定是否进行重新评审；若评审通过，项目经理则根据《产品设计规格》及《软件需求规格说明书》建立《需求跟踪矩阵》，从而保证来源需求到它的较低层次需求的溯源性，和从较低层次的需求到它们的来源需求的溯源性。
5.4.4 Trace Requirements 需求跟踪
5.4.4.1 维护需求的双向追溯性及与项目的一致性
随着项目的开展，为了保证需求的完整性和一致性，项目经理需通过《需求跟踪矩阵》维护需求之间及需求和工作产品之间的关系。项目组在需求跟踪活动中最低的执行标准为：《产品设计规格》—《软件需求规格说明书》—设计文档—代码；《软件需求规格说明书》—测试方案—测试用例；
项目过程中，项目经理通过项目监控（PMC）过程时时监控需求跟踪活动，以识别项目计划、工作产品与需求之间的不一致性，并针对不一致的情况识别不一致的来源、条件和理由；同时也需识别由于需求变更而导致的必须对项目计划、活动和工作产品做出的变更，并启动纠正措施。同时，项目经理需及时更新《需求跟踪矩阵》，以体现更新的工作产品和需求之间的对应关系；
5.4.4.2 管理需求变更
项目过程中，项目经理通过项目监控（PMC）过程时时识别需求变更。针对识别的变更需求（需求类的变更，设计文档类的变更，代码类的变更），项目经理组织项目相关干系人参与对需求变更的影响性分析，分析的内容包括但不限于如下内容：1）需求变更的工作量；
2）需求变更所影响的范围；
3）实现需求变更存在的技术风险；
4）实现需求变更可能对进度、质量、成本带来的风险；
分析完成之后，需求提交人将相关性影响分析按照需求变更单（CR）模板中的要求填写，对需求变更的具体操作流程请参考《配置管理过程》。需求变更的相关情况需记录至《需求跟踪矩阵》中进行跟踪。
5.5 Output 输出
《产品设计规格》（更新）
《软件需求规格说明书》
《需求跟踪矩阵》
5.6 Exit Criteria 出口准则
项目结束。
6 Resource and Tools 资源与工具
项目经理协调并提供需求开发与管理所需的资源和工具，例如电脑、办公环境，工具和软件等以及与外部的协调。
7 Configuration Management and Assets 配置管理和资产
需求开发与管理过程中所有的输出及相关资料都要纳入到配置库、技术资料库或者资产库中进行管理。
8 Training 培训
参与需求开发与管理相关人员，应具备相应的能力、技术和对本过程的理解与掌握，若掌握，则可免修，否则，高层经理需为其安排有关培训。
9 Process Measurement 过程度量
《产品设计规格》的文档规模
《产品设计规格》的需求数
评审《软件需求规格说明书》所发现的缺陷数量
需求开发及需求管理所花费的工作量
需求变更的功能点数
10 Tailoring Guidelines 裁剪指南
活动均不允许裁剪。
11 Verification 验证
QA定期评审需求开发与管理的活动和工作产品，对里程碑处的审计活动和工作产品进行评审和审计，并报告其结果，具体流程参见《质量保证过程》定义。
12 Related Process 相关过程
《配置管理过程》
《评审过程》
《培训管理过程》
《配置管理过程》
《项目监控过程》
《风险管理过程》
13 Reference Materials 参考文献
《CMMI for Development, Version 1.3》
CMM中的需求管理与需求开发
需求管理（Requirements Management ）是属于CMM2中的过程域，简 称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。本文对CMM 的一些基础知识、基础术语不再介绍。 需求管理与需求开发的分界线： 市场营销 用户需求 管理层 需求开发 需求管理 市场 营销 管理层需求变更项目环境 项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。 需求管理 在CMMI 中，需求管理的目标定义为： a. 把软件需求建立一个基线供软件工程和管理使用。 b. 软件计划、活动和工作产品同软件需求保持一致。 更高的目标： 软件需求的复用
需求管理的原则和方法 a. 必须与需求工程的其他活动紧密整合
b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的 c. 只要需求变化了，需求变更的影响就必须被评估 d. 需求必须分优先级 e. 需求一定要分类管理 需求管理的主要工作： 特定目标和特定实践 特定目标 ●管理需求 管理需求并识别需求与项目计划和工作产品之间的差 异。 ●SP 1.1 取得需求理解 ●SP 1.2 取得需求承诺 ●SP 1.3 管理需求变更 ●SP 1.4 维护需求的双向追溯性 ●SP 1.5 识别项目工作与需求间的差异 REQM特定目标的关系
SP 1.1 取得需求理解 SP 1.1 和需求提出者一同来了解需求。 l 识别出谁是需求的提供者 l 识别出需求的接受标准： a. Clearly and properly stated得到清晰和恰当的定义 b. Complete完整的 c. Consistent with each other相互一致的 d. Uniquely identified得到唯一标识的 e. Appropriate to implement适宜实现 f. Verifiable (testable)可以验证（测试） g. Traceable可追溯 l 分析需求，确保符合已建立的准则。 l 与需求提供者达到需求共识，以使项目成员能承诺它们SP1.2 获取对需求的承诺 SP1.2 取得项目成员对需求的承诺。 ●评估需求对现有承诺的影响。 需求变更或新需求发生时，评估它们对项目成员的影 响。 ●协商并记录承诺。
软件需求开发与管理
软件需求开发与管理 1概述 需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等。需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。 软件需求工程划分为需求开发和需求管理，其中需求开发可进一步分为问题获取(elicitation)、分析(analysis)、编写规格说明(specification)和验证(verification)四个阶段, 需求开发活动包括以下几个方面： (1)确定产品所期望的用户类 (2)获取每个用户类的需求 (3)了解实际用户任务和目标以及这些任务所支持的业务需求 (4)分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决 方法和附加信息 (5)将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件 (6)了解相关质量属性的重要性 (7)商讨实施优先级的划分 (8)将所发现的用户需求编写成规格说明和用例模型 (9)评审用例和需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组 接受说明之前将问题都弄清楚。 需求管理活动包括以下几个方面： (1)定义需求基线(迅速制定需求文档的主体) (2)评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它 (3)以一种可控制的方式将需求变更融入到项目中 (4)使当前的项目计划与需求一致 (5)估计变更需求所产生的影响并在此基础上协商新的承诺。 (6)让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪 (7)在整个项目过程中跟踪需求状态及其变更情况。 2需求工程的推荐方法 需求工程推荐方法 需求开发
产品需求分析管理和产品规划培训课程
产品需求分析管理和产品规划培训课程 课程背景 营销大师科特勒指出：“以市场为导向、以客户为中心”就是对市场需求的管理！市场需求管理是公司战略、市场计划、新产品开发的依据，决定了公司竞争力的延续，直接影响到公司效益。 但是：“有价值的客户需求在哪里，对有价值的需求如何进行汇总、分析。”目前大量的理论体系到此为止，如何在实际的操作层面上进行下去？如何执行？根据权威机构统计：项目缺陷的56％来源于需求定义错误，80％的缺陷修复成本用于修复需求导致的错误，需求的正确与否直接影响产品开发周期、产品开发成本，甚至直接决定产品最终的市场成败。 通过和众多国内科技企业接触，我们发现这些企业中普遍存在如下问题： 1.缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系”； 2.产品开发过程需求工作持续时间短，需求分析不充分；需求没有有效地分层分级，对不同阶段需求应该详细到什么程度没有明确的定义； 3.需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解一致性； 4.产品开发闭门造车，关注技术，不关注客户； 5.产品开发出来才找客户、找卖点； 6.不清楚业界众多需求分析工具如何在不同需求分析阶段进行恰当运用等； 本课程结合以上企业在市场需求管理中存在的问题进行深入的探讨，结合多年企业的实践和研发管理咨询的案例，就企业在市场需求的收集、整理、归类、分析、分解与分配、执行与验证等环节的问题展开深入的讲解，并分享大量企业的案例。 课程特色 课程的实践性：讲师从事过市场需求管理的工作多年，同时完成过近10个咨询项目，通过大量的案例和演练，让学员非常便于理解；具体的操作方法和工具：课程涉及的市场需求分析和市场需求管理的方法和工具十分具体，操作性非常强；讲师独特的专业背景：讲师都是从研发做起，在知名企业担任研发中高层领导，并且在成功的企业有成功的实践经验。 培训收益 1.了解研发需求工程过程与其他研发流程体系的接口关系； 2.掌握从市场角度进行有效的客户需求收集的机制和方法，筛选高质量的客户需求； 3.掌握对客户需求进行整理、分类、分析的方法，提高各个角色对需求理解的一致性，最终形成产品包需求，明确产品的竞争优势与卖点； 4.掌握外部需求和内部需求一体化管理的机制，从而降低产品的端到端生命周期成本； 5.掌握对产品包需求进行分解和分配，确保需求与设计协同一致，减少模块间耦合的方法； 6.掌握对客户需求、产品包需求、设计需求进行持续验证和跟踪的机制和方法； 7.掌握构建需求收集长效机制，提升公司整体需求管理能力的机制和方法； 8.掌握支撑研发需求工程各个阶段工作运作的工具和操作方法。 课程大纲 一、例分析：某案例公司市场之路
需求管理过程
需求管理过程 本文件属深圳天源迪科信息技术股份有限公司所有， 未经书面许可，不得以任何形式复印或传播。 2008-1-31发布 2008-2-18 实施
文件建立/修改记录
目录 1 简介 (4) 1.1 目的 (4) 1.2 适用范围 (4) 1.3 背景描述 (4) 1.4 术语表 (4) 1.5 参考资料 (5) 2 总体描述 (5) 2.1 概述 (5) 2.2 职责分工 (5) 2.3 结构描述 (6) 3 活动描述 (7) 3.1 需求培训 (7) 3.2 建立需求跟踪矩阵 (8) 3.3 维护需求跟踪矩阵 (9) 3.4 检查一致性 (10) 3.5 采取更正行动 (11) 3.6 需求变更管理 (12) 4 附录 (13) 4.1 附录A－相关过程 (13) 4.2 附录B－相关规范、指南 (13) 4.3 附录C－相关模板列表 (13)
1简介 1.1目的 制定需求管理过程的目的是管理产品和组件的需求，识别需求与项目计划及工作产品之间的不一致，有效地控制需求变更、以及跟踪需求的演进，指导项目组管理需求。 1.2适用范围 本过程适用于公司所有的软件项目，贯穿项目的整个生命周期。 1.3背景描述 无。 1.4术语表 ●软件需求：用户解决某一问题或者得到某一目标所需的软件功能。 ●基线：基线是经过评审和批准的配置项的集合，其作用是明确划分项目各阶段，确定各阶 段的结束点。在项目的开发过程中，最基本的基线有需求基线、开发基线、发布基线等。 ●配置控制委员会(Configuration Control Board)：简称CCB，是确定配置基线，评估、批准 变更，并保证已批准变更的实施的组织。 ●需求变更：需求变更主要来自三个方面－客户、高层和开发人员。因此，无论哪一方面提 出需求变更的要求，都应当对变更请求进行评估。需求变更通常包括三项内容：新增需求、修改需求、删除需求。每一种变更都可能影响到其他需求的变化，因此在进行变更时需要利用需求跟踪记录。 ●需求跟踪：需求跟踪主要是跟踪需求及其实现之间的一致性，需求跟踪通过管理需求跟踪 记录来进行。在需求的阶段已经建立了需求跟踪记录，在后续的开发过程中，通过不断填写需求跟踪记录，将设计、开发和测试等阶段产品与需求进行一一对应。同时，在任何一个阶段发生变更时，都要检查需求跟踪记录是否需要进行变更。需求跟踪是分布在各个开发阶段之中的。 ●涉众:专指所有会受到项目结果重大影响的人。要有效地解决任何复杂的问题，就会涉及 到满足不同涉众的需要。涉众通常会对问题持有不同的观点，因而必须用所提供的解决方案来满足不同的需要。许多涉众都是系统的用户。其中许多涉众只是系统的间接用户，或者只受到系统所影响的业务结果的影响。还有许多涉众是系统的经济型买主或支持者。了解涉众的组成及其特定需要是开发有效解决方案的关键。典型的涉众有客户（或客户代表）、用户（或用户代表）、投资者、股东、生产经理、买方、项目经理、设计人员、测试
需求开发和管理流程范例
需求开发和管理流程范例 目录 1.目的 (3) 2.适用范围 (3) 3.名词和缩略语 (3) 4.角色和职责 (3) 5.过程综述 (5) 5.1. 流程图 (5) 5.2. 过程说明 (5) 6.过程活动 (6) 6.1. 活动一：获取用户需求 (6) 6.2. 活动二：建立系统需求 (7) 6.3. 活动三.需求分析与建模 (9) 6.4. 活动四.形成需求规格说明 (10) 6.5. 活动五.需求验证 (11) 6.6. 活动六：需求变更 (12) 6.7. 活动七：需求跟踪 (12) 7.过程度量与改进 (15) 8.过程裁剪指南 (15) 9.相关文件 (15)
10.质量记录 (16) 11.附录 (17) 11.1. 附录1：需求优先级说明 (17) 11.2. 附录2：需求状态说明 (17)
1.目的 本程序文件定义了本组织的需求与管理的过程，目的是实现有计划地收集、分析顾客的需求，并保证所有共利益者在项目进展过程中始终保持对需求一致的理解和承诺。 2.适用范围 本过程适用于公司所有合同项目和自主研发项目。 3.名词和缩略语 4.角色和职责
5.1.流程图 5.2.过程说明 需求开发与管理过程包括首先获取用户需求，然后对用户需求进行分类和整理，形成系统需求。通过对系统需求进行分析和建模，形成需求规格说明书，并将分析后的需求以模型或原型方法与用户进行确认，以此建立设计开发基础。最后采用原型、测试验证、评审等方式验证需求。同时，在开发活动中有序的管理需求变更，并通过需求跟踪确保需求的可追溯性和一致性。
6.1.活动一：获取用户需求 通过与用户交流、对现有系统的了解以及对项目任务的分析，开发、捕获和修订用户的需要。 6.1.1.进入准则 经过市场扫描活动、售前支持、客户反馈等活动，产品经理经过基本分析，确定要进行某产品的开发和较大升级； 6.1.2.输入 市场分析报告、售前和售后服务相关记录 6.1.3.任务 任务1：产品市场扫描。市场服务部会同产品经理针对特定产品进行市场扫描工作，主要包括与该产品相关的其他产品的名称、主要功能、市场情况；产品的领域，相关标准情况；产品主要涉及的技术领域和技术发展概况。产品经理根据市场扫描的结果确认是否需要进行产品开发和升级。 任务2：需求调研。产品经理根据《需求调研规程》组织相关人员实施需求调研活动，形成相关调研记录和《需求特性列表》。评审小组对调研结果实施结构化审查。 任务3：产品路线图设计。产品经理根据产品的需求特性列表和市场情况初步确定产品功能特性的优先级，优先级划分参见附录1，并且将优先级的划分与高级经理进行沟通，得到初步的确定后，对需求特性列表按照优先级进行分类整理，形成《产品路线图》。 对于项目而言，此任务可以演化成考虑项目分阶段实施的需求划分。 6.1.4.输出 《需求特性列表》、《产品路线图》 6.1.5.退出准则 《需求特性列表》通过审核，与高级经理沟通后初步明确项目经理
软件项目的需求开发与管理
软件项目的需求开发与管理需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。 本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。 1? 什么是软件需求和需求工程 软件需求的定义 在IEEE软件工程标准词汇表(1997年)中定义软件需求为： （1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。 需求工程的定义 需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情
研发部需求开发流程管理
研发部需求开发流程管理
管理目标 1、所有关系人清晰明确地了解项目的需求和 期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。 2、项目管理三要素平衡（时间/成本/质量）， 即开发项目按需按时按质的完成。 3、目标：功能满足需求，设计支持变化，开发 快速迭代，成果持续交付。 执行概述 1、建立有效的工作流程保证项目的顺利进行， 初期使用传统RUP过程，引入部分敏捷方法，团队磨合完成后逐步实现敏捷开发全流程管理。 2、明确项目目标，制定具有可行性的项目计 划，有效明确的分解项目需求。 3、跟踪设计/开发/测试/回归/发布全流程，推 动项目按预定计划执行。 4、解决项目过程中出现的问题和冲突，一般集
中在需求不明/工作量或时长/开发难度/跨 部门协调等几个方面。 5、调动开发团队的积极性，创造力，推动团队 成员在项目过程中的学习成长。 6、风险识别、风险控制以及风险的预案。 项目管理 1、需求阶段 对项目进行技术可行性分析、技术评估、成本评估以及风险评估。 与需求提出方的代表进行需求讨论，明确项目的目标、价值。 确定项目范围、功能及优先级。 组建项目团队，特别要搞清楚项目的关键人。 项目启动会议，相关的关系人都必须参加。 2、设计阶段 根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统
设计；文档(包括系统用例、Demo、测试用例等)；评审会议。 设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。 该阶段交付成果需要进行评审。 3、执行阶段(开发和测试) 准备开发环境、测试环境。 跟踪，推动项目按计划进行。 项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括CS审核、SQL审核、WEB 审核等。 对需求变更进行控制管理。 测试阶段BUG响应及改进、收集反馈意见。 对项目风险进行管理。 4、发布阶段 包括制定项目发布计划，用户培训，发布上
(完整版)IBM软件产品需求管理流程
IBM 软件产品需求管理流程 1. 简介 IBM 软件产品的版本(V.R.M.F)从市场规划和客户需求开始，到研发以及后续的交付遵循IB M软件部集成产品设计(IPD)流程。IBM 软件产品需求管理流程是IPD的一个体现，也就是一个由市场/客户驱动的，跨市场部门、研发产品管理部门及研发工程部门的端到端需求管理流程。同时，此次内容我们将描述IPD和产品需求管理流程，及流程中的角色（市场、研发产品管理部门及研发工程部门），以及他们之间是如何通过协作来管理需求的。 2. 背景——IPD IPD指导如何对软件产品发布版本进行投资决策和如何协调部门间工作以实现这些决策所 定义目标，IBM软件产品需求管理基于IPD流程，要了解这个需求管理的流程，首先我们要了解IBM所有产品开发所遵循的IPD的流程，包括其决策点。 IPD流程分为六个步骤： 1.概念：即概念验证阶段，主要对需求包进行评审，以确定其是否有足够的商业价值； 2.计划：即资源投入计划阶段，主要对需求包进行评估，以确定是否有足够的资源且在 一定的时间范围内将需求包开发出来； 3.开发：即对需求包进行开发成产品阶段； 4.验证：即对产品进行验证阶段； 5.交付：即将产品交付市场阶段； 6.生命周期：即产品在市场上销售，使用，维护和退出市场的阶段。 其中包括了几个重要的决策检查点(DCP)：
1.概念决策检查点：即经过概念阶段各方面进行的一系列评审，在此检查点确定（1） 我们对需求包是否有足够的理解；（2）需求包是否有足够的商业价值。如果是，继续进入计划阶段； 2.计划决策检查点：即经过计划阶段的评估，在此检查点确定（1）我们是否有足够的 资源在既定的时间范围内完成需求包的开发（2）研发部门是否能在(1)的估计上承诺进行开发。如果是，继续进入开发阶段； 3.可交付决策检查点：即经过开发和验证阶段，在此检查点确定（1）产品是否质量合 格以交付给客户（2）我们产品的相应支持和销售是否已经准备好服务客户,如果是，产品交付市场； 4.生命周期结束决策检查点：即产品在市场使用一定时期后，在此检查点确定产品是否 退出市场。 一个产品从市场需求开始，经过概念验证，时间、资源等计划的支持，然后进行开发，验证，直至发布到市场供客户使用，最后在某个特定的时候结束产品在市场上的销售，在IBM都遵循着IPD流程。在其中过程中，这个产品的概念是否被接受，是否能得到资源上的投入的承诺，是否通过最终验证可以在市场上发布，以及什么时候在市场上停售，这些关键的决策都通过相应的委员会在不同的决策点上进行决策。 3. IPD 与产品需求管理流程 以上描述了IBM IPD的基本概念，我们接下来看IBM软件产品的需求管理是如何基于IPD 的。首先，请看下图一：产品需求管理流程。
产品需求分析与需求管理——如何搞定市场需求
产品需求分析与需求管理——如何搞定市场需求 主讲：董奎（十多年高科技企业的研发与管理实践经验，在某著名高科技企业工作期间，先后担当项目经理、系统工程师、产品经理、软件部经理） 课程对象：企业CEO/总经理、研发总监、研发经理/项目经理/技术经理/产品经理、产品规划专家等。 授课方式：讲师讲授+视频演绎+案例研讨+角色扮演+讲师点评。 【课程背景】 通过和众多国内科技企业接触，发现这些企业中普遍存在： 1、技术很牛，但最终倒闭的公司一大推；被技术人员嗤之以鼻的公司，反而活的还不错 2、研发从早忙到晚，产品开发的不少，但市场成功的产品屈指可数，开发的越多，死得越快 3、产品开发闭门造车，关注技术，不关注客户；产品开发出来才找客户、找卖点 4、了解市场的不懂技术，懂技术的不了解市场，不知道需求应该谁负责 5、需求准确把握决定产品成败，但没有人关注需求，即使偶尔想关注也不知道如何关注 6、需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解的一致性 7、缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系” 8、不能从自身能力提升来引导客户需求，反而天天在抱怨客户需求经常变动 9、针对需求大家“吵成一锅粥”：公司与客户吵，市场与开发吵，开发与测试吵，…… 不能满足客户需求、给客户创造价值，再牛的技术也没有价值。根据权威机构统计项目缺陷的56%来源于需求定义错误，80%的缺陷修复成本用于修复需求导致的错误，把技术变成金钱的不二选择关注、锁定、满足市场需求，创造客户价值。【课程重点】 1、如何确定目标客户，如何分析需求关系人？
2、如何从市场（客户）角度进行有效的客户需求收集？ 3、围绕产品成功2个核心因素差异化+成本优势，整理产品需求 4、如何对客户需求进行整理和分析，形成产品包需求？ 5、如何基于产品需求与竞争友商对比分析，确定我们的核心诉求，形成产品概念？ 课程贯穿案例分享，详细讲解目标客户?客户要求?客户需求?产品包需求?产品概念确定全过程，详细讲解把技术转变为金钱的方法和工具（利润区、回溯分析、决策模型分析、KJ、$APPEALS、BSA、概念定义7个核心秘诀、破坏性创新的3石蕊实验、SweetPoint模型、基于不同产品生命周期的12个创新思路等），提升产品的竞争力，确保市场成功、财务成功。 【课程价值】 1、掌握从市场角度进行有效的客户需求收集的机制和方法，筛选高质量的客户需求； 2、掌握对客户需求进行整理、分类、分析的方法，提高各个角色对需求理解的一致性，最终形成产品包需求，明确产品的竞争优势与卖点； 3、掌握外部需求和内部需求一体化管理的机制，从而降低产品的端到端生命周期成本； 4、掌握产品核心诉求的提炼方法，确定有吸引力的产品概念； 5、掌握支撑研发需求工程各个阶段工作运作的工具和操作方法； 【培训内容】 一、案例分享 二、六个基本概念 1、什么是客户？ 1)客户、用户、目标客户、潜在客户、可以送给竞争友商的毒药客户 2、什么是需求？ 1)WANTS/NEEDS/DEMANDS、真假需求、客户需求、用户需求、产品需求、设计需求、需求规格、技术需求、非技术需求 2)案例：某运营上广告折射对需求五层次的理解 3、需求工作的2个基本点：
研发部需求开发规程管理
精心整理 管理目标 1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。 2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。 3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。 执行概述 1、 2、 3、跟踪设计/开发/测试/回归/ 4、/跨部门协 调等几个方面。 5、 6、风险识别、风险控制以及风险的预案。 项目管理 1、需求阶段 2 根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统设计；文档(包括系统用例、Demo、测试用例等)；评审会议。 设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。 该阶段交付成果需要进行评审。 3、执行阶段(开发和测试) 准备开发环境、测试环境。
跟踪，推动项目按计划进行。 项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括CS审核、SQL审核、WEB审核等。 对需求变更进行控制管理。 测试阶段BUG响应及改进、收集反馈意见。 对项目风险进行管理。 4、发布阶段 包括制定项目发布计划，用户培训，发布上线。 5、试运行阶段 数据监控(日志、服务器状态) 定情况执行补丁升级。 6、收尾阶段 产品交付，项目总结会。 常见问题 1、开发时间的估算 算，通常单个模块开发时间取决于以下因素： 1 2(包括对框架和应用的熟悉程度)。 3 开发者没有相关的代码可以参考，自己也没有经验， 1、在划分好模块后，首先项目管理人员预先估算各个模块所需要的开发时间。 2、召集所有开发人员，讨论模块的分配和开发时间估算。将划分好的模块，分配给开发人员，如状况允许可允许开发人员自主选择以提高开发人员的主动性和参与性。分配模块的时为确保开发的速度和质量，基本原则如下： A、类似的模块由同一人负责开发，比如用户信息的增删改应由同一开发者负责。这样开 发者对相关逻辑会比较熟悉，代码/接口的定义也会相对明确，沟通的成本低，相应可以降低功能实现的缺陷概率。 B、技术难度较大的模块由技术水平比较高的人负责。 C、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。
需求开发与管理过程
密级：普通 标识:S_RD_XQKFYGLGC 版本号：2.0 分册：第1册/共1册 需求开发与管理过程 湖南创博龙智信息科技股份有限公司 湖南创博龙智信息科技股份有限公司对本文件资料享受著作权及其它专属权利，未经书面许可不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
文件更改摘要：
目录 1.目的/方针 (3) 2.范围 (3) 3.术语 (3) 4.角色与职责 (3) 5.入口准则 (3) 6.输入 (3) 7.流程图 (4) 8.主要活动 (4) 8.1.需求获取 (4) 8.1.1.明确所需获取信息的来源与渠道（Where） (5) 8.1.2.获取需求（How） (5) 8.1.3.需求获取资料的保管 (7) 8.1.4.编写用户需求规格说明书 (7) 8.2.需求分析 (7) 8.2.1.结构化分析方法 (7) 8.2.2.基于用例的分析方法 (8) 8.3.需求定义 (9) 8.3.1.定义需求的优先级 (9) 8.3.2.编写《需求分析说明书》 (10) 8.4.需求确认 (10) 8.4.1.需求评审 (10) 8.4.2.需求承诺 (11) 8.4.3.建立需求基线 (11) 8.5.需求变更 (11) 8.5.1.需求变更申请................................................................. 错误！未定义书签。 8.5.2.需求变更的实施 (12) 8.6.需求跟踪 (12) 8.6.1.建立需求跟踪矩阵 (12) 8.6.2.需求跟踪矩阵的维护与使用 (12) 9.输出 (12) 10.出口准则 (13) 11.资源 (13) 12.引用文档 (13)
论如何进行有效的需求管理
论如何进行有效的需求管理 很多人会有这种感受，一个项目做了很久，感觉总是做不完，就像一个“无底洞”。你想加人尽快完成这个项目，而用户总是有新的需求要项目开发方来做，就像用户是一个不知廉耻的要求者，而开发方是在苦苦接收的接受者。实际上，这里涉及到一个需求管理的概念。项目中哪些该做，哪些不该做，做到什么程度，都是由需求管理来决定的。需求管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占了很大的一部分，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。 在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能，优化性能，提高用户友好性的要求。在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。 下面主要针对需求开发及需求管理两个方面对需求进行分析。 1. 需求开发，从目前我们的实际工作情况来看按顺序主要分成如下几个部分： ?请教行业专家 行业客户对信息化的需求越来越细化，对专业性以及行业能力的全面性要求越来越高，惟有深入行业，洞察其需求，研发出更适合客户需求的产品，才能成功。因此有必要先请这方面的行业专家对于客户的业务需求进行从流程上的梳理。为什么请行业专家，而不是直接请客户进行交谈，得到其实需求，个人认为主要是因为目前各政府部门、企事业单位对于信息化与业需求的整合这一块缺少经验，大部分情况还不能完全整理出完善、清晰的系统需求来。只有通过行业专家对其实业务流程进行梳理，一方面更容易与客户产生共鸣，另一方面也可以大大减少因为知识方面的差异导致错识需求的产生。 ?和客户交谈 你要面对“正确”的客户区分不同层次的客户需求，要面对不同层级，不同部门的客户，把客户分类，区分需求的优先级别。如果你做的项目业务是你熟悉的，那还好，如果是你不熟悉的，一定要花点精力学习一下这个行业业务的背景资料，这也是我上面谈到的先请行业专家的原因。毕竟，客户是不可能给你系统地介绍业务的。只有你通晓了行业业务，才能和用户交流，并正确而有效地引导客户，做好需求分析，你不能指望客户能明确地说出需求。
产品需求分析与需求管理
产品需求分析与需求管理 －－如何搞定市场需求通过和众多国内科技企业接触，发现这些企业中普遍存在： 1. 技术很牛，但最终倒闭的公司一大推；被技术人员嗤之以鼻的公司，反而活的还不错 2. 研发从早忙到晚，产品开发的不少，但市场成功的产品屈指可数，开发的越多，死得越快 3. 产品开发闭门造车，关注技术，不关注客户；产品开发出来才找客户、找卖点 4. 了解市场的不懂技术，懂技术的不了解市场，不知道需求应该谁负责 5. 需求准确把握决定产品成败，但没有人关注需求，即使偶尔想关注也不知道如何关注 6. 需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解的一致 性 7. 缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系” 8. 不能从自身能力提升来引导客户需求，反而天天在抱怨客户需求经常变动 9. 针对需求大家“吵成一锅粥”：公司与客户吵，市场与开发吵，开发与测试吵，…… 不能满足客户需求、给客户创造价值，再牛的技术也没有价值。根据权威机构统计项目缺陷的56%来源于需求定义错误，80%的缺陷修复成本用于修复需求导致的错误，把技术变成金钱的不二选择关注、锁定、满足市场需求，创造客户价值。 本课程重点讲解： 1. 如何确定目标客户，如何分析需求关系人？ 2. 如何从市场（客户）角度进行有效的客户需求收集？ 3. 围绕产品成功2个核心因素差异化+成本优势，整理产品需求 4. 如何对客户需求进行整理和分析，形成产品包需求？ 5. 如何基于产品需求与竞争友商对比分析，确定我们的核心诉求，形成产品概念？ 课程贯穿案例分享，详细讲解目标客户→客户要求→客户需求→产品包需求→产品概念确定全过程，详细讲解把技术转变为金钱的方法和工具（利润区、回溯分析、决策模型分析、KJ、$APPEALS、BSA、概念定义7个核心秘诀、破坏性创新的3石蕊实验、Sweet Point模型、基于不同产品生命周期的12个创新思路等），提升产品的竞争力，确保市场成功、财务成功。 一、案例分享 二、六个基本概念 1. 什么是客户？ 1) 客户、用户、目标客户、潜在客户、可以送给竞争友商的毒药客户 2. 什么是需求？ 1) WANTS/NEEDS/DEMANDS、真假需求、客户需求、用户需求、产品需求、设计需求、需 求规格、技术需求、非技术需求 2) 案例：某运营上广告折射对需求五层次的理解 3. 需求工作的2个基本点： 1) 差异化 2) 成本优势 4. 需求工程全过程： 1) 需求收集→需求整理→需求分析→概念确定→需求分解→需求实现与验证 5. 官方体系对需求的定义： 1) RM（目的、关键实践、典型输出） 2) RD（目的、关键实践、典型输出） 6. 产品经理3个核心素质特征：
需求开发与管理过程(Req. Development Mgt. Process)
Req. Development & Mgt. Process 需求开发与管理过程 Prep分配需求ed by 拟制陈刚 Date 日期 2006-05-16 Reviewed by 评审人SEPG team Date 日期 2007-4-20 Approved by 批准田松涛 Date 日期 2007-4-24
Revision Record 修订记录
Table of Contents 目录 1Purpose 目的 (5) 2Scope 范围 (5) 3Abbreviations and Acronyms 术语和缩略语 (5) 4Policy 方针 (5) 5Process Description 过程描述 (5) 5.1Roles and Responsibilities 角色和职责 (6) 5.2Entrance Criteria 入口准则 (6) 5.3Input 输入 (6) 5.4Activities 活动 (6) 5.4.1Summarize 总述 (6) 5.4.2Flow Chart 流程图 (7) 5.4.3Requirements Development and Validation 需求开发及确认 (8) 5.4.4Trace Requirements and Requirements Management 需求跟踪和管理 (10) 5.5Output 输出 (11) 5.6Exit Criteria 出口准则 (11) 6Resource and Tools 资源与工具 (11) 7Configuration Management and Assets 配置管理和资产 (11) 8Training 培训 (11) 9Process Measurement 过程度量 (11) 10Tailoring Guidelines 裁剪指南 (12) 11Verification 验证 (12) 12Related Process 相关过程 (12) 13Reference Materials 参考文献 (12)
(项目管理)软件项目管理规范
软件项目管理规范 一、软件项目管理的定义 软件项目管理是软件工程和项目管理的交叉学科，软件项目管理的概念涵盖了管理软件产品开发所必须的知识、技术及工具。根据美国项目管理协会PMI对项目管理的定义可以将软件项目管理定义为：在软件项目活动中运用一系列知识、技能、工具和技术，以满足软件需求方的整体要求。 软件工程的活动包括问题定义、可行性研究、需求分析、设计、实现、确认、支持等，所有这些活动都必须进行管理，软件项目管理贯穿于软件工程的演化过程之中，如图1所示。 图1 软件工程的演化过程 二、软件项目管理的过程 为保证软件项目获得成功，必须清楚其工作范围、要完成的任务、需要的资源、需要的工作量、进度的安排、可能遇到的风险等。软件项目的管理工作在技术工作开始之前就应开始，而在软件从概念到实现的过程中继续进行，且只有当软件开发工作最后结束时才终止。管理的过程分为如下几个步骤： （1）启动软件项目 启动软件项目是指必须明确项目的目标和范围、考虑可能的解决方案以及技术和管理上的要求等，这些信息是软件项目运行和管理的基础。 （2）制定项目计划 软件项目一旦启动，就必须制定项目计划。计划的制定以下面的活动为依据。 ●估算项目所需要的工作量 ●估算项目所需要的资源 ●根据工作量制定进度计划，继而进行资源分配 ●做出配置管理计划 （3）跟踪及控制项目计划 在软件项目进行过程中，严格遵守项目计划，对于一些不可避免的变更，要进行适当的控
制和调整，但要确保计划的完整性和一致性。 （4）评审项目计划 对项目计划的完成程度进行评审。并对项目的执行情况进行评价。 （5）编写管理文档 项目管理人员根据软件合同确定软件项目是否完成。项目一旦完成，则检查项目完成的结果和中间记录文档，并把所有的结果记录下来形成文档而保存。 三、软件项目管理的内容 软件项目管理的内容涉及上述软件项目管理过程的方方面面，概括起来主要有如下几项。 （1）软件项目需求管理 软件需求是软件工程过程中的重要一环，是软件设计的基础，也是用户和软件工程人员之间的桥梁。简单地说，软件需求就是确定系统需要做什么，严格意义上，软件需求是系统或软件必须达到的目标与能力。 1、目标 需求管理是一种获取、组织并记录软件需求的系统化方案，同时也是一个使客户与项目开发组对不断变更的软件需求达成并保持一致的过程。在需求管理中，软件工程组的工作是采取适当的措施来保证分配的需求，即要将分配的需求文档化，控制需求的变化，负责项目实施过程中需求的实现情况。需求管理的目的是在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解。需求管理的目标有两个： ●使软件需求受控，并建立供软件工程和管理使用的需求基线。 ●使软件计划、产品和活动与软件需求保持一致。 在需求管理过程，为实现第一个目标，必须控制需求基线的变动，按照变更控制的标准和规范的过程进行需求变更控制和版本控制；为实现第二个目标，必须就变更和软件项目各小组达成共识，对软件项目计划做出调整，其中包括人员的安排、用户的沟通、成本的调整、进度的调整等。 2、原则 为进行有效的需求管理，一般要遵循如下五条原则： ●需求一定要分类管理 进行软件项目管理的时候，一定要将软件需求分出层次。不同层次需求的侧重点、描述方式、管理方式是不同的。 ●需求必须分优先级
需求开发与管理
需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。 本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。 1 什么是软件需求和需求工程 1.1 软件需求的定义 在IEEE软件工程标准词汇表(1997年)中定义软件需求为： （1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 （3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。 1.2 需求工程的定义 需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。 2 需求分析的风险 由于需求分析的参与人员、业务模式、投资、时间等客观因素的影响和需求本身具有主观性和可描述性差的特点，因此，需求分析工作往往面临着一些潜在的风险。这些风险主要表现在： （1）用户不能正确表达自身的需求。在实际开发过程中，常常碰到用户对自己真正的需求并不是十分明确的情况，他们认为计算机是万能的，只要简单的说说自己想干什么就是把需求说明白了，而对业务的规则、工作流程却不愿多谈，也讲不清楚。这种情况往往会增加需求分析工作难度，分析人员需要花费更多的时间和精力与用户交流，帮助他们梳理思路，搞清用户的真实需求。 （2）业务人员配合力度不够。有的用户日常工作繁忙，他们不愿意付出更多的时间和精力向分析人员讲解业务，这样会加大分析人员的工作难度和工作量，也可能导致因业务需求不足而使系统无法使用。
需求开发流程管理规定
需求开发流程管理规定 1. 目的 通过需求开发流程的规定，规范公司软件项目的需求开发和管理活动，提高需求质量，降低开发成本，改进系统质量。 ，
4. 流程图 图1：需求开发流程图
5. 主要活动 需求定义的目的是需求提出人通过收集、调查与分析，获取用户业务需求并定义需求。需求定义的主要活动包括：需求收集、需求分析&定义。 需求管理的目的是在需求方与程序组之间建立对需求的共同认识和理解，维护需求与程序开发成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求评审确认、需求变更、需求跟踪控制。 在需求文档中，一般取二级类别进行标识。 5.1.3 需求优先级 需求分析员应确定每个需求的优先级，需求的优先级判定标准如下：
●确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性； ●考虑了各个层次的需求影响，确定了需求的优先级，以确保需求的可行性。 提醒：对于版面调整、活动等不需要做过多业务流程更改的需求，采用《程序需求表》进行填写。 5.2 需求评审确认及开发流程 需求评审是指程序开发方和需求提出方共同对《立项需求说明书》进行评审，双方对需求与商业目的达成共识。
在需求说明书生成后，需求分析员将文档提交给需求受理人，由受理人进行初审，确保文档的正确性和合理性，并符合文档编写规范。 5.2.1 需求评审 评审的目的在于：使需求文档达到易读、无歧义、一致、必要、完整、可实现、可验证。 需求受理人（一般为部门总监，各个地区分站由技术中心受理）对提交的需求文档进行初审通过后，由信息技术中心组织和安排需求的评审工作：确定评审时间、地点、评审人员和其他参加人员。至少应包含以下成员： ●评审组长：总裁及总裁办相关领导、信息技术总监； ●评审成员：项目经理、程序员及其他相关人员； ●输入：《立项需求说明书》初稿 ●输出：《评审结果报告》 当需求文档评审通过后，程序开发方和需求提出方应须进行书面签字确认，使之生效。之后若需要调整需求，则须走需求变更控制流程。 未经书面确认的需求开发，若发生需求分歧，由未签字确认方及其上级承担主要责任。 经书面确认的需求开发，若发生预期需求与开发实现的功能不一致而影响开发质量的，责任归属 界定： A.因需求不明确、阐述遗漏、描述错误等，且后期没有对应的需求变更记录备案，而造成实现 的功能与预期需求不一致，由需求方承担主要责任。 B.因需求不明确、阐述遗漏、描述错误等，而后期存在对应的需求变更记录备案，而造成实现 的功能与预期需求不一致的，由程序开发方承担主要责任。 5.3 需求变更 对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是不可避免。这主要有以下几种原因： 1. 系统所应用的外部环境发生变化； 2. 随着对软件的熟悉和应用，又提出新的需求； 3. 进行需求分析时未能彻底分析原始需求，或分析错误； 4.在开始时不能很全面的知道所需软件的功能。 需求变更的影响：对项目研发而言，变更需求意味着有可能需要重新分配任务、修改前期工作成果、调整工作计划和项目预算等。 只有当需求变更带来的好处大于坏处时，变更需求才是有意义的，但也须遵循变更控制流程：申请→审批→执行；如果需求变更带来的坏处大于好处，则应拒绝变更。 需求受理人应适当拒绝一些不合理的变更。如：提出的变更不是由于程序开发方的过错引起的，此变更可能造成程序开发方占用额外的资源或成本，而需求方又不愿给出额外资源对变更进行处理等。 变更控制流程如图所示，主要包括：变更申请、评审和审批、填写执行记录。