软件需求工程期末知识点总结

需求工程导论

需求问题具体原因

1. 非技术性和社会性因素重视不足

2. 传统分析方法的缺陷

3. 软件规模的日益扩大

4. 需求问题的高代价性

需求工程简介

需求工程的主要任务

1. 必须说明软件系统将被应用的环境、目标、功能、限制和约束

2. 需求规格说明 （specification）

3. 妥善处理目标、功能和约束随着时间的演化情况

需求工程的基本活动

需求工程的基本活动包括需求开发和需求管理两个方面

需求工程与系统工程的关系?

需求基础

需求的定义

1. 用户为了解决问题或达到某些目标所需要的条件或能力；

2. 系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；

3. 对1或2中的一个条件或一种能力的一种文档化表述

对实现某种目标所需要的条件或能力的文档化表述

问题域与解系统的概念与区别

• 当现实的状况与人们期望的状况产生差距时，就产生了问题。

• 要解决问题，就需要改变现实当中某些实体的状态或改变实体状态变化的演进顺序，使其达到期望的状态或演进顺序。

• 这些实体和状态构成了问题解决的基本范围，称为该问题的问题域（Problem Domain）

• 问题域是解决问题所涉及的事件和事物的集合

• 软件系统通过影响问题域，能够帮助人们解决问题，称为解系统

区别：

问题域描述了问题的基本范围和限制条件，是解决问题的基本条件；解系统则是通过软件系统来影响问题域，从而解决问题。问题域和解系统的关系是互动的，它们在互动中相互影响，共同推动问题的解决。

解决问题的困难性

问题解决的基础--------模拟与共享现象

问题解决的方法-------直接与间接

问题解决方案------需求规格说明

• 描述明确的问题域特性E; 定义良好的系统行为S ; 预期的需求R

• 需求工程的目的就是根据E，构建S，使得

• 需求工程的困难之处：

  • 不存在描述明确的E；（付款管理系统, 人为录入付款情况）

  • 不存在确定的针对S的评估标准R；

  • 是一个创造性的过程。

• 需求工程的主要工作

  • 需求开发,确定用户的期望效果 R

  • 研究问题背景，描述问题域特性E

  • 构建解系统，描述解系统行为S，使得

需求的层次性，不同抽象层次需求之间的联系

最常见的抽象层次：

需求开发需要遵循的层次性：

软件需求的分类

1. 功能需求

2. 性能需求

   1. ①速度 ②容量 ③吞吐量 ④负载 ⑤实时性

3. 质量属性

   1. 可靠性、可用性、安全性、可维护性、可移植性、易用性

4. 对外接口

5. 约束

优秀需求的特性

1. 完备性：一个优秀的需求描述需要详尽完整，不应存在任何模糊不清或缺失的部分。它应该清楚地列出所有的要求和标准，以便开发人员能够全面准确地理解并实现需求。

2. 正确性：优秀的需求必须是正确的。这意味着它必须准确地反映了用户的意图和期望。任何错误或不准确的需求都可能导致开发出的产品不符合预期，甚至可能需要额外的修改和返工。

3. 可行性：需求必须能够在系统及其运行环境的已知条件和约束下实现。用户无法判断需求的技术可行性，所以需求的可行性是由开发人员进行检查的。

4. 必要性：每一项需求都应该是必要的，它是满足用户的业务需求所必须的。

5. 无歧义：需求能够正确传递知识的前提是传递者和受众能够形成共同的理解，因此每一项需求都应该有而且只有一种解释，即需求无歧义。

6. 可验证：需求应该是可验证的，也就是说通过分析、检查、模拟或测试等方法能够判断需求是否被满足。如果需求不可验证，就无法判断完成的系统是否满足了该需求，开发人员也无法去选择一个能够实现该需求的方法。

需求工程过程

需求工程活动

1. 需求获取

2. 需求分析

3. 需求规格说明

4. 需求验证

5. 需求管理

需求开发模型

需求管理与需求开发活动的界限

需求获取的任务

1. 收集背景资料

2. 获取问题与目标，定义项目前景与范围

3. 识别涉众，选择信息的来源

