华为可信专业级之—— 需求分析

华为的可信设计与重构专业级考试（科目四）一直是很多华为人无法逾越的拦路虎，这门考试通过需求分析、可信设计、软件建模、设计模式、重构分析等几个部分，涵盖了整个软件工程中最核心的模块。这需要我们花很多时间学习并彻底灵活运用各个知识点才能考过。我将通过一个系列的的文章来带大家理解这几个模块。本篇我们将理解 需求分析。

需求分析

为了引导产品、软件设计开发人员以正确的方法规范的进行需求分析工作，我们需要从以下三个方面来理解和完成需求分析：

1. 开展需求分析的意义, 及需求分析相关的概念
2. 需求分析的基本流程及方法
3. 需求的管理

1. 需求分析的理解

如上图所示，对于整个软件工程的修复成本，越早发现缺陷，修复的成本就越小，除此之外还有其他影响修复成本的，例如伪需求会导致我们整体的方向错误，需求工程是成功的系统开发不可或缺的重要活动，也是应对软件密集型系统诸多挑战的关键要素。因此理解并参与需求分析是软件开发人员进阶的必修课程。

• 需求定义：用户解决某个问题或者达到某个目标所需要的条件和能力；一个系统或者系统组件为了实现某个契约、标准、规格说明或其他需要遵循的文件而必须满足的条件或拥有的能力
• 需求的二重性: 需求=问题＋解决方案； 关键是挖掘根因
• 需求分析定义：准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化到相应的形式功能规约（需求规格说明）的过程。 下图所示展示了一个需求的 分层和分类： 在华为软件需求分析过程中，其实我们一只面临如下一些问题：
• 需求分析输出不能很好的支撑设计、开发、测试、资料。例如需求文档没有原始需求，没有说明用户的使用场景，直接描述分解后的需求规格，导致开发直接按照AR编码实现，测试根据对业务和设计的理解，自己设计测试场景和要评估的客户界面。
• 输入混乱，没有聚焦客户价值。例如版本需求变化频繁，很难控制，有时一个版本通过RMT落地的需求代码量超过版本IR需求包
• 需求描述不清晰。例如需求描述中使用“大概”、“等”类的不确定描述语言。如“设备能够提供实时功率、耗电量统计等信息”
• 需求分解不全面。例如需求分解遗漏，如“平台软件需要归一”不只是平台需要归一，还需要产品配合切换，但该需求未分解到产品，导致发版本时出现配套异常。

2. 需求分析的流程和方法探讨

graph LR
问题识别 --> 分析与综合 --> 规格说明 --> 评审

如上流程图所示，展示了需求分析过程中的主要活动。首先收集用户要求，确定业务目标，并提出这些需求的实现条件；其次逐步细化功能需求，给出详细的逻辑模型，确定功能优先级；再次规范化描述需求的设计规格，即需求规格说明书；最后确保对需求达成共同的理解和认识，对功能给与评价。需求分析方法有：功能分解法、结构化分析法、信息建模法、面向对象分析方法等，华为常见的需求分析方法是 USE-CASE分析法。

2.1 基于用例（Use-Case）技术需求分析方法

基于用例（Use-Case）技术需求分析方法是一种捕获、组织、描述需求的方法。运用用例方法来描述系统需求称之为用例建模。用例也是UML规范中的一种标准化的需求表达方式。每个“Use-Case”描述了系统执行的一系列动作，这些动作为用户提供了可观测、有价值的结果。

2.2 需求分析输出质量的要求：

3 需求管理

常见需求问题有：需求不稳定、需求传递不及时、需求描述不准确、需求分解不充分等。其问题的根因在于对需求活动缺乏有效的管理。需求管理是一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。 如上图所示，华为需求管理流程分为几个步骤：需求收集、需求分析、需求决策（变更）、需求验证。 上图展示了需求管理活动的具体内容，需求变更是需求基础上追加和补充新的需求，或对原有需求进行修改和削减，对软件开发有非常重要的影响：

• 需求变更频繁都是影响研发效能的第一号因素
• 增加项目的人员、费用开支，影响开发进度。
• 影响软件质量。
• 影响开发者与用户之间的合作关系。 做好需求变更的关键步骤我们也可以总结为如下流程：

graph LR
需求评估 --> 变更电子流 --> 需求决策 --> 导入版本协同落地

我们需要明白得是：

1. 软件项目唯一不变的就是不断变更，但在某个版本中，要通过合理的版本管理和需求管理尽可能保持需求稳定。
2. 需求管理贯穿整个软件需求工程中。需求管理最基本的任务是明确需求，使项目团队和用户达成共识，即建立需求基线。
3. 需求管理对项目的成功有着重要影响，需求的变更需要进行规范的流程管控，根据需求排序及时拒绝低优级的需求，可以减少后继的方案设计及开发工作量。