【软件工程】第四章·需求分析

🌈个人主页：十二月的猫-CSDN博客

🔥 系列专栏： 🏀软件开发必练内功_十二月的猫的博客-CSDN博客

💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光

[1. 前言](#1. 前言)

[2. 章节概述和章节框架](#2. 章节概述和章节框架)

[3. 获取并分析需求](#3. 获取并分析需求)

[3.1 需求](#3.1 需求)

[3.1.1 需求是什么](#3.1.1 需求是什么)

[3.1.2 需求的类型](#3.1.2 需求的类型)

[3.1.3 需求的特征](#3.1.3 需求的特征)

[3.1.4 需求的表示](#3.1.4 需求的表示)

[3.2 需求的引出](#3.2 需求的引出)

[3.2.1 风险承担者](#3.2.1 风险承担者)

[3.2.2 需求引出的具体手段](#3.2.2 需求引出的具体手段)

[3.3 需求分析](#3.3 需求分析)

[3.3.1 需求前期处理](#3.3.1 需求前期处理)

[3.3.2 需求下的约束](#3.3.2 需求下的约束)

[3.3.3 需求分析的全过程](#3.3.3 需求分析的全过程)

[3.3.4 补充知识](#3.3.4 补充知识)

[3.6 需求文档化](#3.6 需求文档化)

[3.6.1 为什么要文档化](#3.6.1 为什么要文档化)

[3.6.2 文档化的结果是什么（需求规格说明（SRS））](#3.6.2 文档化的结果是什么（需求规格说明（SRS））)

[3.7 需求的确认](#3.7 需求的确认)

[3.7.1 需求确认](#3.7.1 需求确认)

[3.7.2 需求复审](#3.7.2 需求复审)

[3.8 需求的测量](#3.8 需求的测量)

[3.8.1 测量集中的领域](#3.8.1 测量集中的领域)

[3.8.2 测量措施](#3.8.2 测量措施)

[4. 总结](#4. 总结)

1. 前言

在进入本篇文章前，大家可以先去看看另三篇文章：

【软件工程】第一章·软件工程概述-CSDN博客

【软件工程】第二章·软件过程（过程与生命周期建模）-CSDN博客

【软件工程】第三章·计划和管理项目（详解活动图计算关键路径、最早开始时间、最晚开始时间、冗余时间）-CSDN博客

首先想带大家先来简单复习一下前面的内容：

第一章·软件工程概述：

1、软件工程是什么------定义、方法、作用。

2、软件工程的前世今生------出现的问题（error、fault、failure）、应对方法（问题分析方法+系统化方法+工程化方法）。

3、软件工程的未来------Wasserman 规范（抽象、分析设计方法和符号描述系统、软件过程、软件体系结构、重用和复用、用户界面原始模型、测试代码、工具和集成环境）
第二章·软件过程与生命周期：

1、过程与生命周期是什么

过程是一系列有序的任务，涉及活动、资源和约束（过程不是步骤而是步骤的集合）。

生命周期是软件从概念、实现、交付到使用、维护的整个过程。软件开发全过程称为软件生命周期。

2、过程模型

**种类：**瀑布模型、原型化瀑布模型、V模型、原型化模型、阶段化开发模型、螺旋模型、敏捷方法模型

联系：

瀑布模型是基础。

原型化瀑布模型结合原型化模型与瀑布模型（设计阶段产生原型化模型，在测试阶段考虑是否返回）。

V模型（将设计与测试之间都建立起通道）。

原型化模型（不是具体模型，是一种思想，每一个步骤都可以产生原型去分析）。

阶段化开发模型（开发版本和使用版本分离，分离导致需要选择迭代开发/增量开发/迭代进化开发/统一过程开发）。

螺旋模型（是迭代思想和原型化思想的结合）。

敏捷方法模型（撇弃原型化和迭代化带来的冗余，将目标转化为：快【尽早交付】、准【持续有价值的软件交付活动】、狠【直到客服满意】）（四大原则：个体和交互胜过过程和工具、可运行软件胜过面面俱到的文档、客户合作胜过合作谈判、响应变化胜过遵循计划）

**核心思想：**迭代思想、增量思想、原型化思想
第三章·计划和管理项目：

1、计划项目

**时间计划：**项目进度、项目活动、里程碑、活动图、最早开始时间、最迟开始时间、冗余时间、关键路径。

**工作量计划：**估（专家估算：Delphi技术、乐观悲观法、Wol技术）、算（算式公式：（a+bSc）m（X）、COCOMO模型：aKLOC^b）

2、管理项目

**人员管理：**人员技术、工作方式、项目组织安排（结构性与创造性、一个领导模式、忘我方法模式）

风险管理：什么是风险、风险管理活动（风险评价：风险识别、风险优先级、风险分析）（风险控制：风险降低、风险化解、风险管理计划）、风险降低（风险避免、假设风险、转移风险）、风险化解（6种风险的6种应对方式：产品过大、功能复杂、系统不支持、测试时间、产品控制、协同工作）

2. 章节概述和章节框架

明确一个点： Wasserman 规范（抽象、分析设计方法和符号描述系统、软件过程、软件体系结构、重用和复用、用户界面原型、测试、工具和集成环境）贯穿软件开发全过程。

章节联系： Wasserman 规范中第一个是抽象，抽象包括：问题分析、项目计划管理之外，还应该有需求分析部分。换句话说，我认为在开始真正的软件设计分析开始之前，都需要抽象方法。

**思考：**只有抽象去思考，才能抓住问题的重点；只有抽象去思考，才能分析整个项目的重点从而弄清楚项目所要求的需求。

需求对于系统开发来讲是第一步，也是"决定生死"的一步，所以只有确定正确的需求才能保证后期的工作方向是正确的，否则只会做无用功，劳民伤财。确定需求需要进行诸多方面的操作，本章针对需求的确定、需求建模、复审需求、文档化需求等方面对需求进行研究。

3. 获取并分析需求

软件开发的前期需要进行的就是软件分析，软件分析的最后一步也就是最重要的一步就是需求分析。只有做好需求分析，才有可能做好后面的软件开发任务。

3.1 需求

3.1.1 需求是什么

**定义：**用户关于软件系统的期望行为的综合描述，涉及系统的对象、状态、约束、功能等。

3.1.2 需求的类型

需求：

①功能需求：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。

②非功能需求：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。

3.1.3 需求的特征

需求的特征：

正确性；一致性；无二义性；完备性；可行性；相关性；可测试性；可跟踪性。

补充：

正确：我们和客户都应该评审需求文档，确保它们符合我们对需求的理解

一致：一般来讲，如果不可能同时满足两个需求，那么这两个需求就是不一致的。

无二义：如果需求的多个读者能够一致、有效地解释需求，那么需求就是无二义性的。

完备：如果需求指定了所有约束下的、所有状态下的、所有可能的输入的输出以及必需的行为，那么这组需求就是完备的。

可行：当用户要求两个或更多的质量需求时，常常会出现可行性问题

相关：有时，某个需求会不必要地限制开发人员，或者会包含与客户需要没有直接关系的功能。

可测试：如果需求能够提示验收测试（明确证明最终系统是否满足需求），需求就是可测试的。

3.1.4 需求的表示

需求的表示就是对需求进行建模。

建模可以使用UML统一建模语言，例如用例图、类图等来表示，具体见如下文章：

【软件工程】一篇入门UML建模图（用例图、对象图、顺序图与协作图）-CSDN博客

【软件工程】一篇入门UML建模图（状态图、活动图、构件图、部署图）-CSDN博客

3.2 需求的引出

需求的引出是极为重要的一部分，我们必须使用各种技术来确定客户和用户到底想要什么。

3.2.1 风险承担者

风险承担者包括：委托人，客户，用户，领域专家，市场研究人员，炉石或审计人员，软件工程师或其他技术专家。

核心思想：

1、风险承担者是指项目出现问题，会有真实利益受损的群体。

2、只有与风险承担者会谈才有参考价值。非风险承担者的建议不一定可信。

3.2.2 需求引出的具体手段

①与风险承担者进行会谈

②评审相关文档

③观察当前系统

④做用户的学徒，当用户进行任务时更详细的进行学习

⑤以小组形式与用户和风险承担者交谈

⑥使用特定领域的策略

⑦就如何改进产品，与当前的和潜在用户进行集体讨论

具体手段大致可以分为：

1、会谈（和风险承担者会谈）：个人/小组

2、关注特殊领域/特殊人群（潜在用户）

3、观察学习：观察系统、学习用户使用情况

4、文件审查：查看相关文档

3.3 需求分析

在引出需求后，面对众多的需求我们需要做的第一件事就是需求的前期处理，不然庞大的需求会让我们眼花缭乱。

3.3.1 需求前期处理

前期处理就是要让庞大的需求更加有逻辑，有针对性。

1、优先级划分；

2、需求的规范化（正式名字、唯一定义、量化描述）。

(1)需求的优先级划分

当进行需求的引出时，可能会碰到大家对"需求是什么"存在分歧，此时采用对需求进行

优先级划分的方法是有效的。

①必须要被满足的需求

②非常值得做但是不是必须的需求

③可选的需求（可做可不做）

(2)需求的规范化：

①针对需求确定一种量化的描述方法，避免模糊的表达方式

②将各种指代用词替代为实体的正式名字

③每个名词或事项应在需求文档中给出唯一定义

3.3.2 需求下的约束

①设计约束：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。

②过程约束：对用于构建系统的技术和资源的限制，涵盖资源、文档等方面。

3.3.3 需求分析的全过程

这里我们在意的是需求分析这一个活动的完整过程：

①原始需求获取：客户给出的需求

②问题分析：理解需求并通过建模或模型化方式进行描述

③规格说明草稿：利用符号描述系统将定义规范化表示

④需求核准：开发人员与客户进行核准

⑤软件规格说明（SRS）

信息获取------客户需求、自我建模分析

需求分析结果------规格说明书

3.3.4 补充知识

问题：需求分析时，若小团队且需求不确定，可采用敏捷开发方法；若大团队进行需求确定的开发时可采用"重量级"过程。

①敏捷开发方法的需求建模

适用范围：小团队，不确定的需求

方法：增量式开发（或迭代式开发）

②"重量级"过程

适用范围：大团队，确定的需求

特点：开发人员将编码推迟到已经对需求进行了建模和分析，详细的设计已完成，其中每一步都需要模型，模型间是相关的、相互配合的，以便于设计完全实现需求。

核心要点：

1、不同软件过程可以结合起来使用。

2、软件过程可以结合迭代式思想、增量式思想、原型化思想使用。

3、迭代式和增量式这种分阶段开发思想相当适用于敏捷开发 。

3.6 需求文档化

3.6.1 为什么要文档化

配置管理的一种方式，使得需求分析的每个阶段都有文档进行参考。

**配置管理：**是对软件开发过程以及软件生命周期过程的控制，具体来说就是让软件过程各阶段文档保持一致的系列过程。

软件配置管理：

定义： 一种标识、组织和控制修改的技术，目的是最有效的提高生产率，能够协调软件开发，使混乱减少到最小。（协调开发，使混乱最小化）

任务： 制定软件配置管理计划；确定配置表示规则；实施变更控制；报告配置状态；进行配置审核；进行版本管理和发行管理。

与软件开发过程的关系：变更的评估和批准都需要由软件配置管理人员去做 ，开发过程应纳入配置管理过程的控制之下。

**忽视软件配置管理可能导致的混乱现象：**发错了版本，安装后不工作，异地不能正常工作，已经解决的缺陷过后又出现错误，开发人员把产品拿出去出售赢利，找不到最新修改了的源程序，找不到编程序的人