需求分析过程

需求分析过程

  
1、业务建模的目标是通过用例模型的建立来描述用户需求，需求规格说明书通常在这个阶段产生。这个阶段通常使用业务用例和业务用例实现两种类型；

2、用例分析是系统分析员采用OO方法来分析业务用例的过程，这个阶段又称为概念模型阶段。这个阶段通常使用无类型的用例。用例分析是一个过渡过程，业务架构通常在这个阶段产生。

3、系统建模是将用户的业务需求转化为计算机实现的过程。这个阶段通常使用无类型的用例和用例实现两种类型。系统范围，项目计划，系统架构通常在这个阶段形成雏形（在系统分析阶段确定）。

涉众

业务建模首先要发现和定义涉众。

什么是涉众：涉众是与要建设的业务系统相关的一切人和事。首先要明确的一点是，涉众不等于用户，通常意思的user是指系统的使用者，这仅是涉众中的一部分。

如何寻找涉众，通常从以下几类寻找：

• 业主

业主是系统建设的出资方，投资者，它不一定是业务方。比如可以假设一个图书馆的网络化建设是由一家国际风险投资机构投资的，它本身并不管理图书馆，它只是从资本上拥有这个系统并从借书收入中获得回报。 
了解业主的期望是必须和重要的，业主的钱是这个项目存在的原因。若系统建设不符合业主的期望，撤回投资，那么再好的愿望也是空的。 
一般来说，业主关心的是建设成本，建设周期以及建成后的效益。虽然这些看上去与系统需求没什么大的关系，但是，建设成本、建设周期将直接影响到你可以采用的技术，可以选用的软件架构，可以承受的系统范围。一个不能达到业主成本和周期要求的项目是一个失败的项目，同样，一个达到了业主成本和周期要求，但却没有赚到钱的项目仍然是一个失败的项目。

• 业务提出者

业务提出者是业务规则的制定者，一般是指业务方的高层人物，比如CEO，高级经理等。他们制定业务规则，圈定业务范围，规划业务目标。他们的期望十分十分的重要，实际上，系统建设正是业务提出者经营和管理意志的体现。他们的期望一般比较原则化和粗略化，但是却不能违反和误解，否则系统将有彻底失败的危险。业务提出者一般最关心系统建设能够带来的社会影响，效率改进和成本节约。换句话说，他们只关心统计意义而不关心具体细节，但是，如果建设完成的系统不能给出他们满意的统计结果，这必定是一个失败的项目。在系统建设过程的沟通中，他们的意志一般是极少妥协的，系统分析员不必太费心去试图说服他们接受一个与他们意志相左的方案。实际上，由于他们的期望是非常原则化和粗略的，因此留给了系统建设者很大的调整空间和规避风险的余地。

• 业务管理者

业务管理者是指实际管理和监督业务执行的人员，一般是指中层干部，起到将业务提出者的意志付诸实施，并监督底层员工工作的作用。他们的期望也很重要，一般也是系统的主要用户之一。他们关心系统将如何实现他们的管理职能，如何能方便的得知业务执行的结果，他们如何将指令下达，以及如何得到反馈。业务管理者的期望相对比较细节，是需求调研过程中最重要的信息来源。系统建设的好坏与业务管理者的关系最多，也是系统分析员最需要下功夫的。系统分析员必须要把业务管理者的思路，想法弄清楚，业务建模的结果也必须与业务管理者达成一致。在系统建设过程中，业务管理者的期望可以有所妥协，一个经验丰富的系统分析员可以给他们灌输合理的管理方式，提供可替代的管理方法，以规避导致高技术风险或高成本风险的不合理要求。

• 业务执行者

业务执行者是指底层的操作人员，是与将来的计算机直接交互最多的人员。他们最关心的内容是系统会给他们带来什么样的方便，会怎样的改变他们的工作模式。他们的需求最细节，系统的可用性，友好性，运行效率与他们关系最多。系统界面风格，操作方式，数据展现方式，录入方式，业务细节都需要从他们这里了解。他们将成为系统是否成功的试金石。Look and Feel ，表单细节等是系统分析员与他们调研时需要多下功夫的地方。这类人员的期望灵活性最大，也最容易说服和妥协。同时，他们的期望又往往是不统一的，各种古怪的要求都有。他们的期望必须服从业务管理者的期望，因此，系统分析员需要从他们的各种期望中找出普遍意义，解决大部分人的问题，必要时可以依靠业务管理者来影响和消除不合理的期望。

• 第三方

第三方是指与这项业务而关联的，但并非业务方的其他人或事。比如在这个事例中，借阅人借书时需要交费，若交费是通过网上银行支付的，则网上银行就成为了网上借书系统的一个涉众。 
第三方的期望对系统来说不起决定性意义，但会起到限制作用。最终在系统中，这种期望将体现为标准、协议和接口。 
另一种典型的第三方是项目监理，系统分析员也必须弄清楚监理的期望。

