第三章 - 需求分析

需求分析定义

• 需求分析的目标就是搞清楚用户真正想要的系统是什么以及存在哪些约束条件。
• 需求分析是软件开发的输入，“垃圾入，垃圾出”，所谓“失之毫厘，谬以千里”。
• 需求分析的挑战：
  • 分析人员借助各种手段熟悉、了解和掌握相关的业务领域，解决方案需要经过思考和分析
  • 每个人包括领域专家们对于系统的全局都是一个局部，很难预知哪些领域信息会对以后的开发产生影响
  • 客户的想法毫无征兆的变化

用户需求与系统需求

• 由客户为主导制定的需求文档称为用户（业务）需求
• 由开发者为主导制定的需求文档称为系统需求
• 系统需求是对用户需求的细化和完善。系统需求面向开发，用户需求面向委托方或者用户，用户需求需要得到委托方确认。

涉众（Stakeholder）

• 宽泛概念：是与目标系统相关的一切人和物，他们对目标系统的构建会有一定的影响。可以是提出系统原始需求的人，可以是委托方，也可能是使用目标系统的最终用户等等。
• 涉众的重要程度是不同的。准确的识别出来，并确定其优先级。需要斡旋和协调，让目标系统满足大多数涉众的要求
• 常见涉众：最终用户、投资者、业务提出者、业务管理者、业务执行者、第三方、开发方、法律法规。

系统目标

• 系统的目标和涉众的确定是紧密相连的，因为目标主要决定了涉众存在的缘由。
• 明确各部分目标并保证整体性，内部无矛盾。

确定系统功能

• 通过座谈的方式确定未来软件支持的业务工作流程。
• 访谈关键涉众，因为未来的系统最终由这些人员组织验收。（正式与非正式）
• 采用调查问卷的形式，但是要求问卷中的题目要有代表性。
• 分析旧系统或当前系统中的问题或值得借鉴的地方，挖掘优化的潜力。
• 现场（On Site）与最终用户的调研和访谈，使得最终用户逐渐融入开发过程，也能使其容易理解业务的实现原理。
  

用例（Use case）

• 使用一种交互的方式来描述系统的场景，借以“捕获”用户的需求。（构建动态的场景，强调的参与者的活动）
• 用例使用椭圆表示，代表用户任务
• 任务对应的涉众，用例直接或间接与人形符号（Stickman）关联，叫做Actor。Actor理解成角色（Role）会更合适一些，指使用系统的用户类，不特指具体人。
  
• 角色实现系统的某些用例，一个角色可以对应多个用例；相反，一个用例也可以对应多个角色的参与。

1.寻找用例

1. 考虑在业务系统中进行管理和处理的关键业务实体。
2. 考虑业务相关的过程数据，即围绕基本业务实体的加工和组合而产生的数据，会在业务执行期间频繁和显著的发生变化。
3. 考虑系统业务相关的数据，对以上的数据进行分析和计算。
4. 考虑是否存在对正在运行的其它系统的交互。（分布式场景）

2.用户用例和系统用例

1. 业务用例：是从客户的角度出发描述某个业务的具体工作流，也是一次涉众与实现业务目标功能之间的交互，其中可能包含手工和自动化的过程，也可能发生在一个长期的时间段中。
2. 系统用例：是从计算机系统的角度描述业务系统，其业务边界就是这个计算机系统的设计范围。
3. 概括的说，一个业务用例描述的是业务过程——而不是软件系统的过程，一个业务用例为涉众创造价值，业务用例可以超越系统的边界。

3.用例提炼（!）

3.1 用例提炼-包含关系

• 通过一些通用过程的定义为其它主用例提供某种共同的基础性的功能
• 为避免用例中相同的基础性功能被多次重复实现
• 将这些基础功能作为一种附加用例表示，通过构造型<<include>>关系与依赖它的主用例相连

3.2 用例提炼-扩展关系

• 扩展关系<<extend>>强调客户期望中在某些情况下需要强烈表达出的一种意愿，比如特殊情况的处理
  

3.3 扩展关系与包含关系

• 一般来说被包含用例属于无条件发生的用例，而扩展用例属于有条件发生的用例；
• 被包含用例提供的是间接服务，扩展用例提供的是直接服务；
• 而且扩展用例在用例规约中一般作为基本事件的备选流而存在。
• 扩展关系与包含关系要注意区分，不小心很容易混淆，需要设计人员仔细甄别正确的业务含义及其关系。

4.用例优化

• 即使是在非常复杂的系统中，每个用例图中的用例数目一般要避免超过15个。
• 同一用例图中的用例应尽量具有相同的业务粒度水平以及处于同一抽象级别。
• 由于在实际的设计中，上述的条件在形式上比较难以掌控，建议将所有的用例放在一起进行筛选和分级。
• 从用例出发：
  • 以此进行进一步的开发和细化；
  • 以此作为出发点，进行较详细的成本估算；
  • 作为增量或迭代计划的基础元素；
  • 用于不同团队之间的工作分工。

