在对系统的设计范围进行确认后，下一阶段的工作便是划分每个业务目标的层次结构

    目标层次的划分如下图：

  水平面以上的为概要目标，对相似功能业务的一种概括。对于属于概要目标范围的用例说明，用例序号之后做(*)号以作区分

  水平面上的为用户目标，也就是业务功能点。

  水平面一下的为子功能点，包含于用户目标之中。对于属于子功能范围的用例说明，最好在用例序号之后做(+)号以作区分

   执行者与场景：

      用例目标层次划分后，该到用户目标用例的定义，这里面最主要的概念就是执行者与场景

      a.收集一个用户目标的所有场景，定义主成功场景。其他场景为扩展。

         主执行者完成了目标，所有系统相关者的需求都被满足，这个场景就是主成功场景。

         其他的成功场景和所有的错误处理场景，都会在主成功场景的扩展中进行描述

      b.场景主体的描述

          两个执行者之间的交互过程——客户输入地址等

          保护系统客户需求的确认过程——系统确认PIN密码等

          满足系统客户需求的内部变化——系统扣除某个产品的库存等

      1. 使用简单的语法

         句子不宜过长，句子结构不要过于复杂。平铺直叙，简明扼要。重复解释一个问题，有时不失为一种必要。

      2. usecase步骤的描述尽量不要过多

         10步以内。太长不易于理解。让读者看起来很繁琐。

      3.增加直观性，辅以图形化的手段来阐释：UML 的usecase图。图形唯一的缺点在于维护，一点改变，就可以让所有的图重画。

     确定系统边界:

          1.in-out list

         Topic，为系统需求点。以in 标志为系统内部需求，以out标志系统外部需求。系统内的属于工作内容，系统外的属于考虑范畴。内外表法不只可以用在用例编写阶段，也可以用在需求分析阶 段。

       2 actor-goal list

   1.问题与客户达成共识

      这个共识有签字式的——协议，也有非签字式的——确认。

     记住，所有的共识都基于双方的理解。文字的东西往往会引起歧义，电话确认又往往失于严肃。图形化的方法可以弥补这些缺憾。个人经验，文字的描述比较适用于 早起的问题收集，或者是简单的问题确认。复杂的问题需要交给图形化来解决，wireframe——虚拟界面，是个不错的选择。它除了可以收集输入输出数据 项，还可以给客户一个比较直观的感觉。当然，这个也相对费时一些。但对于需求的确认至关重要，可以减少客户与软件人员的误解。

   2.找出问题背后的发生原因

      韦伯说过，社会行为是行动者赋予主观意义的人类行为。任何人（团体、组织）的活动在社会中都会牵涉到另一个人（团体、组织）。任何行为本身都具有意义，如 无意义，则无行为。

     扯远了，还是谈谈需求问题。客户问题的提出，是为了解决问题。要想解决问题，就必需知道问题是如何产生的。也就是说，要想找到蛋，就必需先找到下蛋的鸡， 研究它的活动轨迹，最后定位鸡蛋的位置——解决问题。在社会学里，找到了行为的意义，也就掌握了行为本身。记住，无意义就无行为，有行为则必有意义。

    3.确定系统用户

      包括用户的角色和权限。这是系统能够运行起来的基本条件。如果不能引起足够的重视，对于系统将是严重的灾难。笔者曾做过一个office resource management系统，从初始的一个角色对应一个office,到一个role对应多个office,一个人一个角色，到一个人多个角色。修改之多， 之繁重，不能与人言。

    4.确定系统边界

      在实践过程中，个人引入了"内外表"来定义系统边界。这个在稍后的usecase中具体描述

    5.划分子系统的三个原则：

       a.职责不同的功能划归不同子系统：将一类包含统一职责的功能划分为一个子系统。如权限管理系统与业务系统分离。（企业系统需要统一的权限管理：安全认证 以及系统授权），再如社会保障信息系统按业务类别的划分：养老，医疗，工伤，失业，生育。按照业务规则划分又可以分为：公共业务（单位，个人），待遇，报 表

       b.需要不同开发技能的单元划归不同子系统:如报表系统与数据仓库的独立开发。

       C.软件工程管理的划分：

          1)兼顾工作量的相对均衡，进一步切分太大的子系统。交给不同的team进行并行开发。

          2)同一类公用\复用模块划分为一个子系统：如规则引擎，简单报表，css theme管理，数据同步\交换，基础平台的二次开发(统一弹出式查询,输入校验,页面组件)等等。

题解：做了多个系统的需求分析之后，有做总结的必要了。

      在需求分析阶段，甚至是整个软件开发阶段，需求的变化是唯一不变的东西。项目中最难做的也是如何去控制需求。这个有点复杂，放到后续文章去说，先说说如何 将客户的问题信息转化为需求：

1.分清客户的问题是“需要”还是一个“需求”

   需要，指问题已明确。需求则表示问题未明确

2.分清最好有与必须有。

   必须有，这个是硬性需求；最好有，非硬性需求。根据项目的实际情况，如成本，时间(计划)，范围的约束来综合评定。

3.客户对问题的描述是为了说明问题还是提供一种解决方案

   在收集和分析客户需求时，一定要搞清楚客户是在描述问题本身还是问题的解决方案

4 有哪些人使用这个系统

   俗语说，有什么样的客户，就有什么样的系统。客户的能力以及偏好，包括理解力，对系统的设计至关重要。

5.有那些人不喜欢这个系统

   是办公室政治？是易用性？是稳定性？maybe something else

6.挖掘潜在问题，形成问题链

   客户大都没有系统训练，他们对问题的描述往往比较零散和随意。如何将问题窜成链，挖掘更深层次的问题是需求分析人员需要帮助他们完成的。记住是帮助，不是 强迫他们按照你的思维思考问题。这里面最难的部分属于如果从软件专业人员的角度提出建议。同时又要让自己的的建议不干扰到客户的原始需求。

   根据个人的经验，需求阶段最大的悲哀在于你出于最好的目的却造成了最坏的结果——建议客户如何如何，建议有时会掩盖客户的真实想法。客户信任我们的建议， 他们误以为我们的建议可以解决他们的问题，然而有时事与愿违。所以，我们应该多听客户的想法，延迟你的建议与引导。

7.非功能性需求的采集

  易用性，扩展性，交互性，性能，安全性等等。