《有效需求分析》笔记

雅琪

<hr/>引导

00 软件需求全景图

传统的需求分析是站在技术视角展开的，关注的是”方案级需求“；而业务驱动的需求思想则是站在用户视角展开的，关注的是”问题级需求“。

变更/优化需求分析任务

需求分析师是“问题解决者”，而不是简单的需求传递者。

在软件需求分析实践中，用户提出变更/优化型需求通常都是直接提出“方案级需求”，而我们需要还原出“问题级需求”。
客户是问题专家，而非解决方案专家，他提出的方案未必能够完美地解决他遇到的问题。
执行指引——

• 针对“方案级需求”，需要首先“澄清问题”：
  
  
  • 想要解决谁的、什么问题？
    
  • 用户现在遇到这个问题会采用什么样的解决方案？
    
  • 这个问题中有需要进一步细化和明确的概念吗？
    
  
  
• 了解问题后，接着了解背景细化以下内容：
  
  
  • 场景（功能）：
    
    
    • 该需求谁使用
      
    • 什么时候使用
      
    • 具体怎么做
      
    
    
  • 术语（数据）：
    
    
    • 有需要澄清的业务术语吗
      
    • 它们的格式是什么？
      
    
    
  • 环境（质量）：
    
    
    • 不做谁生气
      
    • 多久生气一次，为什么？
      
    • 多久用一次
      
    
    
  
  
• 最后，建议并确定解决方案：
  
  
  • 要解决这个问题有哪些可行的方案？
    
  • 这些方案的实现成本分别有多大？
    
  • 你觉得哪种最合适？
    
  • 有其他需要挖掘的需求吗？
    
  
  

组织应用类软件系统需求全景图

• 价值需求
  
  
  
  • 目标场景
    
  • 干系人关注点
    
  • 干系人阻力点
    
  
  
• 详细需求
  
  
  
  • 行为需求（功能需求）
    
  • 数据需求
    
  • 非功能需求
    
  
  

价值需求
【价值需求】就是从黑盒子视角回答：

• 整个软件系统为客户解决了什么问题、创造了什么机会？
  
• 对于系统而言，最关键的干系人有哪些？
  
• 各个重要干系人对系统的关注点是什么？有哪些关心？
  

价值需求分析关键在于执行好目标分析、干系人识别、干系人分析三个任务。

详细需求
【详细需求】就是从灰盒子的视角完成：

• 功能需求：为了给客户提供业务、管理、维护支持，需要提供哪些功能？
  
• 数据需求：系统所涉及的问题域中有哪些数据，之间是何关系？
  
• 非功能需求：所处的业务环境会带来哪些约束和质量要求？
  

如何梳理详细需求？

• 子问题域分解：可以根据实际需要选用层次图、构件图、数据流图等来呈现分解结果。进而定义各子问题域间的业务接口。
  
• 功能主线（从“工作流”线索分析）：
  
  
  
  • 业务支持，就是从灰盒子视角回答四个问题：
    
    
    
    • 根据目标和干系人关注点，系统涉及哪些业务流程？
      
    • 这些业务流程是如何定义的，需要优化吗？
      
    • 系统对流程中所有业务场景都要支持吗？还是只支持一部分？
      
    • 有哪些业务场景的工作经验需要模型化？
      
    
    
  • 管理支持，就是从灰盒子视角回答三个问题：
    
    
    
    • 管理层用户希望通过系统来实现哪些管理、控制需求？
      
    • 希望通过系统做哪些辅助决策？
      
    • 要实现这些管理、控制、决策支持，需要哪些信息？用什么方法获得它们？
      
    
    
  • 维护支持，就是从灰盒子视角回答两个问题：
    
    
    
    • 有谁会需要对系统进行维护？
      
    • 他们需要执行哪些维护任务？
      
    
    
  
  
• 数据主线（从“信息流”线索分析，也包括“资金流、物流”），就是从灰盒子的角度回答三个问题：
  
  
  
  • 系统相关的问题域中有哪些业务数据？
    
  • 它们之间是什么样的关系？
    
  • 每个业务数据的具体构成是怎么样的？
    
  
  
