需求分析基础

为什么要需求分析

需求分析的任务

  • 建⽴分析模型，达成开发者和⽤户对需求信息的共同理解
  • 依据共同的理解，发挥创造性，创建软件系统解决⽅案

需求分析模型与建模

  • “模型是对事物的抽象，帮助⼈们在创建⼀个事物之前可以有更好的理 解”[Blaha2005]
  • 建⽴模型的过程被称为建模。“它是对系统进⾏思考和推理的⼀种⽅式。建模的⽬标是建⽴系统的⼀个表示，这个表示以精确⼀致的⽅式描述系统，使得系统的使⽤更加容易”[Fishwick1994]

建模常用手段

  • 抽象（Abstraction）
  • 分解（Decomposition / Partitioning）

需求分析模型

常见分析模型

面向对象分析

面向对象分析的简单过程

用例图

需求与用例

需求

  • 需求是在客户与开发者之间的合同文件中规定的
    • 很难捕获到所有需求

用例

  • ⽤例最初由[Jacobson1992] 在 Objectory ⽅法中提出的,它将⽤例定义为“在系统(或者⼦系统或者类)和外部对象的交互当中所执⾏的⾏为序列的描述,包括各种不同的序列和错误的序列,它们能够联合提供⼀种有价值的服务”[Rumbaugh2004]
  • [Cockburn2001]认为⽤例描述了在不同条件下系统对某⼀⽤户的请求的响应。根据⽤户的请求和请求时的系统条件,系统将执⾏不同的⾏为序列, 每⼀个⾏为序列被称为⼀个场景。⼀个⽤例是多个场景的集合
  • ✨用例是需求的组织和表现的方法之一

目标、交互与行为序列

案例

  • 连锁超市管理系统的收银员为了完成⼀次销售任务,会使⽤软件系统处理销售过程,那么就可以建⽴⼀个⽤例“销售处理”。考虑实际销售时的不同条件,会发⽣不同的⾏为:
    • 在⼀切顺利时是⼀种正常⾏为流程;
    • 购买多个同样商品时可以逐⼀输⼊每个商品,也可以分别输⼊商品号与数量;
    • 销售过程中可能会发现某个商品⽆法识别;
    • 有可能⼀个商品被纳⼊销售清单后⽤户⼜提出退回……
  • 上述的每⼀个⾏为都是⼀个场景。所有的⾏为联合起来就构成了场景的集合——⽤例,它的⽬标与价值是完成销售任务

用例图基本元素

  • 用例
  • 参与者
  • 关系
  • 系统边界

参与者 Actor

  • 参与者是一个用户或系统在待开发系统中所扮演的角色
  • 一个参与者在用例图中可以表示多个用户（或系统）
  • 一个用户（或系统）也可能担任多个角色
  • 参与者不一定是人类

用例 Use Case: requirements in context

  • 以用例形式表达需求
  • 通过几个典型场景，帮助构建、关联、理解需求
  • 场景是对系统如何使用的描述

系统边界 System Boundary

  • 强调了哪些需要详细化、哪些不需要
  • 在没有明确表示系统边界的图中，系统边界是隐性存在的
  • 参与者总是在边界之外，用例总是在边界之内

关系

用例图的建立

  • ⽬标分析与解决⽅向的确定
  • 寻找参与者
  • 寻找⽤例
  • 细化⽤例
    • 如果⽤例的粒度不合适就需要进⾏细化和调整
    • 判断标准是：⽤例描述了为应对⼀个业务事件，由⼀个⽤户发起，并在⼀个连续时间段内完成，可以增加业务价值的任务

常见错误

  • 不要将⽤例细化为单个操作
    • 例如,不要将⽤户管理细化为增加、修改和删除三个更⼩的⽤例,因为它们要联合起来才能体现出业务价值
  • 不要将同⼀个业务⽬标细化为不同⽤例
    • 例如特价策略制定和赠送策略制定
  • 不要将没有业务价值的内容作为⽤例
    • 常⻅的错误有“登录”(应该描述为安全性质量需求)、 “数据验证”(应该描述为数据需求)、 “连接数据库”(属性软件内部实现⽽不是需求)等

用例模板

关于案例的用例的一些问题

  • 顾客为什么不是参与者
  • 上传下载为什么不是⽤例
  • 系统可不可以分为服务器和客户端两个系统

UML中用例图的作用

概念类图（Conceptual Class Diagram）

  • ⼜被称为“领域模型”(Domain Model)
  • 类图是⾯向对象分析⽅法的核⼼
    • 描述类（对象）和这些类（对象）之间的关系
  • 与设计类图有所不同
    • 关注系统与外界的交互，⽽不是软件系统的内部构造机制
  • 类型、⽅法、可⻅性等复杂的软件构造细节不会在概念类图中