4. 选择获取方法，执行获取，获取功能与非功能需求

5. 记录获取结果

需求分析的任务

1. 背景分析

2. 问题分析、目标分析、业务分析，确定系统边界

3. 软件需求建模

4. 细化需求

5. 确定优先级

6. 需求协商

需求规格说明的工作内容

1. 定制文档模板

2. 编写文档

需求验证的主要任务

1. 执行验证

2. 问题修正

需求管理的主要任务

1. 建立和维护需求基线集

2. 建立需求跟踪信息

3. 进行变更控制

需求获取

需求获取定义

需求获取就是进行需求收集的一个活动，它从人员、资料和环境中得到系统开发所需要的相关信息

需求获取中常见的困难

1. 用户和开发人员的背景不同，立场不同

2. 普通用户缺乏概括性、综合性的表述能力

3. 用户存在认知困境

4. 用户越俎代庖

5. 缺乏用户参与

需求获取的过程

1. 研究应用背景，建立初始的知识框架；

2. 根据获取的需要，采用必要的获取方法和技巧；

3. 先行确定获取的内容和主题，设定场景；

4. 分析用户的高（深）层目标，理解用户的意图；

5. 进行涉众分析，针对涉众的特点开展工作（领导：加强管控，基层员工：减轻操作负担，调度人员：获得库存现状支持）?

需求获取的内容

1. 需求

2. 问题域描述

3. 环境与约束

需求获取的信息来源

1. 涉众：用户、客户、领域专家、市场人员、销售人员

2. 硬数据：登记表格、单据、报表等定量文档，以及备忘录、日志等定性文档

3. 相关产品：原有系统、竞争产品、协作产品(和解系统存在接口的其他软件系统)

4. 重要文档：原有系统的规格说明、竞争产品的规格说明、协作产品的规格说明以及客户的需求文档

5. 相关技术标准和法规：相关法律、法规及规章制度，行业规范、行业标准及领域参考模型

需求获取的方法

1. 传统方法：问卷调查，面谈，文档分析、文档检查、需求剥离

2. 集体获取方法：头脑风暴、专题讨论会、

3. 原型：需求模糊和不确定性较大的情况下，尤其有效

4. 模型驱动方法：面向目标的方法、基于场景的方法、基于用例的方法

5. 认知方法：任务分析、协议分析

6. 基于上下文的方法：观察、民族志（Ethnography）和话语分析（Conversation Analysis）

基于用例/场景获取方法(用例模型)

1. 确定系统范围和目标：明确系统的边界、功能和目标，以及系统的相关利益相关者。

2. 识别场景和用例：通过与利益相关者交流，识别出系统的关键场景和用例，包括正常的业务流程、异常情况、边界条件等。

3. 编写用例描述：对每个用例编写详细的描述，包括前置条件、后置条件、主角、场景和基本事件流等。

4. 确认和评审用例：与利益相关者一起评审和确认用例，确保它们满足需求并具有完整性和一致性。

5. 生成需求规格说明书：根据确认的用例，编写需求规格说明书，包括用例名称、描述、前置条件、后置条件、主角、场景和基本事件流等。

6. 迭代和演化：在项目开发过程中，可能需要对需求进行迭代和演化，通过再次识别场景和用例来完善需求

在需求获取的诸多方法当中，面谈是需求获取当中最为常用的手段，效果显著；观察的作用越来越显重要，它可以帮助解决情景性问题；采样观察的应用方法较为固定，但民族志的应用非常复杂，需要很多的实践积累；文档审查方法是专门用于处理各种硬数据的需求获取方法

使用原型法进行需求获取

基本过程

1. 确定原型需求：明确开发原型的原因、拥有的起始点以及期望的结束标准。

2. 原型开发：根据原型的需求特点和开发目的，选择适当的开发方法和构建技术，建立初始原型。

3. 原型评估：对上一阶段产生的原型进行评估，根据评估者的反馈判断原型是否满足结束标准。评估者可以是用户和开发者。

4. 原型修正：如果建立的原型已经达到预期目的，则结束原型方法过程。否则，根据评估者的反馈对原型进行调整，调整完成后准备再次进行原型评估。

