需求分析模板 需求分析与建模最佳实践

1.1需求分析建模的重点和误区

1.1.1需求分析是做什么的

需求分析的任务不是分析系统如何满足用户的需求，而是分析业务，形成系统完整、内容清晰的业务框架，以指导后续的设计开发工作。

需求分析是先分解，再提炼，消除这个过程中的矛盾。

1.1.1.1分解

现代需求工程理论建议用面向业务的分解代替传统的面向系统的分解。

业务流程是线索的分解结构

这种结构基于业务流程，是一种非常适合在线交易处理和管理信息系统的方法。

程序结构是线索的分解结构

这种分解结构过早进入程序结构，切断了与问题域的联系，导致对问题的研究不足，从而降低了需求质量，增加了变更风险。这种结构适用于问题不复杂、系统与问题相关性不强的情况，如工具软件和面向设备的系统。

基于场景的分解结构，

对于决策支持系统，面向用户的嵌入式系统更适合使用场景作为线索。这些场景可以向上概括为一系列的关注点或功能区域，向下可以分解为具体的决策步骤。

基于数据的分解结构

>。

“总结

在选择了合适的分解结构之后，就可以根据它的线索来确定需求规范的大纲，知道应该捕获什么信息。信息被捕获后，将被填充到大纲中，并不断进行验证。

1.1.1.2炼油公司

分解是一种自上而下的方法。被任何线索分解都会破坏其他线索的完整性。所以需要自下而上的细化，提取共性部分，建立全局域模型。

1.1.1.3消除矛盾

1.1.2建模目标和要点

建模的过程比结果更重要。

建模是需求分析的主要手段。但是如果为了建模而建模，那就成了问题，造成华而不实，沟通障碍。

1.1.2.1建模的目的

建模的优势在于更好地理解正在开发的系统。建模的目的是帮助我们按照所需的风格可视化系统，提供详细解释系统结构或行为的方法，给出指导系统构建的模板，记录我们的决策。

1.1.2.3建模的要点和原则

要点:设计应形成文件；用视觉模型表达建筑；不要为了造型而造型。如果模型不能帮助系统的构建，那就是人力资源的浪费。

模型是用来交流的，所以只在需要的时候建立模型。

1.1.3选择建模工具的要点

1.1.3.1正确理解建模方法

建模的关键点是根据要完成的任务选择合适的建模工具。

1.1.3.2正确理解了统一建模语言

统一建模语言的发展史

对UML的准确理解

为什么用统一建模语言建模

如何选择UML图

1.2周期1:阐明框架和背景

任务:明确需求的结构框架(领域类图)和行为上下文(流程图和用例图)。

输入:需求定义阶段生成的业务时间列表和报表列表。

输出:领域模型和用例模型。

这个任务对应于RUP细化阶段的第一次迭代，并且这个阶段的结束标志是识别除了大多数用例之外，域模型已经被生成。

1.2.1业务流程分析

每个业务事件都是流程的触发器，所以流程分析应该针对每个事件继续进行。但是根据流程的复杂程度，简单的流程只能用文字来描述，复杂的流程可以用流程图来表示。

1.2.1.1业务流程分析任务概述

业务流程分析，具体来说就是识别和分析现有的业务活动，确定活动之间的关系，知道活动需要接收什么信息，生成什么数据，确定数据传输路径，识别哪些部门和岗位负责活动。

在分析过程中，要注意核心业务和主要活动点，部门之间的联系，以及繁琐、重复、昂贵、低效、持久、频繁易手的活动。

1.2.1.2的业务流程分析与流程管理理论的关系

业务流程是信息系统的核心线索。

过程的六个特征:目标、内在、完整、动态、层次和结构。

工作流实施的本质

工艺设计原则(BPD)

1流程应该关注输出，而不是任务。

2让需要流程输出的人自己去执行流程。一方面，在流程设计中经常引入自助的概念；第二个方面是谁应该执行任务。

