软件工程--需求工程--学习笔记（超详细）

最新推荐文章于 2024-05-31 09:42:54 发布

亿维数组

最新推荐文章于 2024-05-31 09:42:54 发布

阅读量1.9k

点赞数 35

分类专栏：总结知识型文章 Software Engineering 文章标签：软件工程学习笔记

本文链接：https://blog.csdn.net/m0_63222058/article/details/134710389

版权

总结知识型文章同时被 2 个专栏收录

20 篇文章 9 订阅

订阅专栏

Software Engineering

5 篇文章 0 订阅

订阅专栏

软件需求工程是软件开发周期的第一个阶段，也是关系到软件开发成败最关键阶段，本章讲解需求的基础知识和需求工程的关键活动。这些知识对于结构化方法、面向对象方法、面向服务方法等都是适用的

本文参考教材：沈备军老师的《软件工程原理》

软件需求面临的挑战

40%-60%的问题是在需求阶段埋下的祸根，下面是在软件需求方面中常遇到的挑战和解释：

1.用户说不清需求
用户可能缺乏技术背景，难以清晰地表达他们的需求，导致需求理解存在困难
2.需求表达的二义性问题
需求文档或说明存在歧义，不同的人可能解释得不同，导致开发过程中的混淆
3.需求经常变化, 项目没有时限
频繁的需求变更可能导致进度延误、成本增加，甚至影响软件的稳定性
4.因误解或二义性的需求直到开发后期才发现
对需求的误解或二义性可能在开发过程中才被发现，导致重新设计和修改,这样的大量返工使修复成本随着开发的进展按1-10-100规则不断增加

需求1-10-100规则，也被称为“1-10-100法则”或“需求成本曲线”，是软件工程中一种经验法则，描述了在软件开发过程中解决问题的成本随时间增加的趋势。这个规则强调了在项目不同阶段识别和解决问题的经济性差异
1 倍成本（需求阶段）：
在需求阶段，通过仔细的需求分析、用户研究和沟通，尽早发现和解决问题。在这个阶段，修复问题的成本最低。
10 倍成本（设计阶段）：
如果在需求阶段未能解决问题，问题可能会在设计阶段变得更加显著。在这个阶段，需要进行更多的工作来调整和修改设计，解决之前未发现的问题。问题的修复成本相对于需求阶段增加了10倍。
100 倍成本（开发阶段或后期阶段）：
如果问题在设计和需求阶段都未被解决，它将在开发阶段或后期阶段显露，并需要更大规模的修改。在这个阶段，问题的修复成本相对于需求阶段增加了100倍。
这个规则的主要目的是强调在软件开发生命周期的早期阶段发现和解决问题的重要性，以避免问题逐渐扩大并在后期变得更加昂贵和复杂。通过在需求和设计阶段投入更多的努力，可以减少在开发和维护阶段的问题数量和成本。这也与敏捷开发中强调早期迭代和反馈的原则相符

5.测试者没有明白产品要做什么
测试团队可能由于需求理解不足而无法有效地执行测试
6.产品性能低、使用不方便等用户不满意
用户对产品性能或用户体验不满意可能是由于需求未充分考虑到用户需求和期望
7.维护费用高，因为许多增强性需求未在需求获取阶段提出
增强性需求是那些在软件系统已经交付使用后，由用户或者业务需求变更引起的新需求。如果这些需求在需求获取阶段未被充分考虑，可能会导致后期的维护成本大幅增加。为了降低维护成本，团队应该在项目的早期阶段就与利益相关者（包括最终用户）进行紧密合作，采用敏捷开发等方法，强调快速迭代和灵活响应变化

需求工程的概念

FURPS+模型

FURPS+是一种软件工程中用于描述和衡量软件质量特性的模型。这个模型将软件系统的质量特性分为五个主要方面，每个方面都有不同的子特性。以下是FURPS+模型的五个主要方面：

1.功能（Functionality）：这个方面主要关注软件系统能够做什么。基本功能是软件必须要实现的核心功能，比如一个文字处理软件必须能够编辑、保存和打印文档。增强功能则是那些让软件更强大、更具吸引力的额外功能，比如拼写检查、格式化工具等。简而言之，功能方面考虑的是软件的核心特性和附加功能

