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  潘：  把视图和模型分开，应付场面的"视图"可以多种，但"模型只有一个"。实际上，你不只要应付评审，还有应付不同的涉众，这些都要有不同的"视图"