把决策权放在较低的管理位置，会得到较高的效率。在需求分析中，如果发现流程的决策点处于较高的管理位置，就要引起重视，这往往会带来实施上的瓶颈，影响系统的正常运行。

4.流程多样化。由于场景不同，同一个业务事件可能执行不同的流程，在系统开发中要充分考虑。

5与客户的单点联系。这充分体现了流程对外部客户满意度的关注，也是未来流程变革的共同趋势。

ESIA过程改进战略

ESIA意味着消除低效环节(e)，简化瓶颈(s)，整合资源(I)和自动化繁琐的任务(a)。

这些因素是工艺变化的主要原因。

1.2.1.3业务流程分析的重点和产品

业务流程分析有几个关键点:

这个过程是分层次的

部门级是需求分析的主要线索，岗位级是填写需求明细时的工作内容，组织级是部门级流程的抽象总结。

流程已键入

主要类型包括:

生产过程:它是过程中最重要的部分，通常最容易识别。

管理过程:是控制生产过程和质量效率进步的过程，容易被忽视。

支撑过程:是对生产过程的补充，通常由协作部门和部门的员工进行，也是容易丢失的部分。

过程分析的产物

应该尽可能多地使用模型来描述过程。最常用的有三种:交叉责任流程图、活动图和数据流程图。

交叉责任流程图:强调业务背景。Visio是最好的工具。

活动图:强调软件开发的导向。《玫瑰与共》都是最好的工具之一。

数据流图:重点是数据分布处理和处理。Visio是最好的工具。

1.2.1.4交叉责任流程图的应用依据及要点

“元素

流程名称、责任区、流程阶段、流程要素。

“画点，

为了确保绘制的流程图真实有效，需要加强用户参与。

擅长，敢于抛弃细节，不要过早的钻研业务活动的具体步骤。

要抛弃一次成型的想法，用迭代的方法，画草，讲问题，换草，再讨论，再修改，直到达成共识。

责任区内的所有活动都要细化到具体岗位。

各项活动之间的关系毋庸置疑，已经达成共识。

1.2.1.5活动地图的应用基础及要点

活动图是支持并行行为的流程图。

完成活动图或交叉责任流程图后，还需要注意:

“瓶颈分析。

“效益分析。

画流程图的时候会花一些时间分析瓶颈和收益，会带来意想不到的收益。

1.2.1.1数据流程图的应用基础

非常适合以数据流为主线。

主要内容

分层数据流图

1.2.2业务实体分析

具体来说，需要知道这个问题域中存在哪些业务实体，它们之间存在什么样的逻辑关系和数量关系，存在什么对应的结构规则。

1.2.2.1业务部门分析任务概述

在领域建模过程中，采用更多的自下而上的方法，对每个业务事件或报表进行类图片片段分析，然后对这些片段进行抽象、细化和合并，形成全局的领域模型。

实体分析的产品有两种可选模型:类图和ER图。推荐类图。

1.2.2.2类图的应用基础及要点

面向对象思想

类的表示形式

类与类的关系:联想、概括、组合。

确定类的主要职责:属性和方法。

领域模型(类图)从下往上合并。

领域模型要遵循以下规则:拒绝实现细节，不拆分大类，不合并子类，不抽象同类。

领域模型:从面向对象的角度看现实世界，通过类图描述事物之间的关系。所以主要的工作就是找出相关的类以及它们之间的关系。

分析模型:分析模型侧重于软件系统分析，领域模型侧重于业务分析。分析模型主要使用实体类、控制类和边界类。

设计模型:设计模型会直接指导编码。

1.2.2.3电流变图的应用基础

ER图的优势在于与数据库设计更好的集成，劣势在于语义比相似图弱。

《数据建模流程》

1.2.3角色和使用场景分析

用例分析技术可以更好的从用户的角度把系统当成一个黑箱，理解和整理需求，说明如何使用系统(场景)。

