目录
敏捷开发工作节奏快，确定好的需求很快就会被最新的需求覆盖。
在这种情况下，没有足够的时间去更新软件需求说明书，大家基本都认为只要列个概要需求点，通过代码就可以反映具体需求，所以，没有必要在繁冗的需求编写上花费大量时间。
这貌似符合敏捷开发模式的节奏，然而大家忽略了项目本身的大小。若是中小型项目，在软件可以通过设计优秀的代码结构，标记代码注释去完成软件功能的前提下，开发人员可以不用编写说明书，而把更多的精力放在增加的功能上；但是对于大型项目，有必要预先设计好软件需求，这样才方便和处于不同地域或时差的团队成员交流，交换正确意见，从而降低沟通成本。
做好需求分析，需要从三个方面着手：
（1）首先进行需求梳理，建立自己的需求池，对需求进行判断，甄别哪些是真需求哪些是伪需求，对需求按类别划分；
（2）然后进行需求分析，考虑新需求对现有逻辑的影响，新需求与现有流程能否对应及扩展，新需求能否丰富原有功能，从用户角度出发是否由“可用”升级为“易用”，新需求是否需要其他部门配合，是否要多角度规划；
（3）最后进行需求放大，拆解重构需求链条，追根求源找到新功能深层的逻辑，对应用户形态。
需求分析完成后，要撰写需求说明书。说明书涉及的内容有：信息描述，产品简介、使用产品的用户、产品规范、产品规模、产品特点；功能描述，包括功能分类、功能模块间关系、支撑图、设计约束、处理说明；接口需求；需求估算；非功能性需求，包括用户界面需求、软硬件环境需求、产品质量需求、故障处理。
一、需求评审
项目相关人员一起参加需求评审活动，复查需求分析的成果，并对功能的准确性、适用性和复杂度，和其它要求提出意见和建议。有以下三种评审方法。
-
分层级评审
用户的需求是可以分层次的，一般而言分成以下层次：
（1）目的性需求，明确开发产品的目的；
（2）功效性需求，明确产品需要实现的功效；
（3）使用性需求，明确落实产品的具体操作步骤。
公司的高层领导关注方针性需求，公司的中层领导关注功能性需求，公司的底层具体执行人员关注使用性需求。
因此，不同层次的需求描述不同，需求审查的参与者也不同。
如果让公司的中层领导去评审目的性需求，就会造成人才没有摆对位置的问题，如果让具体执行人员去评审功能性需求，那项目很有可能落不到实处。
总之，分层级评审可以让不同层次的人群各尽其职，去评审属于他们职责范围内的需求，从多方位寻找需求的问题，预防缺陷。
2.正式评审与非正式评审结合
正式评审的定义是预先设定好评审人员的分工和职能，把与需求有关联的所有人员集中起来，以召开评审会的形式，对需求进行制度化的审核。
有时，由于需要评审的内容超量，一次正式评审会往往不能包含所有应该要审核的具体内容，而且在短时间的会议上评审人员对需求的理解也会出现偏差，就会造成很多问题没能被发现。
所以，非正式评审可以用来辅助正式评审，也就是说，在评审会发起之前，项目负责人可以提前发邮件或者分发需求材料给与会者，在一段时间内，让他们仔细研究会议的信息，记录异常情况，并在正式的审查会议上讨论。
3.分阶段评审
需求评审不应该等到需求最终定稿的时候才开始评审，应该在需求设计的进程中进行分阶段评审。
把一份完整的项目需求划分成不同的阶段，跟随需求设计员的设计进度去逐段分析，依次组织阶段性评审。
第一阶段评审是在目的性需求完成以后；
第二阶段评审是在项目概要设计完成以后；
第三阶段评审是先把概要需求划分成几个模块，然后针对每个模块逐个进行评审；
最后一个阶段是对完整的需求进行评审。这样评审质量提升了，返工率降低了。
二、审查项目要求的准确性
需求准确性可以从以下几个方面反映出来：
① 需求与需求之间是不是互相矛盾或相近？
② 每个需求表达的意义是不是清楚、简短、无歧义（“清楚”表示大部分人看后能明白表达的意思；“简短”表示描述的内容让人一眼就能抓住重点；“无歧义”表示人们对其阐述的观点的理解保持一致）？
③ 每个需求是不是全部通过了评审，分析是不是获得了检验？
④ 每个需求是不是都在项目范畴内？
⑤ 每个需求的描述中的内容和语法有没有错误？
⑥ 所有的需求能不能利用现有的资源去实现？
⑦ 每一条特定的错误信息，是否都是唯一的和具有含义的？
三、审查需求规格说明书的完整性
下面的问题用于全面审查需求说明：
① 编写的所有需求，其详细程度是否一致和合适？
② 需求能不能为计划提供充分的参考价值？
③ 需求之间是不是排出了优先级？
④ 功能注释里的计算是不是有解说？
⑤ 所有现有客户或产品需求是不是都包括了？
⑥ 必要的信息有没有遗漏？
⑦ 对触发系统期望的异常错误的操作是不是都有文档记录？
四、对需求的可实施性进行评审：
① 每个需求是不是都设置了唯一性并且可以正确地识别它？
② 每个功能要求是不是都能追溯至上层需求？
需求能够采用静态测试方法测试。测试需求时，给出一个特定的输入就应该找到预期的输出。而且，需求可以用层级分支图来演示，这样所有与某个需求有关联的其他需求都可以划分到一起，作为一类功能需求。
需求的可实践性包括可追踪性和可检验性，实际上，在代码开发之前，需求设计人员以及测试通过将需求模型、分析模型和测试案例三者相结合，全面思考，挖掘出漏掉的、不正确的和重复的需求，对需求的静态测试是开发过程中不可或缺的一个阶段，它能够在开发初期阶段察觉需求的分歧和缺陷。
五、QA活动
QA在迭代到发布的每个环节中的活动包括：新增功能分析，测试自动化策略分析、手动测试、测试自动化的维护和执行、客户演示等。
六、角色组合：
在每个阶段，除了必须独立测试之外，QA还与不同的角色（包括业务分析师、开发人员和客户）结合在一起 ：
（1）QA与业务分析师组合：
QA选择在业务分析师理解用户Story的时期与其组合，制定验证准则。这样做的好处是：QA可以深入地掌握某一行业的学问，从而便于界定哪些是适合的验证场景；反过来讲，敏捷团队除测试外的成员通过查阅QA已编写好的验证场景，可以更好地理解产品功能。
（2）QA与开发人员组合：
我们清楚地意识到，QA在敏捷团队中掌握的技能和开发人员掌握的技能各不相同，不同职能的人员想要很好地融入一个团队，就必须将各自的技能协调配合工作，达到最终的目标。所以，传统的开发团队在转变为敏捷开发团队过程中，调整心态是首要解决的问题。QA与开发人员组合是顺利开展自动化测试最佳的工作方法。为了确保自动化测试案例抓住正确核心的功能验证场景，测试技术娴熟和经验丰富的QA一定不可缺少。设计简洁且易于修改的自动化测试脚本的能力取决于开发人员的开发技巧。这样两者组合能够提高自动化测试质量。另外，与开发人员组合，QA的程序开发技能得到了提升；与QA结对，开发人员对验证产品质量的认识也有所加强，有助于产出高质量的代码，更有利于形成全功能团队。
（3）QA与客户组合：
QA与客户组合，客户作为行业专家可以帮助QA从真实用户的视角全面地了解软件产品，进而挖掘出更多从前端到后端的测试场景；随着QA和客户深入交流，协同工作，对行业的认知更加深刻，能够体会到用户的真实想法，从而提高QA的业务分析实力，甚至能够成为业务分析人员的储备资源；除此之外，与客户组合，QA在用户验收测试环节可以引导用户试用产品，甚至能够临时担任技术支持，为客户处理一些使用操作问题。
（4）、适用当前的工作职责过度
七、QA人员素质：
敏捷项目对质量保证人员的要求比较高，具有以下素质的QA才是团队需要的。
（1）具备很深的领域学识，能够把握客户业务需求。
（2）掌握使用不同系统和数据库的技术知识。
（3）擅长与不同角色以及客户进行有效交流，营建和睦的工作气氛。
（4）积极检验质量指标和分享工作心得。
（5）拥有搭建自动化框架的技能和纯熟应用各种测试工具。
（6）掌握统计学理论知识，会使用统计工具分析质量指标。