IT项目管理之需求为准
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 现在我们知道了，什么会被加到出错报告 中，但是出错报告是个什么样子，则留由 设计人员决定。我们还指定了一个例外： 如果没有发现错误，不产生错误报告。
需求规格评审实例
练习：以下描述哪些属于不精确的用户需求描述
？如果不精确，应如何改正？
1）系统应表现出良好的响应速度。 不精确，应指出具体项目和响应时间。
由于需求未能得到有效管理， 在最终 项目验收过程中出现了令人不愉快的情况 ，实际开发的软件没能完全反映用户的需 求，导致用户不满意，项目延期。
如何进行需求评审
参与需求分析和评审的人员的管理 软件需求文档的管理 需求分析过程的管理 需求变更的管理
需求规格评审实例
• 例1：“产品应在不少于每秒的正 常周期内提供状态信息。”
第二部分
IT项目管理之需求为准
需求工程
需求获取 需求分析 文档编写 需求验证
需求状态 需求跟踪 版本控制 需求变更
基础认知
需求相关概念剖析
需求的重要性
需求是业务的根源，需求工作的优劣对业务影响最大。就像一 条河流，如果源头被污染了，那么整条河流也就被污染了。
需求是缺陷主要来源
错误引入阶段分析
Re q u ir e m en ts 56%
D esi g n 27%
James Martin：
超过50%的缺陷由不完善的、不正 确的、不准确的和/或不明确的需求 所引起
Code 7%
O ther 10%
James Martin：
80%以上的用于定位业务错误的费 用是基于业务系统需求定义的错误
错误定位费用分析
需求规格评审实例
• 例2：“产品应瞬间在文本中的显示和 隐藏不可打印字符间切换”
计算机在瞬间不能做任何事，所以这个需求 不切实可行。它的不完整性表现在没有声明触发 状态切换的条件。软件要在某些条件下更改自己 ？或者用户为了模仿更改要做一些什么动作？而 且，在文档中改变显示的范围是多大：选中的文 本？整个的文档，或其他的？这也是个模模糊的 问题。不可打印字符和隐藏字符一样吗？或者是 一些属性标志或一些控制字符？问题的后果，就 是需求的不可证实。
《立项报告》、《可行性分析报告》、《标 书》
需求分析在工程中的位置
业务
用户/系统
管理者
初始需求
获取,分 析,定义, 验证需求
需求规格说明
需求开发
变更的需求
控制需求 变更
项目 环境
需求管理
需求工程活动综合关系
需求管理的最终作用
需求管理的目的是在用户与开发方之间建 立对需求的共同理解，维护需求与工作成 果的一致性，并控制需求的变更。
Requirements 82%
Design 13%
Other Code 4% 1%
一个小故事
如何练就需求分析的火眼金晴？
• 5W + 1H + 8C • 5W就是 Who、When、Where、What、Why • Why是关键 • 1H就是 How – 需求本身的流程 • 8C指的是8个约束和限制，即8个Constraints： • 包括性能Performance、成本Cost、时间Time、可
在功能实现过程、方法和技术要求的描述上，是否背离了功能的实际要求 是否有不能理解或造成误解的描述 是否有一个内容表格，该表格包含了所有需求描述 是否所有的图形、表格都进行了标号 是否所有的需求项都进行了标号，并提供了索引 是否所有需求可以被定义的更细致，或简单 对于不清晰的信息是否进行了指出 是否存在有需求让你不舒服 是否所有与需求相关的设计约束都包含了 是否所有与需求相关的性能都包含了 是否所有与需求相关的属性都包含了 是否所有与需求相关的外部接口都包含了 是否所有与需求相关的通信都被包含了 是否所有与需求相关的硬件都被包含了 是否所有与需求相关的数据库都被包含了 是否所有与需求相关的软件都被包含了 是否所有与需求相关的输入和输出都被包含了 是否所有与需求相关的安装特性都被包含了 是否所有与需求相关的维护特性都被包含了 是否所有与需求相关的安全特性都被包含了 所有对其他需求的内部交叉引用是否正确 所有需求的编写在细节上是否都一致或者合适 需求是否能为设计提供足够的基础 是否包括了每个需求的实现优先级 需求定义是否包含了有关文件(指质量手册、质量计划以及其他有关文件)中 所规定的需求定义所应该包含的所有内容 需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求 功能需求是否覆盖了所有非正式情况的处理 是否对各种操作模式(如正常、非正常、有干扰等)下的环境条件都作了规定 是否对所有功能与时间因素有关的方面都作了考虑 是否标识出了所有与时间因素有关的功能？它们的时间准则是否都说明了？ 时间准则的最大、最小执行时间是否都定义了 是否标识并定义了在将来可能会变化的需求 是否定义了系统所有的输入 是否标识清楚了系统输入的来源 是否标识出了系统的输出 是否说明了系统输入、输出的值域、单位、格式等 是否说明了如何进行系统输入的合法性检查 是否定义了系统输入、输出的精度 是否定义了系统性能的各个方面 在不同负载情况下，是否规定了系统的生产率 在不同情况下，是否规定了系统的响应时间 是否充分定义了有关人机界面的需求 是否对需求定义进行了可行性分析和相关文件(资料)是否已归档 是否对影响需求实现的因素进行了调查、调查结果是否已归档
2、为需求写测试用例
• 目标是识别需求的含混性
1. 以需求为基础，并视其为黑盒子，然后编写测 试用例。
2. 要覆盖需求常见的测试点
• 入口条件 • 出口条件 • 主事件流 • 可选事件流 • 非功能需求
3、用检查单识别常见问题
需求特性 清晰性/无二义性
完整性
需求评审检查表
检查内容
所有定义、实现方法是否清楚地表达ຫໍສະໝຸດ 用户的原要求初步可行性研究
详细可行性研究
（1）可行性分析报告 模版
2.项目立项
立项管理过程
建设方的立项管理
承建方的立项管理
（1）某大型集团IT项目 实施管理方法
（2）金蝶公司可行性 分析报告
（2）校务通模型
合同项目立项过程
1.甲方过程
招标书定义、乙方选择、合同签署
2.乙方过程
项目分析、竞标、合同签署
3.相关文档
需求规格评审实例
例2需求：
• 用户能够在一个由特定触发条件激活处于 编辑的文档中在显示和隐藏所有HTML标记 间切换。
• 现在就很清楚，不可打印字符是HTML标记 。由于没有定义触发条件，需求对设计没 有约束力。只有设计人员选定了触发条件 后，你才能编写测试验证触发的正确操作 。
需求规格评审实例
包括：需求确认、需求变更控制、需求跟踪
1、需求确认 需求确认是指开发方和用户共同对需求文档进行评审， 双方对需求达成共识后做出书面承诺，使需求文档具有 商业合同效果。
一、需求确认
项目开发面临的实际问题
项目开发面临的实际问题
项目开发面临的实际问题
需求验证的目的和任务
需求验证的目的就是要确保软件需求具有良 好的特性（如完整性，正确性等）。 需求验证包含的活动
如何设定需求的优先级
• 基于价值、费用和风险的优先级设定
1) 费用方法（Cost）： 最小费用优先原则 2) 价值方法（Value）： 最高价值优先原则 3) 风险方法（Risk）： 最低风险优先原则
它们本质上从单一视角探寻适用标准来评价 每个需求，并且计算出一个分值用于编排需求的 优先级。
基于价值、费用和风险的优先级设定
• 例3：“HTML分析器可以产生HTML标记 错误报告，帮助HTML入门者快速解决 错误”。
• 单词“快速”使其模糊，没有加进错误报 告的定义也是不完整的。我不知道，你怎 么验证这个需求。找一个自称为HTML的入 门者，看看能不能根据错误报告快速解决 错误？
需求规格评审实例
例3需求：
• “HTML分析器可以产生一个错误报告，错 误报告包含有在被分析文件中出错的HTML 文本和行号以及错误的描述。如果没有错 误，就不会产生错误报告”。
2）系统必须用菜单驱动。 “必须”不精确，因系统还可以用其他方式驱动
。 3）在数据录入界面，应该有10个按钮。 不精确，因过于细致，限制了设计的自由度。 4）系统运行时占用的内存不得超过200M。 仅是一个约束条件。 5）电梯应平稳运行。 不精确，应指出加速、减速、运行速度的大小。 6）即使系统崩溃，也不能损坏用户数据。 不精确，因这是一个难以保证的“用户需求”。
靠性Reliability、安全性Security、合规性 Compliance、技术性Technology、兼容性 Compatibility
如何建立组织级需求工程？
专业的角色做 专业的事？
专业的人做专 业的事？
需求工程贯穿开发全过程
•质量属性 •DFX
•书面标准 •事实标准
•功能需求 •非功能需求
• 分析：这个需求是不完整的：
•
状态信息是什么，如何显示给用户。这个需
求有几处含糊。我们在谈论产品的哪部分？状态
信息间隔真的假定为不少于秒？，甚者每10年显
示一条新的状态信息也可以？也许它的意图是消
息间隔不应超过秒，那么1毫秒是不是太短？“每
”这个词导致了不确定性。问题的后果，就是需
求的不可证实。
需求规格评审实例
需求存在什么问题
• 不是“大而全”，而是“准而精”；镀金.swf • 不是“热点组合”，而是“关键点组合”； • 不是“盲目跟风”，而是“为我所用”； • 不是“形成报告”，而是“达成共识”。 • CRUDL
Create-Read-Update-Delete-List
可研与立项
1.可行性研究
项目的机会选择
–满足性（功能需求是否满足需要） –满意性（非功能需求是否满意）
–明确及含蓄的需求(失败)、(成功)
–共识行（是否能共同理解） –可行性（技术是否可行） –明晰性（信息是否存在含混性）
1、为需求进行正式评审
• 正式的审查过程
需求评审做不好的后果：
需求变更 需求不明确 需求不可测 需求不可实现 导致后续工作难于开展或经常出现变更
例1需求：
• 后台任务管理器因以误差上下不超过10秒的秒间 隔，在用户界面的指定位置显示状态信息；
• 如果后台进程处理正常，那么应该显示任务已完 成的百分数/比；
• 任务完成时，应显示相关的信息； • 后台任务出错应该显示错误信息； • 为了测试和追踪，将需求分解多个子需求。使在
构造和测试时，被易于分别执行。
相对权值
需求/特性
XX
X
X
相对利 相对损 总价 价值% 相对费 费用% 相对风 风险% 优先
润失
值
用
险
级
1. XXXXX
X
X
XX XX% X
XX% X
XX% XXX
开发者应该要估计出与每个特性相关的技术或风险相对程度，并利用 在一1 个~ 平9划面分中等列级出。要设定优先级的所有需求、特性或使用实例；在这个 n总例所起实这么需估给使重.计估代这利在改X子有。现种就要计客用损1行技平损值如X计表些益缺这X级中项如特模把的出户1失性术面失。果X根的估平每可利的省两X表~，都果性型相话优如或。、。图，你据计面潜一忽益最情个示9我必某在关，B先果业缺将费无需实图在个略等佳况因划）你们须些其的可级没务乏计用需能求现将特的级人下素分那可将在特有特以＝有上具算和在力的每计性利表选，的等么以使同性效性在把带有出风模、复个算提益明。利相级总在轻用一有范归更应来专每险型所杂特出供，了润对，价分而特抽逻围成详该的门个的中（需度性由给 与 和 权9这值析易性 象 辑 内 一 细实损代知 特 权 考费要，的每客 产 损 值里＝中举类来 级 上 可 的现失表识 性 值 虑用的所 相 一X品户 失 。1相只地，设 别 的 以 级的。最代所的 是 风%测需 对 个价的或 的对要实并定 上 联 容 别特×大表产人 相 险试求 费 特值业业 权利列现X建优 ； 系 纳 上性费的基生员 等 ，量的 用 性%务务 值润出价编立先 不 （ 几 进包用价本的， 的 就和用 ， 所=需的 是＋驱值程总一级 要 例 十 行括权值无风或 ， 把文户 使 构求相 相相X动%，价个。 把 如 种 第到X值。损险者 但 风档界 用 成的关 等对特而值可个 ， 特 二产）百使 是 险失等面 的1一利 的损X性9（/管人 只 性 轮品＋，分用 你 的X等的 总级致益 ，失总%就低理需 有 。 分中（比不 可 权，实 费表9性， 作计可）的求 包 如 析，X代风。成 以 值开现 用示。并 为价以~初与 括 果 。将表险在熟 在 设发情 的需客用一值了9始产特你会严%缺或 平 为者况百（要X户种1×。X×化品性有省不面0可、分高极~%代精1。风列特更A情熟图0以重比9）大表化的0X划险表性多况悉中估用。划地是，情分权。混的下的调算当分关判你况等值如合项，工整出前X等注断可下X级）果在，利具其费代%级其这以才，你一那润和权用码。可些更X能1X。X
4、为需求设定优先级
• 支持项目分期交付 • 支持需求取舍之道 • 支持需求的模式化
为什么要设定需求的优先级
➢软件开发受时间、成本、质量等多种资源 的限制，同时软件开发的高不确定性，导 致 需求在项目结束时往往难以被全部实现。
➢因此需要在需求开发阶段，对需求进行分 解，设定优先级，先实现优先级别较高的 需求，有助于维护项目收益和提高项目成 功率。
需求规格评审实例
练习：以下描述哪些属于不精确的用户需求描述
？如果不精确，应如何改正？
1）系统应表现出良好的响应速度。 不精确，应指出具体项目和响应时间。
由于需求未能得到有效管理， 在最终 项目验收过程中出现了令人不愉快的情况 ，实际开发的软件没能完全反映用户的需 求，导致用户不满意，项目延期。
如何进行需求评审
参与需求分析和评审的人员的管理 软件需求文档的管理 需求分析过程的管理 需求变更的管理
需求规格评审实例
• 例1：“产品应在不少于每秒的正 常周期内提供状态信息。”
第二部分
IT项目管理之需求为准
需求工程
需求获取 需求分析 文档编写 需求验证
需求状态 需求跟踪 版本控制 需求变更
基础认知
需求相关概念剖析
需求的重要性
需求是业务的根源，需求工作的优劣对业务影响最大。就像一 条河流，如果源头被污染了，那么整条河流也就被污染了。
需求是缺陷主要来源
错误引入阶段分析
Re q u ir e m en ts 56%
D esi g n 27%
James Martin：
超过50%的缺陷由不完善的、不正 确的、不准确的和/或不明确的需求 所引起
Code 7%
O ther 10%
James Martin：
80%以上的用于定位业务错误的费 用是基于业务系统需求定义的错误
错误定位费用分析
需求规格评审实例
• 例2：“产品应瞬间在文本中的显示和 隐藏不可打印字符间切换”
计算机在瞬间不能做任何事，所以这个需求 不切实可行。它的不完整性表现在没有声明触发 状态切换的条件。软件要在某些条件下更改自己 ？或者用户为了模仿更改要做一些什么动作？而 且，在文档中改变显示的范围是多大：选中的文 本？整个的文档，或其他的？这也是个模模糊的 问题。不可打印字符和隐藏字符一样吗？或者是 一些属性标志或一些控制字符？问题的后果，就 是需求的不可证实。
《立项报告》、《可行性分析报告》、《标 书》
需求分析在工程中的位置
业务
用户/系统
管理者
初始需求
获取,分 析,定义, 验证需求
需求规格说明
需求开发
变更的需求
控制需求 变更
项目 环境
需求管理
需求工程活动综合关系
需求管理的最终作用
需求管理的目的是在用户与开发方之间建 立对需求的共同理解，维护需求与工作成 果的一致性，并控制需求的变更。
Requirements 82%
Design 13%
Other Code 4% 1%
一个小故事
如何练就需求分析的火眼金晴？
• 5W + 1H + 8C • 5W就是 Who、When、Where、What、Why • Why是关键 • 1H就是 How – 需求本身的流程 • 8C指的是8个约束和限制，即8个Constraints： • 包括性能Performance、成本Cost、时间Time、可
在功能实现过程、方法和技术要求的描述上，是否背离了功能的实际要求 是否有不能理解或造成误解的描述 是否有一个内容表格，该表格包含了所有需求描述 是否所有的图形、表格都进行了标号 是否所有的需求项都进行了标号，并提供了索引 是否所有需求可以被定义的更细致，或简单 对于不清晰的信息是否进行了指出 是否存在有需求让你不舒服 是否所有与需求相关的设计约束都包含了 是否所有与需求相关的性能都包含了 是否所有与需求相关的属性都包含了 是否所有与需求相关的外部接口都包含了 是否所有与需求相关的通信都被包含了 是否所有与需求相关的硬件都被包含了 是否所有与需求相关的数据库都被包含了 是否所有与需求相关的软件都被包含了 是否所有与需求相关的输入和输出都被包含了 是否所有与需求相关的安装特性都被包含了 是否所有与需求相关的维护特性都被包含了 是否所有与需求相关的安全特性都被包含了 所有对其他需求的内部交叉引用是否正确 所有需求的编写在细节上是否都一致或者合适 需求是否能为设计提供足够的基础 是否包括了每个需求的实现优先级 需求定义是否包含了有关文件(指质量手册、质量计划以及其他有关文件)中 所规定的需求定义所应该包含的所有内容 需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求 功能需求是否覆盖了所有非正式情况的处理 是否对各种操作模式(如正常、非正常、有干扰等)下的环境条件都作了规定 是否对所有功能与时间因素有关的方面都作了考虑 是否标识出了所有与时间因素有关的功能？它们的时间准则是否都说明了？ 时间准则的最大、最小执行时间是否都定义了 是否标识并定义了在将来可能会变化的需求 是否定义了系统所有的输入 是否标识清楚了系统输入的来源 是否标识出了系统的输出 是否说明了系统输入、输出的值域、单位、格式等 是否说明了如何进行系统输入的合法性检查 是否定义了系统输入、输出的精度 是否定义了系统性能的各个方面 在不同负载情况下，是否规定了系统的生产率 在不同情况下，是否规定了系统的响应时间 是否充分定义了有关人机界面的需求 是否对需求定义进行了可行性分析和相关文件(资料)是否已归档 是否对影响需求实现的因素进行了调查、调查结果是否已归档
2、为需求写测试用例
• 目标是识别需求的含混性
1. 以需求为基础，并视其为黑盒子，然后编写测 试用例。
2. 要覆盖需求常见的测试点
• 入口条件 • 出口条件 • 主事件流 • 可选事件流 • 非功能需求
3、用检查单识别常见问题
需求特性 清晰性/无二义性
完整性
需求评审检查表
检查内容
所有定义、实现方法是否清楚地表达ຫໍສະໝຸດ 用户的原要求初步可行性研究
详细可行性研究
（1）可行性分析报告 模版
2.项目立项
立项管理过程
建设方的立项管理
承建方的立项管理
（1）某大型集团IT项目 实施管理方法
（2）金蝶公司可行性 分析报告
（2）校务通模型
合同项目立项过程
1.甲方过程
招标书定义、乙方选择、合同签署
2.乙方过程
项目分析、竞标、合同签署
3.相关文档
需求规格评审实例
例2需求：
• 用户能够在一个由特定触发条件激活处于 编辑的文档中在显示和隐藏所有HTML标记 间切换。
• 现在就很清楚，不可打印字符是HTML标记 。由于没有定义触发条件，需求对设计没 有约束力。只有设计人员选定了触发条件 后，你才能编写测试验证触发的正确操作 。
需求规格评审实例
包括：需求确认、需求变更控制、需求跟踪
1、需求确认 需求确认是指开发方和用户共同对需求文档进行评审， 双方对需求达成共识后做出书面承诺，使需求文档具有 商业合同效果。
一、需求确认
项目开发面临的实际问题
项目开发面临的实际问题
项目开发面临的实际问题
需求验证的目的和任务
需求验证的目的就是要确保软件需求具有良 好的特性（如完整性，正确性等）。 需求验证包含的活动
如何设定需求的优先级
• 基于价值、费用和风险的优先级设定
1) 费用方法（Cost）： 最小费用优先原则 2) 价值方法（Value）： 最高价值优先原则 3) 风险方法（Risk）： 最低风险优先原则
它们本质上从单一视角探寻适用标准来评价 每个需求，并且计算出一个分值用于编排需求的 优先级。
基于价值、费用和风险的优先级设定
• 例3：“HTML分析器可以产生HTML标记 错误报告，帮助HTML入门者快速解决 错误”。
• 单词“快速”使其模糊，没有加进错误报 告的定义也是不完整的。我不知道，你怎 么验证这个需求。找一个自称为HTML的入 门者，看看能不能根据错误报告快速解决 错误？
需求规格评审实例
例3需求：
• “HTML分析器可以产生一个错误报告，错 误报告包含有在被分析文件中出错的HTML 文本和行号以及错误的描述。如果没有错 误，就不会产生错误报告”。
2）系统必须用菜单驱动。 “必须”不精确，因系统还可以用其他方式驱动
。 3）在数据录入界面，应该有10个按钮。 不精确，因过于细致，限制了设计的自由度。 4）系统运行时占用的内存不得超过200M。 仅是一个约束条件。 5）电梯应平稳运行。 不精确，应指出加速、减速、运行速度的大小。 6）即使系统崩溃，也不能损坏用户数据。 不精确，因这是一个难以保证的“用户需求”。
靠性Reliability、安全性Security、合规性 Compliance、技术性Technology、兼容性 Compatibility
如何建立组织级需求工程？
专业的角色做 专业的事？
专业的人做专 业的事？
需求工程贯穿开发全过程
•质量属性 •DFX
•书面标准 •事实标准
•功能需求 •非功能需求
• 分析：这个需求是不完整的：
•
状态信息是什么，如何显示给用户。这个需
求有几处含糊。我们在谈论产品的哪部分？状态
信息间隔真的假定为不少于秒？，甚者每10年显
示一条新的状态信息也可以？也许它的意图是消
息间隔不应超过秒，那么1毫秒是不是太短？“每
”这个词导致了不确定性。问题的后果，就是需
求的不可证实。
需求规格评审实例
需求存在什么问题
• 不是“大而全”，而是“准而精”；镀金.swf • 不是“热点组合”，而是“关键点组合”； • 不是“盲目跟风”，而是“为我所用”； • 不是“形成报告”，而是“达成共识”。 • CRUDL
Create-Read-Update-Delete-List
可研与立项
1.可行性研究
项目的机会选择
–满足性（功能需求是否满足需要） –满意性（非功能需求是否满意）
–明确及含蓄的需求(失败)、(成功)
–共识行（是否能共同理解） –可行性（技术是否可行） –明晰性（信息是否存在含混性）
1、为需求进行正式评审
• 正式的审查过程
需求评审做不好的后果：
需求变更 需求不明确 需求不可测 需求不可实现 导致后续工作难于开展或经常出现变更
例1需求：
• 后台任务管理器因以误差上下不超过10秒的秒间 隔，在用户界面的指定位置显示状态信息；
• 如果后台进程处理正常，那么应该显示任务已完 成的百分数/比；
• 任务完成时，应显示相关的信息； • 后台任务出错应该显示错误信息； • 为了测试和追踪，将需求分解多个子需求。使在
构造和测试时，被易于分别执行。
相对权值
需求/特性
XX
X
X
相对利 相对损 总价 价值% 相对费 费用% 相对风 风险% 优先
润失
值
用
险
级
1. XXXXX
X
X
XX XX% X
XX% X
XX% XXX
开发者应该要估计出与每个特性相关的技术或风险相对程度，并利用 在一1 个~ 平9划面分中等列级出。要设定优先级的所有需求、特性或使用实例；在这个 n总例所起实这么需估给使重.计估代这利在改X子有。现种就要计客用损1行技平损值如X计表些益缺这X级中项如特模把的出户1失性术面失。果X根的估平每可利的省两X表~，都果性型相话优如或。、。图，你据计面潜一忽益最情个示9我必某在关，B先果业缺将费无需实图在个略等佳况因划）你们须些其的可级没务乏计用需能求现将特的级人下素分那可将在特有特以＝有上具算和在力的每计性利表选，的等么以使同性效性在把带有出风模、复个算提益明。利相级总在轻用一有范归更应来专每险型所杂特出供，了润对，价分而特抽逻围成详该的门个的中（需度性由给 与 和 权9这值析易性 象 辑 内 一 细实损代知 特 权 考费要，的每客 产 损 值里＝中举类来 级 上 可 的现失表识 性 值 虑用的所 相 一X品户 失 。1相只地，设 别 的 以 级的。最代所的 是 风%测需 对 个价的或 的对要实并定 上 联 容 别特×大表产人 相 险试求 费 特值业业 权利列现X建优 ； 系 纳 上性费的基生员 等 ，量的 用 性%务务 值润出价编立先 不 （ 几 进包用价本的， 的 就和用 ， 所=需的 是＋驱值程总一级 要 例 十 行括权值无风或 ， 把文户 使 构求相 相相X动%，价个。 把 如 种 第到X值。损险者 但 风档界 用 成的关 等对特而值可个 ， 特 二产）百使 是 险失等面 的1一利 的损X性9（/管人 只 性 轮品＋，分用 你 的X等的 总级致益 ，失总%就低理需 有 。 分中（比不 可 权，实 费表9性， 作计可）的求 包 如 析，X代风。成 以 值开现 用示。并 为价以~初与 括 果 。将表险在熟 在 设发情 的需客用一值了9始产特你会严%缺或 平 为者况百（要X户种1×。X×化品性有省不面0可、分高极~%代精1。风列特更A情熟图0以重比9）大表化的0X划险表性多况悉中估用。划地是，情分权。混的下的调算当分关判你况等值如合项，工整出前X等注断可下X级）果在，利具其费代%级其这以才，你一那润和权用码。可些更X能1X。X
4、为需求设定优先级
• 支持项目分期交付 • 支持需求取舍之道 • 支持需求的模式化
为什么要设定需求的优先级
➢软件开发受时间、成本、质量等多种资源 的限制，同时软件开发的高不确定性，导 致 需求在项目结束时往往难以被全部实现。
➢因此需要在需求开发阶段，对需求进行分 解，设定优先级，先实现优先级别较高的 需求，有助于维护项目收益和提高项目成 功率。