活动图进行过程建模（*）

• 对于处理流程的建模，使用UML中的活动图是非常适合的
• 开始点、结束点
• 动作及执行顺序
• 条件
• 分支、汇聚 {and, or}
• 1.对象
  • 一个带有对象的活动图：
    • 
    • 使用工具Eclipse创建分析模型
    • 标识参与的对象并且给出了输出对象的状态
    • 如输出对象“已创建的Eclipse项目”会作为其后续动作的输入继续处理
• 2.细化过程：
  • 
  • 
  • 动作“成本核算”使用了一个特殊符号标记，其表示此动作通过另外一个活动图进行了细化
  • 细化的活动图补充了一些可能的流程，去掉了参与者的角色说明，因为按照上层的活动图可知；所有活动都应由某个相关部门的员工负责
• 流程合并点：
  • 
  • 在合并加入新的流程时，总是伴随着要补充一个控制点的菱形
  • 一种简化的形式，如图中所示，省略对应的菱形控制点
  • 活动图的语法规定：如果动作具有多个汇聚的箭头，则需要等待所有的分支都完成，类似于并行分支的同步情况
• 3.泳道：

  • 

  • 泳道（swimlane）是一种角色的划分方法

  • 利用泳道将活动按照职责组织起来

  • 通过将活动组织成用线分开的不同区域来表示

  • 如图中描述某编辑部稿件处理流程对应的活动图

  • 泳道可以对应不同的用户角色、用例或者部门等，UML规范并没有严格的规定

• 4.基本事件流和备选流：
  • 对于处理流程的描述活动图是非常适合的，可以使用活动图对基本事件流和备选事件流进行描述。
    • 对于用例中基本流的每一个步骤，生成一个单独的动作（action）；
    • 如果这个动作比较复杂，可以对应使用几个动作来对它进行表示，或者使用另外一个单独的活动图对其进行细化；
    • 逐步补充每个备选流的动作，同时注意每个动作是否需要进一步的细化。
    • 备选流的动作应与现有活动图进行衔接，比如“输入数据的合理性检查”有必要加入进来，并对其执行条件做明确的说明。
    • 活动图可作为未来测试的参考。
  • 
  • 

数据流图（*）

1.定义

• 数据流图(DFD) 描绘信息流和数据从输入移动到输出的过程中所经受的变换。
• 数据流图有四种基本符号：
• 数据的源点或终点；变换数据的处理；数据存储；数据流。
• 数据流与程序流程图中用箭头表示的控制流有本质不同，千万不要混淆。

2.数据流图中的基本符号

3.数据流图画法

• 从基本系统模型高的抽象层次开始画数据流图。
• 把基本系统模型细化，描绘系统主要功能。
• 在图中给处理和数据存储加编号，便于引用和追踪。
• 分层细化时保持信息连续性。
• 信息的流动
  • 信息流不能为动词
• 实体到实体的信息流动
  • 处理要有输入输出
  • 处理名不能为名词
• 0级数据图：
• I级数据图：
  
• II级数据图：
  
• 命名：
  • 应代表整个数据流(数据存储、处理)的内容，而不是仅仅某些成分。
  • 不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)。
  • 处理名字最好是一个具体的及物动词。

4.DFD用途

• 系统流程图：物理构成
• 数据流图：逻辑功能
• 面向数据流图的设计方法
• 交流信息的工具
  • 一张数据流图处理少于9个
  • 分层
• 分析和设计的工具
  • 在数据流图上划分自动化边界
  • 每个边界意味着不同的物理系统。

需求说明书

0. 文档说明性内容
   版本号, 创建者, 修改记录, 批准者
1. 目标群体和系统目标
   利益相关者分析、项目公开和隐藏的目的
2. 功能性需求
   所有功能性需求及其用户故事，从建立在活动图上的用例到文字性的需求描述，文档化
3. 非功能性需求
   特别是质量需求及技术需求
4. 交付物
   具体时间和形式交付的产品
5. 验收标准
   对需求进行检验的方法以及结果处理方式
6. 附件
   所有相关文档的列表，包括需求分析阶段的词汇表

需求跟踪

• 给出针对每个源需求及对应目标实现，将它们通过某种方式联系起来。
  • 从用例图到活动图的转换
  • 从活动图或者动作（action）到文本需求的转换
  • 从文本需求到类或者实例变量、方法和方法参数的转换
• 跟踪的作用：
  • 需求变更影响范围如何
  • 从类逆向追溯需求，可以获知实现的改动会影响到哪些原始需求
  • 除此之外，跟踪信息还可以附加对应连接创建的时间、属于增量开发的哪个周期等
  • 测试用例和需求之间的跟踪连接，可以方便的确定出哪些需求已经进行了测试，哪些还存在遗漏，对于掌握和提高测试的完备性具有重要的指导意义