迷信一 需求分析完成后不能再改动
当然，笔者也主张尽量不要在完成后改动需求，因为这样会严重干扰后续工作；但需求往往是会变化的，特别是项目比较大，时间跨度比较长的时候，改动需求几乎 是不可能避免的。因为需求是带有前瞻性的，而未来是不可预测的。某个公司并不因为今天没有开展某项业务，就意味着在明天也不会开展这项业务；某项技术也并 不因为在今天没有应用，就意味着在明天也不会应用。同样道理，并不因为软件项目今天没有某项需求，就意味着在明天也不会有这项需求。我经常听到一些人总是 抱怨项目失败是因为需求老是在变——说实话，市场也经常在变，如果某人说公司亏损是因为市场老是在变，我想大家会笑掉大牙的。
需求变化是很正常的事情，在做需求分析时要充分考虑到这一点。所以正规的做法是架构师必须要全程参与需求分析。因为要考虑需求变化的影响，架构师必须要做好相应的准备。
迷信二 需求分析必须做得非常详细。
为了把需求分析做到非常详细，可以用UML的用例图，再配合协作图、顺序图和状态图；还可以参照IBM或者微软制定的一整套标准和规范——从这个层面上 说，IBM和微软的确是一流的企业（一流的企业制定标准，而且他们制定的标准和规则也是非常好的）。但是，如果仅仅理解一些皮毛和一些工具的应用就盲目跟 风，为了详细而详细则是极端错误的。在前面，笔者就谈到了需求是会变化的；当你预见了这种变化，很多时候是没有办法把需求分析做得很详细的。在这种情况 下，一味的在需求分析上面下功夫就非常不值得了。这时候，可能就有人要问：现在就模糊对待需求分析，那以后的软件开发怎么办？这个问题问得非常好，笔者推 荐《敏捷软件开发》——因为本文主要谈需求的问题，再者笔者的水平有限，所以各位还是读《敏捷软件开发》原文比较好，这里不再赘述。
迷信三 技术不是问题，没有实现不了的需求
这句话跟当年的“人有多大胆，地有多大产”有异曲同工之妙。不客气地说，能放出这种豪言的，根本就不适合做项目，如果是做销售，那还说得过去。技术制约从 来都是软件项目的瓶颈，回头看5年前，10年前的软件就会很容易发现，由于当时技术水平的制约，现在的很多功能在当时的条件下基本上就是不可能完成的任 务。想想微软的longhorn在砍掉了多项重量级应用后，最后缩减成Vista——连微软这种企业都有实现不了的需求（当然是短期的，随着技术的发展， 就能实现了），技术当然是非常大的问题。这也是架构师必须要全程参与需求分析的一个重要原因，凡是技术上实现不了的需求，一律砍掉；实现起来有难度的，经 过评估再决定是否保留。
后话：
有这么一帮人，谈起需求分析来头头是道；而真做起项目来他们的架构师却经常缺席需求分析。如果你不幸遇到这种人，还是为自己的项目祈祷吧。