1.2.3.1用例分析技术概述

用例分析技术包括两个部分:用例图和用例描述。用例图是一个目录，用例描述是一种封装所有需求的形式。

1.2.3.2参与者和用例

参与者是一种角色，可以是人，可以是其他系统，可以是硬件设备，也可以是时钟，但必须在系统之外。

参与者是直接使用系统的最终用户，任何与系统间接相关的人都是持有者，而不是参与者。

1.2.3.3用例图

不要为了使用扩展或包含关系而使用它们。扩展用例建模通常是低优先级事件。一般面向客户的用例图中不应该有包含关系，面对开发团队的时候这些东西要详细的填充和总结。

1.2.3.4用例的来源

如何从需求中总结用例？一般可以采用两种方法:自上而下导出法和自下而上组合法。

自顶向下导出方法

用例图是从流程图中导出的。流程图是通过划分主题域，从主题域中识别业务事件，然后通过业务事件绘制流程图而绘制的流程图。

在得到流程图之后，我们可以首先与客户确定边界和角色，以得到代表系统边界的用例图。

1边界确定。首先，排除不直接使用系统的帖子。

2确定角色。个性化剩余的责任区。

3识别用例。用例源自责任区中的业务活动。

4画用例图。通过上面的分析，我们得到了角色、参与者和用例，然后我们可以画出用例图。

“自下而上的合并方法

对于一些中小型项目，流程不分明，很难从流程中梳理出来。因此，适合采用自下而上的合并方法，从需求捕获阶段获得的需求列表中合并所需的用例。

1收集原始需求。

2确定参与者。

3合并用例。

4画用例图。

用例的注意事项:

1用例图的粒度取决于业务价值。

使用业务动词来命名用例非常重要。不添加xx，不修改xx，不删除xx，不查询xx。

3.用先于别人思考的方式分析，而不是先于别人思考。

1.3周期2:确定要求的细节

这个阶段的任务是填写上一阶段产生的用例模型和领域模型的细节。对于具有行为需求的用例，我们需要填充事件流，包括相关的需求或功能点、接口原型、用例规则和约束。对于数据需求的领域类，我们需要填写字段和格式，包括字段信息、字段格式和规则、计算规则和结构规则。

1.3.1确定行为要求的细节

行为需求对应的是“人、物、物、界面”四大需求中的“物”，也是软件功能需求的主要内容。

1.3.1.1用例的灵活应用

行为需求可以分为四种:业务功能、报表功能、界面和技术支持。

1.3.1.2用例描述模板

对于行为用例，有四个方面需要整理:事件流、相关需求或功能点、接口原型、规则或约束。

事件流分析:场景和用例之间的关系类似于对象和类之间的关系，一个用例是一组相似场景的抽象。用例通常由一组事件流组成。

1.3.1.3业务用例和系统用例

业务用例描述所有的业务操作，而系统用例只描述与系统相关的业务步骤。小心不要把系统用例写成接口操作。

以下是机场签入的业务用例和系统用例演示:

业务用例

显然，2、3、1、9都是与系统无关的步骤。在它们被移除之后，系统用例从业务用例中获得。

系统用例

创建业务用例的好处:避免脱离上下文的开发级别，将系统步骤集成到业务场景中；提供业务优化的可能性；最好设置未来扩展点。

在事件流描述中，应该保留主题。可以用形式，也可以用文字。

避免用例事件流描述中的实现细节、分支结构和循环结构。特别是多路分支结构不能出现。

1.3.1.5界面原型

要点:软件需求规格说明中的用户界面原型是约束、建议，而不是解决方案。需求分析师只能为用户界面设计提供依据，不能提供设计。

不要忽视互动。您可以使用动态原型或状态图来表示接口的流程。

不要让界面掩盖了本质。

1.3.1.6规则和约束

规则是实现中应该考虑的东西，约束是技术选择的限制条件。

规则的类型:业务规则、数据规则和接口规则。

