空间管理您的位置: 51Testing软件测试网 » pioneer of living space.......... » 日志

我们拒绝平庸，拒绝随波逐流，拒绝墨守成规，让梦想不再流浪。

需求管理

上一篇 / 下一篇 2014-05-28 10:38:50 / 个人分类：总结

查看( 574 ) / 评论( 0 ) / 评分( 0 / 0 )

DAV（评估结果动态运算视图）

(*)

评估维度

当前状态

当前级别

级别3

级别2

级别1

级别0

级别－1

管理实践

需求管理

增量价值、可测试

√

2/2

√

2/2

√

2/2

√

0/2

√

0/2

团队文化

协作基础设施

1/2

√

3/3

√

4/4

√

4/4

√

0/6

迭代管理

项目状态报告反应项目路径

2/4

√

4/4

√

4/5

√

1/4

√

0/6

技术实践

软件构建

持续构建

2/3

√

2/2

√

3/4

√

1/3

√

0/5

测试

开发参与测试、集成的

2/3

√

3/3

√

1/3

√

1/3

√

0/3

简单设计

引入重构

2/3

0/2

√

1/1

√

0/2

√

0/3

.h6} Ad&txCp0

需求管理
等级3		3级：增量价值、可测试
	查检项		满足?	访谈问题参考
*参照标准*	需求是业务价值的体现，而不是待完成的技术任务			1、需求是怎么获取的？ 2、需求如何跟踪？优先级是如何确定的？优先级在整个版本开发过程中会有什么样的变化？有哪些因素会导致优先级变化？ 3.需求变更是怎么进行的？会有哪些人参与？ s!GX%KA&T5p04、需求实现人员与需求提出人员之间是如何交流的？交流频率是什么样的?51Testing软件测试网Ab1AM$~X(Q 5.谁来定义验收条件？谁做验收测试？什么时候做？51Testing软件测试网;X2qbz q!WZ 6、需求估计什么时候做？谁会参与估计？ 7.采用的什么需求管理工具？ 8.当需求需要进行澄清时，怎么办？
1.3.1	结合已有需求的价值及交付要求，实时调整story交付的优先级		√
1.3.2	需求内容渐增完成与验证，价值及时体现		√
满足需求管理 - 等级3?		是否增量价值，可测试？	√
等级2		2级：独立、可协商
	查检项		满足?
*参照标准*	需求描述了交付团队需要完成的事项，是独立的，可执行的。估计和协商的方式可以改变。
1.2.1	需求逐层分解为可以独立测试交付的story		√
1.2.2	各需求分解点间耦合性小，容易接受变化		√
满足需求管理 - 等级2?		是否独立、可协商？	√
等级1		1级：短小、可估计
	查检项		满足?
*参照标准*	需求会被进一步分解成可互相依赖的任务（技术需求）以提高估计的准确性。
1.1.1	根据需求分析可以进行较准确的工作量估计		√
1.1.2	根据需求分析可以进行优先级排序		√
满足需求管理 - 等级1?		是否短小，可估计？	√
等级0		0级：概要、模糊、业务导向的表达
	查检项		满足?
*参照标准*	需求分解粒度大，估计不准确，概要式的业务需求导致难以协商
1.0.1	需求进行了业务分析（应用场景），但业务粒度较大，无法进行详细的交流确认		X
1.0.2	概要式的业务需求导致难以协商		X
满足需求管理 - 等级0?		需求分析是否是概要、模糊、业务导向的表达？	√
等级-1		—1级：详细的、高度耦合
	查检项		满足?
*参照标准*	冗长的用例，缺乏完整背景的大段描述——需求分析没有考虑对原来架构影响，描述冗长模糊
1.-1.1	需求模糊，没有任何分析过程，基本属于一句话需求，无法指导后续的开发测试		X
1.-1.2	需求粒度很大，无法准确估计，所有开发完才能测试验收		X
满足需求管理 - 等级 -1?		需求是否是详细的，高度耦合？	√