需求
在IEEE软件工程标准词汇表(1997年)中定义软件需求为：
（1）用户解决问题或达到目标所需的条件或能力。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
（3）一种反映上面(1)或(2)所描述的条件或能力的文档说明
宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。
需求开发
的目的是通过调查和分析，获取用户需求并定义产品需求。
需求调查
的目的是通过各种途径获取用户的需求信息(原始材料)，产生<<用户需求说明书>>。
需求分析
的目的是对各种需求信息进行分析，消除错误，刻画细节等。
需求定义
的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生<<产品需求规格说明书>>，以便开展系统设计工作。
需求管理
的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
需求确认
是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。
需求跟踪
是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
需求变更控制
是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
CMMI2级——需求管理 （第二个大题，考需求描述）
目的：
管理项目的“产品需求和构件需求”，以及识别这些需求与项目计划、工作成果的不一致之处
需求管理是管理一个过程或一个组与别的过程或组间的需求传递，并且追踪工作产品和需求的完整性---->需求管理两件大事！
把需求定下来
把需求控制起来
特定目标和特定实践
------SP1.1获得对需求的理解------
获得开发者和提供者对需求的共同理解
实现时注意事项：
重点是与用户的沟通
识别用户------建立识别需求提供者的标准
以有效的载体沟通需求------清晰准确、完整一致、唯一标识、能够实现
对需求的接受建立客观的标准------缺乏需求的验收标准通常会导致验证不充分、返工或客户拒收
典型成果
用于识别“合适的需求提供者”的需求
评价和接受需求的准则
依照准则进行分析的结果
达成共识的需求集合
------需求承诺------
指开发方和客户方的责任人对通过了正式技术评审的《产品需求规格说明书》作出承诺，该承诺具有商业合同的效果。
需求承诺的“八股文”如下：
本《产品需求规格说明书》建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该《产品需求规格说明书》开展。如果需求发生变化，我们将按照“变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。
甲方签字乙方签字
人们在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么
------SP1.2获得对需求的承诺------
取得项目参与者对需求的承诺
实现时注意事项：
重点在开发团队内部
可实现性评估
确定需求优先级
评估可能的变更及其处理方式
强调：依然需要良好的沟通载体
典型成果
需求影响的评估
记录“需求和需求变化”的承诺
------SP1.3管理需求变更------
管理需求变更
典型成果
需求的状态记录
需求数据库
需求决策数据库
------需求变更原因分析------
需求发生变更的起因主要有：
1.随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。
2.市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。
提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。
对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。
如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。
------需求变更的控制思路------
需求变更控制的目的
如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。如果需求变更带来的坏处大于好处，那么拒绝变更。
需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境
解决这个问题最好的办法是事先建立“游戏规则”：
开发方与客户方达成“事不过三”的约定（符合中国人的习惯），即允许客户变更三次需求；如果客户第四此变更需求，开发方有权拒绝，除非客户愿意补偿开发方的损失。
如果事先没有“游戏规则”的话，开发方需要一些社交技巧来减缓矛盾。例如建议在开发该产品新版本时修改需求
------需求变更管理相关活动------
需求变更管理主要通过以下的活动来实现：
确定需求变更控制过程
建立需求变更控制委员会
进行需求变更影响分析
跟踪所有受需求变更影响的工作产品
调整需求基线
维护需求变更记录和文档
------需求变更流程------
------SP1.4维护需求的双向可追溯性------
典型成果
需求跟踪矩阵
------需求状态------
在整个生命期需求的可能状态
被建议，根据需求的来源，责任人和相关人提出了需求
被拒绝，在一系列需求开发过程后，该需求没有被认可
被批准，在需求（特别是变更需求）被分析后，评估了合理性、可行性、成本、影响等要素，被确认可接受，被标注了新的版本号、给出了新的标号等属性，被加入到需求基线库中，进入实现过程
被实现，已实现设计、编码、单元测试
被验证，根据验收标准，已经通过集成以上的测试，被验证实现了需求的要求，被放置进配置基线库，表明需求已经被实现
被丢弃，被批准的需求已经从基线库中被丢弃，记录下丢弃的原因和决定责任人
被交付，通过用户的验收测试，需求以交付物的形式向用户提交
------SP1.5识别项目工作与需求不一致性------
典型成果
用文档记录不一致处
相应的纠正措施
实际时注意事项
手段：评审＋需求跟踪矩阵
关于文档的维护
CMMI2级——过程和产品质量保证（PPQA）
目的
为员工和管理提供过程和相关工作产品的客观评价
特定目标和特定实践
------SG1客观评价过程和产品------
客观地评价了所执行的过程以及产生的工作产品和服务对适用的过程描述、标准以及流程的符合度
SP1.1客观评价过程
对指定的过程的执行，对照适用的过程描述、标准和流程进行客观评价
SP1.2客观评价工作产品和服务
对指定的工作产品和服务，对照适用的过程描述、标准和流程进行客观评价
------SG2提供客观的评价------
不符合项得到了客观的跟踪和沟通，并且确保了它们的解决
SP2.1沟通不符合问题，确保得到解决
沟通质量问题，并且与管理层和员工确保了不符合问题的解决
通过QA报告；QA问题日志等文档
SP2.2建立记录
建立和维护质量保证活动的记录
质量报告要反映进展和不足两部分
说到“点儿”上
实施CMMI的晴雨表
------PPQA的特定活动------
为裁剪标准过程提供支持和管理；
为Delphi估算提供帮助；
帮助定义或修改工程过程或过程模型；（客观检查的基础）
为工作产品确定验收标准；（客观检查的基础）
为项目设置性能目标；
参与计划的准备；
检查计划（如：项目计划、CMP、Test Plan）是否完整。
------实现中常用方法------
PPQA 组织和协调质量活动识别项目中的缺陷，包括：
检查（Inspection）
走查（Walkthrough）
同行评审（Peer Review）
------产品质量保证活动------
- 在项目策划期间PPQA同项目经理和技术负责人一起评审项目质量目标及度量参数
使用G-Q-M方法（Goal-Question-Metrics）来确定有效的度量
初期应尽量保证数据分析的简单性 - 收集和分析项目的产品质量数据
- 建立数据存储和采集机制
------过程评审------
- 在PPQA计划中确定要进行的评审活动,并且得到项目组的承诺
- 提前安排评审的时间
应提前通报项目经理，双方要就日期和时间达成一致 - 需要准备评审的检查单
评审的对象是项目已定义的过程 - 评审活动要以检视工作产品和访谈作为主要信息来源
如：评审的核心是项目的估算过程，则应和参加估算的人员进行访谈，讨论他们执行这个过程步骤，并检查文档化的结果 - 记录评审结果
------过程与产品质量保证小结------
QA的两项工作内容
过程评审：审计项目组是否按照公司的规程执行项目组的活动
产品审计：审计项目产品是否按照规范产生
QA的工作方式
访谈的形式
文档检查
主持评审
参与项目策划
注意事项：
这是个社会属性大于技术属性的工作
检查单要细致