需求用例分析之四：业务规则

最新推荐文章于 2023-08-10 10:27:41 发布
最新推荐文章于 2023-08-10 10:27:41 发布
阅读量2w 收藏 16
点赞数
分类专栏： 需求工程 软件工程 文章标签： 用例 use case 需求 软件工程
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhangmike/article/details/26866875
版权
本文探讨了业务规则在用例分析中的地位，指出全局规则、交互规则和内禀规则的分类。作者认为交互规则在事件流中描述即可，内禀规则应反映在用例中，但不应过度承担分析设计任务。强调用例简要说明和事件流足以覆盖业务规则，提倡用例分析专注于需求表达。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

作者：张克强

作者微博：张克强-敏捷307

在雅各布森用例分析方法和科伯恩用例分析方法中用例本身其实都没有“业务规则”的属性。但是业界使用中常常会给用例加上这个属性，这是为什么呢？为什么两位大师没有加上，是大师们疏忽了？而为什么不少人加上了呢？

从时间和传播上很容易推断，业务规则的来源是传统的需求规格说明书。在传统的需求规格说明书中，整理提炼业务规则或称业务逻辑是其中核心的分析产物。受到传统需求规格说明书的深远影响，不少人觉得这样的业务规则是值得写的用例规约中的。

业务规则有哪些？

在《用例规约的编写--业务规则和实体描述》一文（下文称为c文）中，将业务规则分为三类：

1．第一种是全局规则，一般与所有用例都相关而不是与特定用例相关

2．