• 非功能主线，就是从灰盒子的角度回答一个问题：
  
  
  
  • 系统相关的外部环境会带来什么样的约束和质量要求”，比如系统部署、应用环境。
    
  
  

系统的所有功能因何而存在？

• 通过系统固化、优化业务流程，提升流程执行效率、节约成本、降低风险等。比如，CRM、供应链系统。
  
• 通过系统拓展业务的渠道，使其延伸到电话、互联网、移动互联网等通道上。比如，客服中心。
  
• 通过系统将个人知识、能力转化为组织知识、能力。比如，知识库、协同文档。
  
• 通过系统实现数据的信息化，辅助管理、决策。比如OA、财务。
  

约束&规则

• 约束分析：当系统中有大量的约束时，需要强化约束分析。
  
• 规则分析：当系统是一个强规则，规则量大、规则很复杂时，就可以考虑单独作为一个主题来分析，否则可以在流程分析、业务功能分析、领域建模时附带对规则进行分析即可。
  

一 价值需求

01 目标/愿景分析
前 情

• 需求 = 预期 - 现状，实际上就是用户的预期和现状之间的差距。
  
  
  
  • 预期 > 现状，用户通常会积极配合需求调研；
    
  • 预期 = 现状，用户表现不积极，很难用直接调研的方法获取需求；
    
  • 预期 ＜ 现状，用户会抗拒变化，对需求调研表现消极；
    
  • 针对后两种情况，需要通过对现状的深入了解，提出用户可能为之心动的“新预期”，从而“预期 ＞ 现状”
    
  
  
• 目标就是问题和机会
  
  
  
  • 机会场景：如果客户对现状满意，就要提出新预期来让他产生需求。关键在于从用户角度思考，而不是从系统中找优点。
    
  • 问题场景：如果客户预期高于现状，通常可以通过访谈获得。
    
  • 目标分析主要针对的是项目发起人、出资人或项目属主。
    
  
  
• 目标的三种描述方式
  
  
  
  • 定性描述：只是指出了一个模糊的方向，无法有效的界定系统的范围。
    
  • 定量描述：SMART 原则，具体的、可衡量的、可实现的、有相关性的、有时限性的。
    
  • 场景化描述：用故事场景来描述用户的期望，包括当前的现状、它所引发的影响，以及系统可以采用的策略。
    
  
  

要 点

• 访谈“问题”：通过对关键干系人的访谈，识别预期与现状的差距。
  

• 研讨“机会”：通过与领域专家、技术专家、用户代表的交流，寻找潜在机会。
  

• 定义问题/机会：先讲故事，再讲数字。
  

• 描述问题：如果收集到多个问题场景或机会场景，那么应该逐个进行问题/机会定义、问题分析与解决方案确定。
  
  
  • 业务态：一定要从业务的角度阐述问题或机会，而不是从系统的角度来阐述。
    
  • 客观性：不要加入主观的判断，而只是真实的还原问题。
    
  • 匹配性：项目的目标或愿景针对的都是高层读者，因此定义的问题要能够与高管的关注视角相匹配。
    
  
  
• 分析影响：
  
  
  • 指代清晰，具体到人：说明该问题影响了谁，并且清晰、具体的列出。
    
  • 视角匹配，影响明确：
    
    
    • 高层：经营性层面
      
    • 中层：具体事务
      
    
    
  • 推理合理，层次清晰
    
  
  

• 分析问题并确定解决方案：深入分析问题，然后确定策略级的解决方案。
  

• 分析问题：
  
  
  • 鱼骨图法：认为问题是由一系列子问题构成的。
    
  • 问题现状树法：认为问题是由一系列因果关系产生的。
    
  • 系统思考法：认为问题是由一系列因果关系产生的，而且包括促进因和阻碍因两种。
    
  
  
• 明确解决方案策略：在描述解决方案时，应该从宏观视角说明，并且强调出具体的策略，以便客户高层能够理解。
  
• 提炼“一句话目标”：对这个目标场景进行概述。其要点在于业务态、价值态，以“措施＋效果”的结构描述。
  

02 干系人识别

前 情
项目是一个博弈游戏，重要的是获得足够的筹码，也就是需要找到关键的筹码持有人，赢得足够的筹码就可以赢得项目，并且你也不可能获得所有的筹码。
要 点

