需求建模和表述的技术

核心概念

需求分析最常见的误会是需求分析可以将需求做出成为方案，这是最大的误区，需求应该是还原业务，应该以业务为线索，换句话说就是

需求分析—–>业务分析，但

需求分析–X–>方案分析。

什么是分析

1.分解

2.提炼

3.消除矛盾

实际上分析就是分解–>提炼–>消除矛盾这么一个过程。

分解

分解是解决复杂问题的基本方法，也是有效的方法。

1. 以业务流程为线索分解

如下图，这种分解方法是按照目标系统->主题领域->业务事件->业务活动->业务步骤的过程分解下来，适用于信息系统类软件需求，信息系统类软件存在业务流，因此，采用此种结构较为合理。

2. 程序结构为主线索分解（不推荐）

这种分解结构以程序结构为主导，也是现在需求分析中最常见的方法，他割裂了与问题域之间的联系，容易导致问题域研究不足，降低需求质量和要求。

3. 基于场景的分解结构，对于决策支持系统、面向用户的嵌入式系统而言，决策场景、使用场景就是主要的线索。怎么来理解这一句话呢？这类系统更多的是计算机辅助的角色，与信息系统的信息流不同的是这类系统往往需要更即时的反馈，用以支持现场的反馈，因此更多强调任务性，也就是使用场景。举个例子说明这个问题。

我们研发了一款产品，他的任务是解决护士查房任务中使用笔来记录测量结果，导致要重复录入的问题，那么这个产品软件的场景就是护士在查房中对多个病人的查房数据的管理需要。

这种系统适合按照回溯的方法来进行需求分析，如下图：

4. 基于数据的分解结构，这种分解结构立足于程序内部的数据为主线索，这种分解对于需求分析师的要求是比较靠经于开发工程师的，至少要有开发经验。

提炼

分解是一种自顶向下的一种分析技术，一般来说，分解的任何一线索都或破解其他线索的完整性，因此，分析师要建立全面的系统认识，进而进行自底向上的提炼，也可以把他叫成抽象。例如将每个业务中的类进行提炼，抽取公共部分，建立针对整个系统的全局领域模型。这其实已经涉及到设计的领域了。

消除矛盾

消除矛盾是需求分析的一个必要过程，需求分析中，可能会出现相互矛盾、相互冲突的需求，这时候需要把收集的信息集中在一起，找到这些线索消除矛盾，分析影响范围。如有必要，需要进一步调研。

建模技术

什么是建模和为什么要建模

建模就是要把抽象的东西物化，这个就像开发商给你看的沙盘，开发商要说他的房子怎么好怎么好肯定不能手舞足蹈的在你面前比划，如果这样肯定卖不出去房子，因为这个太抽象了，大部分人是无法想象一个抽象的、空间的东西的，更不要说抽象的软件了。

建模的目的就是为了可视化，什么是可视化呢？就是还原我们的想法和现实情况进行物化的表示。建模的方法也多种多样。

一是可以采用基于现实的原型建模，包括低精度的和高精度的。

所谓低精度原型是指采用手绘等方法，快速还原你要设计的系统，适用于前期系统的沟通和需求的捕获，当然，也可以用在需求的初步分析上，这跟在咖啡厅的纸巾上创造是一个道理，这种方法的特点是可以快速的反应你的想法和确认你要得到的信息，弊端就是不正式，容易丢失；

所谓高精度原型是指采用计算机的方法，一比一还原要实现的系统，甚至能够实现一些基本的业务交互，这种适合于后期的需求细化和软件实现，对于需求的沟通非常有作用，这种方法的优点是可以还原真实的想法，甚至可以根据原型实现软件，弊端是工作量巨大，变更影响也巨大。

二是基于“设计语言”的设计建模，这也有很多方法，比如UML、BMPN,因此，选择合适的建模方法是很重要的。

建模的原则

1.不要为了建模而建模

2.最好的模型是与现实联系的

3.选择创建什么模型对如何动手解决问题和如何形成解决方案有深远影响

4.单个模型是不充分的，对每个重要的系统最好用一组几乎独立的模型去处理。

使用UML

Unified Modeling Language，是一种语言，很简单，语言是什么？语言是交流工具，那么语言的特点就是要统一大家才能听懂，所以这就是UML。从交流的层面来讲，UML也就是一个符号系统，某一种符号表示某一种意思，这样简单理解就可以了，不要搞得太复杂。

说到UML是一个符号系统，自然而然，符号系统就能按照自己的方式组织表达出一定的意思，这个在UML中就是图，我们来看看对需求分析和建模有帮助的几种图。

跨职能流程图

跨职能流程图来源于商业建模领域。跨职能流程图显示进程中各步骤之间的关系以及执行它们的职能单位。可以使用跨职能流程图显示一个进程在各部门之间的流程，或者显示一个进程是如何影响公司中的不同职能单位的。

这个图用来分析部门间或系统间的业务进程是比较适合的工具。

可以看看示例：

用例图

说用例图呢，其实有点片面。用例图是用来对用例分析技术执行结果的一种表示。用例分析技术包括用例图和用例描述，我们重点讲用例图。

讲用例图必须把三个概念搞清楚：

用例

这里展开说一下用例，我们要明确几个点：

1. 用例场景是有步骤的，是对一系列业务步骤组成的一个业务活动，所以用例不宜过小，譬如点击某一个“确认”按钮就可能不是一个用例；

2. 用例场景是有目标的，能为参与者带来有价值的结果；

