New Feature Review Question List (Draft)

听取一个客户的功能后,可以参考以下问题对功能进行审核.
审核重点在于该功能的来源,而非具体实现方式.

-------------------------------------------------
明确功能点所针对的问题来源
-------------------------------------------------
Q1. 谁是这个功能点的原始提出者?
Q2. 这个功能点期望解决一个什么问题?
Q3. 这个问题是谁(role)所面临的问题?
Q4. 目前的工作流程是如何处理这个问题的?

--------------------------------------------------
寻找问题点的解决方案
--------------------------------------------------
Q5. 已有的设计是否能解决这个问题?
Q6. 是否还有其他方式可以解决这个问题?

----------------------------------------------------
寻找解决方案带来的新问题
----------------------------------------------------
Q7. 采用某种解决方案后,带来什么样的新问题?(请列举3个新问题)

 

 

是RUP的例子还是你想出来的东西?

看了温伯格的一些书后,琢磨的.

挺不错的想法，但是在项目开发的过程中，还要综合考虑人力成本，时间成本等各项因素

checklist最好是用封闭式问题，我觉得您这里用的问题都过于开放些。如果我是填表人，我真的不知道怎么填是正确的。如果我是审核人员，我也不知道怎么样的填写是正确的。建议修改为（例如）：
Q1：有没有说明功能的原始提出者？
A1： Yes   No

另外不建议使用功能点这个词，你说的就是功能Function，而不是Function Point，FP是一种度量方式。

更新了一下标题.
把 "新功能点审核CheckList( 草稿)"
改为"New Feature Review Question List (Draft)"

本意是一些开放式的问题,引导相关人员对新的Feature(特征?)做评审。 应该是某种评审会议的形式，而不是填写表格的形式来运用。

比如:
Q1：有没有说明功能的原始提出者？
这个问题着眼于挖掘出具体是哪个人,或哪些人。
从而引导对问题更清晰的阐述。

嗯，基本上想法是好的。
这样也就不是check list了，几乎就是一个问卷。

我个人经验，开放式问题后面会带来很大麻烦。
比如：Q2. 这个功能点期望解决一个什么问题?
每个评审都不会给出同样的答案吧？这样你如何去判断review是通过还是没有通过呢？

只要这个Feature相关的stakeholder能够达成共识即可。
也就是相关人员觉得能自圆其说即可。

有经验的人开这种会议比较好，如果团队中有太多新手的话就没什么效率了。