• 根据目标识别关键干系人：在很多需求分析实践中，大家更多关注于干系人的影响度，而忽略了他与项目的相关度，从而错误识别了关键干系人。
  

• 根据风险识别其他关键干系人：
  

• 一般不建议把基层用户列为关键干系人。如果对基层用户影响较大，可以通过提前“管理预期”，在系统上线前降低预期，再创造系统上线后的部分超预期，使用户的满意度有所提升。
  
• 面对具有“一票否决权”的关键干系人，必须分析他的关键需求，进而提出针对性的、双赢的解决方案。
  

03 干系人分析

识别出关键干系人后，选择合适的代表进行调研，分析他们的关注点、阻力点、以及满足关注点、避免阻力点所需的功能、非功能需求。

前 情
在干系人关注点分析时，要从两个角度出发：一是他们希望系统解决什么问题、提供什么业务支持；二是他们希望避免出现什么样的负面影响。
要 点

• 选择干系人代表
  

• 优选代表：一是有代表性，二是典型性。
  
• 了解基本信息：职业角色、个人特点、联络信息。
  

• 分析干系人需求
  

• 访谈干系人：可以根据需要组合使用不同的分解结构。
  
• 分析关注点：
  
  
  • 除了分析干系人的关注点（正需求），还需要分析阻力点（负需求）。
    
  • 在描述分析结果时，可以包括两个部分：第一部分是干系人关注点/担心点（Why），第二部分是相应的功能需求（How）。
    
  • 在写Why的部分时，要把握三个写作要点：一是从业务角度写，二是要以结果态写，三是必须体现出价值。
    
  
  

• 干系人关注点整理：横向评估不同关键干系人之间诉求、关注点的冲突，并制定相应的应对策略。
  

二 详细需求 之 系统分解

04 业务子系统划分

可以根据实现结构来划分，但在需求阶段更推荐根据业务来划分。

前 情
建议用业务角度来划分子系统，以提升用户的沟通效率、激活用户的参与度。
要 点

• 划分业务子系统：根据系统特点，选择合适的划分策略进行分解。
  

• 按业务职能分解：最典型的就是产、销、供、管四个部分。
  
• 按产品/服务分解：先梳理出“业务结构树”，然后以不同的产品/服务作为划分线索。
  
• 双维度分解：采用“职能”和“产品/服务”双维度进行划分，分一级、二级两个维度划分。
  
• 按关键特性分解：从系统对用户的价值角度识别关键特性，然后逐一再做后续的需求分析。
  

• 标识接口、确定关系：明确各子系统之间的服务接口。
  

• 呈现业务子系统划分：
  

• 层次图：各个子系统关系简单、强调纵向分解，通常只有两级、多级分解时使用。
  
• 构件图：各个子系统存在横向行为、服务、调用关系需求呈现。
  
• 数据流图：各个子系统之间的“业务关系”、“服务关系”主要是数据共享、数据交换形式。
  

05 业务接口分析

前 情
业务接口分析和系统接口设计的区别：

• 一个业务接口可以由一个或多个系统接口来实现
  
• 接口分析只明确 WHY（用途与业务价值）、WHAT（交互过程） 及约束，不涉及 HOW（解决方案）
  

要 点

• 明确接口的用户与业务价值
  
  
  • 哪个子系统实现该接口是合适的？由“知道”接口所需信息的子系统来实现接口。
    
  • 哪些子系统会用，用来实现什么价值？逐一标识，说明为什么会使用，即达成的业务目的是什么。
    
  • 使用频率大概是什么样的？
    
  
  
• 细化接口的交互过程
  
  
  • 时序图，呈现出接口的交互过程；
    
  • 数据词典：细化的定义出每次交互过程中数据包的构成情况。
    
  
  
• 确定接口设计约束：需要考虑特定数据、通信协议、遗留系统带来的限制、数据传输、数据查询、加解密、部署环境（服务器、网络）、使用者特点（频率、操作环境）。
  

三 详细需求 之 功能主线

06 业务流程识别

前 情
什么是业务流程？
业务流程是由一个多人协作的过程，而且需要通过一些有效的规则来控制，才能达到预期的结果。
企业或组织的核心价值在于响应外部客户的服务请求，通过一系列的协作满足服务请求，为客户带来价值，同时为企业/组织带来价值。我们找到流程的源头——外部服务请求，也就识别出了业务流程。
什么是端到端流程？

