基于业务流程再造的IT项目用例分析基于业务流程再造的IT项目用例分析.doc

基于业务流程再造的IT项目用例分析 摘要：在it项目中，业务流程再造从根本上重新思考并彻底重新设计业务流程，系统的用例分析应当以业务为中心，结合参与者视角，才能较完整和系统地发现、描述用例，表达客户的行为需求或功能需求。 abstract: in it projects, business process reengineering fundamentally rethinks and radically redesigns business processes. the system’s use-case analysis should be based on business center and combine the participants perspective, then it can be more complete and systematic manner to find use cases, describe use cases and express the customer behavior needs or functional requirements. 关键词： 用例；业务流程再造；需求分析 key words: use-case；business process reengineering；requirements analysis 中图分类号：tp30 文献标识码：a 文章编号：1006-4311（2012）11-0178-02 0 引言 息系统项目开发中需求分析的重要地位不言而喻，在需求阶段出现的错误会一直延续到系统的设计阶段和实施阶段，其结果往往是为纠正错误付出昂贵的代价甚至导致项目失败。然而如何才能确定客户的需求却是困扰系统分析师的首要难题，我们往往很难通过简单的询问客户来真正了解到客户所需要的内容。因为很多时候客户一开始也只有一些初步的功能要求，给不出明确的想法，一个流传盛广的冷笑话是：“我知道这就是我所要求的信息系统，但是它不是我想要的。” 1 用例与需求分析 在rup中用例被定义为“由一组用例实例构成，每个实例是系统所执行的一系列活动，以此产生对特定参与者具有价值的可观察结果。”它被用于说明系统的参与者使用系统以实现某些目标，广泛应用于需求的发现和记录。一般认为用例主要是说明系统如何工作的功能性需求或行为需求，它是以参与者为中心，从参与者的角度来描述它要做的工作，并分析这些工作之间是如何交互的，既所谓用例驱动的过程方法。 用例强调了需求分析的两个态度：一是关注系统的用户或参与者来编写需求，询问其目标和典型情况；另一个是关注理解参与者所考虑的有价值结果。有价值的可观察结果对用户来说正是系统的实现目标，通常和业务用例直接对应。同时，我们还应该注意到用例是由参与者发起的，不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。 在信息系统开发中需求分析过程大致可以分为三个阶段：理解应用域（业务建模），建立概念模型阶段和系统建模。其中业务建模的目标是通过用例模型的建立来描述用户需求，需求规格说明书通常在这个阶段产生；而概念模型阶段是系统分析员采用面向对象的方法来分析业务用例的过程，业务架构通常在这个阶段产生；最后，系统建模是将用户的业务需求转化为计算机实现的过程，系统架构通常在这个阶段形成雏形（在系统分析阶段确定）。从这三个阶段我们可以看出，用例分析是需求分析阶段的核心，我们需要在用例中包含满足所有涉众关注点的事物。 那么，信息系统开发中该如何来确定用例的参与者，发现用例，完成用例的场景描述呢？通常的做法，系统分析师首先会定义“涉众”，可能包括投资人、项目发起人、项目管理者、项目执行者、第三方、相关法律法规和客户等。再在此基础上确定系统的用户，即用例的参与者，问他们类似的问题：你工作主要做什么？这件事是谁交待办的？做完了你需要通知或传送给谁吗？做这件事情你都需要填写些什么表格吗？把这些问题的答案汇集起来就是业务用例。这是目前广泛采用的一种获取用例的有效方式，系统分析师再配合参与者的业务代表进一步就可以完成业务用例文本情节的描述，这种描述方式是完全站在参与者的角度，强调了用户的目标和观点。 然而，如果新系统相对于旧系统的业务发生了调整，作为参与者业务代表并不总是清楚自己在新系统中将完成哪些工作，难免有“不识庐山真面目，只缘身在此山中”的困