项目开发前期，如何更完整、准确地理解业务逻辑
由于最近的几个项目只有我一个在做，比较草率。现在总结，觉得主要缺点是初期的业务理解期间的作业做的比较少，导致设计不完善，后期偶尔会发现架构不合理。
  怎么才能很好的从懂业务的人那里学到或者说理解业务呢？
  我感觉软件的最终用户其实并不一定从心里想用这个软件，有可能怀有抵触心里，因为计算机软件的使用将改变他们现有的工作方式，甚至是工作环境（涉及到岗位的变动），所以在同他们接触期间，遇到诸多困难。加之懂业务的人通常不怎么懂计算机，所以他们说出来的话也很有二义性，不能准确地代表他们的真实想法。
  不知道有没有什么好的方法、方式、工具、思想、技巧等等可以借鉴的，希望各位大侠给予指点。

------解决方案--------------------
这个问题大了。
如果用户不配合，这是个项目管理问题，想办法让他们配合，找到他们的需求点是很重要的。如果他们完全没有这方面的需求，那就只能是上面的行政命令了。如果用户说不清楚，就需要借助一些工具弄清楚。各种建模与流程工具都是做你说的这个用途的啊？

------解决方案--------------------
我也了解这个问题很大，但这就是我目前需要解决的啊。行政命令现在是我唯一可以使用的方法了，只有下方这个命令的领导有这个需求，呵呵，其他领导都是能闲一天是一天啊，员工更是如此。我的阻力好大啊！从头到尾都由我一个人来做，现在好像是我求着他们来做这个业务分析一样，因为这可能涉及下岗呀。
我对建模工具不是很熟悉，能推荐一些么。
------解决方案--------------------
这 个问题，就需要具体情况，具体处理了：
1、在做需要调研时，一定要先站在用户的角度去想问题，去学习业务流程，也就是做学生阶段。
2、遇到“加之懂业务的人通常不怎么懂计算机，所以他们说出来的话也很有二义性，不能准确地代表他们的真实想法。”这种情况，不要去想他们不懂计算机，不懂常识操作，而要用你的实际操作，去影响他们，让他们认识到计算机的好处，让他们在与你的接触中尝到电脑带来的优势性。 也就是做朋友阶段。
3、在前两步的基础上，写出一份有条理的需求报告，针对个别业务细节，可以准备两到三个不同的方案，来供用户选择。得到最终方案后，双方确定签字。 也就是最后的商业化阶段。
------解决方案--------------------
这个问题比较麻烦，主要看项目管理人员和系统分析师的。可以在项目启动时，要求客户派一两名业务骨干加入项目组，这个需要客户的大力配合；通过适合的需求获取方式（不同类型项目用不同的方法，比如原型化，用例图等）；也可以在需求规格说明书时要求客户签字（其实这个也就是让客户重视一下需求而已，签不签没多大意义）；在客户旁边开发，通过不断迭代，不断跟客户沟通，这个也需要客户配合。
------解决方案--------------------
跟我的情况差不多，但是不是我不理解初期的需求文档，而是按着文档开发到中途向客户汇报时客户说这不是他想要的，又TMD跟我说口头需求，哎，以客户为导向的没有办法呀