• 完整：所谓的端到端，实际就是服务请求从提出到满足的全过程。也就是判断一个流程是否完整，应该站在服务请求的立场，判断服务请求是否满足或者被拒绝。
  
• 边界：识别业务流程时涉及两种边界。一是职能边界，也就是跨越了我们未涉及的业务域；二是系统边界，也就是不属于系统关注的部分。
  

要 点

• 识别外部引发的主、变、支流程：业务流程大多是响应外部客户、外部员工服务请求的，因此先识别它们。
  

• 主业务流程：体现了外部客户的主诉求。
  
• 变体业务流程：实际上属于主业务流程，但相对独立。
  
• 支撑业务流程：提供一些边缘的、辅助的业务支撑，属于一种锦上添花的业务。
  

• 识别内部引发的主、变、支流程：有些服务请求是由内部员工主动发起的，诸如销售流程，还有些是在特定时间、状态下发起的，因此识别完外部的，还需要从内部补充。
  

• 识别管理流程：有一部分业务流程是为了实现控制、监督、管理等意图，需要单独识别。
  

• 按阶段划分——
  
  
  • 用于事先预防的管理流程
    
  • 用于事中控制的审批、规则
    
  • 用于事后分析的报表、数据分析
    
  
  
• 按业务划分——
  
  
  • 业务上线类的审批控制
    
  • 人、财、物、资源的管控
    
  • 进度和异常的控制
    
  
  

• 判断业务流程优先级：业务流程是信息系统交付的最小单元，因此对业务流程做优先级判断，有利于做出更合适的迭代计划。推荐根据它是否为主营业务、发生的频率高低来进行综合评估。
  

07 业务流程分析与优化

前 情
分层业务流程

• 组织级流程：部门间协作关系，供决策层读者阅读。
  
• 部门级流程：岗位间协作关系，供管理层阅读，业务流程分析应该在这个粒度上进行。
  
• 个人级流程：一个岗位的工作步骤，应该到业务场景分析时再细化。
  

业务流程八要素

• 5 个基本要素：
  
  
  
  • 流程涉及了哪些分工？
    
  • 每个角色负责执行什么活动？
    
  • 活动间的协作关系？顺序执行、并行执行、异步执行。
    
  • 根据实际情况来处理协作过程，这就是流程中的“分支”。
    
  • 各分工之间需要传递工作产物，这就是“产物关系”。
    
  
  
• 3 个管理要素：审核、规则、异常
  

要 点

• 选择流程图描述方式：根据读者、流程类型选择合适的流程图来描述流程分析的结果。
  

• 勾勒流程主体：厘清业务流程中的分工、活动、协作、分支、产物关系五要素，搭出流程的主体框架。找到客户代表或业务专家，通过“一听二问三读”的方法来完成整个流程图的绘制。
  
• 补充事中管控点：厘清业务流程中的异常、审批、规则。
  

• 首先和业务专家、客户代表就“异常”进行交流。
  
• 其次把重心放在“审批”上。
  
• 最后沿着流程，思考一下是否需要设置一些规则。
  
  
  • 协作间规则：用于控制流程协作的规则。
    
  • 业务活动执行规则：在执行各个业务步骤时需要遵循的规则。
    
  • 数据规则：针对表单、文档、生成产物的格式、内容进行限制的规则。
    
  
  

• 分析流程执行过程的监管需求：从管理者对流程的进度、异常等方面的管控，识别、补充一些辅助的相关需求。
  
• 流程优化初步：以“同理心”转换到客户角度，通过穿越流程的方法来识别问题。找到问题后，采用“ESIA”策略优化流程：
  

• E（清除无效）：找到流程中不产生效能的、浪费的、低效的环节，然后想办法清除。
  
• S（简化高频）：对频率最高的环节进行优化，流程效率将上升。
  
• I（整合依赖）：将相互依赖的环节整合在一起，提高效率。
  
• A（自动化烦琐）：把人做起来麻烦的事让电脑来干，提升效率。
  

08 业务场景识别

一个完整的业务场景应该是独立的、可汇报的、可暂停的单元。

