需求分析读书笔记（一）

一.用例（usecase）：

  1.定义：某个参与者（actor）要做的一件事。

  2.特征：

    2.1 这件事是相对独立的。这意味着它不需要与其它用例交互而独自完成参与者的目的。

    2.2 这件事的执行结果对参与者来说是可观测的和有意义的。

    2.3  这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。

    2.4 这件事必然是以动宾短语形式出现的。即，这件事必须有一个动作和动作的受体。

 3.用例的类型：业务用例（business usecase） ，业务用例实现（business usecase realization），用例实现（use case
realization），若不指定类型，则它就是通常意义上的use case。

  4.用例的粒度：，一个系统的业务用例定义在多于10个，少于50个之间。不论粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的。

二. 需求分析的阶段

    一般来说，需求分析要经过业务建模，用例分析和系统建模三个阶段才能完成需求工作。

    1、业务建模的目标是通过用例模型的建立来描述用户需求，需求规格说明书通常在这个阶段产生。这个阶段通常使用业务用例和业务用例实现两种类型；
    2、用例分析是系统分析员采用OO方法来分析业务用例的过程，这个阶段又称为概念模型阶段。这个阶段通常使用无类型的用例。用例分析是一个过渡过程，但笔者认为其非常重要，业务架构通常在这个阶段产生。
    3、系统建模是将用户的业务需求转化为计算机实现的过程。这个阶段通常使用无类型的用例和用例实现两种类型。系统范围，项目计划，系统架构通常在这个阶段形成雏形（在系统分析阶段确定）。

三 涉众分析

一般来说，只有当以下工作都完成，才能说业务模型建立完成，它们是：
   a 发现和定义涉众
   b 画定业务边界
   c 获取用例
   d 绘制用例场景图
   e 绘制业务实体模型（领域模型）
   f 编制词汇表

   涉众通过以下大类去寻找：

  1.业主 ： 业主是系统建设的出资方，投资者，它不一定是业务方。

  2.业务提出者：业务提出者是业务规则的制定者，一般是指业务方的高层人物，比如CEO，高级经理等。他们制定业务规则，圈定业务范围，规划业务目标。

  3.业务管理者：业务管理者是指实际管理和监督业务执行的人员，一般是指中层干部，起到将业务提出者的意志付诸实施，并监督底层员工工作的作用。他们的期望也很重要，一般也是系统的主要用户之一。

  4.业务执行者：业务执行者是指底层的操作人员，是与将来的计算机直接交互最多的人员。他们最关心的内容是系统会给他们带来什么样的方便，会怎样的改变他们的工作模式。

  5.第三方：第三方是指与这项业务而关联的，但并非业务方的其他人或事。

  6.承建方：承建方，也就是你的老板。老板的期望也是非常重要的。老板关心的是通过这个项目，能否赚到钱，是否能积累核心竞争力，是否能树立品牌，是否能开拓市场。

  7.相关的法律法规：相关的法律法规是一个很重要的，但也最容易被忽视的涉众。这里的法律法规，既指国家和地方法律法规，也指行业规范和标准。

四 ，业务建模一般步骤和方法

    第一步：从涉众中找出用户。在ROSE中，应该使用business actor 类型。

    第二步：找出每个用户要做的事，即业务用例，在ROSE 中应使用Business use case类型。

    第三步：利用业务场景图帮助分析业务流程，在ROSE 中，这个阶段最好使用活动图Activity diagram。

    第四步：绘制用例场景图。与业务场景图不同的是，用例场景图只针对一个用例绘制该用例的执行过程。强烈推荐使用activity diagram。

    第五步：从第三步或第四步中绘制的活动图中找到每一步活动将使用到的或产生的结果。这是找到物的过程。找到后，应当建立这些物之间的关系。在ROSE中，这称为业务实体模型。应该使用business entity 类型。

     图例：

       1.用户：

2.业务用例

 

3.业务场景

  

4.业务用例实现视图

5.业务用例场景

6.程业务实体视图：

 五，用例规约的编写

    分类：全局规则，交互规则，内禀规则，补充规则

 

本文是网络ID为coffeewoo的作者原创编写，原始出处为http://coffeewoo.itpub.net

 

转载于:https://www.cnblogs.com/select/p/3959934.html