【软件工程】需求分析和需求管理

一.需求分析简述

1.为什么要展开需求分析？

• 伪需求会导致开发方向错误
• 需求缺陷发现越晚修复成本越高

2.为什么要学习需求分析？

• 理解并参与需求分析工作是软件开发人员进阶的必修课

• 开发必备

  • 需求分析是用户和开发者之间的翻译员，开发者要准确理解需求，才能做正确的事；
  • 梅捷开发流程下需要全栈工程师，快速准确分解需求是开发人员的必备能力素质；

• 进阶必修

  • 公司某系统架构师职责需求节选：独立或者主持完成解决方案关键竞争特性的软件系统设计和需求分解分配，满足客户要求符合客户网络安全要求；
  • 个人职业发展进阶的必修课；

• 成功必选

  • 50%以上的项目存在资源超支/功能限制，其中需求类问题占比48%；
  • 需求工程是成功的系统开发不可缺少的重要活动，也是应对软件密集型系统诸多挑战的关键。

3.什么是需求？

• 用户解决某个问题或者达到某个目标所需要的条件和能力；
• 一个系统或者系统组件为了实现某个锲约，便准，规格说明或其他需求遵循的文件而必须满足的条件或拥有的能力；
• 对上述两点描述的条件或能力的文档化表示。

4.什么是需求的二重性？

• 在不同的条件和能力下，会有不同的解决方案。也就是说一个问题可以有多个解决方案，这就是需求的二重性
• 需求=问题+解决方案，关键是挖掘根因

5.什么是需求分析？

• 定义：
  • 准确理解用户的要求，进行细致的调查分析，即将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化到相应形式的规约（需求规格说明）的过程。
• 目标:
  • 把用户对待开发软件提出的”需求“或者”需要“进行分析和整理，确认后形成描述完整，清晰与规范的文档，确认软件需要实现那些功能，完成那些工作。
  • 软件的一些非功能性需求（如软件性能，可靠性，相应时间，可扩展性等），软件设计的约束条件，运行时与其他软件的相关性等也是软件需求分析的目标。
• 故而，需求包括功能性需求，质量性能需求和约束。

6.需求的分层分类？

7.需求分析过程中存在的普遍问题

• 输入混乱，场景不清晰
  • 需求粒度差别很大。从特性，内部增强，版本遗留都有。粒度从十几行到数万行不等。
• 需求分析输出不能很好的支撑设计，开发，测试，资料。
  • 需求文档没有原始需求文档，没有说明用户的使用场景，直接描述分解后的需求规格，导致开发直接按照AR编码实现，测试根据对业务和设计的理解，自己设计测试场景和要评估的客户界面。
  • 需求分析多站在系统的角度描述内部功能，需求片段，甚至不考虑客户如何使用，资料人员无法根据设计文档进行开发，需要SE两外输出材料。很多材料问题，需要SE补充针对性的方案设计才能解决。
• 需求描述不清晰
  • 需求描述中使用”大概“，”等“类的不确定描述语言。
  • 需求描述不具体
• 需求分解不全面
  • 需求分解遗漏

8.本章小结

• 需求分析的任务就是解决”做什么“的问题，就是全面地理解用户的各项要求，并准确地表达所接受的用户要求
• 需求分析的输入是目标，问题和场景，输出是形式化的功能规约，质量属性和设计约束，分析过程中要考虑众多涉众利益和DFX属性
• 非功能需求要指不明确的功能需求，需求分析阶段应将不明确的功能需求细化成功能性需求。但像竞争力需求是商业领域关注内容，不是属于软件需求考虑范畴。

二.需求分析流程

1.需求分析主要活动

• 问题识别
  • 收集用户的要求，确定业务目标，并提出这些需求的实现条件，以及需求应该达到的目标。
• 分析和综合
  • 逐渐细化为功能需求，非功能质量属性需求，并综合系统的解决方案，给出详细逻辑模型
  • 确定每项功能需求优先级，以便于需求落地管理。
• 规格说明
  • 规范化描述需求的设计规格，即需求规格说明书。
• 评审
  • 确保对需求达成共同的理解和认识
  • 对功能需求描述的正确性，完整性和清晰性，以及其它需求给予评价

2.需求分析方法

• 功能分解方法
• 结构化分析方法
• 信息建模法
• 面向对象的分析方法
• 常见的需求分析方法：USE-CASE,功能分析

3.基于用例（USE-CASE）技术需求分析方法

• 什么是用例（Use-Case）？
  • 一种捕获，组织，描述需求的方法。运用用例方法来描述系统需求称之为用例建模。用例也是UML规范化的一种标准化的需求表达方式。
• 用例建模的单元是什么？
  • “Use-Case”。每个”Use-Case“描述了系统执行的一系列动作，这些动作作为用户提供了可观测，有价值的结果。
