所在位置:答疑 - 内容   
我项目中需求评审,他们总挑我的目标不明确,没有量化的问题.十分讨厌
 

2007-9-19  11:16:54  richardpeng:  因为项目的时间紧,因此我打算设计不做了,数据项和一些规则都在需求用例里描述好.这样最起码不会让程序员做错了(但质量可能会差). 
2007-9-19  11:17:07      传输"UC-TITAN-STUDIO-005-配置数据访问组件(0.2 版).doc"完成。 
2007-9-19  11:26:26  richardpeng:  界面的流转关系,不应该放在需求用例中吗?我是想,这样跟用户交流起来会方便一些的. 
2007-9-19  11:28:42  richardpeng:  是不是我这需求用例中设计的痕迹比较重? 
2007-9-19  16:57:06  潘:  数据项和一些规则--这是需求 
2007-9-19  16:58:30  潘:  界面的流转关系--不是需求。涉众要的只是功能和性能,包括可用性。你可以画界面原型和涉众交流,但那只是一种获取真正需求的工具。 

2007-10-12  9:12:23  richardpeng:  潘老师您好,我项目中需求评审,他们总挑我的目标不明确,没有量化的问题.十分讨厌.比如:目标是"提高开发效率"、"节约开发成本"等等。客户没有提出这些问题来,因为这些目标是客户想达到的,但谁也不可能给出个量化的值。到底能提高百分之多少。评审的人却说可以估计,如果这东西可以估计,那么写出来有什么意义呢。感觉就是站着说话不腰疼。故意挑毛病。 
2007-10-12  9:13:27  潘:  确实是要量化的,还是要去揣摩涉众的心理对它的度量是什么 
2007-10-12  9:19:00  richardpeng:  我这项目是公司的研发项目。这个问题我也跟高层领导探讨过,比如:提高开发效率,这个目标。谁也给不出具体的值来。 
2007-10-12  9:21:44  潘:  那么老大是公司领导了?提高开发效率是个问题的话,问题存在哪些地方?系统上马之后要达到什么效果领导才会满意?提高开发效率后会怎么样?要是一直不提高开发效率,会怎么样? 
2007-10-12  9:21:56  潘:  这些你都可以去揣摩领导的意思 

2007-10-12  9:31:02  richardpeng:  对。老大是公司老总。我这项目是准备开发一个基于J2EE 的整合开发平台。象以前开发都是在Eclipse、Jbuilder 等开发工具上编写代码。而且对于新技术需要花去一定量的学习成本。而我这个平台全提供可视化的操作方式。基本不用编写代码,而且比较简单(因为很多地方都有固定的模式嘛)。围绕这个目标的具体做法,在用例中才能体现出来。但在前景文档中没有这些东西。而且您刚才提的几个问题,我们也想到了。现在唯一麻烦的就是没有具体的值(老大对没值似呼不是很在意,到是下面的评委认为不满意)。 
2007-10-12  9:32:21  richardpeng:  这些评委自己不负责项目,就可以张嘴瞎说,说我可以估计,也可以做模拟。 
2007-10-12  9:32:55  richardpeng:  跟我玩理论。 
2007-10-12  9:34:16  潘:  老大都不在意,评委在意有大的妨碍吗 
2007-10-12  9:36:40  richardpeng:  有啊。 
2007-10-12  9:37:01  richardpeng:  不签字通过。 
2007-10-12  9:38:21  richardpeng:  现在公司正在实施CMMI3,流程上要求了。但老大不是很在意流程。 
2007-10-12  9:39:01  richardpeng:  虽然我项目也在往下进行,但总觉得很不舒服。 
2007-10-12  9:42:42  潘:  评委是什么人,老总在不在意他们的看法 
2007-10-12  9:46:07  潘:  老大是支持你,但他可能也要考虑其他因素 

2007-10-12  9:46:40  richardpeng:  感觉能有30%左右在意吧。因为不量化,验收也存在问题。否则,在"提高开发效率"这个目标上只能凭感觉了。老总让评委去拿出个合理的方案来量化该目标。可谁也拿不出意见。就一直这么拖着了。 
2007-10-12  9:50:44  richardpeng:  老大更关心我项目的进度问题,至于有没签字,有没拿出量化方案,他还从没过问。 
2007-10-12  9:50:56  潘:  可能问题,还是对目前的开发流程描述不够细。例如现在画一个界面程序员要多少步,上了你这个平台剩下多少步。 
2007-10-12  9:51:37  潘:  还有你这个平台要多少人力物力开发,投入产出值不值得等等 
2007-10-12  9:51:54  潘:  最终的度量指标,无非是时间和金钱 
2007-10-12  9:52:31  潘:  金钱上可能是减少开支,也可以是增加收入 

2007-10-12  9:58:05  richardpeng:  "可能问题,还是对目前的开发流程描述不够细。例如现在画一个界面程序员要多少步,上了你这个平台剩下多少步。" 这些描述需要在需求中体现吗?具体怎么做,应该在我的设计中才能体现啊。  
2007-10-12  10:00:53  潘:  要的,类似于"将程序员完成界面的操作次数减少40%"这些才是需求。提高开发效率太模糊。 
2007-10-12  10:01:46  潘:  类似于"将程序员完成界面的操作次数减少40%"这些才是合格的愿景目标 
2007-10-12  10:01:51  潘:  刚才说错了 

2007-10-12  10:02:16  richardpeng:  哦。好象有点明白了。 
2007-10-12  10:03:33  潘:  "程序员建立数据访问层的时间减少到总时间的×××%" 
2007-10-12  10:03:37  潘:  等等 

