第九章 需求工程之照章办事

业务规则

• 每个组织的运营都要遵守很多政策、法规以及行业标准，这样的控制原则统称为业务规则或业务逻辑。
• 业务规则通常通过人工的政策和流程来保证。
• 需要软件应用强化这些规则
• 大多数业务规则起源于任何特定的软件应用之外。
• 业务规则是业务的属性，业务规则本身并不是软件需求
• 业务规则是需求的来源，它们决定着协同必须具备哪些属性才能符合规范。
• 业务需求描述了组织期望的产出或概要目标，支出要构建或采购一个软件。
• 业务需求是项目实施的理由
• 业务过程描述了将输入变为特定的输出以达成特定结果的一系列活动。
• 信息系统通常将业务过程自动化，因而有效率及其他好处（可以满足提出的业务需求。）
• 业务规则通过监理词汇表、施加限制、触发行动或监控运算过程等方式影响业务过程。
• 同一个业务规则可能应用到多个手动或自动流程中，因此最好把业务规则当做一组独立的信息。
• 业务规则如果影响各类软件需求

需求类型	业务规则的影响	示例
业务需求	政府法规可能称为项目的某个业务目标	化学品跟踪系统必须符合最近五个月内所有联邦和州的化学品使用与处理报告法规
用户需求	隐私策略决定哪些用户可以或者被禁止使用系统完成某些任务	只有实验室管理员可以为自己之外的其他人生成化学品接触报告
功能需求	公司政策规定所有供应商在收到发票之前必须经过核准登记	如果收到来自一个未注册供应商的发票，供货系统应该以电子邮件方式向供应商发送供应商登记表以及W-9表格的可编辑PDF文档
质量属性	来自政府机构的法规可以指明安全性的要求，它们必须由协同强制执行	系统必须维护安全培训记录，在员工申请有害化学品前，必须保证他们接受过适当的培训。

• 组织开发的应用应当以一致的方式遵循这些策略，也就是业务规则。
• 跟踪每个规则的实现代码，在规格有变动时更新系统更容易。

业务规则分类

• 从业务角度
  • 业务规则是一个指导原则，它描述了在某个特定活动或环境中的行为、行动、实践或流程所应尽的义务。
  • 规则应该有明确的动机，并带有强制手段，而且必须指明违反规则带来什么后果。
• 从信息系统角度
  • 业务规则是对业务某些方面的定义或限制的声明。
  • 它的目的是维护业务结果或控制以及影响业务行为
  • 秩序简单识别和记录与系统有关的业务规则，并将他们与实现他们的特定需求联系起来。
• 业务规则类型
• ![[业务规则分类.excalidraw]]
  • 事实
    • 就是业务在某个特定的时间点简单而正确的陈述
    • 事实描述重要业务术语之间的关联或关系
    • 系统中重要数据实体的事实很有可能出现在数据模型中
    • 例如
      • 每个化学品容器都有一个唯一的条形码标识
      • 每一个订单都包含运费
    • 将重点放在范围内的事实上，不要试图收集完所有的业务知识集。
    • 尝试将事实联系到内外关系图的输入/输出、系统事件、已知数据对象或者特定的用户需求。
  • 约束
    • 约束描述的是限制系统或其用户可执行的行为
    • 组织政策
      • 图书馆读者在同一时间内最多只能借10本书
      • 保险函中明文显示的投保人社会保险号码不得超过4位。
    • 政府法规
      • 所有软件应用必须符合适合视力障碍人士使用这一政府法规
      • 航空公司飞行员每24小时航程必须有连续8小时的休息时间。
    • 行业标准
      • 抵押贷款申请人必须满足联邦住房管理局的资格标准
      • Web应用不宜使用HTML5标准中废弃的任何HMTL标签或属性。
    • 某些业务规则限制业务的运作方式，这些应当存储在业务规则库中
    • 只要这些约束体现在软件需求中，就表明这些需求来源于哪个相关的规则。
    • 很多约束类型的业务规则都涉及哪个类型的用户可以操作哪些功能，采用角色与权限矩阵记录。
    • ![[Pasted image 20220829185240.png]]
  • 触发规则
    • 当特定条件满足时，触发某些活动的规则
    • 这种规则可能会提出软件功能方面的要求，使系统探测到触发事件时表现出正确的行为。
    • 如果<某些条件为真或某些事件发生>，那么<某些事件就会发生>
    • 决策表提供了一个简单的方式来记录涉及复杂逻辑的行为触发类业务规则。
    • 业务有时会提出有利于商业性成功的一些规定。
      • 如果客户购买的图书作者写过多本书，就在订单完成前向客户展示此作者其他著作信息
      • 在客户将书放入购物车后，显示购买了次数的其他用户还购买了哪些相关书籍。
  • 推理
    • 有时也成为推断的知识或派生的事实
    • 推理通常指从已知的事实中产生新的事实。
    • 如果、那么句型，“那么”部分只是描述知识性的信息，而不是要执行的动作。
    • 例如
      • 如果在30个日历日之内没有收到应付款，这个账号就存在拖欠债务的问题。
      • 如果供应商在收到订单的五天后仍然无法发货，就会被任务是延期交付的。
  • 运算
    • 通过使用特定的数学公式或算法将已知数据加工为新的数据。
    • 很多运算遵循的规则都是企业外部规则