• 承建方

承建方，也就是你的老板。老板的期望也是非常重要的。老板关心的是通过这个项目，能否赚到钱，是否能积累核心竞争力，是否能树立品牌，是否能开拓市场。老板的期望将很大的影响一个项目的运作模式，技术选择，架构建立和范围确定。比如，老板试图通过这个项目打开一个市场，树立起品牌，不惜成本，那么，系统分析员需要尽可能的深入挖掘潜在业务，建立扩展能力很强，但成本较高的业务架构，选择那些较新，但风险较高的技术。反之，如果老板只想通过这个项目赚更多的钱，系统分析员就需要引导业务方压缩业务范围，选择风险小的成熟技术，甚至不用考虑业务架构，考虑系统的可维护性，而较少考虑系统扩展能力。 
一个业主满意但老板不满意的项目，恐怕也不是一个成功的项目吧？

• 相关的法律法规

相关的法律法规是一个很重要的，但也最容易被忽视的涉众。这里的法律法规，既指国家和地方法律法规，也指行业规范和标准。例如，这个借阅系统中要建立借阅人档案，就必须保障借阅人的隐私权；要与网上银行交易，必须遵守信息安全法等。若遇到业务方提出违反了法律法规的要求时，系统分析员要能给他们指出来，说服无果的情况下要在合同里留下免责条款。否则一不小心惹上官司可是件郁闷的事。 
另外，有时必须得遵守一些行业规范。例如本事例是网上借阅，网络需求决定了需要遵守HTML规范，才能保证借阅者能正常浏览网页。

• 用户

用户是一个抽象的概念，是指预期的系统使用者。用户可能包括上述的任何一种涉众。用户涉众模型建立的意义是，每一个用户将来都可能是系统中的一个角色，是实实在在参与系统的，需要编程实现。而上述的其它涉众，则有可能只是在需求阶段有用，最终并不与系统发生交互。在建模过程中，概念模型的建立和系统模型的建立都只从用户开始分析，而不再理会其它的涉众。在Rose中建模的时候，也只需要建立用户的模型，其它涉众则只需要体现在文档中即可。

用例定义

Use Case（用例）是一个UML中非常重要的概念，在使用UML的整个软件开发过程中，Use Case处于一个中心地位。

Use Case 是对系统功能的描述，一个Use Case描述的是系统功能的一部分，这一部分一定是在逻辑上相对完整的功能流程。

Use Case 是单个任务，能产生有用的结果，由系统最终用户执行。"最终用户"和"结果"的定义可以多种多样 --例如，最终用户可能是自动化子系统，而结果的种类也可以随着用例的不同而有着根本上的不同。有时结果是实际产品，如报表，而有时结果是公司目标，如雇佣一个雇员。但结果始终有一个可以感知（由用户）的值。

从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。因此用例关注于客户想要系统提供的价值，而不是我们在系统内部如何细分和构造的。它不要是系统按照功能分解的蓝图。

用例类型

在Rose中默认的类型有business usecase , business usecase realization和use case realization三种。相应的，就是指

 

用例模型

用例模型分为两种：

一.业务用例 

业务用例着重于业务操作。它们表示实现业务目标的业务中的具体工作流。业务过程可能涉及手工和自动过程，并且在一段长期的时间内进行。

二.系统用例

系统用例着重于要设计的软件系统。参与者如何与软件系统进行交互？我们在系统用例说明中书写的事件流应该足够详细，从而用作编写系统测试脚本的出发点。

用例模型主要包括以下两部分内容：

一.   用例图(Use Case Diagram)

用例图确定系统中所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述。它使我们对系统的功能有了一个整体的认知，我们可以知道有哪些参与者会与系统发生交互，每一个参与者需要系统为它提供什么样的服务。

用例图主要由以下模型元素构成：

• 参与者 (Actor)

   参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。

• 用例 (Use Case)

   用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。

• 关联 ( Association)

   关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。

三种模型元素在UML中的表述如图 

 

   用例图中箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者；如果不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。在参与者和用例之间的信息流不是由关联来表示的，该信息流是缺省存在的（用例本身描述的就是参与者和系统之间的对话），并且信息流向是双向的，它与关联箭头所指的方向亳无关系。

二.   用例规约(Use Case Specification)

用例图中并没有描述出参与者与系统之间对话的细节，针对每一个用例都应该有一个用例规约文档与之相对应，该文档用事件流来描述用例的细节内容。

---

用例建模

在用例建模的过程中，我们建议的步聚是先找出参与者，再根据参与者确定每个参与者相关的用例，最后再细化每一个用例的用例规约。

首先，确定参与者

   所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲，参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手：

   系统开发完成之后，有哪些人会使用这个系统？

   系统需要从哪些人或其他系统中获得数据？

   系统会为哪些人或其他系统提供数据？

   系统会与哪些其他系统相关联？

   系统是由谁来维护和管理的？