2007-10-12  10:04:50  richardpeng:  可能我那些目标,改成比如:持久层代码编写量降低70%。 
2007-10-12  10:05:47  潘:  :D 
2007-10-12  10:07:54  richardpeng:  有些我可能不太容易用时间来度量的,那么我可以转换成操作次数,需要程序员的能力等等来体现,新的方式的价值。是这样吧? 
2007-10-12  10:09:04  潘:  对呀 
2007-10-18  9:03:08  richardpeng:  需求规格中是否一定要包括非功能性需求?这方面即使用户没提,也需要去引导,然后写出来? 
2007-10-18  9:08:22  潘:  是 
2007-10-18  9:09:15  richardpeng:  不是很理解. 
2007-10-18  9:09:41  潘:  运行速度,并发人数,操作次数....这些是客观存在的 
2007-10-18  9:10:01  richardpeng:  不是有点给自己找麻烦吗? 
2007-10-18  9:10:50  潘:  :D 如果要把软件作好,肯定得找麻烦。如果,随便给个东西,那不用写需求都可以啊,随便搞一个就行 
2007-10-18  9:11:28  richardpeng:  可象运行速度这些指标,用户也很难提出具体值来. 
2007-10-18  9:12:03  潘:  涉众是不会(也没有资格)和我们提需求的,他提的是他这类涉众的一种利益。需求是我们根据涉众的利益综合出来的 
2007-10-18  9:12:36  潘:  可象运行速度这些指标,用户也很难提出具体值来.--他不需要给出具体的值,即使他给了,也不能要 
2007-10-18  9:14:17  潘:  例如,有ABC 三个岗位,每个岗位一些功能。你问A,A 说我这边功能要很快,快到××××。但也不能成为需求,因为还涉及到B、C 的利益 
2007-10-18  9:14:53  潘:  你可以这么想,你要开发一款婴儿用的产品,是不是也需要婴儿和你提需求呢?

2007-10-18  9:18:42  richardpeng:  我是做技术出身(比较起来更擅长设计和编码),现在做项目经理.可能是现在的职位不同,关心的事情会不一样,更关心进度\成本\质量.对于需要这方面,我是不想分析人员去给弄得那么的细,会给我增加更多的成本.感觉分析人员做到客户能用就行.这两者之间是有些矛盾的.潘老师,您怎么看待这事呢. 
2007-10-18  9:19:42  潘:  这也是一方涉众利益啊 
2007-10-18  9:19:59  潘:  你不写出来,开发人员怎么有共识 
2007-10-18  9:20:52  潘:  例如,涉众说要快到0.1 秒,但你这边觉得成本太高,3 秒就足以应付。这不得让开发人员知道吗。 
2007-10-18  9:21:38  潘:  什么叫"能用就行",你这边必须有标准。

2007-10-18  9:24:01  richardpeng:  说得对.我明白了. 
2007-10-18  9:25:02  潘:  所为需求,就是把没有形成共识的东西写下来。如果大家都知道怎么做,还用写什么。 
2007-10-18  9:33:57  richardpeng:  用例反映了功能性需求,那么非功能性需求是否需要跟具体用例对应起来呢? 
2007-10-18  9:34:45  潘:  如果是针对用例的写在用例文档中,如果是针对整个系统的,集中放到文档的最后 
2007-10-18  9:38:56  richardpeng:  产品的特性一般是写在<前景>文档中的.写的是产品中有特色\特点的地方(功能性和非功能性).在需求跟踪时,正向的跟踪容易做,但逆向的跟踪却没法做了.因为有的用例根本没有对应的特性.是这样吗> 
2007-10-18  9:45:52  潘: 不是这样。前景(愿景)描述的是总体改进目标,就像你上次说的"持久层代码编写量降低70%" 
2007-10-18  9:46:27  潘:  但"持久层代码编写量降低70%"不是一个系统需求,不是系统的一个功能,也不是系统的一个性能 
2007-10-18  9:47:10  潘:  愿景时是不应该知道(或者说绑定)具体需求的

2007-10-18  9:51:06  richardpeng:
http://www.********.org.cn:9081/doc/RationalUnifiedProcess.zh_cn/process/artifact/ar_vsion.htm 我是参考RUP 的模板写的,在他的前景文档中,有涉众的愿景,也有产品特性这部分,还有性能需求等等. 
2007-10-18  9:52:12  潘:  那个不用理他 
2007-10-18  9:54:23  richardpeng:  不理不行啊.我们按这东西评审,阶段评审时还得有需求跟踪等. 
2007-10-18  9:55:52  潘:  那你就随便写点呗。RUP 基于IvarJacobson 的贡献,他又不是需求专家,不用迷信它。在UML、RUP 之前已经有很多有效的需求技能了。 
2007-10-18  9:56:54  richardpeng:  我第一次写这前景文档时,就把部分内容给删掉了,结果就没通过. 
2007-10-18  9:57:09  潘:  把后面的Copy 进来一部分呗 
2007-10-18  9:58:14  richardpeng:  很大的问题是我不是专家,如果是您那么写了,他们会听.但我那么做了,他们就会觉得是不正确的.郁闷.呵呵 
2007-10-18  9:59:48  潘:  把视图和模型分开,应付场面的"视图"可以多种,但"模型只有一个"。实际上,你不只要应付评审,还有应付不同的涉众,这些都要有不同的"视图"