第4章 需求开发与需求管理
需求分析与需求管理
需求变更的处理流程
评估影响
分析需求变更对项 目进度、成本、质 量等方面的影响。
制定方案
制定变更方案，明 确变更实施的具体 措施和时间安排。
识别变更
及时发现并记录需 求变更，了解变更 的性质和影响。
沟通协调
与相关干系人沟通 ，确保各方对变更 的理解和接受。
审批实施
经过审批后，正式 实施变更，并对项 目计划进行调整。
易用性
工具应易于使用，以便提高员工的工作效率和满意度。
兼容性
工具应能与其他企业系统兼容，以便数据的共享和整合。
需求管理工具的使用方法
01
需求收集
使用工具收集各方需求，如客户、 内部团队等。
需求跟踪
使用工具跟踪需求的开发状态，确 保按计划完成。
03
02
需求分析
对收集到的需求进行分析，如优先 级排序、可行性评估等。
需求分析与需求管理
BIG DATA EMPOWERS TO CREATE A NEW
ERA
汇报人：可编辑 2024-01-09
• 需求分析概述 • 需求收集 • 需求整理与分类 • 需求规格说明编写 • 需求变更管理 • 需求管理工具
目录
CONTENTS
01
需求分析概述
BIG DATA EMPOWERS TO CREATE A NEW
需求变更的控制与跟踪
建立变更管理流程
明确需求变更的申请、评估、审批和实施的 流程和责任人。
记录变更信息详细记录需求变更的信息，包括更内容、 原因、影响和批准情况。
定期审查与评估
定期对需求变更进行审查和评估，以确保变 更的合理性和可行性。
跟踪实施情况
对已实施的变更进行跟踪，确保变更效果的 达成和项目目标的实现。
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 分析需求，确保符合已建立的准则。
需求开发与需求管理指引
第1章CMMI综述1.1 CMMI 简介 ...................................................................... 4 1.1.1 CMMI 发展简史 ....................................................... 4 1.1.2 CMMI的过程域 (5)1.1.3 CMMI 的两种表示法 ...................................................... 6 789 9 9 10101.4过程域的部件及解释 .............................................................. 14 1.4.1 必需部件 ............................................................ 15 1.4.2 期望部件 ............................................................ 15 1.4.3信息部件 (16)1.5 CMMI 评估 (17)1.2.1 成熟度等级 L1 : 初始级的特征 1.2.2 成熟度等级 L2 : 已管理级的特征 1.2.3 成熟度等级 L3 : 已定义级的特征 1.2.4 成熟度等级 L4 : 量化管理级的特征 1.2.5 成熟度等级L5 : 持续优化级的特征1.3 CMMI 连续式表示法1.3.1 能力等级 0-不完整级的特征 1.3.2 能力等级 1-已执行级的特征 1.3.3 能力等级 2-已管理级的特征 1.3.4 能力等级 3-已定义级的特征 1.3.5 能力等级 4-量化管理级的特征 1.3.6 能力等级5-持续优化级的特征.................................................................. 12 .................................................................. 12 .................................................................. 12 . (13).............................................................. 13 .. (14)1.2 CMMI 阶段式表示法1.5.2 CMMI 标准评估方法SCAMPI (17)1.5.3 CMMI 评估考虑事项 (18)1.6 CMMI 和CMM 的比较 (19)1.6.1 CMMI 与CMM 的模型比较 (19)1.6.2 CMMI 与CMM 过程域比较 (19)1.6.3 CMMI 与CMM 评估方法比较 (21)1.7 CMM/CMMI 在中国 (21)1.1 CMMI 简介1.1.1 CMMI 发展简史1981年，美国卡内基梅隆大学软件工程研究所（SEI），应美国联邦政府的要求开发了一种用于评价软件承包商能力并帮助其改善质量的方法。
Chapter04_Exercises
C. 识别、控制和跟踪需求的变化
D. 以上选项都不是
11. （
）需求工程师的任务是将所有利益相关者的信息进行分类以便允许决策者选择一
个相互一致的需求集。
A. 真
B. 假
12. 下面的（
）不是在项目启动阶段被提出的“与环境无关”的问题。
A. 成功的解决方案将带来什么样的经济收益？
B. 谁反对该项目？
C. 谁将为该项目付款？
2. 请指出下面需求描述存在的问题，并进行适当的修改。
（1） 系统用户界面友好。 （2） 系统运行时应该占用尽量少的内存空间。 （3） 即使在系统崩溃的情况下，用户数据也不能受到破坏。 （4） ATM 系统允许用户查询自己银行帐户的现存余额。 （5） ATM 系统应该快速响应用户的请求。 （6） ATM 系统需要检验用户存取的合法性。 （7） 所有命令的响应时间小于 1 秒；BUILD 命令的响应时间小于 5 秒。 （8） 软件应该用 JAVA 语言实现。 答案要点： （1） 问题：“友好”是不可验证的。
B. 每个指定系统的实现
C. 软件体系结构的元素
D. 系统仿真所需要的时间
9. 组织需求评审的最好方法是（
）。
A. 检查系统模型的错误
B. 让客户检查需求
C. 将需求发放给设计团队去征求意见
D. 使用问题列表检查每一个需求
10. 使用跟踪表有助于（
）。
A. 在后续的检查运行错误时调试程序
B. 确定算法执行的性能
（2） 需求分析：分析和综合所采集的信息，建立系统的详细逻辑模型。 （3） 需求规格说明：编写软件需求规格说明书，明确、完整和准确地描述已确定的需求。 （4） 需求验证：评审软件需求规格说明，以保证其正确性、一致性、完备性、准确性和清
需求开发与需求管理ppt课件
4. 需求开发的主要困难与对策
4.5 双方误解需求
人们在交流的时候，经常会发生“问非所求， 答非所问”的事情。
有时用户会把开发人员的建议或答复给想歪了：
有一个软件开发人员滔滔不绝地向用户讲解在“信 息高速公路上做广告”的种种好处，用户听得津津 有味。最后，心动的用户对软件开发人员说：“好 得很，就让我们马上行动起来吧。请您决定广告牌 的尺寸和放在哪条高速公路上，我立即派人去做。”
需求调查不象侦探推理那样从蛛丝马迹着手，应该 先了解宏观问题，再了解细节问题。
如果双方气氛融洽，可以采用灵活的访谈形式，轻
5. 如何开展需求调查
5.3 《用户需求说明书》与《产品需求规格 说明书》的主要区别与联系
前者主要采用自然语言（和应用域术语）来表 达用户需求，其内容相对于后者而言比较粗略， 不够详细。
“主动型”是指开发者积极地开展需求工程中的各 项活动。他们把获取准确的需求当作自己的职责， 会想尽一切办法克服需求开发和需求管理过程中的 困难，而不是找借口推卸责任。俗话说“良好的开 端是成功的一半”，“主动型”需求工程是开发成 功产品的必备条件。
4. 需求开发的主要困难与对策
4.1 知识技能问题
需求分析员与用户面谈时应当注意以下事项：
如果与用户约好了时间，切勿迟到或早退。要注意 礼节，尽可能获得用户的好感，并为下次打扰他们 埋下伏笔。
需求分析员应事先了解用户的身份、背景，以便随 机应变。IT人士不可貌相，有些大企业的领导其外 表很土气，象农民。如果你路上碰到他，以为是个 勤杂工，说：“喂，老师傅，来帮我拎东西。”也 许这笔生意就泡需求都应当用陈述句说明“是什么”，如果 “是什么”的内涵不够清晰，则应补充说明“不是 什么”。
第4章 需求开发
第4章需求开发 (1)4.1 介绍 (1)4.2 用户需求调查 (2)4.2.1目的 (2)4.2.2角色与职责 (2)4.2.3启动准则 (2)4.2.4输入 (2)4.2.5主要步骤 (3)[Step1] 准备 (3)[Step2] 调查与记录 (3)[Step3] 分析需求信息 (3)[Step4] 撰写用户需求说明书 (3)[后续活动：需求确认] (3)4.2.6输出 (4)4.2.7结束准则 (4)4.2.8度量 (4)4.3 产品需求定义 (4)4.3.1目的 (4)4.3.2角色与职责 (4)4.3.3启动准则 (4)4.3.4输入 (4)4.3.5主要步骤 (5)[Step1] 细化并分析用户需求 (5)[Step2] 撰写产品需求规格说明书 (5)[后续活动：需求确认] (5)4.3.6输出 (5)4.3.7结束准则 (5)4.3.8度量 (6)4.4 需求分析方法概述 (6)4.4.1问答分析法 (6)4.4.2建模分析法 (6)一、结构化分析法 (7)二、面向对象分析法 (7)三、恰当地使用图形符号 (8)4.5 实施建议 (8)第4章需求开发需求开发（Requirement Development, RD）的目的是通过调查与分析，获取用户需求并定义产品需求。
需求开发过程域是SPP模型的重要组成部分。
本规范阐述了需求开发过程域的两个主要规程：✧需求调查[SPP-PROC-RM-SURVEY]✧需求定义[SPP-PROC-RM-DEFINE]上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
需求分析是需求开发过程域的重要活动之一，但是不宜用“规范”这种形式来论述。
本章对需求分析方法作了概括性介绍，请读者阅读更加专业性的需求分析论著。
本规范适用于国内IT企业的软件研发项目。
建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。
需求开发和管理过程 附需求调研指南全套
需求开发和管理过程附需求调研指南1. 前言1.1 意图和价值意图：明确需求，确保利益相关者的共同理解，并调整需求、计划和工作产品。
价值：确保客户的需求和期望得到满足。
1.2 适用范围本过程文档是项目经理需求开发人员（包括：售前市场人员、需求调研人员等）执行需求开发与管理过程活动的依据和指导。
本过程适用于公司所有软件项目，且贯穿于整个生命周期。
1.3 名词术语用户需求是用户对要建立的系统的要求描述，它主要说明用户“要做什么”、“想做什么”的问题。
软件需求也叫产品需求，是软件产品能否满足用户需求的要求描述，它主要说明软件产品“能做什么”、“不能做什么”的问题。
2. 过程定义2.1 角色和职责2.2 入口准则需求开发人员已经确定；初步的《项目计划》已经通过评审。
2.3 输入初步的《项目计划》；《项目合同》；《技术解决方案》；客户原始需求文档。
2.4 过程活动需求阶段包括需求开发和需求管理两个过程活动。
需求开发过程需求开发过程是获取用户需求并对用户需求进行分析整理形成软件需求的过程。
需求开发过程可以包括用户需求调研、用户需求分析、软件需求定义和软件需求评审四个过程，也可以根据具体情况对该过程进行裁减。
需求开发的结果文档包括用户需求类文档、软件需求类文档、有时为了满足软件产品前期设计的需要，也会制作形成业务模型、数据字典、系统开发原型（Demo）文档等。
所有的需求文档经过用户和开发方双方评审认可并签字后，形成项目的需求基线。
需求管理过程需求管理是在需求文档基线化后，对需求实现的跟踪以及当需求发生变更时，对需求变更进行控制和管理的过程。
需求管理包括变更控制、版本控制、需求跟踪过程。
需求管理同时包括变更的需求及相关需求之间的关系管理。
2.4.1 需求开发过程2.4.1.1 用户需求调研在项目正式立项后，项目经理组建需求开发团队，需求开发人员根据初步《项目计划》、客户原始需求文档（包括：市场人员从客户那里得到的初步需求文档，投标文件中定义的技术方案内容等），确定需求调研时间及需求获取相关干系人，并将此活动更新到《干系人计划》中，同时制定出《需求调研计划》。
软件项目管理案例教程(第4版)-第4章
4.2.4 需求文档
需求文档作用
使用对象
需求文档的作用
软件项目客户 了解软件项目能够提供的软件产品，检查软件需求是否满足需要
项目管理人员 根据需求文档制定项目的开发计划和软件过程，初步预测资源的使用
软件开发人员 理解要开发的产品及具体要开发的内容 软件测试人员 验证软件系统是否满足了预期的要求 软件维护人员 使用需求文档帮助理解软件系统内在的逻辑关系
需求验证的内容：
（1）有效性检查
对于每项需求，首先必须证明它是正确有效的，确实能解决用户面对的问题。
（2）一致性检查
在需求文档中，需求不应该冲突，即对同一系统功能不应出现不同的描述或相互矛盾的约束。 当两条需求不能同时满足时，则定义二者是不一致的。 采用形式化的需求规格说明可以用软件工具验证需求的一致性。
自动化
实现级->设计级->功能级->需求级
4.1.4 需求工程
需求工程目标：
通过对问题及其环境的理解建立分析模型，在完全理解用户需求的基础上用SRS表达用户需 求
建立分析模型：它包含问题及其环境所涉及的信息流、处理功能、用户界面、行为模型及 设计约束
编写SRS：按照软件组织定义的SRS大纲，采用某种需求描述语言来完成
这家人承诺：杯子做好后会有高额的酬谢。
爱斯基摩人不断摇头，决定一分钱也不付给你。
4.1.1 软件需求概念
客户不知道自己要什么
客户：塑料杯、木头杯、还是橡胶杯，我也不知道！
客户知道自己要什么，但表达不清
客户提要求：使用时要能适应北极的环境。
我们经常会对客户的要求产生错误的理解
我们的理解：他一定要一个结实的杯子！
潜在缺陷
需求分析和需求管理
需求跟踪和状态报告
需求跟踪矩阵
建立需求跟踪矩阵，确保每个需求与相 应的计划任务、工作产品和交付物之间
的关联关系得到记录。
偏差分析
对实际需求执行情况与计划之间的偏 差进行分析，找出潜在的问题和风险
。
状态报告
定期生成项目需求状态报告，向项目 干系人提供有关需求执行情况的最新 信息。
调整和优化
根据需求跟踪和状态报告的结果，对 项目计划进行必要的调整和优化。
在项目执行过程中，持续 跟踪和报告需求的状态是 至关重要的。这有助于确 保项目进展与利益相关者 的期望一致，并及时发现 和解决问题。为了实现这 一目标，可以采用以下方 法
建立需求跟踪矩阵，将需 求与项目计划和执行活动 相关联，以便跟踪需求的 实现情况。
定期向利益相关者提供项 目状态报告，包括需求的 完成情况、存在的问题和 风险等。
原型法
设计并展示初步的产品原型，收集用户的反馈和意见。
需求研讨会
组织利益相关者进行讨论，明确产品需求和功能要求。
需求规格说明书编写
确定编写人员
选择具备一定技术背景和文档编写经 验的人员负责编写。
明确编写目标
确保规格说明书能够清晰、准确地描 述产品需求。
编写内容
包括产品概述、功能需求、性能需求 、接口需求等。
02
需求收集
访谈和问卷调查
访谈
通过与利益相关者进行面对面的交流 ，深入了解他们的需求和期望。访谈 可以采用一对一、小组讨论或焦点小 组的形式。
问卷调查
设计一份包含相关问题的问卷，通过 在线或纸质形式分发给利益相关者， 收集他们的反馈。
观察和参与
观察
通过实地观察利益相关者的日常工作和生活，了解他们的需 求和痛点。
需求开发与需求管理
另一个值得关注的方向是如何在需求开发和需求管理中更好地考虑用 户体验和情感因素，以提高软件产品的质量和用户满意度。
THANKS
感谢观看
相互依赖
需求开发和需求管理相互依赖，前者为后者提供基础，后者 在前者基础上进行管理和优化。
相互促进
良好的需求开发能够提高需求管理的效率，而有效的需求管 理又能促进需求的开发和实现。
共同目标
两者共同致力于满足客户需求，提高项目成功率。
05
案例分析
案例一
总结词
精准定位，快速迭代
详细描述
该电商平台通过市场调研和用户访谈，精准定位用户需求，快速迭代产品功能， 不断优化用户体验，从而在竞争激烈的市场中脱颖而出。
需求开发的流程
需求收集
通过与利益相关者的沟通，收集项目的需求和业务需求 。
需求编写
将分析后的需求编写成详细的需求规格说明书，包括功 能、性能、约束等方面的要求。
ABCD
需求分析
对收集到的需求进行分类、整理和筛选，明确需求的优 先级和重要性。
需求评审
对编写完成的需求规格说明书进行评审，确保需求的准 确性和完整性。
需求开发的方法
原型法
通过制作原型来展示产品的基本 功能和界面，帮助利益相关者更 好地理解需求。
调查问卷法
通过调查问卷的形式收集利益相 关者的意见和建议，了解他们的 需求和期望。
面谈法
与利益相关者进行面对面的交流， 深入了解他们的业务和需求，确 保需求的准确性和完整性。
03
需求管理
需求管理的定义
在需求开发的基础上，通过需求 管理对需求进行跟踪、调整和优 化，确保客户需求得到满足。
02
需求管理降低项目 风险
需求开发与需求管理课件
学习交流PPT
2
1. 什么是需求
• 1.1 需求的基本概念
• 宽泛地讲，需求来源于用户的一些“需要”，这些 “需要”被分析、确认后形成完整的文档，该文档详 细地说明了产品“必须或应当”做什么。
• 所以如果只有一些零碎的对话、资料或邮件，你就以 为自己已经掌握了需求，那是自欺欺人。
帝派来的，大家要注意形象。由于休息室空间有限，请
大家自觉让位。午休时他们可以躺着睡，我们只能坐在
位置上打个盹儿…….。”
• 2.4 重视“间接用户”，千万别“大意失能对软件产品有很大的影响。
• 例如，财务软件开发商在把“财务软件”卖给客户之前，
• “主动型”是指开发者积极地开展需求工程中的各项活动。他 们把获取准确的需求当作自己的职责，会想尽一切办法克服需 求开发和需求管理过程中的困难，而不是找借口推卸责任。俗 话说“良好的开端是成功的一半”，“主动型”需求工程是开 发成功产品的必备条件。
• “领先型”是需求工程的最高境界。开发者发掘了连用户自己 都没有意识到的需求，导致用户跟着新产品跑而不是新产品围 着用户转，这叫引导消费。需求工程做到这个份上，才能使产 品立于不败之地，长盛不衰。
明书》。系统设计人员将依据《产品需求规格说明书》
开展系统设计工作。
• 3.3 需求管理过程域
• 需求管理的目的是在客户与开发方之间建立对需求的共
同理解，维护需求与其它工作成果的一致性，并控制需
求的变更。
学习交流PPT
8
3. 需求工程基本概念
• 3.4 需求工程的一些感悟
• 不论是合同项目还是自主研发的产品，都必须开展需求开发和需求管理活动。
需求管理
需求管理需求管理是指在项目或产品的开发过程中，对需求进行识别、规划、分析、跟踪和控制的一系列管理活动。
通过需求管理，可以确保项目或产品符合客户的期望，同时提高项目交付的质量和效率。
需求管理的过程包括需求收集、需求分析、需求验证和需求控制等环节。
在需求收集阶段，需求管理团队通过与客户、利益相关者的沟通和访谈，收集和整理相关需求信息。
需求分析阶段，对收集到的需求进行分类、分解和优先级排序，以确保产品或项目的开发方向明确。
在需求验证阶段，需求管理团队与客户进行沟通，确认需求的准确性和完整性。
最后，在需求控制阶段，需求管理团队对需求进行变更控制，确保项目或产品的稳定性。
需求管理的核心目标是满足客户需求，同时确保项目或产品的质量和预算控制。
通过需求管理，可以避免因需求变更带来的项目延期和成本增加。
同时，需求管理也有助于保持项目团队与客户的紧密合作，促进项目的顺利进行。
在需求管理中，需求管理团队需要与项目各方进行有效的沟通和协调。
团队成员需要具备良好的沟通能力和分析能力，以便更好地理解和满足客户需求。
同时，团队成员还需要具备项目管理和问题解决的能力，以应对需求变更和冲突。
在实施需求管理过程中，还需要使用一些工具和技术来支持需求管理工作。
例如，需求管理团队可以使用需求管理软件来收集、分析和跟踪需求相关的信息。
此外，还可以使用流程图、原型设计和模型等工具来帮助识别和验证需求。
总之，需求管理是项目和产品开发过程中的重要环节，通过对需求进行规划、分析和控制，可以确保项目或产品符合客户的期望，提高交付的质量和效率。
需求管理需要团队成员具备良好的沟通、分析和问题解决能力，同时也需要借助工具和技术来支持需求管理工作。
只有有效地进行需求管理，才能提高项目成功的概率，满足客户的需求。
第4章_软件需求管理
软件项目需求分析的20条法则
14、及时作出决定
分析人员会要求客户作出一些选择和决定，这 些决定包括来自多个用户提出的处理方法或在质 量特性冲突和信息准确度中选择折衷方案等。 有权作出决定的客户必须积极地对待这一切， 尽快做处理，做决定，因为开发人员通常只有等 客户做出决定才能行动，而这种等待会延误项目 的进展。
软件项目需求分析的20条法则 13、准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的。 由于处理细节问题不但烦人而且耗时，因此很容 易留下模糊不清的需求。但是在开发过程中，必 须解决这种模糊性和不准确性。 在需求分析中暂时加上“待定”标志是个方法。 用来指明哪些是需要进一步讨论、分析或增加信 息的地方。 如果客户一时不能准确表达，通常就要求用原 型技术，通过原型开发，客户可以同开发人员一 起反复修改，不断完善需求定义。
软件项目需求分析的20条法则
10、获得满足客户功能和质量要求的系统
每个人都希望项目成功，但这不仅要求客户要 清晰地告知开发人员关于系统“做什么”所需的 所有信息，而且还要求开发人员能通过交流了解 清楚取舍与限制，一定要明确说明您的假设和潜 在的期望，否则，开发人员开发出的产品很可能 无法让您满意。
① 设备配臵：列出处理器的型号、内存容量、 外存容量等。 ② 支持软件：操作系统、相关系统软件等 ③ 接口。
用户接口 软件接口
④ 其他
需求管理过程
① ② ③ ④ ⑤ ⑥ ⑦ 定义需求 需求确认 建立需求状态 需求评审 需求承诺 需求跟踪 需求变更控制
软件需求的变更控制
软件需求变化是每个项目都会遇到的问题，一 旦发生需求变化，就不得不修改软件设计、重 写程序代码、修改测试用例、调整项目计划等。 需求变更可能来自开发方、客户或产品供应商 等，也可能源于项目组内部。主要变更原因：
需求开发与需求管理指南
基本目标：让所有人员有条不紊地开展工作，在预定的时间和成本之内，开发完成质量合格的产品，从而使企业和个人获得预定的利益。
奋斗目标：调动一切积极因素，努力提高产品质量、提高工作效率并且降低成本，使企业和个人获得比预定目标更多的利益。
在IT企业中，研发项目所涉及的主要过程域有：
本书倡导的研发管理思想是：
以追求商业利益最大化为总目标，将提高质量、提高效率、降低成本的方法（经验）融入到所有过程域中，形成适合于本企业的研发管理规范；开发和部署与规范配套的管理工具，从而有效地帮助企业依据规范开展研发管理工作。
1.2
1.2.1
早在1986年，美国PRTM公司创作了PACE（Product And Cycle-time Excellence，产品及周期优化法）方法论。PACE关注的要素有：
在企业里，大部分工作是成熟的，有成功的模式可以套用，应当走规范化路线；而另外小部分工作可能是独特的，并不适宜套用规范（也可能没有规范可以套用），那么应当采用超越规范化的管理方式。
一般地，企业既需要大量的规范化管理方式，又需要小量的超越规范化的管理方式。通常前者约占80%，而后者约占20%（这里80－20仅仅是建议比例）。
企业研发管理的指导思想是：结果导向，并且关注过程。
“结果导向”是指：以最终产生的经济效益来衡量研发项目的业绩，追求利益最大化。
“关注过程”是指：将期望的结果分解到每个过程域（即工作环节）去实现，努力把每项工作做好，从而得到好的结果。一般地，好的过程才可能得到好的产品，而差的过程只会得到差的产品。
衡量工作优劣的三个关键指标是：质量、时间和成本。人们在工作的时候总是希望：做得好（即质量高）、做得快（即时间少）而且少化钱（即成本低）。如果出现三者难以同时兼得的情况，那么决策者一定要搞清楚质量、时间、成本之间的复杂关系，判断孰重孰轻，给出优化和折中的措施。
软件开发过程中的需求分析与管理
软件开发过程中的需求分析与管理在软件开发过程中，需求分析与管理起着至关重要的作用。
精确的需求分析能够确保软件开发团队准确理解客户需求，避免后期需求变更带来的成本和时间延误。
本文将探讨软件开发过程中的需求分析与管理，包括需求获取、需求分析和需求管理。
需求获取需求获取是软件开发过程中的重要步骤，它涉及与用户、客户以及其他利益相关者的有效沟通与合作。
以下是几种常用的需求获取技术：1. 面谈：与用户面对面沟通，了解其需求和期望。
2. 问卷调查：通过问卷调查收集用户意见和期望。
3. 案例分析：通过分析类似项目或行业的案例，获取需求的参考。
4. 视频会议：利用现代技术进行远程需求获取。
5. 原型演示：通过构建原型让用户亲自体验，从而获取更直观的需求反馈。
需求分析需求分析是将所获取的需求进一步细化和规范，明确开发团队的工作任务和目标。
以下是需求分析的关键步骤：1. 需求整理：将需求分类整理，确保所有需求都被考虑到。
2. 需求明确：对需求进行进一步详细描述和说明，确保开发团队明确需求。
3. 需求优先级确定：根据项目目标和客户期望，确定需求的优先级，以便后续的任务分配。
4. 验证可行性：评估需求的可行性，包括技术可行性、资源可行性和成本可行性。
需求管理需求管理是软件开发过程中的重要环节，它确保需求的变更和控制，以满足客户的期望。
以下是需求管理的几个关键方面：1. 需求变更管理：建立明确的需求变更流程，确保需求变更的合理性和影响评估。
2. 需求跟踪：追踪需求的实现情况，及时发现和解决问题。
3. 需求回顾：定期回顾需求，确认其仍然适用于当前项目，并作出相应调整。
4. 需求文档管理：建立完善的需求文档管理系统，确保需求的及时更新和共享。
结论在软件开发过程中，需求分析与管理是确保软件项目成功的关键因素。
通过有效的需求获取、需求分析和需求管理，可以降低后期项目变更和风险，并最大程度地满足客户的需求和期望。
因此，软件开发团队应高度重视需求分析与管理，将其作为项目成功的关键步骤之一。
软件开发项目管理
计划是否落实 是
出访组团登记
否
结束
出访团组基本情况 登记表
否 否
护照登记表?
是否本单位人员 是
是否需要 办理护照
是 申请护照
护照管理
签证管理
chapter__４
结束
申请出国 护照事项表
护照卡?
申请出国 签证事项表?
58
本章要点
一、软件需求定义 二、软件需求管理过程 三、需求建模的基本方法
原型方法 结构化分析法 面向对象的用例分析法 功能列表法 其他
chapter__４
20
需求规格
需求分析工作完成的一个基本标志是形成 了一份完整的、规范的需求规格说明书
需求规格说明书的编制是为了使用户和软 件开发者双方对该软件的初始规定有一个 共同的理解，使之成为整个开发工作的基 础。
chapter__４
21
软件需求规格说明的原则
从现实中分离功能，即描述要“做什 么”而不是“怎样实现”
平均值
4.5 4.3 4.2 4.1 4.1 3.9 3.8
3.8 3.6 3.6
9
本章要点
一、软件需求定义 二、软件需求管理过程 三、需求建模的基本方法 四、案例分析
chapter__４
10
软件需求管理过程
软件需求管理的过程
需 求 需求获取 确 认
需求验证
需求分析 编写需求规格
需求变更
需求的隐含错误 需求不明确、含糊 用户不断增加需求、变更需求 用户刁难 开发人员的镀金
chapter__４
3
本章要点
一、软件需求定义 二、软件需求管理过程 三、需求建模的基本方法 四、案例分析
chapter__４
需求开发与管理过程
需求开发与管理过程XXXXXX有限公司--------------------------------------------------------------------- XXXXXX有限公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
文件更改摘要：目录1.目的 (3)2.适用范围 (3)3.术语和缩写 (3)4.职责 (3)5.入口准则 (4)6.输入 (4)7.过程流程图 (5)8.过程描述 (5)8.1.需求获取准备 (6)8.1.1.明确需要获取的信息 (6)8.1.2.明确所需获取信息的来源与渠道 (6)8.2.需求获取 (7)8.2.1.需求获取资料的保管 (9)8.3.整理用户需求 (9)8.4.需求分析 (10)8.4.1.结构化分析方法 (10)8.4.2.基于用例的分析方法 (11)8.5.需求定义 (12)8.5.1.标识需求 (12)8.5.2.定义需求的优先级 (12)8.5.3.编写《软件需求规格说明书》 (13)8.6.产品原型制作 (13)8.7.需求讲解及原型演示 (13)8.8.需求评审及确认 (13)8.9.需求管理 (14)8.9.1.需求变更 (14)8.9.2.需求变更申请 (14)8.9.3.需求变更评估 (14)8.9.4.需求变更的实施 (14)8.10.需求跟踪 (15)8.10.1.建立需求跟踪矩阵 (15)8.10.2.需求跟踪矩阵的维护与使用 (15)9.输出 (16)10.出口准则 (16)11.引用文档 (16)12.使用模板 (16)1.目的通过定义需求开发和管理过程，规范项目的需求开发和管理活动，提高需求质量，从而提高开发效率，降低开发成本，改进软件质量。
应调查用户的需求，通过需求分析工作将用户需求转化为产品需求，并评审需求的正确性，获得需求的承诺；应控制需求的变更，并确保项目工作产品与需求的一致性。
软件需求开发和需求管理
软件需求开发和需求管理需求开发与需求管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。
虽然如此，在项目开发工作中，很多人对需求的熟悉还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和把握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和需求管理工作。
本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。
1 什么是软件需求和需求工程1.1 软件需求的定义在IEEE软件工程标准词汇表(1997年)中定义软件需求为：（1）用户解决问题或达到目标所需的条件或能力。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。
实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。
1.2 需求工程的定义需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。
需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。
这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。
需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
目录第4章需求开发与需求管理 (3)4.1 什么是需求 (4)4.1.1基本概念 (4)4.1.2需求案例 (4)4.2 了解用户 (6)4.3 需求工程 (7)4.3.1基本概念 (7)4.3.2一些感悟 (8)4.4 需求开发的主要困难与对策 (9)4.4.1知识技能问题 (9)4.4.2态度问题 (10)4.4.3合作关系 (10)4.4.4用户说不清楚需求 (12)4.4.5双方误解需求 (12)4.4.6开发人员写不好需求文档 (13)4.4.7用户经常变更需求 (13)4.5 如何开展需求调查 (13)4.5.1需求调查规程 (13)4.5.2准备调查 (14)4.5.3调查与记录 (14)4.5.4撰写用户需求说明书 (15)4.6 如何进行需求分析 (17)4.6.1问答分析法 (17)4.6.2建模分析法 (17)4.6.2.1 结构化分析法 (18)4.6.2.2 面向对象分析法 (18)4.6.2.3 恰当地使用图形符号 (19)4.6.3作出决策 (19)4.7 什么是好的产品需求规格说明书 (20)4.7.1正确 (20)4.7.2清楚 (20)4.7.3无二义性 (20)4.7.4一致 (21)4.7.5必要 (21)4.7.6完备 (21)4.7.7可实现 (22)4.7.8可验证 (22)4.7.9确定优先级 (22)4.7.10阐述“做什么”而不是“怎么做” (23)4.8 如何定义产品需求 (23)4.8.1规程 (23)4.8.2软件需求规格说明书的模板 (24)4.9 需求确认 (26)4.9.1规程 (26)4.9.2需求评审 (26)4.9.3需求承诺 (28)4.10 需求跟踪 (29)4.11 需求变更控制 (30)4.12 CMMI对应规范 (32)4.12.1需求开发过程域的目标与实践 (32)4.12.2需求管理过程域的目标与实践 (33)4.13 需求建模工具 (33)4.14 需求管理工具 (34)4.15 应用示例 (34)4.15.1成功的示例 (34)4.15.2失败的示例 (34)4.16 小结 (34)第4章需求开发与需求管理我们把所有与需求直接相关的活动通称为需求工程。
需求工程是国内大学软件工程教育最薄弱的环节之一，这种教育模式下诞生的软件工程师会有这样的习惯：他们在开发产品时并不清楚究竟该做什么，但却在一直忙碌不停地开发。
这不是个别的荒唐现象，这差不多成了国内软件业的痼疾。
把责任推给学校显然无济于事。
不论你是学生还是职业软件工程师，如果你不懂需求工程，你就不可能把产品做好。
为了你的前途，你应该认真学习需求工程。
令人遗憾的是大多数软件工程教科书喜欢以学术的形式论述需求，大讲结构化分析或面向对象分析，并给出一堆模型和符号。
然而大部分开发人员首先要学习的是如何调查需求、如何写需求文档等基本技能。
需求工程是经典软件工程的核心内容，按理说早就研究得相当透彻了，奇怪的是人们就是学不好、用不好。
可见需求工程的研究者似乎并不清楚实践者的真正需求，真让人哭笑不得。
有个射击教练教出了不少神枪手，那些神枪手的枪法虽然很准，但老是打错人，有的甚至拿枪来自杀。
你能说射击教练教和神枪手们合格吗？基于我自己学习以及培训别人的心得体会，我准备以说理的方式论述需求工程，期望能减轻软件开发人员心头长久的痛。
4.1 什么是需求4.1.1 基本概念宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。
所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。
人们常问：“需求、设计、编程、测试四者究竟哪个重要？”这个问题不好回答。
四者都是软件开发过程中必不可少的环节，光做好其中一个环节并不能产生好的系统，但是做坏了其中任何一个环节，必定对系统产生坏影响。
若站在风险管理角度讲，我认为需求开发与管理是最重要的环节。
因为需求是产品的根源，需求工作的优劣对产品影响最大。
就像一条河流，如果源头被污染了，那么整条河流也就被污染了。
Frederick Brooks在他1987年的经典文章“No Silver Bullet”中阐述了需求的重要性：开发软件系统最困难的部分就是准确说明开发什么。
最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。
此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。
没有软件工程书籍不强调需求的重要性，也几乎没有软件开发人员不知道需求的重要性。
但是读过书并不表示就能够熟练掌握，需求工作说起来容易做起来难啊。
根据我的观察和切身体会，大部分软件开发人员并不知道如何把需求工作做好。
在我为本公司软件开发人员写需求工程培训教材时，恰好遇到公司里一群高智商的开发人员集体犯需求观念错误的事情。
我就把它写成案例，现炒现卖。
4.1.2 需求案例本公司是国内一家大型的电信设备供应商，本案例涉及6个机构A,B,C,D,E和F，它们之间的关系如图4-1所示。
故事是这样的：A和B都是公司的研发机构，B做核心平台的研发，A做增值业务的研发（我在A工作）。
C是公司的项目管理机构，负责立项、结项和研发经费管理。
D是公司的一个销售机构。
一年前，B研制了一种数据接入服务器的原型。
B对A讲：“我们的接入服务器前途很好，请你们帮助开发网管软件（属于增值业务范畴），大家合作把产品做好，一起发财。
”D对B和A讲：“你们把接入服务器和网管软件做好，我们负责卖，挣了钱大家一起分。
”A想了想觉得机会难得，于是向C申请立项。
立项后，A把该项目外包给一家专业做网管软件的公司E，期望半年内完成。
由于接入服务器是B的，于是A和E就派开发人员到B处搞需求分析。
B的接入服务器并不成熟，老在变，三方折腾了好久，最终E用了一年时间把接入服务器的网管软件做出来了。
E把网管软件交付给A，A付清了E的开发费用，再把网管软件交付给D，D再卖给客户F（某地电信局）。
F对D讲：“你们的网管软件不是我们想要的东西，等你们把软件改好后我们再付钱。
”D赶紧对A讲：“兄弟阿，货已经出手了，但是不对路，请赶紧把它改好，不然大家都没钱赚。
”A很愤怒，怨天不公：“我们辛苦了一年，又花了很多钱，可是产品做完了却没人要，岂有此理！”祸不单行的是，C来找A的麻烦：“你们的项目延期半年多了，经费也用光了，请尽快结束项目。
”A的那位项目经理为此每天愁眉苦脸，他的上司请来几位参谋商量对策（包括我在内），设法把事情搞定。
大家挖空心思只想出一个馊主意：既然套子是B下的，那么就把套子还给B。
要设法把“那么好”的网管产品转让给B，只要B能给我们成本费，以后就跟B拜拜。
图4-1 本案例6个机构的关系图读者听了这个故事肯定既迷糊又惊诧：“哇，大公司是这样开发产品的啊？”。
我也是在人家请我商量对策的时候，才知道有这样的事情。
问题的根源在于没有搞清楚网管软件的需求，这都是B,A,E闭门造车惹的祸。
三方开发团队里可是有不少的博士、硕士呐，可是他们集体犯了如此低级的错误。
最可悲的是，相关责任人关心的是如何把事情“搞定”，而不是深刻反思。
估计类似的事情还会继续发生，每发生一次就损失成百上千万元。
大公司再有钱也会给浪费光的。
讲了这个故事，我不免有所感叹：需求问题有时如同爱情问题，真是“当局者迷，旁观者清”啊。
我自己也是这么过来的，但愿以后不再犯类似的错误。
4.2 了解用户“用户”（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（the end user）和“间接用户”（或称为关系人）。
掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。
客户与最终用户可能是同一个人也可能不是同一个人。
如果软件是面向企业用户的，那么客户与最终用户通常不是同一个人。
如果软件是面向个人用户的，那么客户与最终用户通常是同一个人。
由于客户是掏钱买软件的人，所以他是“上帝”。
“现代营销学之父”菲利普•科特勒所著的《市场营销导论》是这样描述客户的：客户永远是本公司的座上客。
客户并不依赖我们，而我们却依赖客户。
客户不是我们工作的障碍，而是我们工作的目标。
我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。
客户不是我们要与之争辩和斗智的人。
从未有人曾在与客户的争辩中获胜。
客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。
[科特勒2001, p25]某饭店经理在解释“先有鸡还是先有蛋”这个哲学问题时，精辟地阐述了客户的地位：如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。
软件开发方与客户打交道的主要目的是：一是获取需求，二是签合同。
客户所说的需求一般比较宏观，更详细的需求应该从最终用户那里获取。
对于大宗买卖，软件开发方会把“上帝”侍侯得舒舒服服，想方设法拿到合同。
利益往往诱使人们搞不正之风，洽谈业务时少不了吃喝玩乐。
我有位在国内大型电信企业搞销售的朋友，几乎每周都出差，带一帮客户老爷们游山玩水。
这种做法差不多成了电信行业的“事实标准”。
羊毛出在羊身上，奢侈花费最终将摊到老百姓的头上。
为了避免被客户怀疑是在挖墙角，国内电信厂商一般不会招聘从电信局辞职的人，足见厂商对客户的“敬重”。
有不少客户精通业务，技术水平相当不错。
跟这些客户打交道，开发方千万别派出只会吹牛皮的“酒囊饭袋”之辈。
我曾听说有些项目负责人在竞标时，在技术方面竟然被客户反驳得哑口无言，着实丢脸。
如果项目规模比较大，那么开发方与最终用户的来往就比较多。
如从最终用户那里获取详细的需求，请最终用户试验软件，对最终用户进行培训等等。
即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。
有一次我们公司新员工上产品培训课，有位小领导匆匆赶来作指示：“隔壁班正在给电信局的员工们进行培训，他们都是上帝派来的，大家要注意形象。
由于休息室空间有限，请大家自觉让位。
午休时他们可以躺着睡，我们只能坐在位置上打个盹儿…….。
”除了客户和最终用户之外，软件开发方不能疏忽另一类用户——“间接用户”，千万别“大意失荆州”啊。
间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。
例如，财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。
否则即使该软件的功能是完美的，但却被政府认为是非法的。
所以国家财政部就是所有财务软件的间接用户，它不仅不付钱给财务软件开发商，反而要收取鉴定费、手续费等。
同理，市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则软件开发商被逮住后戴上“非法经营”的帽子就惨了。
4.3 需求工程4.3.1 基本概念我们把所有与需求直接相关的活动通称为需求工程。