原子业务规则

• 在原子级别记录业务规则，而不是在一条规则中组合多个细节。
• 不要在“如果、那么”结构的前半段使用“或”逻辑，在后半段不要使用“与”逻辑
• 你可以把DVD或者蓝光碟片借走一周，并在在没有其他读者预约的情况下续借两次，每次3天

记录业务规则

• 因为业务规则可能影响很多应用，所以组织应该把自己的规则视为企业级资产进行管理
• 大型组织或者其运营与信息系统均由业务规则驱动的组织应当监理业务规则数据库。
• 相关的规则分类也可以用局册数、决策表或角色与权限矩阵之类的工具表单
• 为每一个业务规则提供一个唯一ID，可以帮助将需求链回特定规则，与之联系起来。
• 静态或动态说明规则将来变化的可能性。
• 业务规则来源包括企业以及管理规定、主体专家和其他人员、政府规章制度之类的文档。

发现业务规则

• 组织内的“尝试“，通常来自从事此业务很长时间的个人，他们知道业务的运作细节
• 其他需求和代码中已内嵌业务规则的遗留系统
• 业务过程建模，引导分析师找出可以能影响每个流程步骤的规则，约束、触发事件、运算规则以及相关事实。
• 现有文档、包括以往项目的需求规范说明、法规、行业标准、企业规范、合同以及业务计划书
• 数据分析，如数据对象可以有的各种状态以及在什么情况下用户或系统事件可以改变对象的状态
• 其他部门构件的合规系统
  

业务规则与需求

• 业务规则是来自外部的策略声明，必须通过软件强制执行，因此提供了系统功能要求
• 每个业务分析师都必须决定哪些规则和自己的应用有关，哪些必须由系统强制执行，如何强制执行
• 例如
  • 规则#1（触发规则）：“如果化学容器临近有效期，需要通知当时的容器持有人”
  • 规则#2（事实）：“容器内所装化学品会分解为易爆物，那么容器的保质期为一年”
  • 规则#1是“向化学品持有人提示过期时间”这个系统==[[0第一章 软件需求的本质#特性|特性]]==的来源。
  • 类似规则#2的其他规则，可以帮助系统明确哪些容器存在过期时间，因而需要在合适的时间提醒持有人。
  • 根据[[0第一章 软件需求的本质#特性|特性]]推导功能需求
    • Expired.Notify.Before：如果一个由保质期的化学品容器的状态是为被销毁，那么系统需要在容器过期前一周通知容器当时的持有人。
    • Expired.Notify.Date：如果一个由保质期的化学品容器的状态是为被销毁，那么系统需要在容器过期当天通知容器当时的持有人
    • Expired.Notify.After：如果一个由保质期的化学品容器的状态是为被销毁，那么系统需要在容器过期一周后通知容器过期一周后通知容器当时的持有人。
    • Expired.Notify.Manage：如果一个由保质期的化学品容器的状态是为被销毁，那么系统需要在容器过期两轴后通知容器当时持有人的经理。
  • Expired.Notify 如果一个有保质期的化学品容器的状态是未被销毁，那么系统需要在下表所示的时间通知表中相应联系人

需求表示	被提醒人	提醒时间
.Before	容器当前的持有人	过期日一周之前
.Date	容器当前的持有人	过期当天
.After	容器当前的持有人	过期日一周后
.Manager	容器当前持有人的经理	过期日期两周后

把一起串起来

• 为了避免冗余，不要将业务规则目录中的规则复制到需求文档中。
• 在特定的功能与算法的来源描述中引用相应的规则
• 三种关联方式
  • 如果使用需求管理工具，就为需求新建一个“来源”属性并把原始规则列为功能需求的来源。
  • 在需求跟踪举证或需求映射矩阵中定义功能需求与相应业务规则之间的可跟踪链接，当业务规则与需求保存在同一个库中时，使用这种方法最方便。
  • 如果业务规则需求存储在文件处理软件或电子表格文件中，在需求描述中插入业务规则ID的超链接并将其指向记录业务规则描述的文件。