3. 用例是对一组用例实例的抽象，也就是说用例是有路径的。

用例图图例

参与者：用一个火柴人表示

系统边界：用一个边框表示系统内外的分解

用例：用一个椭圆表示

他们组合在一起就是这个样子：

关系

参与者与用例之间的关系，参与者与用例之间是一种通信关系，使用一根带箭头或者不带箭头的线来表示，表示任何一方都可以发送和接收消息。

用例与用例之间的关系包括包含、扩展和泛化，表示方法如下：

包含关系： 表示基础用例在某一个位置显式的合并了另一个用例的行为，箭头方向从基用例到被包含用例，看一个例子：

回顾数据是一个基用例，表示系统提供数据回顾的功能，护士可以通过这个功能“回顾数据”，“打印数据”是被包含用例，表示“回顾数据”之下还包含了“打印数据”这个功能。因此被包含用例不是孤立的，而是基用例的一部分。

扩展关系：基用例在间接说明的位置上隐式的合并了另外一个用例的行为，箭头方向是从扩展用例到基用例，还是先看一个例子：

“打印报警列表”是一个完整的功能，但打印的前提是打印机就绪或空闲，因此“检查打印机状态”用例是可以被隐式的调用的，这种用例由系统提供，可以不与参与者进行交互。

泛化关系：本质是一种父子关系，泛化的用例继承了父用例的行为，子用例可以增加或覆盖父用例的行为，子用例可以出现在父用例出现的任何位置。箭头方向指向父用例。看一个例子：

这是一个很显式的父子关系，用户可以使用任何替代方案去付款。

用例图绘制的注意事项： 使用动宾短语描述用例；不要为了好看去过分的扩展，细节的内容可以在用例描述中去扩展。

关于用例获取的方法，会在另外一篇文章来介绍，这里不再深入。

活动图

活动图是用来描述用例内部流程的一种图。当然活动图还可以用来表述其他过程机理、业务过程及工作流等，所以跟流程图有点类似，甚至表示的东西都差不多。区别是活动图是一种面向对象的表述和支持并行流程。

活动图的表示符号：

活动图的好处是可以清晰的看到业务发生的过程，如果说用例是一个高层次的抽象，活动图则是一个细节层次的的描述，因此用例与活动图的配合可以起到很好的效果。可以看如下的示例：

组件图

部署图

需求描述的方式和方法

需求的描述，应该达到下面两个目标：

任何阅读需求的人对需求的解读是一致的，不存在歧义性；

每一个读者的解读都与作者试图表达的意思是一致的。

自然语言

功能需求的描述，可以从系统运行或者用户使用的角度来写。应该用一致的表达风格来表述需求。

对于从系统运行角度表述需求的方法，可以采用下面的表述：

【可选的前置条件】【可选的前置条件】系统应该【期望的系统响应】

例如：

SRS-002 在已经打开了心电参数监测开关时，系统运行主界面应该始终显示至少一通道的心电波形。

对于从用户的角度来表述需求的方法，可以采用下面的表述：

某个【用户类别或者角色名称】应该能够【对某个对象】【做某事】【限定条件、响应时间或质量描述】

例如：

SRS-001 仪器的操作人员应该能够通过参数开关打开或关闭心电参数的监测。

为了更清楚的表达需求，我们可以将从用户角度和系统角度的需求联合起来，混合的表达，比如：

SRS-001 仪器的操作人员应该能够通过参数开关打开或关闭心电参数的监测。

SRS-002 在已经打开了心电参数监测开关时，系统运行主界面应该始终显示至少一通道的心电波形。

SRS-003 在仪器关闭心电参数监测开关时，系统运行的主界面应该不显示心电参数的任何信息，对应的心电参数显示区域应该能够被其他参数显示使用。

当然，我们在从用户角度描述功能需求的时候，对于不同用户类别的功能，应该加以区分，并明确的做出说明，比如

写作风格

需求分析师要记住这一点，需求文档不是文学作品。因此不用在需求文档中去展现你的文采和学识，要在需求文档中去展现你的逻辑思维，因此编写需求文档时，要注意：

简洁和明确，语法，断句要正确。尽量使用短句；

举个例子：

系统应该提供参数开关的能力修改为系统应该能够打开或关闭参数则更加简洁明了

术语定义和字典，对于术语，要采用统一的术语定义，对于专有名词，要有字典；

使用关键词应该，并对使用的关键词进行定义，比如

应该是系统应当具备这样的功能

需求条目独立，避免使用大段文字表述多个需求，还是看前面的例子

SRS-001 仪器的操作人员应该能够通过参数开关打开或关闭心电参数的监测。SRS-002 在已经打开了心电参数监测开关时，系统运行主界面应该始终显示至少一通道的心电波形。SRS-003 在仪器关闭心电参数监测开关时，系统运行的主界面应该不显示心电参数的任何信息，对应的心电参数显示区域应该能够被其他参数显示使用。

应该修改为下面的表述

1.SRS-001 仪器的操作人员应该能够通过参数开关打开或关闭心电参数的监测。

2.SRS-002 在已经打开了心电参数监测开关时，系统运行主界面应该始终显示至少一通道的心电波形。

3.SRS-003 在仪器关闭心电参数监测开关时，系统运行的主界面应该不显示心电参数的任何信息，对应的心电参数显示区域应该能够被其他参数显示使用。

4.Note：那么什么时候应该这样写呢？判断依据很简单，你写的一段文字中有多个句子都可以独立测试。