需求工程.doc

第1章 需求问题
本章要点：
·需求是软件项目成败的关键所在
·越早发现需求错误，越早改正它，其
代价越小
·需求是系统必须具有的能力
·好的需求特征：无歧义、完整、一致、
可检验、确定的、可跟踪的、正确的、
可行的和必要的
·中国有句谚语：“好的开始就等于成
功的一半”；西方谚语是：“Garbage
in，garbage out！”两者都表明，从项
目一开始，就要有正确的用户需求
·1.1软件开发的目标：满足用户的需要
·1.2项目失败原因：(1)缺乏用户介入
(2)不完整的需求和规格说明
(3)不断改变的需求和规格说明
·项目成功的原因：(1)用户介入
(2)高层管理的支持
(3)需求陈述清晰
·1.3需求在项目中的作用：奠定了软件工程和项目管理的基础
·1.4需求错误的代价会随着项目的展开而发生变化。如果需求错误能够被及时的修复，那么其代价就会被限制在一定范围内。如果不能及时发现并修正需求错误，让它泄漏到其后的项目设计等阶段，那么修正成本会越来越高，只要原因是：面向需求的错误被发现的时候，开发小组已经投入了时间和精力对这些错误的需求进行设计。其结果是设计可能作废或者返工。另外，它也可能掩盖了错误的真是特征。
·可能会提高成本的几个方面：
重新进行需求规格说明、重新设计、
重新编码、重新测试、改变订单、纠
正活动、报废、收回有缺陷的软件产
品以及相关的用户手册、产品赔偿或
保修的成本、重新安装新版本的成
本、重新建档的成本
·1.5高质量的需求过程带来的好处：
简化软硬件的集成、确保软硬件系统
功能匹配适当、降低需求变更带来的
负面影响、有利于系统测试、确保产
品质量、使所有涉众感到满意
·1.6若干需求的定义：
IEEE软件工程标准词汇表(1997版)
(1)用户解决问题或达到目标所需的条件或能力
(2)系统或系统部件要满足合同、标
准、规范或其他正式规定文档所需
具有的条件或能力
(3)一种反应上面(1)或(2)所描述的条
件或能力的文档说明
一个包容且更为精炼的定义：
(1)用户解决某一问题或达到某一目
标所需的软件功能
(2)系统或系统构件为了满足合同、
规约、标准或其他正式实行的文档
而必须满足或具备额软件功能
·1.7好的需求应具有的特性：
概括为“内涵一致，外延完整”
具体：
一致性
全面性
1.7.1歧义因素
1.7.2完整性因素
1.7.3一致性因素
1.7.4可检验性因素
1.7.5确定性因素
1.7.6可跟踪性因素
1.7.7正确性因素
1.7.8可行性因素
1.7.9必要性因素

第2章 需求的层次
本章要点：
·需求是多层次的，包括业务需求、用
户需求、功能需求和非功能需求
·需求路线图：涉众需要→系统的特性
→建立软件需求
·软件需求包括不同的层次：业务需求、
用户需求、功能需求和非功能需求
业务需求反映了组织机构或客户对
系统、产品高层次的目标要
求，它们在项目前景文档中
予以说明
用户需求描述了用户使用产品必须
要完成的任务，这在用例文
档或方案脚本说明中予以
说明
功能需求定义了开发人员必须实现
的软件功能，使得用户能完
成他们的任务，从而满足了
业务需求。这些软件功能首
先表现为系统特性。功能需
求，连同其后说明的非功能
需求，在软件需求规格说明
中说明
非功能性的需求描述了系统展现给
用户的行为和执行的操作
等，它包括产品必须遵从的
标准、规范和约束，操作界
面的具体细节和构造上的
的限制
·2.1业务需求
·2.2用户需求
·2.3功能需求
·2.4非功能性需求
2.4.1可靠性
·影响可靠性的因素：
MTBF(平均无故障时间)
MTTR(平均修复时间)
即使出现故障，系统也能可靠运
行吗？
复制和故障转移的方案是什么？
系统故障时，需要手动干预，还
是系统可以自动进行故障转移？
系统的安全性如何？
实现可靠性会对性能造成负面影
响吗？
实现可靠性的成本有多高？
2.4.2可用性
2.4.3有效性
·有效性划分为性能和可伸缩性两个
子范围
2.4.4可维护性
2.4.5可移植性
2.4.6约束
·约束是指对开发人员在软件产品设
计和构造上的限制
·2.5需求路线图
·需求路线图反映了从用户需求到软件
需求的一般路径，即从问题领域转向
解决方案领域。具体路径可以表述为
涉众需要→系统的特征→建立软件需
求
·涉众的需要是新系统必须解决的业务
或运行问题的一个反映
·特性是系统为了完成涉众的一个或多
个需要而提供的服务
·特性附加属性用来在特性和其他项目
信息之间建立联系
·特性属性：
状态：跟踪项目基线定义及后续开发
的进程
优先级/效益：用于范围管理和确定
开发优先级。所有特性并非平
等的。根据特性的相对优先级
把它们划分等级
工作量：有助于建立符合实际的进
度、目标和开支预算。预测团
队的工作量等级，有助于对在
给定的时间范围内能完成什
么，不能完成什么建立预期
风险：对特性导致风险的预测，如成
本过高、进度延迟甚至项目被
取消等
稳定性：对特性出现变更的可能性的
预测，用于帮助建立开发优先
级，以及确定哪些是需要继续
启发的
目标发布：记录特性第一次出现的最
早产品版本
分配给：指出谁将负责实现特性
原因：用来跟踪所要求的特性来源

