需求文档与评审
2020-07-22 11:04:24 0 举报AI智能生成
需求文档与评审
作者其他创作
大纲/内容
what
需求文档==初稿‘；更新：版本编号可能产生变化
一般以：文档方式呈现
需求文档编写规范：
what
针对异常情况：粗略的列出错误或者异常的情况（最基本）；具体的错误提示信息，如果不确定，可以放在后期的测试（执行的时候）阶段，提出bug单，建议要怎么修改
专业术语：自定义，参考一些专业文档或者书籍；过往的项目经验；
UI界面原型：当有的地方不好描述的时候，可以截图或者加上一句：参见高保真原型介面
依赖性
背景：why：解决什么问题
当前现状
异常处理
概设
祥设
测试用例
分解：每个人写小部分
作用
1：用户需求是源头，用来指导后续的开发和测试的工作展开2：需求的质量怎么样，确定软件的质量如何，后续工作
2：通过该文档，与用户建立连接，让用户理解需要做什么，与需求文档中的描述是不是一致的
3：可以作为用户使用手册的参考文献
需求评审，测试
who
需求分析人员
测试工程师
开发工程师
用户代表
需求分析人员会出一个需求文档的初稿或者概要，然后用户确定没问题后，需求分析人员会和研发团队（需求分析人员，测试工程师，开发工程师）对这个初稿进行评审
怎么做how
评审机制
自省
内省
外省
流程
需求人员进行宣讲（也叫串讲，告诉本次要做什么，用户的背景以及用户的要求）
开发人员，测试人员一起理解需求
对需求产生问题进行统一的记录（方式多样，刚开始打批注，空余时间集中整理为需求问题记录表）
要对需求中的问题进行答复或修改，并告知所有的团队成员
进行第二次宣讲（也叫反串讲），达成三方理解一致，形成需求基线（需求规格说明书的基线）
检查点
被测对象
需求文档
测试方法
黑盒方法：静态
检查点
一致性：前后依赖或者有关联的模块中间有共同的东西是一致的
需求遗漏：需求中包含的东西不全面，和用户需求有出入
二义性：也叫歧义性：造成不同的人有不同的理解
需求错误（正确性）：不清晰的，不明确到底是做什么的
统一性：与UI相关的要考虑统一性
完整性
：需求上的东西：一定是软件要实现的
需求文档里面应该有明确的输入与输出规格
标识（对于不同的分类，需要有不同的标识）
易理解性：让开发和测试容易理解
后续阶段的需求测试
测试需求与分析阶段：有遗漏、不完善、不清晰
回头补充你的需求规格说明书（找需求分析人员，找他确认）
管理者的角度
组织架构
人，根据公司规模制定相应的组织架构
以开发为中心
老大是开发
向开发汇报
绩效考核，软件质量指标，刑侦与技术管理，开发话语权是比较大的
延伸：测试团队规模扩大，可能负责多个项目：与项目挂钩（这里会出现项目接口人：是以开发为负责）
以项目经理为中心
相对以开发为中心，测试的地位有提高，基本上和开发平级
项目经理是老大：汇报对象是项目经理
项目软件
外包
资源，固定的
外包，成本控制：更多的是让公司考虑（由公司的决策或者行政部门），（人员培养，技术积累）
技术提升：培训，培养：交叉能力（会强调能力的多方面的发展）：也是在项目间歇。
一旦进入项目组，离开或者结束点，都是项目经理说了算
资源池释放
甲乙，甲乙丙
产品软件
产品经理是老大
汇报对象是产品经理
独立测试团队
项目经理、测试经理、开发经理是平级独立
独立的资源。调配；预算（人员培训绩效考核等都是产品经理说了算）
汇报对象：测试经理
第三方评测机构（外包服务）
可以通过组织架构，评估测试团队在研发团队中的地位以及影响力，也可以看出公司是否重视测试或者是公司对质量的认识
评审流程
评审更多的是以会议形式展开，会形成：会议纪要
角色定义
作者：主讲人
评审团：
记录员：
子主题 4
0 条评论
下一页
