需求文档评审课上想到的一个问题

limengyun326

在需求文档评审课上的需求评审实践中，老师好象很强调对隐式需求的挖掘．

但是，个人感觉，对于在评审中提出过多的挖掘隐式需求的问题，是不是很浪费时间呢？

因为很多问题，也许需求人员和客户很明确得已经确定不需要那种功能，而对于评审人员却并不知道．

若说要考虑挖掘隐式需求，那可是无止尽的．

所以，在需求评审时，对于隐式需求的挖掘如何把握一个＇度＇就是我所想问的一个问题．










&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

[ 本帖最后由 limengyun326 于 2007-7-3 17:30 编辑 ]

lxm

顾客有时候无法说清楚需求，使用者的习惯，经验，考虑问题的全面性也有关系。正常情况下好说，非常情况下如何处理？不是每个顾客都能说的清楚。在成本（时间）允许情况下，隐含需求尽量挖出来。

thedaythegirl

隐式需求当然不是让你无之境的去挖掘，对于挖掘出的隐式需求也未必都能够实现，这需要相关的技术人员进行分析，实现更多的功能是需要成本的，分析人员会根据项目的实际情况考虑性价比的。

shtina

我觉得挖掘隐式需求某方面说也是为了更好的保证软件质量，减少以后的需求变更，如果软件已经到开发阶段，测试也开始进入一些准备工作阶段，而需求一直在变来变去，大家做了的又要重做，改来改去，肯定效率会很低的。
在做需求的时候，用户不一定是专业的，他只知道自己想要的结果是什么，所以这种情况下就要挖掘隐式需求了
关于‘度’，我觉得在时间允许的情况下，尽可能多的去挖掘隐式需求

[ 本帖最后由 shtina 于 2007-7-24 13:34 编辑 ]

candy_83

我觉得对于我们刚入测试行业的新手来说，要掌握好需求挖掘的度，那是非常困难的事情，这是需要业务知识和经验的累计的，所以在需求评审中我们所要做的就是尽可能多地了解业务知识，学习业务专家的经验～ 等有了能力的时候，才去把握那个度～

tidy_wwwww

记得大学上软件工程时，老师曾经举过一个例子，说如果做一个库管软件，可能对方的库管人员可能说我只需要你把每个月的进出库登记作出来。但是如果做入库，我们是不是需要做入库单？做入库单是不是就要考虑入库单的随时更新？这就发掘出一个方面：入库的数据库和相关信息的建立，出库也一样。这是针对开发的，测试也一样。所以客户可能提出的要求可能很简单，但是我们对相关信息的挖掘可能就很复杂。怎么挖掘？我想这就是经验。

lengyan

LZ学的好认真啊,我学那部分的时候没想那么多~
首先我觉得需求分析人员应该尽量熟悉用户的业务流程,并且要和用户多进行沟通,同时应该讲究一些沟通的技巧,毕竟很多专业方面的东西,用户是不能很好的理解的,能把复杂的东西简单化讲给用户,让他们能够更好的理解我们要做的东西,那么他们应该也能对他们的需求提的更明确一些~
其次LZ说的在需求评审中挖掘隐式需求,我觉得应该参照以前的项目经验,自己的以往经验积累,以及对行业的了解.同时,如果是需求人员和客户明确已经确定不需要的功能的话,在评审会议上,应该会被需求分析人员拒绝的.

xxxxwjj

路过
研究中！！
才上了几天课，我发现我以前好多思想都错了，乱了
郁闷
发现自己以前的见识太小了（幼稚）
整理思维中！！！

log_1

这主要是考验你对客户的业务和流程的熟悉程度，你熟悉了客户的业务和业务流程你自然就会想到很多隐含的需求了，这个主要是看个人的工作经验和项目经验。

wangxiu836

恩，当时上课讨论挖掘隐式需求的时候,我也问过这个问题,其实很多都是依赖测试人员的经验和对用户所需要产品的了解,对相同产品的了解,就像版主说的,如果需求那么容易把握，也就不会存在那么多因为需求的变更或遗漏导致的软件失败了。所以我们要积累经验啊!

arlenexhl

我感觉老师只是为了讲这样一个方面的存在(一般容易备忽略的),起到提点的作用,其实以后的具体情况只有具体分析啊!

random_qjj

斑竹似乎等于没有回答嘛。。。一般项目中是如何掌握的呢？说点实际的吧。。。

chenyulei

可以从客户所在的行业，项目的复杂度，以及公司的利益等几个方面综合考虑

Jor

经验。。一切都在经验。。。 和对行业的了解程度。。都是需要下功夫的

天网

如果需求那么容易把握，也就不会存在那么多因为需求的变更或遗漏导致的软件失败了。

keenling

我也为这个问题困扰。一方面说需求分析要完成的功能不要超出用户的要求，不然等于浪费时间。另一方面要挖掘用户的隐式需求。隐式需求说白了就是猜用户要的，这样难免会无穷无尽。这还是很难把握的。