第3章 软件需求与产品生命周期
本章要点
·主要软件生命周期模型(瀑布模型、快速应用开发模型(RAD)、螺旋模型、RUP、迭代模型)的特点分析
·敏捷方法
·形式化方法
·如何选择生命周期模型
·3.1瀑布模型
·软件工程的线性顺序模型，有时也
称“传统生命周期”或“瀑布模型”
·瀑布模型提出了软件开发的系统化
的、顺序的方法，从系统需求开始，
随后是分析、设计、编码、测试和
维护。借鉴了传统的工程周期
·瀑布模型包含以下活动：
系统工程和建模
软件需求分析
设计
代码生成
测试
维护
·瀑布模型的优点：
客户很容易熟悉该模型
以有序的方式解决复杂的问题，
易于理解，目标简单——完成所
需要的活动
可以严格控制项目进程，使项目
管理易于实施
方便按阶段设置里程碑，便于项
目跟踪
定义了质量控制过程。运用该过
程来确定系统的质量
·瀑布模型的缺点：
它有内在的线性顺序
它不能准确反映软件开发中解决
问题的特点
它的状态和进展容易给人以错觉
最后集成造成较大的风险
他是文档驱动的，文档工作量非
常大
当瀑布模型必须面对范围管理的
挑战时，就显得力不从心了
实际的项目很少按照该模型给出
的顺序进行
用户常常难以清楚的给出所有需
求，而瀑布模型却要求如此
开发者常常被不必要地耽搁
·采用瀑布模型需要具备以下这些项
目特征：
在系统开发前需要对要求有完整、
全面、清晰的了解
上述需求不存在隐含的不可克服的
风险
需求变更不能过于频繁
不同渉众的需求互相兼容，不存在
明显的冲突
开发团队掌握了解决需求问题的有
效方法
开发期限允许分阶段的串行工作
·3.2快速应用开发模型(RAD)
·RAD方法包含如下几个阶段：
需求计划阶段
用户描述
构建阶段
结束
·RAD模型的优点列举如下：
采用高效率的开发工具，从而减少了整个产品的开发周期。提高了生产率，降低了成本
用户能够储蓄地参与开发，提高了用户参与程度，从而使用户的满意度上升，保证了系统能够满足用户的需要
工作重点从文档转为构建，所见即所得
·RAD模型的缺陷：
如果用户不能持续地参与整个生命周期中，最终产品会受到负面影响
要求系统能适当模块化，如果没有可重用的组件，它的效率就会下降
盲目应用时，会缺乏成本概念和项目完成的时间限制。项目有永远不能完结的风险
对于大型的但可伸缩的项目，RAD需要足够的人力资源以创建足够的RAD组
RAD要求承担必要的快速活动的开发者和用户在一个很短的时间框架下完成一个系统。如果两房中的任何一方没有完成约定，都会导致RAD项目失败
·以下几种情况时，项目可以采用RAD模型：
系统可模块化和可缩放
用户能参与到整个生命周期中
项目开发周期很短，通常约60天
项目团队熟悉问题领域，能熟练使用开发工具
·3.3螺旋模型
·螺旋模型每一次迭代包含以下6步：
(1)决定目标，替代方案和约束
(2)识别和解决项目和风险
(3)评估技术方案和替代方案
(4)开发本次迭代的交付物和验证迭代产生的正确性
(5)计划下一次迭代
(6)提交下一次迭代的步骤和方案
·螺旋模型的优点：
能够及时找到项目存在的风险，避免因为克服不了的困难而造成大的损失
使用户能够尽早讲信息经常反馈给开发人员，保证了产品的正确性和高质量
可以方便地评估和验证每次迭代的成果，实现从开发到维护的无缝连接
·螺旋模型的缺点：
如果项目本身是低风险的或者规模较小，采用该模型可能产生昂贵的成本。每一次螺旋结束后评估风险的时间及人工耗费都较大
模型本身比较复杂，开发人员和用户难于掌握
大量的中间阶段会产生额外的内外部文档
难以定义没个阶段的目标
·以下情形可采用螺旋模型：
适用于大型项目；更适用于内部开发
用于新功能、新产品或需要采用新技术时
收益不确定，项目不能确保成功时
用户不能确定其需求或需求很复杂时
·3.4 统一软件开发过程(RUP)
·RUP是一个面向对象且基于网络的程序开发方法论
3.4.1统一开发过程RUP的二维开发模型
3.4.2RUP的核心概念
·角色：描述某个人活着一个小组的行为与职责。RUP预先定义了很多角色
·活动：是一个有明确目的的独立工作单元
·工件：是活动生成、创建或修改的一段信息
3.4.3RUP中的各个阶段和里程碑：
(1)初始阶段 生命周期目标里程碑
(2)细化阶段 生命周期结构里程碑
(3)构造阶段 初始功能里程碑
(4)交付阶段 产品发布里程碑
3.4.4RUP的核心工作流
6个核心过程工作流：
(1)业务建模
(2)需求
(3)分析和设计
(4)实现
(5)测试
(6)部署
3个核心支持工作流：
(1)配置和变更管理
(2)项目管理
(3)环境
3.4.5RUP的裁剪
(1)确定本项目需要哪些工作流
(2)确定每个工作流需要哪些产品
(3)确定4个阶段之间如何演进
(4)确定没个阶段内的迭代计划
(5)规划工作流内部结构
3.4.6RUP的迭代开发模式
与传统的瀑布模型相比，迭代过程具有其自身的优点：
(1)降低了在一个增量上的开支风险
(2)降低了产品无法按照既定进度进入市场的风险
(3)加快了整个开发工作的进度
(4)迭代过程使适应需求的变化会更容易些
3.4.7RUP的6大经验
(1)迭代式开发
(2)管理需求
(3)基于组件的体系结构
(4)可视化建模
(5)验证软件质量
(6)控制软件变更
3.4.8RUP的十大要素
(1)开发一个前景
(2)达成计划
(3)标识和减小风险
(4)分配和跟踪任务
(5)检查商业理由
(6)设计组件构架
(7)对产品进行增量式的构建和测试
(8)验证和评价结果
(9)管理和控制变化
(10)提供用户支持
3.4.9RUP总结
RUP的长处：提高了团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模版和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，具有较大的通用性。
RUP的不足：RUP只是一个开发过程，并没有涵盖软件过程的全部内容。
·3.5 迭代式模型
3.5.1迭代
·迭代的定义：迭代包括产生产品发布(稳定、可执行产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。
3.5.2迭代方法在需求管理中的优势
·迭代方法的优点：
(1)更好的需求变化适应性
(2)更好的范围管理
3.5.3迭代模型与瀑布模型的差别：
迭代模型和瀑布模型的最大差别就在于风险的暴露时间上
3.5.4迭代方法常见的问题：
(1)过分详细的规划
(2)项目不收敛
(3)做起来再说
(4)回避棘手问题
(5)忘记新风险
(6)不同的小组按自己的进度进行工作
(7)第一次迭代做太多的事情
(8)太多的迭代
(9)迭代重叠
3.5.5应用迭代方法给分析人员带来的新思维
·3.6 敏捷方法
·敏捷方法的价值观：
(1)沟通
(2)简单
(3)反馈
(4)勇气
(5)谦逊
3.6.1敏捷方法遵循的原则：
(1)最优先要做的是尽早的、持续的交付有价值的软件来使客户满意
(2)即使到了开发的后期，也欢迎改变需求
(3)经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好
(4)在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
(5)围绕被激励起来的各题来构建项目
(6)在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交换
(7)工作的软件是首要的进度度量标准
(8)敏捷过程提倡可持续的开发速度
(9)不断地关注优秀的技能和好的设计会增强敏捷能力
(10)简单是最根本的
(11)最好的构架、需求和设计出自组织团队
(12)每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整
3.6.2敏捷开发与需求
3.6.3敏捷方法的适用条件和不适用条件
·敏捷方法的适用条件：
(1)软件开发采用了敏捷方法
(2)采用迭代增量式的开发方式
(3)需求不确定或不稳定
(4)开发软件是主要目标
(5)需要有项目渉众的积极支持和参与
(6)开发团队能够自我决策
(7)需要负责、主动的开发人员
(8)需要有足够的资源
·敏捷方法的不适用条件：
(1)现有组织文化适合采用传统的开发流程
(2)团队规模很大，分布在各地
(3)敏捷方法不适合应用于性命攸关的系统上
·3.7 形式化方法
3.7.1形式化方法的优缺点
支配形式化方法的基本概念：
(1)数据不变式
(2)状态
(3)操作
(4)离散数学
形式化方法的缺点：
(1)形式化模型的开发目前还很费时和昂贵
(2)因为很少有软件开发者具有使用形式化方法所需的背景知识，所以尚需多方面的培训
(3)难以使用该模型与用户进行交流沟通，因为几乎所有的用户对其一无所知
3.7.2形式化方法的十条戒律：
(1)应该选择适当的符号体系
(2)应该形式化，但不要过分形式化
(3)应该估计成本
(4)应该有随时可以请教的形式化方法顾问
(5)不应该放弃传统的开发方法
(6)应该建立详尽的文档
(7)不应该对质量标准做任何折中
(8)不应该教条化
(9)应该测试、测试、在测试
(10)应该复用
·3.8 关于选择生命周期模型的总结
书P53，P54

第4章 需求工程
本章要点：
·需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科
·完整的软件需求工程包括需求开发和需求管理两个部分，需求开发的一般过程分为需求获取、需求建模、需求规格说明、需求验证4个阶段，需求管理则主要包括需求基线的就爱努力、需求变更控制以及需求跟踪等活动
·需求过程被认为是建立软件系统最重要的方面之一。在项目中，它涵盖了与需求相关的所用活动
·需求工程的渉众
·需求工程方法大致分为4类：面向过程、面向数据、面向控制、面向对象
·面向对象的需求工作流包括：问题分析，理解渉众需要，定义系统，管理项目规模，改进系统定义
·软件需求过程的改进具有以下两个主要目标：解决在以前项目或目前项目中遇到的问题；防止和避免可能在将来的项目中要遇到的问题
·需求过程改进路线图
·4.1 什么是需求工程：
需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科
·4.2 需求工程的内容：
完整的软件需求工程包括需求开发和需求管理两个部分，需求开发的一般过程分为需求获取、需求建模、需求规格说明、需求验证4个阶段，需求管理则主要包括需求基线的建立、需求变更控制以及需求跟踪等活动
·4.3 需求工程过程
4.3.1Pressman的需求工程过程：
(1)导出需求
(2)需求分析和协商
(3)需求规范
(4)系统建模
(5)需求确认
(6)需求管理
4.3.2Boehm的需求工程过程
(1)确定重要的渉众
(2)确定满足渉众要求的条件
(3)确定满足要求的条件中的冲突因素
(4)协商满足各方面要求的高层协议
(5)列出互相满足要求的选项
(6)研究折中选项
(7)预期管理
(8)将达成的协议融入规格说明和计划中
(9)重复步骤1~8，直到产品完全开发完成
(10)面临和解决新的风险项目
·4.4 需求工程的渉众人员：
领域专家，最终用户，系统投资人，需求分析员，系统开发人员
·4.5 需求工程的方法：
面向过程、面向数据、面向控制、面向对象
·4.6面向对象的需求工程方法
·面向对象的需求分析的基本步骤
(1)与用户广泛接触，收集和查看相关资料，对问题域有一个大致的了解。在此基础上，提炼和标识对象
(2)描述对象（类）的属性
(3)描述对象之间的关系
(4)描述问题域的“场景”，即描述问题域中完成每个任务需要的对象间的协作关系
·Coad和Yourdon采用5个步骤来确定一个多层的面向对象模型，5个步骤分别对应模型的5个层次：
(1)找出类和对象——类和对象层
(2)定义属性——属性层
(3)识别结构与关系——结构层
(4)确定主题——主体层
(5)定义服务——服务层
·4.7 面向对象的需求工作流：
4.7.1问题分析
4.7.2理解渉众需要
4.7.3定义系统
4.7.4管理项目规模
4.7.5改进系统定义
·4.8需求过程的改进
·软件需求过程的改进具有以下两个主要目标
(1)解决在以前项目或目前项目中遇到的问题
(2)防止和避免可能在将来的项目中要遇到的问题
4.8.1需求与其他项目过程的联系：
(1)制定项目计划
(2)项目跟踪和控制
(3)变更控制
(4)系统测试过程
(5)编制用户文档
(6)构造过程
4.8.2软件需求对其他渉众的影响
4.8.3需求过程改进的基础
·4条改进软件的原则
(1)改进过程应该是革命性的、彻底的、连续的、反复的
(2)人们和组织机构都只有在他们获得激励时才愿意变更，而变更更可能会导致痛苦
(3)过程变更是面向目标的
(4)将改进活动看成是一些独立的小项目
4.8.4过程改进周期：
(1)评估当前采用的方法
(2)制定改进活动计划
(3)建立、实验和实施新的过程
(4)评估结果
(5)需求过程的积累材料
4.8.5需求过程改进路线图
书P73

第5章 需求获取的方法
本章要点：
·获取需求是一个确定和理解不同渉众的需要和约束过程
·获取需求的方法：面向目标，基于场景，面向方面，面向视点，基于知识
·需求描述语言可分为三种：非形式化、半形式化和形式化语言
·需求获取是需求工程的主题内容之一
·需求获取可定义为：渉众团体之间的相互沟通，识别需要的过程
·5.1 需求的获取方法：
5.1.1面向目标的方法
5.1.2基于场景的方法
5.1.3面向方面的方法
5.1.4面向视点的方法
5.1.5基于知识的方法
·5.2 需求描述语言：
非形式化、半形式化和形式化语言
·5.3 案例分析

第6章 寻找客户的需求
本章要点：
·了解用户需求的第一步是在有关问题的定义上和用户达成一致
·用户陈述的问题往往是表面现象，因此有必要和用户一起挖掘出问题背后的问题，即找出问题的根源，从而从根本上解决问题
·确定系统的渉众，除了开发团队和用户等直接渉众，还要找到间接的渉众
·系统边界确定了系统的内涵，即它究竟包括了哪些功能，可以解决哪些问题
·确定解决方案的约束条件
·6.1 在问题定义上达成共识
·6.2了解问题产生的根本原因
·用户陈述的问题往往是表面现象，因此有必要和用户一起挖掘出问题背后的问题，即找出问题的根源，从而从根本上解决问题
6.2.1鱼骨图——P82 83 84
6.2.2帕累托图
·6.3 确定涉众和用户
·渉众在软件开发项目中主要是指和这个项目有密切相关利益的人，他们共同感兴趣的就是需求分析阶段
·6.4 确定系统的界限
·6.5 确定解决方案的约束条件

第7章 理解用户的需要
本章要点：
·有效而直接的用户访谈技巧要求访谈者准备一个问题列表，目的是了解真实的问题和潜在的解决方案
·专题讨论会可以减少一部分需求冲突，绕开纷繁的情况得到需求列表，以此作为进一步分析的基础
·制作情节串连扳就是使用工具向用户说明系统如何适应组织的需要，并表明系统将如何运转。情节串连扳的类型包括被动式、主动式和交互式，其复杂度一次递增
·7.1 用户访谈
·用户访谈的5个阶段：
(1)准备访谈
(2)计划和安排访谈日程
(3)访谈开始和结束
(4)引导访谈
(5)后续的访谈整理工作
7.1.1准备访谈
(1)组织结构报告
(2)年度报告
(3)长期发展计划
(4)部门目标的尘世
(5)已有程序手册
(6)系统文档
7.1.2计划和安排访谈日程
7.1.3访谈开始和结束
7.1.4引导访谈
·在访谈中避免提封闭性问题
·封闭性问题的特点：
(1)限制了被访谈者提供信息的类型、层次和数量
(2)通常提供了二选一的回答
(3)暗示了较极端或不确定性的回答
(4)花费较少的时间得到细节信息
(5)比较容易做笔记
(6)有时只能得到很少的信息
(7)可能导致被访谈者无法自由提供信息
(8)对相关术语和词汇的要求高
·开放性问题的特点：
(1) 设计比较广，加在被访谈者上的约束很少
(2)用来确定理解范围
(3)可以得到被访谈者的行业词汇、概念和可参考的只是框架
(4)有助于增强理解，得到一些潜在的理论
·认真倾听的5个关键方法：
(1)询问开放性问题
(2)使用适当的表达
(3)暗示相信被访谈者
(4)重述被访谈者的回答
(5)有效的使用沉默
7.1.5调查问卷
·注意事项：
(1)使问卷表尽可能简短
(2)估计回答问题需要的时间，并在问卷表开头表明这个时间
(3)确保问题时前后一致的
(4)让与回答者关系密切的人员来进行问卷调查，并保证他们对问题的理解是正确的
(5)在指定问题前，先确定需要得到怎样的答案
(6)分别列出所有可能的答案
(7)一旦所有的需求核问题都准备好了，把需求点当作X轴，问题当作Y轴。确保所有的需求能被问题覆盖。最后，剔除与需求无关的问题
·7.2 专题讨论会
·在下列情况中使用：
(1)信息平均地分布在一小部分个人中
(2)无法个别地会见所有的渉众
(3)一系列的访谈已经结束，团队需要在共同环境中得到大家的响应
(4)一开始，明确说明集体讨论会议的目标
(5)尽可能提出更多的提议
(6)发挥想象力
(7)收集信息时，不允许出现批评或争论
(8)一旦信息收集完毕，对提议进行整理
·注意事项：
(1)提前确定会议地点
(2)事先公布会议议程
(3)如果可能，在会议开始时宣布一些希望大家遵守的基本准则
(4)牢牢控制讨论的话题，不要让讨论偏离主题
(5)如果这个会议是最终确定需求，而不是探寻需求，可采用原型演示的方法
(6)在小组讨论结束时，感谢大家抽出时间参与讨论，告诉大家整理确认需求的计划并传阅会议纪要
·7.3 情节串连扳
·制作情节串连扳就是使用工具向用户说明系统如何适应组织的需要，并表明系统将如何运转。情节串连扳的类型包括被动式、主动式和交互式，其复杂度一次递增

第8章 定义系统
本章要点：
·项目范围涉及三个要素：项目所要提交的功能、项目可用资源和实现项目可用的时间
·让客户满意并不意味这就要满足客户所有的需求
·建立的项目需求基线必须满足：至少对客户来说，是可以接受的；在开发团队看来，具有合理的成功可能性
·前景文档获取用户的需要、系统的特性以及项目的其他要求。它的范围跨越需求金字塔的上两级，在较高的抽象级别上定义问题和解决方案
·8.1 项目的范围问题
·项目范围涉及三个要素：项目所要提交的功能、项目可用资源和实现项目可用的时间
8.1.1项目可用资源
8.1.2项目开发时间
8.1.3系统功能、时间与资源
·8.2 客户要求的总比实际的多
·8.3 确立系统基线
·建立的项目需求基线必须满足：至少对客户来说，是可以接受的；在开发团队看来，具有合理的成功可能性
8.3.1设定优先级
8.3.2评估工作量
8.3.3加入风险因素
8.3.4缩小项目范围，确定基线
·8.4 建立项目前景文档
·前景文档获取用户的需要、系统的特性以及项目的其他要求。它的范围跨越需求金字塔的上两级，在较高的抽象级别上定义问题和解决方案

祝大家考试顺利！
——神装工作站。