基本元素

  • 对象
    • 标示符
    • 状态
    • ⾏为
  • 类
    • 对象集合的抽象
  • 链接（link）（dependency）
    • 对象之间的互相协作的关系
    • 描述了对象之间的物理或业务联系
  • 关联
    • 对象之间链接的抽象
    • 聚合与组合
  • 继承
    • 泛化关系

关联与依赖

  • Two analysis classes are often related to one another in some fashion
    • In UML these relationships are called associations
    • Associations can be refined by indicating multiplicity (the term cardinality is used in data modeling
  • If there are associations between classes, then there are links （dependencies） between instances of the classes

案例

继承

  • Organise the domain object classes into a hierarchy
  • Classes at the top of the hierarchy reflect the common features of all classes
  • Object classes inherit their attributes and services from one or more super-classes. these may then be specialised as necessary

案例

建立概念类图

  • 对每个⽤例⽂本描述，尤其是场景描述，建⽴局部的概念类图
    • 根据⽤例的⽂本描述，识别候选类
    • 筛选候选类，确定概念类
    • 识别关联
    • 识别重要属性
  • 将所有⽤例产⽣的局部概念类图进⾏合并，建⽴软件系统的整体概念类图

候选类识别

  • 发现软件系统与外界交互时可能涉及的对象与类，它们就是候选类
  • ⾏为分析、名词分析、CRC等很多种⽅法都可以⽤来分析⽤例⽂本描述

名词分析

候选类向概念类的转化

  • 如果候选类的对象实例
    • 既需要维持⼀定的状态，⼜需要依据状态表现⼀定的⾏为
      • 确定为⼀个概念类
    • 如只需要维护状态，不需要表现⾏为
      • 其他概念类的属性
    • 不需要维护状态，却需要表现⾏为
      • ⾸先要重新审视需求是否有遗漏，因为没有状态⽀持的对象⽆法表现⾏为
      • 如果确定没有需求的遗漏，就需要剔除该候选类，并将⾏为转交给具备状态⽀持能⼒的其他概念类
    • 既不需要维护状态，⼜不需要表现⾏为
      • 应该被完全剔除

识别关联

  • 分析⽤例⽂本描述，发现概念类之间的协作，需要协作的类之间需要建⽴关联
  • 分析和补充问题域内的关系，例如概念类之间的整体部分关系和明显的语义联系
  • 对问题域关系的补充要适可⽽⽌，不要把关系搞得过度复杂化
  • 去除冗余关联和导出关联

识别重要属性

  • 这些属性往往是实现类协作时必要的信息，是协作的条件、输⼊、结果或者过程记录
  • 通过分析⽤例的描述，并与⽤户交流，补充问题域信息，可以发现重要的属性信息
  • 在分析每个单独的⽤例（场景）描述时，为各个概念类发现的重要属性可能不多，甚⾄有些概念类没有任何重要属性。但是，系统通常有多个⽤例和很多场景，会建⽴多个局部的概念类图，只有在合并所有局部概念类图之后，各个概念类的重要属性才能得到全⾯的体现

顺序图

  • A behavioral model shows the interactions between objects to produce some particular system behavior that is specified as a use-case
  • Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction between objects
  • 分析阶段，主要是利⽤系统顺序图，表达系统和外部参与者之间的交互⾏为

一个简单示例

消息种类

系统顺序图


状态图

基本概念

  • State:
    • a set of observable circumstances that characterizes the behavior of a system at a given time
  • State transition:
    • the movement from one state to another
  • Event:
    • an occurrence that causes the system to exhibit some predictable form of behavior
  • Action:
    • process that occurs as a consequence of making a transition

示例

案例

建立状态图

  • 确定上下⽂环境
    • 状态图是⽴⾜于状态快照进⾏⾏为描述的，因此建⽴状态图时⾸先要搞清楚状态的主体，确定状态的上下⽂环境。常⻅的状态主体有：类、⽤例、多个⽤例和整个系统。
  • 识别状态
    • 状态主体会表现出⼀些稳定的状态，它们需要被识别出来，并且标记出其中的初始状态和结束状态集。在有些情况下，可能会不存在确定的初始状态和结束状态。
  • 建⽴状态转换
    • 根据需求所描述的系统⾏为，建⽴各个稳定状态之间可能存在的转换。
  • 补充详细信息，完善状态图
    • 添加转换的触发事件、转换⾏为和监护条件等详细信息

结构化分析

结构化分析方法

结构化方法的历史

  • 结构化⽅法是针对1960’s到1980’s软件开发界所⾯临的问题提出⼀系列分析、 设计和编码的技术⽅法。那个时代：
    • Most commercial programming was done in Cobol and Fortran, then C and BASIC
    • There was little guidance on “good” design and programming techniques
    • There were no standard techniques for documenting requirements and designs
  • 关键是软件的复杂度的急剧上升

Multiple Structured Methods emerged

  • Structured Programming
    • in circa 1967 with Edsger W.Dijkstra
  • Structured Design
    • around 1975 with Larry Constantine and Ed Yourdon
  • Structured Analysis
    • in circa 1978 with Tom DeMarco, Yourdon, Gane & Sarson, McMenamin & Palmer
  • Information Engineering
    • in circa 1990 with James Martin

结构化分析思想

  • ⾃顶向下分解
  • 图
    • 数据流图
    • 实体关系图
    • 状态转移图

结构化分析的简单过程

数据流图

面向流的模型

  • 将系统看做是过程的集合；
  • 过程就是对数据的处理：
    • 接收输⼊，进⾏数据转换，输出结果
  • Represents how data objects are transformed at they move through the system
  • 可能需要和软件系统外的实体尤其是⼈进⾏交互
  • 数据的变化包括：
    • 被转换、被存储、或者被分布

流模型

  • Every computer-based system is an information transform ….

Flow Modeling Notation基本元素

External Entity 外部实体

  • A producer or consumer of data
    • Examples: a person, a device, a sensor
    • Another example: computer-based system
  • Data must always originate somewhere and must always be sent to something

Process 过程

  • A data transformer (changes input to output)
  • Examples: compute taxes, determine area, format report, display graph Data must always be processed in some way to achieve system function

Data Flow 数据流

  • Data flows through a system, beginning as input and be transformed into output

Data Stores 数据存储

  • Data is often stored for later use

语法规则

  • 过程是对数据的处理，必须有输⼊，也必须有输出，输⼊数据集应该和输出数据集存在差异
  • 数据流是必须和过程产⽣关联的，它要么是过程的数据输⼊，要么是过程的数据输出
  • 所有的对象都应该有⼀个可以唯⼀标示⾃⼰的名称

分层结构

创建数据流图

0层图

  • review the descriptions and use a grammatical parse to determine “operations”
  • determine external entities (producers and consumers of data)
  • create a level 0 DFD

1层图

  • write a narrative describing the transform
  • parse to determine next level transforms
  • “balance” the flow to maintain data flow continuity
  • develop a level 1 DFD

分层

  • 输⼊、处理、输出
  • 处理的分层细化

过程分解的平衡原则

实体关系图（ERD）-数据的建模

  • Examines data objects independently of processing
  • Focuses attention on the data domain
  • Indicates how data objects relate to one another

什么是数据对象？

  • Object — something that is described by a set of attributes(data items) and that will be manipulated within the software (system)
    • each instance of an object(e.g. a book) can be identified uniquely(e.g. ISBN#)
    • each plays a necessary role in the system i.e., the system could not function without access to instances of the object
    • each is described by attributes that are themselves data items

数据对象和属性

  • A data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the object

关系

  • Connectedness
    • A fact that must be remembered by the system and cannot or is not computed or derived
      • Several instance of a relationship can exist
      • Entity can be related in many ways

Cardinality and Multiplicity

建⽴实体关系图

  • Level 1—model all data objects (entities) and their “connections” to one another
  • Level 2—model all entities and relationships
  • Level 3—model all entities, relationships, and the attributes that provide further depth

ERD的图形表示

实体关系图

键（Key）

  • 实体的⼀个或者多个属性能够唯⼀确定和标示每个实例，这些属性或者属性 组合就被称为实体的标示符，或者键（Key）

使⽤需求分析⽅法细化和明确需求

细化和明确需求

  • 为什么要细化
    • ⽤户需求的描述的模糊性和系统设计所需要的严谨性之间的⽭盾
  • 如何细化
    • 需求分析建模
    • 发现其中的遗漏、冲突、冗余和错误
    • 迭代（获取、分析、获取、分析。。。）

各类概念图的作用

  • 系统顺序图
    • 有助于发现交互性的缺失
  • 概念类图
    • 有助于发现部分信息的使⽤不准确
      • 例如步骤 2 中输⼊的是商品标识,⽽不是商品,第 5 步显示的已输⼊商品列表信息和总价
    • 部分信息不明确
      • 例如会员信息、商品信息、商品列表信息、赠品信息、更新的数据、收据等等各⾃的详细内容并没有描述
    • 遗漏了重要内容
      • 例如总价的计算需要使⽤商品特价策略和总额特价策略,赠品的计算需要使⽤商品赠送策略和总额赠送策略
  • 状态图
    • 有助于发现界面的跳转

hw：画用例图，画概念类图，根据需要画顺序图、状态图

建立系统需求

  • 8种规格说明
    1. by mode
    2. by user class
    3. by object
    4. by feature
    5. by stimulus
    6. by functional hierarchy
    7. multiple organization
  • 不同的分析⽅法适合不同的规格说明