典型的不确定因素

在原型法中，常见的不确定因素包括需求不确定性、技术不确定性、商业不确定性等。这些不确定因素可能导致项目范围模糊、时间表不准确、资源分配不合理等问题，从而影响项目的进度和成功率。因此，在采用原型法进行需求获取时，需要充分考虑各种不确定因素，通过合理的规划和安排来降低其对项目的影响。

需求分析

需求分析的根本任务

1. 建立分析模型，达成开发者和用户对需求信息的共同理解

2. 依据共同的理解，发挥创造性，创建软件系统的解决方案

需求建模过程

常用的需求分析技术

1、数据流图DFD

4种基本元素：外部实体、过程、数据流和数据存储

2、实体关系图

3、用例图

4、类图/领域模型

5、顺序图

6、活动图

需求分析方法

1. 传统分析

   1. 没有方法，依赖个体才智，依据个人习惯

   2. 缺乏结构、不可重复、不可测量，冗长、混乱、偏颇、无结构等等

2. 结构化分析

   1. 传统结构化分析 (late 1960’s)，现代结构化分析 (late 1970’s)

      • 以数据流动为中心，以DFD为核心技术，辅助ERD,STD…

   2. 信息工程 (late 1980’s)

      • 以数据知识结构为基础，ERD为核心技术，辅助DFD，STD, FDD, PD…

3. 面向对象分析

   1. 以对象为中心，以UML（类图）为核心技术

   2. 以全面思想革新为理想，以承继结构化技术为现实

需求分析阶段的重要活动

前期需求阶段：

• 以问题域为关注点(需求分析)

  • 背景分析

  • 问题分析、目标分析、业务分析，确定系统边界

后期需求阶段：

• 需求建模

• 需求细化

• 确定需求优先级

• 需求协商

需求规格说明

需求规格说明活动流程

?需求开发过程中常见文档

常见写作技巧

1. 内容的组织

   1. 所有内容位置得当

   2. 引用或强化，但不重复

2. 表达方式

   1. 形式依赖于内容

   2. 使用系统的表达方式

3. 细节描述

   1. 定义术语表或数据字典

   2. 避免干扰文本

   3. 避免歧义词汇

优秀的需求规格说明文档特性

1. 完备性

2. 一致性

3. 根据重要性和稳定性分级

4. 可修改

5. 可跟踪

需求验证

需求验证活动流程

需求验证方法及含义

需求评审

评审又被称为同级评审，是指由作者之外的其他人员来检查产品问题。在系统验证中，评审是主要的静态分析手段，所以评审也是需求评审的一种主要方法。原则上，每一条需求都应该进行评审。

参与评审的人员：

组长、阅读人员、用户代表，技术人员、作者、领域专家、记录人员、观察员

评审的过程：

原型与模拟

• 涉及到复杂的动态行为时

• 成本较高

开发测试用例

需求开发测试用例也可以被看成一个有效的需求验证方法

• 如果无法为某条需求定义完备的测试用例，那么它可能就存在着模糊、信息遗漏、不正确等缺陷

• 无法定义测试用例的并非是绝对有问题的，下列需求就是通常无法定义测试用例的

  • 排斥性需求:这种需求要求特定的行为绝对不会发生，例如需求可能会要求系统故障不能导致数据库的崩溃

  • 全局性非功能性需求:例如可靠性、可用性等，对这些需求的测试往往都是大数据集的处理

用户手册编制

• 验证功能需求

  • 对软件系统功能和实现的描述

• 验证项目范围

  • 对系统没有实现的功能的描述

• 验证异常流程需求

  • 问题和故障的解决

• 验证环境与约束需求

  • 系统的安装和启动

利用跟踪关系

• 业务需求?用户需求?系统需求

  • 如果业务需求和用户需求没有得到后项需求（用户需求和系统需求）的充分支持，那么软件需求规格说明文档就存在不完备的缺陷

• 系统需求?用户需求?业务需求

  • 如果不能依据跟踪关系找到一条系统需求的前项用户需求和前项业务需求，那么该需求就属于非必要的需求

?自动化分析

?