使用用例获取需求
原文是：Usi
gUseCasesforrequireme
tscapturePeteMcBree
C1998McBree
Co
sulti
gmcbree
pcadvisio
com可在http21
ewtimesyeah
et找到。简介：开发都通常都使用典型场景sce
arios来理解一个系统的需要是什么和系统是怎样工作的。不幸的是，尽管开发都已经这样做了，但它极少用有效的形式归档。用例UseCases就是将这些场景获取正式化、形式化的技术。用例是Jacobso
在面象对象的软件工程中提出的，但它实际上是独立于面象对象的。用例是获取业务过程和系统需求的有效方式。而且技术本身是非常简单易学的。使需求可被浏览形式化场景获取是为了使用户和开发者都可以浏览这些场景。任何功能需求符号都必须满足以下两条准则：应易于需求源和浏览者理解，并且不应包含系统的形式与内容的任何细节功能需求是外部需求，用它来评估系统的设计和最终实现。应当以系统无关的方式获取买家stakeholders的需要和期望。用例令需求可被浏览用例正被广泛使用。与其它需求分析技术相比，用例已经取得成功，这是因为：用例将系统视为黑盒用例使了解需求的实现精度变得容易后者来源于前者。用例应该不涉及需求相关系统的任何内部结构，这样如果用例指出“提交对订单数据库的改变”或“在Web页面显示结果”，内部结构显而易见并可标识为潜在的设计限制。需求不应该涉及任何内部结构是因为：描述内部结构带给设计者额外的限制。没有这些限制设计者会有更大的自由来建立恰当的实现了外部可观察行为的系统，并有可能提供突破性的解决方案。
f工业对用例的接受用例是在大约六年前正式发布的，此后被绝大多数主要对象方法吸收。用例也已经被业务处理再工程协会busi
essprocessree
gi
erri
gcommu
ity吸收为描述现有及未来模式业务操作的有效方法。用例本身最近因其UML中的位置和地位再次得到强调。UML已经被OMG接受做为对象系统的标准建模语言。什么是用例用例本身是指一个用户或其它系统与要设计的系统进行的一个交互，这个交互是了达到某个目标goal。术语活动者Actor用来描述有该目标的人或系统。这个术语强调了任何人或系统拥有目标的事实。目标本身是一个动词短语，“客户：如下订单”，“店员：记录库存”。作为用例的一部分，有必要记录目标成功和失败的对于活动者和系统的含义。在下订单的实例中，目标达成可能包括货物交给活动者和公司收到相应的货款。仔细定义目标成败是定义系统范围scope的基础。因为对于一个简易的订单输入系统，目标达成可r