做软件需求重要是分解用例场景，没有用例不是需求。

软件工程这类书要学，不过软件工程软件需求关键是用例场景的合理建立，这条，好象没有什么大学教科书谈到，仿佛中国的大学计算机科学系教师统统没有做过软件项目的，完全没有这个概念。所谓的软件需求，如果不是变成走不通的伪代码，是用不上的美工方案，程序员对此除了干瞪眼是没辄的。

其中大的原因是从事网站或者类似的软件需求的许多人都不懂真正的软件需求是什么东西，包括我处理过的SAP/ERP项目这类都是同样的问题，尽管那不是网站；他们犯的一般共同的错误是把网页表现形式（那其实是美工的工作），以及内容的采排看作是需求，完全没有一个用例的观念。

用例，usecase，目前多见于UML下的对面向对象程序中的对象行为的表达；不过，这不是它的源泉；它之所以被看作是这类语言的标准URL描述手段，是因为面向对象本身是在虚拟程序中模拟真实世界那样地工作；而真实世界，是围绕着用例展开的。用例的观念其实也不能算是一个软件概念，只不过在软件领域定义得为精确而已，从每个人的生老病死，婚姻嫁娶，其实都是一个个的用例的描述和实施。用例，顾名思意，是假如（假设）出现某种情况，采取什么样的行动；可能会有什么样的结果；然后，根据这个结果，再采取什么样的行动……直到得到希望的某个终结局。

用例也叫场景，软件，实际上是对场景操作过程的描述，而不是一堆版面框架网页的集成。没有用例支持不叫软件，更加不叫项目??连垃圾都算不上。很多时侯我们说需求不明确，其实是说这个用例不清晰；在电子商务网站中，除了人员素质导致对基本概念方法不明白外，可能的导因是商业模式不明确，或者不成立。这个成立与否，实际上可以从上面的假如如何那般的推导中进行初步的可行性推演。所以，程序员实际上有两个层次，一个是你说什么他做什么，但永远没有结果的。他却的确实现了你（需求人员）提出的所有要求，但这个项目却必然是永远没有结果的，因为，它本身只是把这个程序员当成网页编辑用了，项目没有基本用例的支持。我想90%的程序员是这类"程序员"，没有用例明确定义也没有软件能力的评估，因为软件人员不是美工。另一种程序员则可以从上诉推演中发现整个项目本身有没有用例，以及用例是否合理（理论上没有明显的逻辑障碍）；虽然程序员一般不应该关心商业模式是否合理，但实际上他有这个能力，常常是第一个发现商业模式的问题，假如他也关心的话。

可惜大部分用户需求人员不明白这个道理，反而可能会以为程序员是在推卸责任，或者是刁难需求；也正因为这个原因，需求人员和实现人员的冲突在项目中屡见不鲜，倒不是个人矛盾的冲突，而是由于双方没能有一个基本的立足点。我见过这样的项目，需求人员建一个大型网站的需求是一大箩的每个网页的非常详细的描述，到每个字每个连接……直至每个网页出现的次序，项目经理说一个笑话：万一他摔一跤，这箩子东西鬼才能再捡回原来的模样。的确，负责需求的客户方副老总和一帮企业需求编辑辛苦做了两个月，但其实这不是需求，而是使用这个项目软件的具体编辑排版的安排；根本不是程序员要看的东西。程序员需要的是使用这个网站时需要有那几种用例逻辑，然后抽象出其中的对象，根据对象建立存储方式（象数据库存储结构）和内容采摘方式。那大箩东东，实际上什么用处也没有的。开发软件如同建房子，旁观者可能问一句："建房子啊"拍手说明白了，但对于开发员来说，如果得不到准确的房子细到砖砖瓦瓦的准确设计（需求定义）；要知道建小平房和建金茂大夏都是建房子，建宾馆还是建殡仪馆也是建房子，到底客户要的是什么房子合适，不搞清楚干下去的程序都是不负责任的，或者是冒牌货。