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