原型帮助解决设计决定和用户界面的设计，但是它们并不提供任何关于需求的信息。
　
　　设计师和顾客有可能花费太多的时间和精力来设计用户界面，而忽视对作业过程的关心。
　
　　用例（Use Case）
　
　　参见用例用例是一种纪录新系统或软件更换时的需求的技术。每个用例包含一个系统在作业时与用户或与其它系统之间交换信息的场景。一般用例避免使用术语，而尽量使用顾客、用户或他们的专家的语言。一般用例由软件开发者和顾客一起写成。
　
　　在1990年代中用例很快地成为了纪录需求分析的最主要的方式。尤其在它的发源地，在面向对象的程序设计中它的普及性非常高。但用例不仅可以用在面向对象的程序设计系统中，实际上用例本身并非面向对象的。
　
　　每个用例集中于描写如何来完成一个作业目标或任务。对传统的软件工程来说每个用例描写系统的一个特点。对大多数软件项目来说一个新的系统有多个（往往十几个）用例。不同的软件项目的格式或项目的进展都可能影响用例的细节性。
　
　　用例描述系统在运行时与外部执行者之间的信息交换。外部执行者是任何系统外的、与系统交换信息的物件或人物。它们可以是用户、用户的角色或其它系统。
　
　　用例将系统当作一个“黑匣子”，它从外部来看与系统之间的信息交换（包括系统的回答）。这样它简化对系统的需求的描写而且防止对系统的工作方式作任何过早的假设。
　
　　每个用例应该符合下述条件：描写完成作业目标的作业任务不包含任何编程码有一定的细致性足够短，一个程序员应该可以在一个版本的工作中独立完成这个用例所描写的作业过程。
　
　　在描写功能需求时用例非常好用，但它们不适合描写非功能需求。
　
　　确认持关键信息者

　　从1990年代开始确认持关键信息者被确定为一个非常关键的过程。它同时也是需求分析的第一步。此前经理人员往往被认为是持关键信息者。许多系统是按照这些经理人员的设想设计的，而实际的用户很少或根本没有对设计做任何贡献。这样的系统往往是大失败。因此在1970年代和1980年代在软件工程师中渐渐地持关键信息者的概念扩展到主要用户，后来还扩展到次要用户。在1990年代中工程师们更加从一个系统整体的观念上来确定持关键信息者。他们渐渐认识到不但在雇佣他们的顾客中有持关键信息者，其他持关键信息者包括：

　　与顾客横向相连（或应该横向相连）的组织

　　顾客的后勤办公室或类似的组织

　　高级经理人员

　　成功地确认持关键信息者是完整地完成需求分析的基础。
　

上一页  [1] [2] [3] 

【责编:Lili】