前 情
业务/使用场景 VS 功能

• 枯燥的、非用户直接相关的功能性描述，只能拒人千里之外，最终导致与用户沟通的不畅，影响需求的获取与理解。
  
• 生动的、用户视角的使用场景、业务场景描述，才能与用户产生共鸣，实现“用户为中心”的需求获取与理解。
  

用例的本质

• 用例分析技术的核心在于“用户视角”的需求观，强调了目的、场景的重要性，而用例图本身并不是本质。简而言之，用例即业务场景、使用场景。
  
• 在一个信息系统中，业务流程是指不同岗位之间通过协作满足外部服务请求的过程；而业务场景则是以某岗位为主完成的、相对独立的、可以汇报的业务活动。因此，从某种角度而言，用例的粒度是由组织分工决定的。
  
• 对于不带业务流程的项目或产品，那么用例就是一个用户的使用场景，也是一个相对独立的、可以暂停的场景。
  

用户故事的本质

• 用户故事，是一种轻量的、有效的用户需求描述方式，它希望用户或用户代表以**“作为 xxx（角色），希望通过系统 xxx（解决方案、功能要求），以便达成×××业务目的、要解决的业务问题”**的形式提出需求。因此从本质上，还是“用户视角”，也具有业务场景的特性。
  
• 关于故事的合适粒度，通常开发团队会约定一个以工作量为基础的粒度，。如果超过了这个粒度，就要求“现场客户”将这个故事进行分拆，直到达到合适的粒度为止。
  

要 点

• 基于流程图识别系统角色
  

• 基于流程图识别业务场景，这一步骤应沿着流程过程，对每个活动、分支、判断点进行分析和思考：哪些业务活动要系统支持、哪些是部分支持，审批点是否属于系统内，判断点是否为独立环节。
  
• 补充业务场景，即未在流程图中体现，在特定时间、特定状态触发的业务场景。
  
• 绘制用例图片段并概述业务场景
  

• actor 与用例之间的关系：
  
  
  • actor 指向用例，表示该系统角色可以通过系统完成相应的业务；
    
  • 用例指向 actor，如果 actor 是人，一般是指用例在执行过程中会通知他；如果 actor 是系统，一般是指用例在执行过程中将调用改系统。
    
  
  
• actor 与 actor 之间的关系：泛化，表示角色权限继承。
  
• 用例与用例之间的关系：
  
  
  • 包含，表示的是一定会执行的公共子事件流；
    
  • 扩展，表示的是不一定会执行的扩展事件流；
    
  • 泛化，表示公共的事件流，它是不连续的，就像用例模板一样。
    
  
  
• 对用例图片段整理和说明，包括 actor 与最终用户的映射、用例概述和用例优先级。
  
• 用例图给谁看？管理层用户关注事到事的逻辑，更愿意看流程图；操作层用户关注人到事的逻辑，因此用例图更合适。
  

• 对无业务流程的系统识别业务场景
  

09 业务场景分析

场景 → 问题/挑战 → 方案 → 功能。

前 情
用户视角的场景描述
在需求分析中先梳理出整个使用场景的各个步骤，也就能够让用户更有带入感地发现功能需求。
场景 → 挑战 → 方案

• 场景细化：将场景细化为事件流，先整理出用户预期的正常步骤，然后写出变化的情况。
  
• 问题/ 挑战识别：针对每一步骤，站在用户的角度来思考他们会遇到什么问题，面对什么样的挑战。
  
• 思考应对方案：针对这些问题，思考系统应该提供什么样的功能。
  

要 点

• 概述业务场景
  
  
  • 该业务场景中，用户要实现什么样的业务目的？
    
  • 执行该场景有什么前提条件？结束前需保证何状态？
    
  • 除场景执行者之外，还有谁关心它？关心什么？
    
  
  
• 细化业务场景的业务步骤，在执行的过程中，可以思考三个问题：
  
  
  • 最典型的、用户预期内的业务步骤是怎么样的（基本事件流）；
    
  • 针对各个步骤，有哪些潜在的变化情况（扩展事件流）；
    
  • 针对各个步骤，有无异常情况，异常如何处理（异常事件流，通常是错误处理部分）
    
  
  
