软件需求的关键是分解用例场景.doc

软件需求的关键是分解用例场景 做软件需求最重要就是分解用例场景，没有用例就不是需求。 软件工程这类书要学，不过软件工程软件需求最关键就是用例场景的合理建立，这条，好象没有什么大学教科书谈到，仿佛中国的大学计算机科学系教师统统没有做过软件项目的，完全没有这个概念。所谓的软件需求，如果不是变成走不通的伪代码，就是用不上的美工方案，程序员对此除了干瞪眼是没辄的。 其中最大的原因就是从事网站或者类似的软件需求的许多人都不懂真正的软件需求是什么东西，包括我处理过的 SAP/ERP 项目这类都是同样的问题，尽管那不是网站；他们犯的一般共同的错误就是把网页表现形式（那其实是美工的工作），以及内容的采排看作是需求，完全没有一个用例的观念。 用例， usecase，目前多见于 UML 下的对面向对象程序中的对象行为的表达；不过，这不是它的源泉；它之所以被看作是这类语言的标准 URL 描述手段，是因为面向对象本身就是在虚拟程序中模拟真实世界那样地工作；而真实世界，就是围绕着用例展开的。用例的观 念其实也不能算是一个软件概念，只不过在软件领域定义得最为精确而已，今天从每个人的生老病死，婚姻嫁娶，其实都是一个个的用例的描述和实施。用例，顾名思意，就是假如（假设）出现某种情况，采取什么样的行动；可能会有什么样的结果；然后，根据这个结果，再采取什么样的行动……直到得到希望的某个最终结局。 用例也叫场景，软件，实际上就是对场景操作过程的描述，而不是一堆版面框架网页的集成。没有用例支持就不叫软件，更加不叫项目 —— 连垃圾都算不上。很多时侯我们说需求不明确，其实就是说这个用例不清晰；在电子商务网站中，除了人员素质 导致对基本概念方法不明白外，最可能的导因就是商业模式不明确，或者不成立。这个成立与否，实际上可以从上面的假如如何那般的推导中进行初步的可行性推演。所以，程序员实际上有两个层次，一个是你说什么他做什么，但永远没有结果的。他却的确实现了你（需求人员）提出的所有要求，但这个项目却必然是永远没有结果的，因为，它本身只是把这个程序员当成网页编辑用了，项目没有基本用例的支持。我想 90%的程序员是这类 "程序员 "，没有用例明确定义也就没有软件能力的评估，因为软件人员不是美工。另一种程序员则可以从上诉推演中发现整个项目本身有 没有用例，以及用例是否合理（理论上没有明显的逻辑障碍）；虽然程序员一般不应