2.可用性（Usability）：这方面强调软件的易用性和用户体验，一个直观友好的界面会让用户更轻松地使用软件

3.可靠性（Reliability）：这关注的是软件在各种情况下的稳定性和可靠性。指软件执行功能的准确性和一致性，即系统是否按照预期工作，不出现错误或者崩溃

4.性能（Performance）：这关注软件系统的表现和性能。效率方面考虑的是系统在使用资源方面的高效性，比如程序运行速度是否快，内存占用是否合理。容量方面涉及系统处理大量数据或用户时的能力，比如一个数据库系统能够处理多少条记录

5.支持性（Supportability）：可支持性包括可测试性、可扩展性、可适应性、可维护性、兼容性、可配置性、可服务性、可安装性、可本地化等

在这5个当中，F为功能需求，URPS为非功能需求

在这个模型中，"+"表示可拓展性（+），这是一个允许在每个主要方面添加其他特性的机制，比如下面这四种需求：

设计约束（如必须采用某种算法，必须使用某种数据库系统等）
实现需求（规定如所需标准、编程语言、数据库完整策略、资源限制和操作环境等）
接口需求（规定系统必须与之交互操作的外部软件或硬件等）
物理需求（规定了系统必须具备的物理特征，如物理网络配置需求）

需求的层次

软件需求包括三个不同的层次：

1.项目干系人需求：这是在项目启动阶段明确的需求，主要关注项目干系人的期望和期望的系统行为（原始需求）

2.前景文档：这是在项目初期编写的文档，用于记录关键的用户需要和系统特征（概要需求）

3.软件需求规约：（SRS）记录详细的功能需求、非功能需求和约束条件，其中，功能需求常常由用例模型来刻画（详细需求）

优秀需求具有的特征

一、单个需求规格说明书应具有的特性：

1.完整性
2.正确性
3.可行性
4.必要性：对于客户的需求没有画蛇添足
5.划分优先级：如果把所有需求都同等重要，那么项目管理者在计划调度中就丧失了控制自由度
6.无二义性
7.可验证性：如果没法设计出相应的测试用例，则该需求就是不可验证的

二、多个需求规格说明书（例如一个需求文档）应具有的特性：

1.完整性：不能遗漏任何必要的需求信息
2.一致性：一个软件需求和其它的一个软件需求不矛盾
3.可修改性：在必要时或维护每一需求变更历史记录时，应该修订软件需求规约
4.可跟踪性：将需求与设计文档、测试用例、源代码等其他工作项关联起来，以便能够直观地了解各个部分之间的关系

软件需求工程

在当今“面向服务”的软件工程时代，随着软件工程技术的发展，需求工程越来越引起人们的关注，软件需求工程是发现、获取、组织、分析、编写和管理需求的系统方法，以使客户和项目组之间达成共识

通过上图可以看到，需求工程总共包含五个步骤：

1.需求获取：对业务问题分析，与项目干系人（包括客户、最终用户、管理层等）沟通，以理解系统的目标、期望和约束，进一步分析，形成前景文档

2.需求分析：提炼、分析和仔细审查已收集到的项目干系人需求，建立需求分析模型（用例图、时序图、活动图、类图......）

3.需求定义：在上述分析模型的基础上形成软件需求规约SRS，作为用户和开发者之间的一个契约

4.需求验证：以上述前景文档、分析模型、需求规约等需求文档为输入，通过符号执行、模拟、快速原型、评审等途径，验证需求文档的正确性和可行性

5.需求管理：通常包括定义需求基线、划分需求优先级，以及在整个软件开发过程中进行需求实现的跟踪和需求变更评估、核准与控制

step1需求获取

需求工程的目标是让项目干系人对需求达成一致的、正确的理解，因此项目干系人是需求最主要的来源
项目干系人是指受项目影响或与项目有直接、间接利益关系的个人或组织，例如项目的组织者、最终用户、承担着、开发者、系统管理和维护者、技术支持者、领域专家等

