本文介绍了需求分析建模的关键点和误区，强调了从用户角度理解业务需求，通过分解、提炼和消除矛盾来构建业务框架。建模的目的在于沟通和理解，选择合适的建模工具如UML，并通过业务流程分析和业务实体分析确定细节。步骤包括理清框架与脉络，确定需求细节，同时关注接口需求和非功能需求的追踪。整个过程旨在为系统设计提供清晰的指导。
目录
1.2.1.4 跨职责流程图应用基础与要点 =》 串行、多个执行体
1.2.1.6 数据流图应用基础 =》 数据的流动、处理、存储 =》
1.3.1.7 基于stakeholder利益分析的需求挖掘
1.1 需求分析建模的要点与误区
1.1.1 需求分析到底做什么
需求分析的任务不是站在系统设计者的角度分析系统如何实现用户的需要，而是站在使用者的角度对业务/用户的需求进行分析，形成一个体系完整，内容清晰的业务框架，以指导后续的设计开发工作。
备注：软件设计是通过软件的方式来实现业务框架，因此，软件设计是基于需求分析的结果进行的。业务框架是需求者（用户、产品经理等）对目标系统的期望和诉求。架构师和程序员不过是通过计算机软件的方式实现需求者的期望和诉求。而分析师就是把客户自然语言的诉求转换成了对目标软件系统的软件诉求，是代表客户向软件架构师和程序员提出了目标系统外部行为的诉求！！！因此，系统分析师本身就带有了一点的软件系统的设计成分，相同的客户自然语言的诉求，不同的分析师，可能会以不同的方式转化成对目标软件系统的诉求，面向对象的分析师，以面向对象的方式提出目标系统的诉求，结构化分析师以结构化的方式提出目标系统的诉求，这就导致，相同的客户需求，目标系统的架构设计和代码实现会受到系统分析师的极大的影响！！！即使都是面向对象的分析，分析师对用户需求的组织方式，最终也会影响系统的设计和实现方式。这就是为什么，需求分析虽然不关心系统的实现，但需求分析的结果，极大影响目标系统的设计和实现！！！
需求分析本身就隐含了对目标系统的设计的成分！！！What本身就包含了部分设计。
需求分析结果是分析师代表客户提出了目标软件系统的构想！！！
需求分析就是先分解，再提炼，在这个过程中消除矛盾，把客户的需求转化成软件的需求！！！
1.1.1.1 分解的方法 *****
产品研发与公司运营方式，其曲同工，系统需求的分解方法与目标产品和公司的运营策略息息相关。
工程性、销售性公司=》客户导向：先找明确的客户需求，再找方案和产品。
高科技、研发型公司=》产品导向：先研发前瞻性产品和技术方案，再发掘客户。
客户业务导向分解：站在业务和客户的角度，把业务分解一个个层次化、结构化的小的业务需求，然而把业务需求转换成目标系统的功能需求！！！ =》 面向对象的需求分析。基本思想：先不管我有什么，先看你需要什么，然后再通过什么手段和方法满足你的需求。=》适合短期的工程性的项目，大部分信息系统都是工程性软件项目！！！
目标系统导向分解：站在目标系统的角度，把目标系统分解一个个层次化、结构化的小的功能需求，然而把目标功能需求组合成业务需求！！！ =》 传统的结构化需求分析。基本思想：先看我有什么，然后在看你需要什么，最后再看如何组合我现有的东西，满足你的需求。=》适合长期研发性项目。
》业务流程为线索的分解结构 =》面向对象方法分析=》站在系统外看向内系统=》以用户为出发点
这种结构是以业务流程为主线索，对于联机事务处理系统，管理信息系统而言都是非常适用的方法。
有了业务结构，就可以通过面向对象代码的来映射业务结构。正所谓提出问题，就是提出需求！！
也可以让ChatGPT来实现这个业务架构。
系统就是有各种不同的业务流程或业务场景构成的。
》程序结构为线索的分解结构 =》结构化方法分析 =》站在系统内向外看用户 =》 以软件为出发点
这种分解结构过早的进入了程序结构，割裂了与问题域之间的联系，从而导致对问题研究不足的情况，从而降低需求质量，增加后续变更风险。这种结构适用于问题不复杂，系统与问题关联性不强的情况，例如工具软件（相对于各种变化的应用软件），面向设备（相对于面向互联网普通用户）的系统等。
这种方式：用功能点的堆叠来满足客户的业务需求！！！
》基于场景的分解结构
对于决策支持系统，面向用户的嵌入式系统，就比较适合使用场景作为线索。
这些场景向上可以总结成一系列关注点或功能域，向下可以分解成具体的决策步骤。
》基于数据的分解结构
》小结
选择了合适的分解结构之后，就可以按其线索把需求规格说明书大纲确定下来了，就知道应该捕获什么信息了，信息捕获回来之后就将其填充到大纲里，并不断验证，不断用捕获的信息填充大纲。
1.1.1.2 提炼、合并、重组
分解是一种自顶向下的方法，按任何一种线索分解，都会破坏其他线索的完整性。
所以还需要自底向上的方法进行提炼、合并、重组，抽取出共性的部分，建立针对全局的领域模型。
1.1.1.3 消除矛盾
1.1.2 建模的目标和要点
建模的过程比结果重要。
建模是需求分析的主要手段。
但如果为了建模而建模，它就会变成一个问题，导致华而不实，造成沟通障碍。
1.1.2.1 建模的目的
建模的好处在于更好地理解和阐述正在开发或即将开发的系统。
建模的目的在于帮助我们按照需要的样式对系统进行可视化，提供一种详细说明系统的结构或行为的方法，给出一个指导系统构造的模板，对我们所做出的决策进行文档化。
1.1.2.2 建模的要点与原则
要点：设计要文档化；用可视化的模型表达架构；不要为了建模而建模，如果模型不能对系统的构建起到帮助作用，那么就是一种人力资源的浪费。
模型是用来沟通的，因此仅当需要的时候才构建模型。
1.1.3 选择建模工具的要点
1.1.3.1 正确认识建模方法论
建模的要点是根据要完成的任务，选择合适的建模工具。
不同的工具应对的业务需求的复杂度、易变性、不确定性不同，越来越高。
目标系统自身的可复用性、可重用性不同越来越高。
1.1.3.2 正确认识UML
》UML的发展历史
》UML的准确理解
》为什么要用UML建模
》如何选择UML图
1.2 步骤1：理清框架与脉络
任务：理清需求的结构框架(领域类图)，行为脉络(流程图和用例图)。
输入：需求定义阶段产生的业务时间列表和报表列表。
输出：领域模型和用例模型。
该任务对应于RUP中细化阶段的第一次迭代，该阶段的结束标志是标识除了绝大部分用例，生成了领域模型。
1.2.1 业务流程分析
每个业务事件都是流程的触发，因此针对每个事件都应该继续做流程分析。
不过根据流程的复杂度作出裁剪，简单的流程可以只用文本描述，复杂的流程可以通过流程图表示。
备注：
用例图是窗口，是呈现。
解构用例图得到类图、流程图、时序图。
1.2.1.1 业务流程分析任务概述
业务流程分析，具体来说就是识别，识别现有业务活动，确定活动之间的关系，了解活动需要接受哪些信息，产生哪些数据，确定数据传输路线，标识出活动是由哪些部门，岗位负责。
分析过程中，要注意抓住核心业务和主要活动点，部门之间的衔接，工作中繁琐，反复，成本高，效率低，时间长，转手多的活动。
1.2.1.2 业务流程分析与流程管理理论的关系
业务流程是对信息系统进行庖丁解牛的核心线索。
》流程的六大特性：目标性，内在性，整体性，动态性，层次性，结构性。
》工作流实现的本质
》流程设计（BPD）的原则
1 流程应该以产出为中心，而非任务为中心。
2 让需要得到流程产出的人自己执行流程。
一方面现在流程设计经常引入自助的概念；
第二个方面是任务应该由谁来执行可以参照这一原则。
3 将决策权放到更低的管理职位上，这样会得到更高的效率。在需求分析时，如果发现流程的决策点在较高的管理岗位上，就应该注意它经常会带来执行上的瓶颈，也就会影响系统的正常运作。
4 流程多样化。因为场景不同，同一个业务事件可能会执行不同的流程，在系统开发时，应该充分考虑到。
5 单点接触客户。这一点充分体现了流程对外部客户满意度的关注，也是未来流程变化的一个常见趋势。
》流程改进（BPR）的ESIA策略
ESIA就是清除低效环节（E），简化瓶颈点（S），整合资源（I），繁琐任务自动化（A）。
这些因素就是导致流程发生变化的主要原因。
1.2.1.3 业务流程分析的要点是产物
在进行业务流程分析时，有几个关键点：
》流程是有层次的
部门级是需求分析的主线索，岗位级是需求细节填充时的工作内容，组织级是对部门级流程的抽象概括。
》流程是有类型的
主要类型包括：
生产性流程、业务数据流（数据面）：是流程中最重要的部分，通常也最容易标识。
备注：数据流可以通过流程图建模。
管理型流程（管理面+控制面）：是对生产性流程的管控，对质量效率进度等进行控制的流程，容易忽略。
备注：控制流可以通过时序图建模。
支撑性流程（支撑面）：是对生产性流程的补充，通常是协作部门，本部门员工执行，也是容易丢失的部分。
》流程分析的产物 =》 职责流程图，活动图和数据流图。
应该尽可能地使用模型来描述流程 =》 直观、一图顶千言。
最常使用的有四种：
- 传统流程图：串行、单一执行体
- 跨职责流程图：串行、多个执行体
- 活动图：并行、多个执行体
- 数据流图。
跨职责流程图：强调业务背景。Visio是最佳工具。
活动图：强调对软件开发的指导。Rose，Together都是最佳工具之一。
数据流图：强调数据的流通加工和处理。Visio是最佳工具。
1.2.1.4 跨职责流程图应用基础与要点 =》 串行、多个执行体
跨职责流程图与单一职责流程图的区别是：
前者涉及到多个执行体和职责体，
后者只涉及一个执行体和职责体。
如下图所示，执行体包括客户、经纪人、经理、信息员、交易员
》元素
流程名称，职责带区，流程阶段，流程元素。
》绘制要点
要保障绘制出来的流程图是真实有效的，就必须要强化用户参与。
要善于，敢于抛弃细节，不要过早钻研到业务活动的具体步骤中。
要抛弃一次成型的思路，使用迭代的方式，画草搞，谈问题，改草搞，再讨论，再修正，直到达成共识。
所有职责带区上的活动都细化到具体的岗位。
每个活动之间的关系都已经没有疑问，都达成共识。
1.2.1.5 活动图应用基础与要点 =》并行、多个执行体
活动图就是可以支持并行行为的流程图。
在完成活动图或跨职责流程图之后，还需要注意：
》进行瓶颈分析。
》进行利益分析。
当流程图绘制完成之后，花些时间进行瓶颈和利益分析，会有意想不到的收获。
活动图与流程图的区别：
(1)、流程图着重描述处理过程，它的主要控制结构是顺序、分支和循环，各个处理过程之间有严格的顺序和时间关系。而活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现的是系统的外形行为，而非系统的处理过程。
(2)、活动图能够表示并发活动的情形，而流程图不行。
(3)、活动图是面向对象的，而流程图是面向过程的。
1.2.1.6 数据流图应用基础 =》 数据的流动、处理、存储 =》
显式地标识数据的流动和变化，强调数据的转变过程，以数据为中心，而不是以处理为中心。
对于数据流为主线索的处理过程非常合适。
》主要元素
选课系统顶层数据流图：
选课系统1层数据流程：
1.2.2 业务实体分析 =》 类图
具体来说，就是要了解这个问题域（而不是软件系统）中有哪些业务实体，它们之间存在什么样的逻辑关系，数量关系，以及有什么相应的结构规则。
备注：
问题域的实体最终会通过软件系统中的类来实现！！！
分析的结果直接决定了系统的设计！！！
因此，分析行为本身就带有了设计目标软件系统测成分！！！
1.2.2.1 业务实体分析任务概述
在领域建模过程中，更多地采用自底向上的方法，针对每一个业务事件或报表，分析类图片段，然后再将这些片段抽象，提炼，合并，形成全局的领域模型。
备注：
也就是说，先业务用例图 =》再有业务流程图（流程图、活动图、时序图等） =》最后才有类图！！！
从流程图、活动图、数据流图、时序图中寻找“类”和类图！！！
当然，一个系统是由多个用例图组成，一个用例图由有多个流程图、活动图、时序图组成。
实体分析的产物有两种可选模型：类图（面向对象方法），ER图（结构化方法）。推荐使用类图。
1.2.2.2 类图应用基础与要点 =》面向对象分析方法
》面向对象思想
》类的表示方法
》类之间的关系：关联，泛化，组合。
》确定类的主要职责：属性和方法。
领域模型(类图)，是自底向上合并出来的。
领域模型应该遵循：拒绝实现细节，大类不拆分，子类不合并，同类不抽象。
领域模型（业务模型、现实模型）：以面向对象的视角看待现实世界，通过类图来描述事物之间的关系。因此主要工作是找出相关的类，以及他们之间的关系。
分析模型（软件模型）：分析模型是针对软件系统分析，领域模型则偏重对业务分析。
分析模型主要用到实体类，控制类，边界类。
设计模型（实现模型）：设计模型将直接对编码予以指导。
1.2.2.3 ER图应用基础 =》 结构化分析方法
ER图的优势在于更好地跟数据库设计结合，缺点在于语义较类图更弱一些。
》数据建模过程
1.2.3 角色与使用场景分析
用例分析技术，能更好地以用户的角度，将系统当作一个黑盒子，了解并梳理需求，解释如何使用系统的一个个场景。每个用例就代表一种场景。
备注：用例本身的初衷就是站在客户的角度看待系统的一种方法论。
1.2.3.1 用例分析技术概述
用例分析技术，包含两个部分：用例图，用例描述。用例图是目录，用例描述是封装所有需求的形式。
1.2.3.2 参与者与用例
参与者是一种角色，可以是人，可以是其他系统，可以是硬件设备，也可以是时钟，但一定要是在系统之外。
参与者是直接使用系统的最终用户，任何间接与系统相关的人员是StakeHolder，不是参与者。
1.2.3.3 用例图
千万不要为了使用扩展，包含关系而使用他们。扩展用例建模通常都是优先级较低的事件。
面向客户的用例图通常都不应该出现包含关系，这些事情应该是在面向开发团队时才进行填充和归纳的细节。
1.2.3.4 用例的来源
如何从需求中归纳出用例呢?
通常可以采用两种方法：自顶向下导出法，自底向上合并法。
》自顶向下导出法
就是从流程图中派生出用例图。而流程图是通过划分主题域，再从主题域标识业务事件，然后通过业务事件绘制出来流程图。
拿到流程图后，我们首先可以跟客户进行边界确定和角色确定，以得出表示系统边界的用例图。
1 边界确定。首先排除掉不直接使用系统的岗位。
2 确定角色。对剩下的职责带区进行角色化。
3 确定用例。用例是从职责带区中的业务活动中派生出来的。
4 绘制用例图。有了以上分析，我们得到了角色，参与者，用例，就可以绘制出用例图了。
》自底向上合并法
对于一些中小项目而言，流程并非泾渭分明，从流程开始梳理会比较困难，就适合采用自底向上合并法，从需求捕获阶段得到的需求列表着手，合并出需要的用例。
1 收集原始需求。
2 确定参与者。
3 合并用例。
4 绘制用例图。
用例的注意事项：
1 用例图的颗粒度取决于业务价值。
2 用业务动词命名用例十分重要，不要在用新增xx，修改xx，删除xx，查询xx了。
3 采用先事后人的方式分析，而非先人后事。
1.3 步骤2：确定需求细节
这一阶段的任务，是对上一阶段产出的用例模型和领域模型进行细节填充。
对于行为需求的用例，我们要填充事件流，包括：相关需求或功能点，界面原型，用例规则与约束。
对于数据需求的领域类，我们要填充字段与格式，包括字段信息，字段格式与规则，计算规则，结构规则。
1.3.1 确定行为需求的细节
行为需求对应的是“人，事，物，接口”四大需求主线中的“事”，这也是软件功能需求的主体内容。
1.3.1.1 用例的灵活运用
行为需求可以分为四个类型：业务功能，报表功能，接口，技术支持。
1.3.1.2 用例描述模板
对于行为用例来说，需要整理的内容有事件流，相关需求或功能点，界面原型，规则或约束四个方面。
事件流分析：场景和用例的关系，类似对象与类之间的关系，一个用例是对一组类似场景的抽象。而一个用例通常是一组事件流所构成。
1.3.1.3 业务用例与系统用例
业务用例描述的是所有业务操作，系统用例则只描述与系统相关的业务步骤。要警惕将系统用例写成界面操作。
下面是机场checkin的业务用例与系统用例示范：
业务用例
很明显，2，3，1，9都是跟系统无关的步骤，将他们去除后，就从业务用例得到了系统用例。
系统用例
》创建业务用例的好处：避免开发层面断章取义，而使系统步骤融入到业务场景中；提供业务优化的可能性；更好设置未来的拓展点。
》事件流描述中，应该保留主语。可以使用表格或者文字的方式。
避免在用例事件流描述中出现实现细节，分支结构，循环结构。特别是不能出现多路分支结构。
1.3.1.5 界面原型
》要点：软件需求规格里的用户界面原型，是约束，建议，而非解决方案。需求分析人员也只能给用户界面设计提供依据，而非设计。
》不要忽略交互。可以采取动态原型的方式，也可以用状态图表示界面的流转。
》别让界面掩盖本质。
1.3.1.6 规则与约束
规则是在实现时应该考虑的东西，约束是对技术选择时的限制条件。
》规则的类型：业务规则，数据规则，界面规则。
业务规则：与业务逻辑相关的规则。
数据规则：数据结构层面上的规则。比如长度，类型等。
界面规则：用户界面相关的规则。比如什么颜色的数据显示不同的等级。
》规则的层次
数据与界面规则通常都是微观规则，而业务规则却通常涉及宏观微观等多种不同层次，因此在组织时需要注意其中的差别。
总之，对于规则与约束，有一个核心原则，就是“只写针对本用例的内容”。
1.3.1.7 基于stakeholder利益分析的需求挖掘
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软件质量模型 和 McCall软件质量模型。
也可以根据自己项目的特点，关注重心来确定。也就是说，不同的业务系统，关注的非质量要求是不一样的！！！
接下来我们将介绍ISO/IEC 9126定义的6类21项质量属性进行简要分析。
》功能性
》可靠性
》易用性
》效率
》可维护性
》可移植性
1.5 小结
SERU方法的核心，就是从“事，物，人，接口”四个主线着手，沿着业务脉络(业务主题域-业务事件/流程-业务活动-业务步骤)进行分解，构建(构件-流程图-用例-事件流)，实现需求分析。
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
