·抽象后的列表为读者提供了许多理解的余地，因此不同的读者对文件的理解可能不同。一个项目越大，读者越多，理解的方式就越多。
·从抽象后的列表中很难看出它是否完全。它们往往忽视了许多细节。
·顾客和开发者对这个列表的理解往往完全不同。
·这样的合同式的列表给顾客一个错误的安全的感觉，好像他们的要求都已列入了。但是由于这些列表本身对细节问题不能细述因此许多关键的细节问题实际上并未列出和解决。这些问题一直到后来软件开发时才被发现。那时开发者一般要与顾客再次讨论这些问题并试图按他们的意愿和条件来解决这些问题。
·这个列表对此后的系统设计不提供任何帮助，它们的结构无法直接进入新软件。
原型（Prototype）
从1980年代中开始，越来越多的人将作原型看作是解决需求分析的困难的办法。原型模拟最终软件的屏幕显示，这样用户可以看到最终软件将是什么样，而实际上在这些屏幕显示的背后还一切都空着呢。这样顾客可以在系统还没有建立之前就做出设计决定。当原型首次被使用的时候它们的效果被视为非常惊人。引入原型往往提高顾客与开发者之间的信息交换。原型的屏幕显示后来往往很少被改变，因此可以大大地降低费用。
但此后十多年的实际应用证明虽然原型是一种有用的技术，但它也有它的缺陷：
·经理人员在看到原型后往往不理解为什么到还要一段时间后最终设计才能完成。
·设计师往往将拼凑在一起的原型码用到后来真正的系统中，因为他们怕在再次编码时“浪费时间”。
·原型帮助解决设计决定和用户界面的设计，但是它们并不提供任何关于需求的信息。
·设计师和顾客有可能花费太多的时间和精力来设计用户界面，而忽视对作业过程的关心。
用例是一种纪录新系统或软件更换时的需求的技术。每个用例包含一个系统在作业时与用户或与其它系统之间交换信息的场景。一般用例避免使用术语，而尽量使用顾客、用户或他们的专家的语言。一般用例由软件开发者和顾客一起写成。
在1990年代中用例很快地成为了纪录需求分析的最主要的方式。尤其在它的发源地，在面向对象的程序设计中它的普及性非常高。但用例不仅可以用在面向对象的程序设计系统中，实际上用例本身并非面向对象的。
每个用例集中于描写如何来完成一个作业目标或任务。对传统的软件工程来说每个用例描写系统的一个特点。对大多数软件项目来说一个新的系统有多个（往往十几个）用例。不同的软件项目的格式或项目的进展都可能影响用例的细节性。
文章来源于领测软件测试网 https://www.ltesting.net/