• 遍历步骤分析困难，导出功能
  
  
  • 在各个业务步骤、变化及异常情况下会遇到何困难？针对这些困难，系统需要提供什么样的功能支持
    
  • 是否存在不能按以上步骤处理的情况？这种情况需要系统提供什么样的功能支持？
    
  
  
• 识别环境与规划
  
  
  • 性能相关：主要包括执行该业务场景的人数、典型的业务量、峰值情况的业务量、密度（特别是一天内业务发生的频率不一时需要说明）。
    
  • 易用性相关：主要就是用户的成长经历和相关系统使用的经验，它对于系统易用性设计有指向性作用。
    
  • 部署环境相关：说明用户所在的网络、软硬件等相关环境
    
  
  
• 分析实现方式，完成初步交互设计：包括交互过程、静态快照、设计说明。
  

10 管控点识别与分析

管理支持的核心：通过管理流程事先规避风险，通过规则和审批事中控制风险，通过数据分析做事后优化。

前 情
数据不是信息
数据和信息是有距离的，而这个距离就是“why”所带来的，多问问用户为什么要看到这些数据，基于这些数据有什么作用。
什么是管控点？
我们在做业务报表、BI 需求、数据挖掘/数据仓库、大数据分析时，核心在于把握用户想要什么信息，他的管理意图是什么，才有实现有效分析。
要 点

• 标识管理者
  

• 管理自我：这一级别准确来说并不属于管理者，就是员工。关注个人的时间管理、计划管理、情绪管理等，这群人不会在本任务中被关注。
  
• 管理团队：“管理型”管理者的第一级，通常是负责带领一支小团队完成上级交办的特定任务。关注团队管理、人员管理，在本任务中少量涉及。
  
• 管理事务：“管理型”管理者的第二级，比如项目经理。他们将对一件事负责，人、进度、资源都会涉及，在本任务中经常遇到。
  
• 管理职能：“管理型”管理者的第三级，比如产品、测试。他们关注于多事务，也关注人、资源、进度，在本任务中也经常遇到。
  
• 管理业务：“经营型”管理者的第一级，他们将涉及经营性指标。更加关注客户、产品、供应商等经营性主题，反而对具体的执行性事务关注变少，在本任务中经常遇到。
  
• 管理业务群：“经营型”管理者的第二级，与“管理业务”最大的区别在于他将管理多业务，一般对于资本、均衡等方面更重视，想法也更宏观。通常他们关注的都将是“决策相关”的管控点。
  

• 标识管控点（涉及管理学知识、行业相关知识）
  

• 分析所需指标，应该进行正、反两面进行分析：
  

• 正面就是迎难而上，思考分析业务设置合理性需要哪些信息；
  
• 反面就是逆向思考，思考业务设置如果不合理会出现什么情况，这些情况可以通过哪些数据反映出来。
  

• 分析实现方式
  

11 业务报表分析

要 点

• 明确报表的使用场景
  
  
  • 谁使用：涉及报表生产者、报表越读者。生成者出于“考核”、“业绩”压力可能会对数据进行“伪造”。
    
  • 为什么用
    
  • 使用频率如何
    
  
  
• 分析报表的内容：报表的本质不是“事件流”，而是“内容”，即生成报表之前要输入什么条件，从哪里得到所需数据源，生成哪些数据项及其格式、计算方法。
  
• 整理报表的输出要求
  

12 维护需求分析

要 点

• 标识配置性维护场景
  
  
  • 用户群变化：使用系统的用户的职位、权限等发生改变。对于权限而言，核心包括功能权限、数据范围权限、分配权限的权限。
    
  • 流程变化
    
  • 数据变化
    
  • 法规变化
    
  
  
• 标识系统允许阶段维护场景
  
  
  • 正常时：对运行状态的监控、数据备份。
    
  • 故障时：对故障的定位、排错、恢复及应急措施的支持。
    
  
  
• 补充其他维护场景：包括运行前的初始化，系统升级、迁移时的支持。
  

四 详细需求 之 数据主线

13 领域建模

前 情
类图

• 类：表示一个具体的业务数据，分为类名、属性、方法。
  
• 类间关系：用来描述各个业务数据之间的横向关系。最常用的有，关联、整体部分（松散聚合和紧密组合）、类别。
  

