一个真实的项目需要立项，立项会议由项目经理来主持
市场：售前 拿到用户原始需求
产品经理：产品经理、需求工程师 转换需求
项目经理：立项 确认参会核心研发团队
开发：开发经理、主程 评审需求
测试：测试经理、TL、主测 1.熟悉业务需求2.提出建议和意见
测试团队：
lab导师——测试经理
我——主测
目录
文章目录
一、需求评审与提取
（一）需求来源清单
| 通用软件（禅道项目管理系统） | 定制项目 |
|---|---|
| 为大部分企业或个人 | 单独为某个企业开发 |
| 1.研发内部定义 | 1.用户提供（主要） |
| 2.较早前版本使用过程中用户反馈 | 2.市场竞品分析 |
| 3.借鉴管理类软件行业翘楚（SAT） | 3.抄袭行业领先者 |
| 4.借鉴软件项目生命周期管理经验(文章) | 4.推送解决方案给客户 |
| 5.参考ISO\CMMI标准（提高软件的质量） | |
| 6.较早前未解决的BUG |
（二）禅道要解决的痛点
| 职位 | 痛点 | 解决的功能（评审：产品经理、需求工程师有没有想到，在他的需求说明书里有没有写到） |
|---|---|---|
| 项目经理 | 1.项目马上就要结束了，但还有很多功能没有实现，还有一堆bug没有解决2.资源总是那么紧张3.产品经理又变更需求了 | 1.应有风险控制模块，进度管理模块2.应有人力资源计划模块、人力资源管控优化3.应有需求变更规范，需求变更响应 |
| 开发 | 1.天啊，需求又变更了2.该死的浏览器，该死的ie，该死的微软3.测试的人也太bt了，老挑我毛病4.项目经理啥都不懂，在那儿装5.填完日报填周报，有啥用？ | 1.提供开发对需求的变更的处理功能2.评审结果管理3.bug应分有效无效4.职责与权限划分5.周报可回溯，可横向纵向对比，绩效参考 |
| 产品经理 | 1.为什么开发连这么简单的功能都做不出来2.为什么我的需求开发和测试都理解偏差了呢3.为什么上线会出那么多的bug4.为什么开发做出来的东西和我预期的总是有很大的差距5.为什么我要的东西总会延期 | 1.功能点难易程度定级2.设计评审流程规范（开发测试设计提交给产品）3.风险控制，BUG分析4.开发过程跟进5.进度管理 |
| 测试 | 1.明天就上线了，代码还没有提交呢2.开发的bug也太多了3.要测ie6，ie8，ie9，chrome，Firefox，opera，360 4.我还有那么多测试用例没有跑呢 5.测试需求又变更了，之前写的用例没有用了6.我一个人对付5个开发… 7.线上又出bug了，又要挨训了8.我还要负责过程改进，还要监督流程 | 1.交付规范2.BUG趋势预警，开发发布质量管控3.测试环境4.测试进度控制5.需求变更规范与应急6.测试资源分配7.发布规范8.测试任务分配 |
（三）需求功能列表
这是需求工程师应该列出来的（可以通过禅道的开源版手册看到，链接：http://www.zentao.net/book/zentaopmshelp/162.html）。
我们要对每个功能结合痛点一一去评审，是否满足用户的需求，是否有遗漏，提出自己的建议。
（四）评审过程
1.确定评审组长（项目经理）
2.制定并发布评审计划
3.准备评审（需求工程师或者产品经理把禅道项目管理软件需求规格说明书发给参加会议的所有人，在评审前通读需求说明书，有利于评审时有的放矢，提出建议）
4.举行评审会议（评审执行）
5.改正、跟踪和回归评审
6.分析、总结和报告
7.归档
（五）评审执行
| 编号 | 评审项 | 结果 |
|---|---|---|
| 1 | 系统目标的定义与用户的要求是否一致 | OK |
| 2 | 系统需求分析阶段提供的资料是否齐全 | NG |
| 3 | 文档中的所有描述是否完整、清晰并准确地反映用户的要求 | NG |
| 4 | 与所有其他相关系统的重要接口是否都已经描述 | NG |
| 5 | 被开发项目的数据流与数据结构是否足够并确定 | NG |
| 6 | 所有图表是否清楚，在补充说明上是否足以被理解 | NG |
| 7 | 主要功能是否已经包含在规定的软件范围里，是否能充分说明 | OK |
| 8 | 软件的行为和它必须处理的信息、必须完成的功能是否一致 | OK |
| 9 | 设计的约束条件或限制条件是否符合实际 | NG |
| 10 | 是否考虑了软件需求的其他方案 | NG |
| 11 | 是否详细制定了检验标准，他们能否对系统定义是否成功进行确定 | NG |
| 12 | 文档中的所有描述是否完整、清晰并准确的反映用户的要求 | OK |
| 13 | 有没有漏洞、重复或者不一致的地方 | OK |
| 14 | 用户是否审查了初步的用户手册或者系统原型 | |
| 15 | 软件项目计划中的估算是否受到了影响 | |
| 16 | 软件开发的资源需求是否会因为估算而受到影响 | NG |
| 17 | 软件测试的资源需求是否会因为估算而受到影响 | |
| 18 | 是否符合国际的要求 |
二、产品设计文档评审
（一）评审对象
| 评审对象 | 作者 | 评审方法 |
|---|---|---|
| 产品原型设计文档 | 产品经理 | 聆听学习、释疑、提意见 |
| 产品概要设计文档 | 开发经理 | 聆听学习、释疑、提意见 |
| 产品详细设计文档 | 开发人员 | 学习，注意接口、参数 |
目的：
1.对系统业务熟悉
2.功能展现方式在脑海有呈现
3.性能参数指标
4.测试策略的雏形
（二）评审过程-学习为主、意见为辅
竞品分析-聆听-提问-会议记录整理-带着测试思维去评审->
因为概要设计和详细设计更专业
（三）原型设计评审
产品经理或者需求工程师用axure软件做一个原型设计（把软件的大概的样子做出来生成一个web页面给客户或参与评审的人去看）
设计工具——设计展现——设计评审
（四）概要设计评审
评审概要设计业务逻辑图每一步的可执行性
（五）详细设计评审
1.功能设计
2.性能设计
3.数据库设计
4.接口设计
5.安全设计
6.术语表
见禅道软件详细设计报告
三、功能列表
做出产出，做出一个功能列表
| 编号 | 所属模块 | 功能描述 |
|---|---|---|
| 1 | 维护配置 | 初始化管理脚本 |
| 2 | 维护配置 | 备份禅道 |
| 3 | 项目经理模块 | 建立项目 |
| 4 | 项目经理模块 | 组建项目模块 |
| 5 | 开发模块 | 创建版本 |
| 6 | 开发模块 | 申请测试 |
| 7 | 开发模块 | 解决BUG |
作业
熟读开源版的使用手册，编写功能列表（用excel和word写都可以）