其次，确定用例    

   找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。寻找用例可以从以下问题入手（针对每一个参与者）：

   参与者为什么要使用该系统？

   参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？

   参与者是否会将外部的某些事件通知给该系统？

   系统是否会将内部的某些事件通知该参与者？

再次，绘制用例图

最后，描述用例规约

---

用例规约模板

1. 用例编码：用例名称

（用例编码采用大写字母和数字组成。用例名称使用动宾结构句子。）

[所有用例都应该有名称。名称应始终以用户为中心，而不是以系统为中心，从用户的角度来命名，而不是以系统的角度命名。

要为用例指定某些易于管理的身份，这样就可以方便地从其它文档引用它。通常，需要一个用例编号]

1.1  简要说明

[说明中应简要表述用例的作用和目的，描述用例实现什么。一个段落即足以作此说明。]

2. 参与者

3. 前置条件

[用例的前置条件是执行用例之前必须存在的系统状态。]

3.1    < 前置条件一>

4.界面（可选，涉及界面的包含此项）

描述涉及的界面原型。

界面说明

描述界面上各元素。包括显示的数据项及操作按钮。
涉及数据表：
说明界面元素所涉及的数据表。
4.1       数据项

数据项	数据类型长度	初始数值	数据来源	必录项否	备注
界面元素名称	界面元素数据类型及长度	界面元素初始化时所赋值	初始数值的数据来源(代码表名或数据表名)	是否为必录数据

4.2       按钮功能
描述各按钮及其功能说明。

5. 事件流

[包括基本流和备选流，事件流应该表示出所有的场景。用例在实际执行的时候会有很多的不同情况发生，称之为用例场景；也可以说场景是用例的实例，我们在描述用例的时候要覆盖所有的用例场景，否则就有可能导致需求的遗漏。在用例规约中，场景的描述可以由基本流和备选流的组合来表示。场景既可以帮助我们防止需求的遗漏，同时也可以对后续的开发工作起到很大的帮助：开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例。]

5.1  基本流

[当主角有所行动时，此用例随即开始。用例应说明主角的行为及系统的响应。应按照主角与系统进行对话的形式来逐步引入用例。

 基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。我们建议用以下格式来描述基本流：

1) 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。

2) 用一句简短的标题来概括每一步骤的主要内容。

3) 每一步骤都需要从正反两个方面来描述1)参与者向系统提交了什么信息；(2)对此系统有什么样的响应。在描述参与者和系统之间的信息交换时，需指出来传递的具体信息。]

5.2  备选流

[备选流负责描述用例执行过程中异常的或偶尔发生的一些情况，备选流和基本流的组合应该能够覆盖该用例所有可能发生的场景。在描述备选流时，应该包括以下几个要素：

1) 起点：该备选流从事件流的哪一步开始；

2) 条件：在什么条件下会触发该备选流；

3) 动作：系统在该备选流下会采取哪些动作；

4) 恢复：该备选流结束之后，该用例应如何继续执行。

备选流的描述格式可以与基本流的格式一致，也需要编号并以标题概述其内容，编号前可以加以字母前缀A(Alternative)以示与基本流步骤相区别。]

5.2.1          < 第一备选流>

5.2.2          < 第二备选流>

[在一个用例中很可能会有多个备选流。为了使表达更清晰，应将各个备选流分开说明。使用备选流可以提高用例的可读性，并防止将用例分解为过多的层次。应切记，用例只是文本说明，其主要目的是以清晰、简洁、易于理解的方式记录系统的行为。]

6. 后置条件

[用例的后置条件是用例一执行完毕系统可能处于的一组状态。用例常常会更改系统状态（例如，现在帐户余额下降了），而不是生成实际产品。另外，需要在某些用例之后执行其它用例以便完成整个任务。此类信息都应填写在"后置条件"部分中。即，可以在用例完成之后检查后置条件，以便确定用例是成功还是失败。]

6.1    < 后置条件一>

7. 业务规则

8. 特殊需求

[特殊需求通常是非功能性需求，它为一个用例所专有，但很难或很自然的在用例的事件流文本中表述。特殊需求的示例包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性（包括可用性、可靠性、性能或支持性需求）。此外，其他需求如操作系统及环境、兼容性需求和设计约束也应在此节中记录。需要注意的是，这里记录的是专属于该用例的特殊需求；对于一些全局的非功能性需求和设计约束，它们并不是该用例所专有的，应把它们记录在《补充规约》中。]

8.1   < 第一特殊需求>

9. 扩展点

[此用例的扩展点。扩展关系可以根据一定的条件来决定是否将扩展用例的事件流插入基础用例事件流，并且插入点可以有多个。]

9.1    <扩展点名称>

[扩展点在事件流中所处位置的定义。]