• 基于用例技术的需求分析方法交付件是什么？
  • 用例模型（包括用例图，用例规格说明书），补充规约（可选），词汇表（可选）
• 基于用例技术的需求分析方法有哪些主要活动？

- 收集需求
    - 通过访谈，考察，研讨等形式提前确认用户需求，识别功能，性能，质量，约束等需求
    - 需求收集后需要对需求排优先级
- 定义系统边界
    - 明确系统的分析范围，系统边界确定了，Use Case的粒度也就确定了。
- 识别Actor
    - 系统边界外
    - 和系统直接交互，而且是有意义的交互
    - 可能是人，物，定时器
- 识别Use Case
    - Actor可见
    - 对Actor有价值
    - 有系统实现
    - 用例是系统执行的一系列动作，这些动作将生成特定参与者可观测的价值结果
    - 一个用例能表达从接触到完成有意义目标的完整的系统执行过程
    - 一个用例定义一组用例实例
- 整理场景
    - 根据功能可以在那些场景下使用，有哪些输入因素，进行适当的组合归并后得出要分析的场景
    - 场景分类：基本场景，可选场景，异常场景。
- 描述Use Case
    - 详细，完整地进行用例描述

4.需求分析输出的质量要求

• 完备性：需求分析的输出必须涵盖所有的需求，不漏失、不重复。
• 可追溯性：需求分析的输出必须能够与用户需求、客户需求、系统设计、软件测试等相关文档相互关联，从而实现全过程的管理。
• 明确性：需求分析的输出必须要清晰明确，避免歧义和模棱两可的描述。
• 一致性：需求分析的输出必须要符合要求，并且能够满足整个系统的一致性。
• 可验证性：需求分析的输出必须要可验证，能够通过软件测试来验证需求的正确性和完整性。
• 可变性：需求分析的输出必须要能够适应变化，能够随着需求变化而变化，保证随着需求变化而不断地进行迭代和改进。

三.需求管理

1.为什么需求管理？

• 常见的需求问题

  • 需求不断变化——-需求不稳定
  • 需求变化没有及时落地实现————需求传递不及时
  • 开发人员和测试人员之间理解不同，没有及时串讲沟通—————-需求描述不准确
  • 需求分解分配不合理，交付时间短，边分析便开发。——————需求分解不充分

  问题的根因：对需求活动缺乏有效管理

2.什么是需求管理？

• 需求管理是系统工程
  • 需求管理是一种获取，组织并记录系统需要的系统化方案，以及一个使客户与项目团队对不断变化的系统需求达成并保持一直的过程
  • 需求管理主要是针对需求相关活动的规划，控制和变更管理
• 需求管理是项目成功的关键要素
  • 需求分析在启动和计划阶段占有相当大的比例，对项目影响很大
  • 之所以管理需求，是为了获取项目成功

3.有哪些需求管理活动？

• 版本控制
  • 使项目团队和用户达成共识，定义需求基线。
• 需求跟踪
  • 将每项需求都能与对应的设计，源代码，测试用例联系起来，以实现需求跟踪
• 状态跟踪
  • 整个项目过程中，要始终跟踪需求状态即变更情况
• 变更控制
  • 需求变更需要经过正式评估来决定是否批准
  • 保持项目计划与需求的同步
  • 以可控制的方式将需求变更融入项目中
  • 估计变更需求产生的影响，并协商新的约定

4.需求管理活动中那个是最重要？—需求变更

• 什么是需求变更？
  • 需求说明书一般要经过论证，如果在需求说明书经过论证以后，**需要在原有的需求基础上追加和补充新的需求，或者对原有需求进行修改和消减，**均属于需求变更
• 需求变更对软件开发有何影响？
  • 需求变更频繁都是影响研发效能的第一号因素
  • 增加项目人员，费用开支，影响开发进度
  • 影响软件质量
  • 影响开发者与用户的合作关系
• 软件不断变更法则：真实世界中使用的程序必须进行变更，否则它在环境中的作用就会越来越小
• 如何做好需求变更？
  • 关键步骤：需求评估→变更电子流→需求决策(RAT/RMT/CCB)→导入版本协同落地
  • 做好需求变更预防
    • 培养正确的需求意识，对必要的变更理性对待
    • 从业务需求入手，清晰识别需求
    • 充分利用需求来源，合理识别真正需求的高优先级需求
    • 提供选择方案，让变更有一定代价来控制变更的随意性
  • 分级管理客户需求
    • 需求并非全是同样的，在需求分析阶段会根据其价值进行排序
    • 可以根据需求排序来分级管理需求变更
  • 加强需求变更的控制
    • 所有的需求变更都要经过变更流程进行控制
    • 没有被接纳的需求在设计方案时就不需要再展开
    • 需求变更过程是为了使得代价和影响最小化，并非简单拒绝
    • 需求变更必须经过组织评审来决定，不能随意接纳或者拒绝

5.本章小结

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