瀑布型：市场调研—》需求--》设计--》开发/编码--》测试--》上线发布--》运营维护--》下线
角色划分，每个人有不同的职责：市场，需求，开发，测试，配置，运维
配置管理人员：编译代码，环境部署。
测试对象 软件：文档+数据+程序（代码）
=========================================================================
学习目标：
1.了解需求管理过程
2.掌握需求评审过程和内容（需求评审会议）
3.测试需求分析
4.测试项和测试子项
=========================================================================
需求管理过程：
1.可行性研究-->可行性报告
2.需求导出和分析
系统模型-->需求描述-->用户需求和系统需求-->需求有效性验证-->需求文档（系统需求规格说明书 SRS）
3.需求检查、评审：
有效性检查、一致性检查（功能冲突）、完备性检查（功能遗漏）、实现性检查（判断技术能不能实现）、可检验性检查（模糊不明确的描述）
4.需求管理：
需求理解：保证项目组内和外部客户对需求的理解达成一致。
需求承诺：书面承诺，统一需求文档
需求变更：维护变更历史（文档记录），为调整控制提供数据（有依据可寻）
需求变更后维护： 需求的双向可追溯性，从软件可维护的角度提出管理要求
标识项目工作：与需求的不一致性，若不一致，随即启动纠正措施(发现与需求的bug)
============================================================================
需求评审会议：
参与人员：人员不是固定的
目的：组织各部门人员共同检查需求文档
召开前：会议主题、发送会议资料、通知责任人、准备常见应对问题
会议中：阐明会议内容、会议记录、明确争论原则、讲解需求、需要支持、总结需求责任人复述、预计上线时间 责任人。
会议后：总结争论点、确认调整方案，是否需要再次召开、发送会议记录、落实行动计划、确定任务安排、任务排期、定稿发送
=========================================================================
测试需求分析
软件质量模型：外部和内部质量
1.功能性--适合性（适合用户需要）、准确性（功能正确实现）、互操作性（接口互用）、保密安全性、功能依从性（合法）
2.可靠性--成熟性、容错性（容错机制）、易恢复性（恢复能力）
3.易用性--易于理解、易学性、吸引性
4.效率--时间、资源利用率
5.维护性--易分析性（日志信息记录 快速定位问题）、易改变性、稳定性、易测试性
6.移植性--适应性（不同系统）、易安装性、共存性（其它软件共存）、易替换性（替换其他同类软件）
怎样分析需求：了解软件质量特性，进行测试需求分析定义测试范围，明确测试项和子项，便于后续设计测试用例。
点-->功能点：输入-->处理-->输出
线-->多个功能点串联 业务场景：模拟用户的操作场景
面-->非功能性 隐形需求
体-->系统接口测试 输入参数--处理 接口定义--输出 实现
原始需求分析：
来源：srs 软件需求规格说明书、开发需求、协议标准规范、用户需求、继承性需求、经验库、同行竞争分析等等。
原始需求（口述、记录）-->原始需求细化（需求规格）-->开发需求：需求细化，明确实现方式。-->测试需求：测试角度更加细化，做到 可度量、可实现、可验证。
=============================================================================
如何获取测试项、测试子项
根据测试需求？
了解需求跟踪矩阵的内容、目的
需求跟踪矩阵（RTM）
管理需求变更和验证需求是否得到实现的工具，可追踪每个需求的状态。
RTM作用：1.变更可以快速识别到各个环境的变更（需求变更，设计变更，开发代码变更，测试用例变更），防止遗漏某些变化而导致的连锁变化。
2.证需求是否得到了实现，跟踪每个需求的状态