最低0.47元/天 解锁文章
需求用例分析之九：序列图
高效软件开发
06-25 5543
作者：张克强    作者微博：张克强-敏捷307序列图，也称时序图、顺序图，英文名Sequence Diagram。在雅各布森用例分析方法中鼓励使用各类图形来表达，但恰恰没有明确提到序列图。而科伯恩用例分析方法以结构化/半结构化文本用例为中心，强调基于目标的文本格式，对UML各类图所提甚少。在RUP和OOAD中，UML序列图的最基本定位是用于识别类与类之间的信息传递，是识别类的方法的最佳场合。它是
需求规格说明书格式及要求
yuanlanjun
08-24 2285
1 引言 1.1 编写目的 1.2 项目风险 具体说明本软件开发项目的全部风险承担者,以及各自在本阶段所需要承担的主要风险,首要风险承担着包括 a) 任务提出者 b) 软件开发者 c) 产品使用者 1.3 文档约定 描述编写文档时所采用的标准,或各种排版约定.排版约定应该包括: a) 正文风格 b) 提示方式 c) 重要符号 也应该说明高层次需求是否可以被其所有细化的需...
【业务规则】业务规则方法的基本原则
bibybaby的专栏
02-05 1150
业务规则方法的基本原则： 1. 规则应该明确地写下来。 2. 规则应该用简明的语句描述。 3. 规则应该独立于规程和工作流程而单独存在。 4. 规则应该以期望的方式指导和影响行为。 5. 规则应该由可识别的重要业务要素驱动。 6. 规则应该能够供被授权的部门使用。 7. 规则应该只有一个来源。 8. 规则应该直接由具有相关知识的人描述。 9. 规则应该受到管理。...
产品需求文档怎样编写
AlaiaCodeingLife
09-07 3332
身为一个初学者,领导交代的任务当然得努力完成啊,本着害怕忘记的心态写下了这篇博客 首先我们得了解什么是需求文档? 产品需求文档是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然，这个定义针对的是一个全新的产品。广义上来讲，产品需求的描述，应该包含有产品的战略和战术，战略是指：...
需求分析——确定需求细节（规则与约束）
Ask马小向的专栏
11-02 1万+
之前写过一篇关于需求分析描述细节需要注意的规则和约束，今天在看徐峰的软件最佳实践时，看到了更为总结的描述，下面摘录进来： 规则是在实现时应该考虑的东西，约束是对技术手段选择起到限制作用的各种条件。 规则分类：行为（或成为功能、业务）规则、结构（或数据）规则、界面规则。 行为规则：是指和业务逻辑、业务流程相关的规则。 结构规则：是指和业务实体、属性、派生属性相关的规则，
MDA之PIM-2分析业务规则
转移到 github
04-07 192
分析业务规则1.业务规则概念     企业流域中人设一项必须遵守的条件(Conditions),约束(Constraints)或政策(Policies)都算是业务规则。Odell书(Advanced Object-Oriented Analysis and Design Using UML)中将业务规则分为两大类，分别为约束规则(Constraints Rules)与衍生规则(Derivation...
搜索业务规则分析、过滤条件构建
huangyh技术栈
12-01 1177
1.1 需求分析 面板上有商品分类、品牌、各种规格、价格区间等过滤条件。 业务规则： 当用户点击搜索面板的商品分类时， 显示按照这个关键字查询结果的基础上，筛选此分类的结果。 当用户点击搜索面板的品牌时，显示在以上结果的基础上，筛选此品牌的结果。 当用户点击搜索面板的规格时，显示在以上结果的基础上，筛选此规格结果。 当用户点击价格区间时，显示在以上结果的基础上，按价格进行筛选的...
需求用例分析之八：用例颗粒度
高效软件开发
06-08 1万+
在RUP中，没有对用例的颗粒度给出清晰的指导。2004年Rational 中国区技术销售经理 傅纯一发表一文《用例建模指南》。 2011年，雅各布森为首三人等发布了Use-Case 2.0。其第4条原则是Principle 4: Build the system in slices。将Use-Case进行切片，称为Use-Case Slice。 在Use-Case 2.0中，Use-Case Slice的推荐组织方式是利用条目化工具与Use-Case分别管理，维护两者的关联从属关系，推荐采用了故事点了对Us
需求用例分析之三：补充规约
高效软件开发
05-18 6678
补充规约在RUP中是记录那些在用例模型的用例中不容易体现出来的系统需求。这些需求包括：  § 法律法规方面的需求和应用标准。§ 要建立的系统质量属性，包括可用性需求、可靠性需求、性能需求和可支持性需求。§ 其他需求，诸如操作系统和操作环境、兼容性需求以及设计约束。 补充规约是对用例模型的重要补充。补充规约和用例模型应该一起获取对系统的一整套需求。 通过以上文字可以知道，补充规约是
用例驱动需求分析：从结构化到用例建模
3. 用例规格说明书：更详细的操作步骤、系统响应和业务规则。 4. 参与者描述：对每个参与者的特性、目标和行为的说明。 5. 关联的场景和故事板：辅助理解用例的具体执行过程。 用例驱动的需求分析方法强调以用户为...
《大象：thinking in uml 》(第二版) 11章 系统分析 1-2节 确定系统用例、分析业务规则
andy的博客
05-19 1920
只供参考，喜欢请支持正版图书 11.1 确定系统用例 具体说来，这些方法包括： ■　映射 映射是最简单最直接的方法，例如值机人员办理登机手续这个备选用例就可以不加修饰地直接被采纳为系统用例。 ■　抽象 抽象也是比较常用的方法，当业务场景当中的备选用例不能够被直接映射时，我们可能需要进行一些抽象，找到该备选用例在计算机当中真正要做的事 11.1.2 现在行动：确定系统用例 图11.3　申请永久用电系统用例 11.1.3 现在行动：描述系统用例 ■　用例场景示例 我们先来看一个用例场景的例子，从图11.3所示
如何编写业务规范
芦金宇的专栏
01-02 1194
辅助信息 包括规范的目的、包括内容、起草单位、主要起草人等信息。让人看到文档第一眼就知道该规范是用来干什么的。 项目背景 说明为什么要起草这个项目规范。 项目概述 总体说明项目的情况。 术语和缩略语 给出术语和解释，方便读书阅读和理解该规范。 业务开放范围 指明业务开放范围，使使用者了解是否需要接下去阅读。 业务功能 详细描述业务功能和相应规范。 ...
业务分析的一些原则和方法
Leizi专栏
01-06 2003
１.业务需求的描述框架２.业务域的划分原则３.系统边界与界面４.业务对象与业务流程５.子系统间接口识别（泳道图/垂直跨职能图）６.业务算法分析业务对象是业务流程产生或者处理的实体数据，业务对象一般都具有产生、使用、消亡的过程。这个过程的细节是由业务流程决定的。业务结构描述了每一个业务域的主要子功能域。业务流程指业务操作的时间顺序或者先后步骤。功能需求描述了各个业务域完成的主要业务职能。业务接口
业务规则入门简介
OR家园-howard
06-06 4336
引言 业务规则，通常被人们描述为业务逻辑的外部化或业务自动化，是一种实现和强制实施业务策略的方法；而业务规则管理系统（BRMS ）则是加速变更过程的方法。在我作为业务规则架构师的经验中，帮助确定业务规则一直是最具挑战性的任务之一，因为业务规则一向难于理解。但是，如果理解了业务规则是如何构成的，则理解业务规则也不是那么困难。本文通过研究一个来自保险行业的实际示例，尝试揭开能将结构化逻辑分类成为
基于规则的业务需求设计
最新发布
山客的专栏
08-10 187
指标实现是指该指标是实现类。考核评分主要是对考核主体进行评分，考核主体包括省、市、企业等，每个主体都有自己的实际业务操作，如省市需要做计划，并进行计划审核，企业也需要上报计划，省、市进行审核，评分时会针对上报的及时性、审核的及时性、修改次数、上报是否逾期等指标进行，当然实际业务操作不止计划上报，还有其它的业务操作也会纳入考核范畴。基于规则的业务需求，是在实现特定业务需求时，如考核评分，需求方提供了多种评分规则，需要根据不同的业务场景并依据这些评分规则进行评分的一类业务，业务场景包括：数据报警、考核评分等。
软件需求分析
shuijinglianyi的专栏
12-12 6977
 概念：软件需求包括：功能需求、非功能需求、设计约束（1）       业务需求：业务需求指反应组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求.通常在项目定义与范围文档中予以说明。 （2）       用户需求：用户需求指描述用户使用产品必须要完成什么任务，如何完成需求。通常是在问题定义的基础上进行用户访谈、调查、对用户使用的场景进行整理，从而建立从用户角
软件需求3个层次――业务需求、用户需求和功能需求
weixin_34232744的博客
12-16 932
      软件需求包括3个不同的层次――业务需求、用户需求和功能需求。除此之外，每个系统还有各种非功能需求。 业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope...
需求分析说明书和需求规格说明书
热门推荐
leogreat110的博客
11-30 5万+
一、需求分析说明书和需求规格说明书的区别 两者区别 需求分析说明书：一般是对某个市场或者是客户群来讲的，类似于调研报告，重点 是体现出产品要满足哪些功能，哪些是重点、热点。 需求规格说明书：是从业务规则讲起的，细一点偏向于软件的概要设计。是从开 发、测试的角度去讲产品功能，里面要包含原型界面、业务接口、活动图等 二、需求分析说明书模板 1.简介 1.1目的 1.2范围（软件功能，与其他系统的关系，系统的地域使用范围） 1.3定义、首字母缩写词和缩略语 1.4概述（软件其他部门所包含的内容，如参考资料，并解
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值