主题：【原创】软件开发项目中的需求开发问题 -- 闲云野熊

就象老熊所说，这个用户要求的征集，也会很繁琐。粗略地分，可以分成对已有系统的维护和新系统的创建。

对已有系统的维护相对比较简单。用户已经对于系统有一定的印象和经验，所以对于自己想要什么不想要什么，会有一个大概其的印象，而不至于满口跑火车。即使他想要加一些新功能，也会依照已有的系统来类比。对于作软件的也比较省事儿，估算时间成本时可以比照已有系统，八九不离十。这就象一辆跑车，车主要求车厂给追加个CD天窗ABS之类...

对于从无到有的新系统，这个方法就不适用了。因为用户没有印象，所以不能，也不应该指望用户在一开始就把所有要求全部提光，后来就一声不吭。就像阔佬托车厂给他造汽车，车厂当然不会上来就把车造出来再给用户，“看，这就是你要的汽车！”“什么？我没有要五个方轱辘呀？”得，又得重新造。

车厂（好像现在还不存在这种车厂，咱打比方哈）这种情况下应该排个设计师，跟客人边谈边画，画完给他看，“喏，这就是你要的车子”“嗯，屁股能不能小点，轮胎能不能再宽点儿... ” 就这样边谈边改，最终差不离的时候才算定稿，然后才交付车厂进行生产。这个Rapid Prototype(RP)方式在软件开发上即可用所谓快速开发，先把用户能看得见的东西给他拿出来，大家看着实物，边谈边改；不看着实物，光是空对空地讲，回头他经常会给你来个彻底不承认。RP可能会增加用户需求征集时间，但是在这里多花一个钟头后头能省好几个钟头。

对于老熊说的(2),非常有同感。这个要求从直接用户那里上来，一路上经过BA/BSA/TSD几道手，往往就面目全非。最好的是能找到最终用户，由最终用户来敲定而不是由他们的领导来提要求。领导们只关心这个“18摸”计算机挖地雷快不快啊？

对于系统接口的问题，咳，这个其实更多的是个政治问题了，公司政治，已经不是简单的技术问题了。有人能做不原意做，有人不能做却硬撑着要做... 这些都已经是软件工程之外的问题，属于“人际工程”...