需求描述最佳实践
需求规格的格式取决于开发团队的特点及所选的开发方法论。
用户需求说明书是为生成软件需求规格说明书服务的。
文字的歧义可能与其长度成正比。
要使需求描述更加清晰，就应该转用“结构化文本”式描述。
在你被逼在需求描述中增加How的信息之前，先确认自己已经
尝试过为需求添加了Why。
对于非功能需求而言，应该抛弃定性，改用场景化描述；
并通过选取指标、积累经验值的方法过渡到定量描述。
需求验证最佳实践
需求验证的目标是尽可能暴露问题，而不是证明无错。
在企业中推行即时评审、同级桌查等正式化程度不高的评审手段，
是创建企业评审文化的有效手段。
在评审会中，不要用“评价者”的口气谈论你的观点。
参加需求评审的人不是越多越好，一定要保证同级、适合。
评审时要确保评审内容、缺陷检查表的规模适合，内容应该按每
小时30～40页的速度来准备，缺陷检查表尽量在9条之内。
需求基线操作实务
优先级是相对的，要在同一级中进行比较。
评价具体功能点的优先级时，应将其放到业务场景甚至是业务
流程环境中考虑。
软件估算是随着工作任务的细化不断提高精确度的。
不同阶段进行软件估算时，应该采用不同的计数单元。
悲观估计、乐观估计应和“风险”理由对应起来。
第三部分-需求管理
优先级是相对的，要在同一级中进行比较。
评价具体功能点的优先级时，应将其放到业务场景甚至是业务
流程环境中考虑。
软件估算是随着工作任务的细化不断提高精确度的。
不同阶段进行软件估算时，应该采用不同的计数单元。
悲观估计、乐观估计应和“风险”理由对应起来。
变更管理操作实务
需求变更管理的目标是控制变更，而非避免变更。
控制变更的目标是减少变更对开发工作的影响。
需求团队的贡献在于“尽早标识变更”，设计团队的贡献在于
“尽可能以弹性的设计来减少变更的影响”。
建立统一的渠道让客户意识到变更的成本，减少“来路不正”
的变更，记录“变更的工作”。
CCB的核心人员只有两个，分别代表用户团队和开发团队，
其他组成人员都是协作者和决策者。
基于业务驱动的需求项（树型）列表，是对变更进行业务
影响分析的有效方法。
对变更进行分类、再分类，是管理变更的重中之重。
需求跟踪操作实务
需求跟踪是高阶管理活动，所需的工作量很大，特别是软件需求。
到设计元素的跟踪，因此一定要考虑投入与产出是否成正比。
需求细化是什么？在第二阶段我已经通过分解和细化到达了具体的用例，而第三阶段的重点就是单个用例以及该用例可能涉及到的界面部分建模。书中将用例分为三类是有一定道理的，即业务用例，报表用例和接口用例。对于业务用例的重点是基本流，扩展流和业务规则。对于报表类的用例重点则是报表的输入，输出内容，输出格式。在这里有个情况不得不提出的就是，一些报表类用例脱离了只要不是项目历史开发人员很难看懂，原因即是关键的报表的数据来源在哪里没有说清楚，这点也是报表类用例必须关注的要点。
如果将用例分为两个层次，第一重点就是关注业务活动流和规则的细化，另外一个就是涉及到交互和界面的建模和细化。这两个层次仍然有一定的关系，重点仍然是要先考虑业务流和规则，再来考虑交互和界面。如果先陷入到了界面建模再考虑业务流和规则，则又是顺序错误的开发人员思维，即违背了用例是业务活动驱动的初衷。