除了向项目干系人调研需求，还要收集竞争产品信息，以保证待开发软件的竞争力

需求获取总路径：业务分析-->确定系统边界-->项目干系人交流-->竞争产品观察-->定义系统高层输入-->形成前景文档

当我们讨论确定系统边界和定义系统高层输入时，可以用以下通俗的例子来解释：

确定系统边界：

想象一下你在建造一座房子。在确定系统边界的过程中，你需要决定这座房子的具体范围。这包括确定哪些空间属于房子内部，哪些是房子外部。你可能需要考虑房子的主要功能，比如客厅、卧室、厨房等，以及它与外部环境的关系，比如花园或停车场。这个过程就像画一条虚拟的线，将房子与周围的空间区分开，这条线就是系统的边界

定义系统高层输入：

现在，假设你正在设计这座房子的自动化系统。在定义系统高层输入时，你会考虑到从外部获取的信息，这些信息将影响系统的运行。比如，你可能会考虑温度传感器、光线传感器和人体检测器，它们会向系统提供关于室内环境的信息。这些信息就是系统的高层输入，因为它们是系统运行所需要的关键数据，但并不涉及具体的技术细节。

总的来说，确定系统边界就是定义系统的范围，决定系统内外的分界线；而定义系统高层输入则是考虑系统所需的基本信息，这些信息将在系统中被处理和利用。在房子的例子中，系统边界是房子的外墙，而系统高层输入可能包括温度、光线等环境信息

对于“和项目干系人交流”这个步骤，我们可以使用下面这些方法：

1.访谈

2.调查问卷

3.需求研讨会

4.用例研讨会（采用用例技术进行讨论，识别出执行者和用例，进行功能需求建模）

5.制作示意板（使用工具或动画演示等向项目干系人说明系统如何适应组织的需要）

6.角色扮演

7.复审现有需求

8.观察正在工作的用户

step2需求分析建模

已收集到的项目干系人需求是原始、粗糙的，需要对其提炼、分析，理解问题的本质，然后进行建模，从不同的角度把问题抽象表述出来

分析建模的主要成果是分析模型，此处的模型是一个平台无关模型（PIM），和具体实现的平台和技术没有关系

分析模型的三个主要目标是：1.描述客户需要2.建立软件设计的基础3.定义在软件完成后可以被确认的一组需求。为了达到这些目标，不同的软件开发方法都对应有各自的分析模型，不同的分析模型有着不同的元素

结构化分析模型

以数据字典（DD）为核心，包括数据流图（DFD）、实体——关系图（ERD）和状态转换图（STD），分别刻画了软件使用或生产的数据、软件功能域模型、软件信息域模型和软件行为域建模

可转下面链接学习！

软件工程——结构化分析通俗讲解

面向对象分析模型

以对象及其服务作为建模标准，主要包括用例图、活动图、类图、时序图、通信图、状态机图，其中软件的功能域建模采用用例图，当用例事件流相对复杂，可以用活动图补充描述，软件的信息域建模采用类图，每个类都代表一个关键的数据抽象，软件的行为域建模采用时序图、通信图、状态机图

可转下面链接学习！

软件工程——面向对象分析建模通俗讲解

虽然有着不同的分析模型，但是有着相同的建模原则：

1.必须描述并理解问题的信息域（信息域包括输入输出数据、永久性数据对象）
2.必须确定软件所需要的功能
3.必须描述软件的行为（受外部事件驱动的结果）
4.模型必须能提以一种能提示层次化方式的分解
5.分析任务应该从本质信息向实现细节转移

step3需求定义

需求定义的任务：定义需求、撰写需求文档（前景文档和详细的软件需求规约）

软件前景文档

软件前景文档是一种详细说明软件项目前景和方向的文档。它通常由项目团队或项目经理编写，旨在为项目的相关方提供清晰而全面的了解，下面将介绍前景文档中的常见元素

