需求管理工具基础知识点
什么是需求？
解决用户问题或达到用户目标所需的条件或能力。
强调做什么（What）而不是如何做（How）
需求管理的原因？
软件需求要基线化，要管理起来，否则需求的实现是盲目的，不受控的
软件需求的实现要跟踪、要记录、要标示
要测量软件需求（是否能实现，是否有歧义，是否还有隐含需求）
要验证软件需求：
1)一致性验证验证：主要是分析需求描述中是否存在一些需求冲突问题
2)完整性验证：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或者性能；
3)现实性验证：验证需求内容的可实现性；
4)有效性验证：验证需求对于实际的问题解决确实是正确有效。
需求工程分为两部分(要求记忆)：
需求的开发：
需求获取
需求分析
需求定义
需求验证
需求的管理：
需求分配
需求评审
需求基线
需求跟踪
变更控制
Quality Center（QC）
DOORS
禅道
Testlink
Bugzillia（缺陷管理，不能进行需求管理）
=========================================================================================
1.需求的内容描述？
需求是描述要做什么，而不是描述怎么做。
2.SRS的目的是？
在客户和开发者之间达成一致
为编制计划和成本计价提供基础
为设计提供了基础
为确认和验证提供一个基础
提高开发效率
便于移植
3.SRS的内容特点：
正确性
无歧义
完整性
一致性
可验证性
可追踪性
需求规格的特点：
软件需求的正确性
软件需求无歧义性
软件需求完整性
软件需求一致性
软件需求可验证性
软件需求可追踪性
4.需求规格说明书的内容：
产品环境介绍：软件在什么环境下使用？
用户特征：软件给谁用？
假设和依赖关系：开发语言、开发环境
用户接口：人机接口/界面
功能需求：描述了软件必须执行的基本动作
用需求编号加上简短词汇做为功能需求名，不要用“功能需求（1）”作为功能名。例如：CALC.R.INTF.001 计算表达式
内容包含：
简要介绍
输入
处理
输出
性能需求：描述对软件的静态的和动态的量化需求
静态：支持的终端数目、支持的同时使用的用户数、表和文件的大小……
动态：请求响应时间、吞吐量、资源利用率……
技术限制：使用特定技术的限制，包括接口，数据库，通讯协议，编程规范等
本地化：描述支持多种语言的需求
软件接口：与外部软件的接口
考虑软件质量模型中互操作性
标准符合性：软件质量模型中依从性
需求分级
螺旋模型可以根据需求分级来确定哪些功能先做
测试用例的重要级别和需求分级相关
总结：在你阅读需求的时候，反复的问自己，这个需求如果让你来测试，
你怎么测试，能否进行测试，怎么判断测试的标准。
需求分级(记忆)：
基本的（essential/Mandatory）:绝对基本特性；如果不包含，产品就会被取消。
实例：ERP软件的登录功能。
条件的（conditional）:不是基本的特性，但这些特性会影响产品的生存能力。
实例：微信软件中的打游戏功能。
可选的（optional）:期望的特性；省略一个或多个特性不会影响产品的生存能力。
同行评审的概念：
同行评审（Peer Review）是一种通过作者的同行来确认缺陷和需要变更区域的检查方法。
需要前期准备、计划和时间进度表
越早越好
评审什么？
所有的技术文档包括代码都要评审。
同行评审活动（要记忆）：
正规检视
技术评审
走查
变更控制委员会（CCB)
需求评审过程整个流程图要记忆下来。（重点内容）
参考需求跟踪配置项的截图：
谁：PM（项目经理）负责需求跟踪。
目的：确保所有的分配需求均被实现，被验证，后续的工作产品与分配需求一致。
需求跟踪矩阵表(RTM, requirements traceability matrix)
什么情况下修改需求叫变更，什么情况下修改需求不叫变更？（重点内容）
以需求基线为分界线，需求在基线之前的修改都不叫变更，需求一旦基线后所有的修改都要走需求变更流程。
软件需求变更流程（重点内容）
需求变更过程：（建议记忆）
1.需求变更提出人->
2.CMO将CR单（变更请求）状态表示为提交，将CR提交给CCB签发。
3.CCB组织一个会议对CR进行分析和评估。
4.如果CCB组织会议是拒绝修改的，那么反馈给CMO将CR单标识为拒绝，并返回给提交人。
5.CMO把CR状态标识为接受，将CR与要修改的配置项发给项目组成员并开放CI的配置库权限。
6.项目组成员可以执行更改了并验证。
7.CCB召开会议对修改进行评审，如果通过将CR状态标识为已验证，发给CMO。
否则(指验证不ok)返回给修改人。
8.CMO要检查验证CR记录，收回配置库权限，将CR标识改为已关闭，再发给提交人