🌈 个人主页：十二月的猫-CSDN博客
🔥 系列专栏： 🏀软件开发必练内功_十二月的猫的博客-CSDN博客💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光
目录
1. 前言
2. 章节概述和章节框架
3. 获取并分析需求
3.1 需求
3.1.1 需求是什么
3.1.2 需求的类型
3.1.3 需求的特征
3.1.4 需求的表示
3.2 需求的引出
3.2.1 风险承担者
3.2.2 需求引出的具体手段
3.3 需求分析
3.3.1 需求前期处理
3.3.2 需求下的约束
3.3.3 需求分析的全过程
3.3.4 补充知识
3.6 需求文档化
3.6.1 为什么要文档化
3.6.2 文档化的结果是什么（需求规格说明（SRS））
3.7 需求的确认
3.7.1 需求确认
3.7.2 需求复审
3.8 需求的测量
3.8.1 测量集中的领域
3.8.2 测量措施
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 为什么要文档化
配置管理的一种方式，使得需求分析的每个阶段都有文档进行参考。
配置管理：是对软件开发过程以及软件生命周期过程的控制，具体来说就是让软件过程各阶段文档保持一致的系列过程。
软件配置管理：
定义：一种标识、组织和控制修改的技术，目的是最有效的提高生产率，能够协调软件开发，使混乱减少到最小。（协调开发，使混乱最小化）
任务：制定软件配置管理计划；确定配置表示规则；实施变更控制；报告配置状态；进行配置审核；进行版本管理和发行管理。
与软件开发过程的关系：变更的评估和批准都需要由软件配置管理人员去做，开发过程应纳入配置管理过程的控制之下。
忽视软件配置管理可能导致的混乱现象：发错了版本，安装后不工作，异地不能正常工作，已经解决的缺陷过后又出现错误，开发人员把产品拿出去出售赢利，找不到最新修改了的源程序，找不到编程序的人
3.6.2 文档化的结果是什么（需求规格说明（SRS））
将需求重述为关于要构建的系统将如何运转的规格说明。
需求定义在说需求是什么，需求规格说明在说系统在这个需求定义下能做什么。
软件工程师的目标：让系统能做什么的范围尽量包括需求是什么的范围。
需求定义和需求规格说明的关系如下图所示：
3.7 需求的确认
3.7.1 需求确认
检查需求规格文档与需求定义的对应性。
3.7.2 需求复审
再一次审查已经通过的需求规格文档。
3.8 需求的测量
3.8.1 测量集中的领域
产品，过程，资源
3.8.2 测量措施
①产品方面：需求的数目；评估需求文档
②过程方面：需求变化的数目；引起需求变化的原因
4. 练习题
4. 总结
本文到这里就结束啦~~
目前【软件工程】系列已经完成：
【软件工程】第一章·软件工程概述-CSDN博客
【软件工程】第二章·软件过程（过程与生命周期建模）-CSDN博客
【软件工程】第三章·计划和管理项目（详解活动图计算关键路径、最早开始时间、最晚开始时间、冗余时间）-CSDN博客
持续更新中🎢🎢🎢
如果觉得对你有帮助，友友们可以点个赞，收个藏呀~