要 点

《UML 彩色建模》

• 识别过程数据
  
• 识别自然数据：就是问题域中所涉及的“参与者”、“地点”、“东西（物品、服务）”。还要考虑是否需要引入“角色”。
  
• 识别描述类数据
  
  
  • 一是概述类，如为了方便选择商品，抽象了品类这一概述性名称；
    
  • 二是规则类，也就是想使用数据库表配置的相关规则。
    
  
  
• 整理领域类图片段，合并出系统领域模型：找出所有主业务流程，针对每个流程绘制领域类图片段，然后将它们合并成整个系统的领域模型
  

14 业务数据分析

要 点

• 数据应用分析：就是厘清哪些流程、场景在使用这些数据，使用这些数据的哪些部分，甚至厘清 CRUD （创建、查询、更新、删除）的关系。
  
• 数据构成分析：首先要厘清这个业务数据包括哪些字段，然后针对各个字段厘清它的数据类型、数据规格、约束/取值范围、其他。
  
• 数据特点分析
  
  
  • 结构特点：主要字段与次要字段、稳定字段与不稳定字段。
    
  • 使用特点：即时数据与历史数据、关键字段与辅助字段。
    
  
  

五 详细需求 之 质量主线

15 标识关键质量需求

前 情
质量需求，要从逆向、场景化的角度来思考。
要 点

• 识别重要质量属性
  

• 安全性：最大威胁在于存在敏感数据、组织“名气”很大、处于开放网络环境、基于早期版本的操作系统部署。
  
• 可靠性：最大威胁在于要求高、环境复杂、使用者手生。
  
• 易用性：最大威胁在于效率要求高、用户基础弱、与“你”差异大。
  
• 性能：最大威胁在于高并发访问、复杂的算法与逻辑。
  
• 可维护性：最大威胁在于变化，包括业务变化、技术变化。
  
• 可移植性：最大威胁在于系统生命周期长、系统部署范围大。
  

• 对重要质量属性排序
  

• 威胁影响度
  
• 出现频率：分为经常出现、偶尔出现、低概率出现，给予 3、2、1 分的权重。
  

16 质量场景分析

要 点

• 识别质量场景：站在对面，思考什么时候不安全、不可靠、不易用；给出具体的场景。
  
• 制定对策：针对某一质量场景所带来的影响、威胁，要采用什么样的技术手段来避免或者降低风险。但是每种措施都难免会带来新的问题和影响，因此也要看清它带来的潜在问题。
  
• 验证矛盾并解决
  

六 补充

17 业务规则分析

要 点

• 按规则作用域归类规则
  

• 按规则类型二次归类规则
  

• 行为类：也就是一些影响业务流程、场景执行的规则，它们适合放在相应的流程分析、场景分析的描述中。
  
• 数据类：也就是用来控制数据格式、内容的规则，它们适合放在领域模型的规则描述中。
  
• 权限类：也就是用来控制执行和数据查看权限的规则，它们应该放在权限需求描述中。
  

• 分析规则后的动机：它包括两个方面：一是业务动机，二是可执行性考虑。理解业务动机，可能会发现该规则欠考虑的地方；理解可执行性考虑，则可能会发现通过系统实现后，可以更好地优化规则。
  

18 约束分析

要 点

• 明确项目约束
  
  
  • 进度要求：不仅仅列出最晚交付时间值，还应该理解这个最后期限最后的理由。
    
  • 资源支持：明确接口人、开发测试环境支持等
    
  • 预算要求：一般不涉及。
    
  
  
• 明确实现约束
  
  
  • 技术选型
    
  • 部署环境
    
  • 开发环境
    
  
  

<hr/>有点意思，想看更多？GuluF 的个人知识库

泰鹏注塑朱雪峰

感谢分享。请问，怎么理解黑盒子视角 灰盒子视角 我看文中反复出现

任卓

我理解的所谓黑盒子视角，就是关注这个产品/功能/模块，解决了谁的什么问题，优势劣势分别是什么，用户价值是什么。
而灰盒子视角，就是关注这个问题是如何被解决的，内部业务流程是什么，如何与外部更大的系统或流程融合打通，解决方案是什么。