1.简介部分
1.1目的：描述文档的目标，即提供关于软件前景的详细信息。
1.2范围：界定文档的内容适用范围
1.3术语和缩略语：定义文档中使用的专业术语和缩略语，以确保读者理解文档中的术语。
1.4参考资料：列出了文档编写时参考的所有资料和来源。
1.5概述：提供对文档主要内容的简要概括。
2.定位部分
2.1商机：描述软件项目的商业机会，即为什么开发这个软件，它解决了什么问题。
2.2问题说明：阐述该软件项目旨在解决的具体问题或挑战。
2.3产品定位说明：定义产品在市场中的定位，包括目标用户和竞争对手。
3.项目干系人和用户说明：列出了与项目相关的各方利益相关者和最终用户，并描述他们对项目的期望和影响。
4.产品概述部分
4.1产品总体发展：描述软件的整体开发计划，包括主要里程碑和时间表。
4.2功能概要：提供对软件功能的高层次概述。
4.3假设与依赖关系：列出项目中的假设和对其他组件或系统的依赖关系。
4.4成本与定价：包含软件开发和维护的估算成本，以及产品的定价计划。
4.5许可与安装：描述软件的许可模型和安装要求。
5.产品特性：详细列出软件的功能和特性，以便读者了解软件的具体功能。
6.约束：描述了可能对项目或软件实现产生影响的任何限制或约束。
7.质量范围：确定软件交付的质量标准和期望。
8.优先级：确定软件功能和任务的优先级，以指导开发过程中的决策。
9.其他产品需求：列出其他不属于功能特性但对软件实现至关重要的需求。
10.文档需求：描述关于文档本身的需求，包括格式、发布计划等。

软件需求规约（SRS）

在前景文档的基础上，对需求调查得到的大量项目干系人需求进行分析，可以定义出详细的软件需求规约SRS，在此，软件需求的重点已经从概括地说明用户需要、目的和目标、目标市场和系统特性转移到如何在解决方案中实施这些特性的具体细节

SRS文档由三个部分组成：功能需求、非功能需求和约束条件

下面是统一软件过程提供的两种SRS模板

在决定系统的成功或失败的因素中，满足非功能需求往往比满足功能需求更为重要

但URPS这四方面的非功能需求有时是冲突的，比如为了实现兼容性可能要牺牲性能，因此用户和开发者要确定哪些属性比其他属性更为重要，并定出优先级

step4需求验证

需求的验证一般来说有下面四方面：

1.一致性：所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。当软件需求规格说明书是用形式化的需求陈述语言书写的时候，可以用软件工具验证需求的一致性

2.现实性：指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的

3.完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能

4.有效性：必须证明需求是正确有效的，确实能解决用户面对的问题。使用原型系统是一个比较现实的方法，开发原型系统所需要的成本和时间可以大大少于开发实际系统所需要的

常用的需求验证方法有两种：需求评审和原型确认

需求评审：评审需求文档（前景文档和SRS等），及时发现缺陷，寻找改进的契机，同时从评审反馈中获得知识，补充了正规的交流和培训机制，帮助团队建立对产品的共同理解

步骤：准备计划-->实施评审-->返工-->定稿签字

输入：待评审的需求文档+Check List

输出：评审结论+缺陷清单

原型确认：通过快速开发简单的原型系统来验证用户需求的有效性，避免进行大规模投入后因需求理解偏差而导致的返工

根据目的划分：

1.水平原型确认

水平原型主要关注系统的一个功能或模块的横向展示，即展示系统在某个阶段上的整体外观和感觉，而不涉及深度的功能实现

2.垂直原型确认

垂直原型关注整个系统的一个垂直切片，即涉及系统中一个或一组功能的深度展示，包括功能的详细实现和交互，更多被用于设计验证而不是需求开发

根据不同用途：

1.抛弃型原型确认

抛弃型原型确认是一种快速原型开发方法，其目标是创建一个用于验证需求和设计概念的快速原型。一旦确认了需求或得到了足够的反馈，这个原型被丢弃，而不是被用作最终系统的基础

2.演进型原型确认

演进型原型确认是一种渐进式的原型开发方法，原型的发展是逐步演进到最终产品的过程。初始原型可以基于最初的需求，然后通过反复的修改和添加功能逐渐变为最终系统