目前，在我们公司，每年都有很多的软件开发项目需要开发实施，这些软件项目在立项阶段有一个必须要做的工作，就是做需求说明书，没有需求说明书，自然无法立项与招标，按目前的做法，主要是找较熟的开发商帮助调研，这样做就造成了多方面的问题：
１、调研没有规划，造成调研不系统，项目范围一般都不完全。
２、调研的开发商有可能是义务劳动。
３、调研的开发商参与过早，如果参加选型，会造成不公平。
按我现在的想法，解决这种问题的关键在于找“较熟的开发商”做需求调研就是名不正言不顺，要么是自己做，要么就是找个咨询商来做，这样就不会有纠缠不清的问题，从强化甲方能力来说，自己做应该是最好的，在前期可以签个长期提供服务的合作商来协助提高。
另外一点要明确的是，做“业务需求说明书”的目的是为了说明业务流程的现状，并假设系统开发完成后，在业务流程中起到的作用，这个“作用”就是此开发项目的项目范围。有不少项目在选项型就搞了一个非常详细的功能说明书，但最后真正完成实现的系统与这份功能说明书，完全风马牛不相及，这里的根本原因就是搞混了概念，项目范围不是详细设计，因为需求是变化的，但业务在相对时间内才是不变的，如果不从业务的角度出发描述项目范围，那这个项目范围肯定是有问题的，这个想法在rup2003的软件工程流程图里得到了理论支撑，图如下：
从图上可以看出，业务建模作为项目计划阶段的重要输入，在迭代的过程中是不做改变的，业务建模成果对项目范围的确定起到了关键性的作用，是确定项目范围最重要的依据，所以象我们这样的甲方应该花大力气强化业务建模的能力，这样才可以避免被合作商牵着鼻子走，才可以在做项目的时间胸有成竹。
iterate.gif来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/1673/viewspace-254314/ ，如需转载，请注明出处，否则将追究法律责任。
