《软件需求分析（第二版）》第18章——需求管理的原则和实践 重点部分总结
一、讨论
1、对于动态的需求基线，在添加新需求后，怎么做高效的需求管理？/对提出的新需求或已变更的需求，项目的响应方式是什么？
(1)、推迟实现优先级低的需求；
(2)、增派人手；
(3)、短时间的突击加班，最好是有偿加班；
(4)、为了满足新功能，推迟产品的交付日期；
(5)、保持产品交付日期不变，但在质量上打些折扣。这也是需求变更之后项目通常采取的反应方式，虽然这样做并不可取。
二、简答题
1、需求管理包括哪些内容？
需求管理包括：
(1)、控制对需求基线的变更；
(2)、保持项目规划与需求之间的一致；
(3)、控制单项需求和需求文档的版本情况；
(4)、控制基线中需求的状态；
(5)、管理单个需求和其他项目工作产品之间的逻辑关系链。
2、怎么评估需求管理中的工作量？
将下面这些活动中所投入的工作量加起来，就可以算出需求管理的工作量：
(1)、提交需求变更和提议新的需求；
(2)、评估已提议的变更，包括进行影响分析；
(3)、变更控制委员会的活动；
(4)、更新需求文档或数据库；
(5)、向受影响的小组或个人传达需求变更；
(6)、收集需求的跟踪信息。
3、跟踪需求状态中，已提议、已批准、已实现、已验证、已删除、已否决等状态代表什么含义？
| 状态 | 定义 |
|---|---|
| 已提议（Proposed） | 该需求已被有相应权限的人提出 |
| 已批准（Approved） | 该需求已被分析，它对项目的影响已进行了估计，并且已经被分配到某一特定版本的基线中。关键涉众已同意包含这一需求，软件开发团队已承诺实现这一需求 |
| 已实现（Implemented） | 实现这一需求的代码已完成了设计、编码和单元测试。这一需求已被跟踪到相关的设计元素和编码元素 |
| 已验证（Verified） | 已在集成产品中确认了这一需求的功能实现是正确的。这一需求已被跟踪到相关的测试用例。这一需求目前可以被认为是已完成了 |
| 已删除（Deleted） | 已批准的需求又从需求基线中取消了。要解释清楚为什么要删除这一需求，以及是谁决定删除的 |
| 已否决（Rejected） | 需求已被提议，但并不计划在下一版本中实现它。要解释清楚为什么要否决这一需求，以及是谁决定否决的 |
三、名词解释
1、需求基线
需求基线（Requirement baseline）是团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合。
2、需求属性
将每一个需求想象成一个对象，它具有一些能将自身与其他需求区分开来的属性。除了文本描述之外，每个功能性需求都应该有若干条与之相关联的支持信息或属性，这些属性为每一个需求建立了一个上下文和背景，这已超越了所需的功能描述。
大家如果还有什么问题、建议或者补充可以留言，看到了我会及时回复！一手资讯请关注本人公众号：WDeerCode代码圈哦！