业务规则:与业务逻辑相关的规则。

数据规则:数据结构级别的规则。比如长度，类型等。

界面规则:与用户界面相关的规则。比如什么颜色数据显示的层次不同。

规则的层次

数据和接口规则通常是微观规则，而业务规则通常涉及很多不同的层面，比如宏观和微观，所以要注意组织上的差异。

总之，对于规则和约束，有一个核心原则，就是“只为这个用例写内容”。

基于利益相关者利益分析的1.3.1.7需求挖掘

1.3.2确定结构要求的细节

如果行为需求源自用例模型，那么结构需求源自领域模型。我们将从基本内容和常见盲点两个角度来说明结构需求的细节填充。

1.3.2.1的基本内容

领域模型的组织

从领域模型组织的角度来看，通常是按照主题领域进行第一次分解，一个主题领域对应一个领域模型，然后根据需要提取每个主题领域共有的领域类，形成全局公共领域类模型。对于每个主题域中的域模型，可能还会涉及到很多域类，按照逻辑关系可以分为不同的包，每个包都是一个逻辑相关的域类图的片段。然后，给出了每个部分的概述。您将获得以下级别:

在xx类中，我们可以进一步描述每个领域类。通常从“数据窗口分析”、“数据组成与格式”、“导出数据的计算方法”三个角度来描述。

数据窗口分析

系统中的公共数据往往成为工作重叠和冲突的地方。在这种情况下，建议使用数据窗口来处理，即公共属性变为公共，各个模块中仍然按单个属性。

数据组成和格式

数据组成和格式包括:数据类型，如int、char、boolean等。；长度精度等信息。作文格式，如2个字母，6位数字等。

导出数据的计算方法

在域类中，也可能有一些属性不是直接输入的，它们的值是计算出来的，比如订单总量。因此，我们还需要为这些属性生成规则。它们通常以决策表或决策树的形式描述。

1.3.2.2常见盲点

数据结构的特征

对于一个领域类来说，不同属性的重要性、稳定性、周期性都会影响到具体的开发决策，比如大、小领域、稳定与不稳定领域、即时记录、历史记录等。

《数据使用特点》

非功能性需求

1.3.3第2周期的产品

完整的用例描述，完整的领域类细节，界面流程图，页面原型。

1.4其他需求分析

其他需求包括:接口需求、全局非功能需求和全局设计约束。

1.4.1接口要求

有分解就有接口。识别接口后，千万不要谈接口的设计和实现。从需求的角度来看，界面的重点应该是从用户、内容和格式、设计约束和需求三个方面。

1.4.1.1用户

在描述界面用户时，我们可以从以下几个角度进行解释:

用户名，列出接口的外部用户。

“业务目的，说明用户通过这个界面实现什么样的业务。

“使用时间，解释用户将在什么情况下使用该界面。

“使用频率，描述各类用户调用界面的频率。

1.4.1.2的内容和形式

1.4.1.3设计约束

实现接口时必须考虑的约束或设计要求是广泛的，如协议格式要求、性能要求、环境限制等。

1.4.2非功能性需求的跟踪

1.4.2.1质量特征分析

在组织非功能性需求时，可以参考相关的质量特性标准，其中最常用的是ISO/IEC 9126软件质量模型和麦考尔软件质量模型。也可以根据项目特点和关注焦点来确定。接下来，我们将介绍由国际标准化组织/IEC 9126定义的6个类别和21个质量属性，以供简要分析。

“功能性

“可靠性

易用性

效率。

“可维护性”

“便携性”

1.5总结

SERU方法的核心是从“物、事、人、界面”四条主线出发，沿着业务上下文(业务主题域-业务事件/流程-业务活动-业务步骤)进行分解，构建(组件-流程图-用例-事件流程)，实现需求分析。

资料来源:http://www.uml.org.cn/RequirementProject/201809262.asp?·阿蒂德=21214