一、软件需求开发阶段

需求

相关概念
软件系统与外部环境关系：

定义[IEEE 610.12-1990]

用户为了解决问题或达到某些目标所需要的条件或能力；
系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力；
对 1）或 2）中的一个条件或一种能力的一种文档化表述。

说人话就是：
需求是用户的一种期望，是用户对问题域当中的实体状态或事件的期望描述。

需求分类

按照标准[IEEE830-1998]，需求分为：

最主要是系统需求中的软件需求。

软件需求分类：

功能需求 ( functional requirement )
性能需求 ( performance requirement)
质量属性 ( quality attribute)
对外接口 (external interface)
约束 (constraint)

1. 功能需求

功能需求 ( functional requirement )
就是和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮用户完成任务。

主要表现为系统和环境之间的行为交互。
是软件需求中最常见,最主要和最重要的需求,也是最复杂的需求。是一个软件产品能解决用户问题和产生价值的基础,是软件开发工作的基础。

2. 性能需求

性能需求 ( performance requirement)
就是系统整体或组成部分应该拥有的性能特征，或者说是在限定的约束，,完成其指定功能的程度。

常见性能需求:

速度：系统完成任务的时间。
容量：系统所能存储的数据量。
吞吐量：系统在连续时间内完成的事务数量。
负载：系统可以承载的并发工作量。
实时性：严格的实时要求。

3. 质量属性

质量属性 ( quality attribute)
就是系统完成工作的质量,即:系统需要在一个“好的程度”上实现功能需求。

常见质量属性:

可靠性：在规定时间间隔和规定条件下,系统或部件执行所要求功能的能力。
可用性：软件系统在投入使用时,可操作和可访问的程度或能实现指定系统功能的概率。
安全性：软件阻止对其程序和数据进行未授权访问的能力。
可维护性：为排除故障,改进质量或适应环境变化而修改软件系统或部件的容易程度。
可移植性：系统或部件能从一种硬件或软件环境转换到另一种环境的特性。
易用性：与用户使用软件所花费的努力及其对使用的评价相关的特性。

4. 对外接口

对外接口 (external interface)
就是指系统与（环境中的）其他系统之间需要建立的接口。

包括： 用户界面、硬件接口、软件接口、网络通信接口等。

5. 约束

约束 (constraint)
就是进行系统构造时需要遵守的约定。

常见约束:

系统开发及运行的环境约束：目标机器、操作系统、网络环境、编程语言、数据库管理系统等。
问题域内的相关标准：法律法规、行业规定、企业规章等。
商业规则：用户在任务执行中一些潜在的规则。

功能需求的层次性

需求是分层次的。

首先，我们会与提出需求的组织或公司的高层管理人员对接。那此时获取的需求，称为业务需求。
主要描述开发系统的目标，或为什么要开发系统。业务需求是系统建立的战略出发点。
业务需求设计出的任务涉及到的实际工作，需要有用户来执行或完成。那此时就要与用户对接，了解用户在执行或完成这些任务时，需要做些什么，这一部分的需求，被称为用户需求。
在获取用户需求时，可能需要补充一些问题域的知识
经过需求获取，我们将获取到的需求整理为需求清单，那接下来，我们要完成第二项任务，即要将需求映射为系统行为。而我们将映射后的需求，称为系统级需求。
每一个系统级需求，反映了一次外界与系统的交互。当然，可以借助需求分析模型来实现对系统级需求的精确描述和定义。

上述的过程，我们称之为需求分析。

需要注意的是，需求分析是需求工程中最重要的一项活动。

三层次的需求具体如下：

业务需求

系统建立战略的出发点，表现为高层次的目标，描述了组织为什么要开发系统。属于抽象层次最高的需求。

为了满足用户的业务需求，需要描述系统高层次的解决方案，并定义系统应该具备的特性(feature)。

参与各方要对高层次的解决方案达成一致,以建立一个共同的前景。

比如，为了达到扩大销售额这一目标，会要求增加并管理会员，以提供会员服务，增加回头率；制定多样的特价或促销方案，吸引顾客购买商品。等等。

用户需求

执行实际工作的用户对系统所能完成的具体任务的期望,描述了系统能够帮助用户做些什么。

特性:

模糊、不清晰;
多特性混杂;
多逻辑混杂;

针对每一个系统特性,都可以建立一组用户需求。

系统级需求

就是用户对系统行为的期望。
系统需求可以直接映射为系统行为，定义了系统中需要实现的功能,描述了开发人员需要实现什么。

每个系统级需求反映了一次外界与系统的交互行为，或者一个实现细节。系列系统行为联系在一起可以帮助用户完成任务，满足业务需求。

--

需求工程

定义： 所有需求处理活动的总和。
任务：

从用户的角度，说明软件系统将被应用的环境及其目标，说明用来达到这些目标的软件功能。
从软件开发者的角度，将目标和功能反映到软件系统当中，映射为可行的软件行为，并对软件行为进行准确的规格说明。
现实世界是不断变化的世界，因此还需要妥善处理目标和功能随着时间演化和变动的情况。

分为：

需求开发活动
包括：需求获取、需求分析、规格说明、需求验证
需求管理

具体过程如下：

1）需求获取

从人、文档或环境中获取需求。(对应于需求的业务需求和用户需求两个层次)

制品： 需求清单

2）需求分析

通过分析、建模来整合各种信息，映射得到系统行为及解决方案。（对应于系统级需求层次）

制品：严谨的、准确的、一致的、易于理解的模型及描述。

3）需求规格说明

从功能需求、性能需求、质量属性、对外接口、约束等方面对软件需求进行详细描述。

制品：需求规格说明(书)，文档要求简洁、精确、一致和易于理解。

4）需求验证

验证需求规格说明文档是否正确、准确的反映了用户的期望。

制品： 有需求基线的需求规格说明，是后续所有软件开发活动的基础。

经历了需求获取、需求分析、规格说明、需求验证之后，我们就对用户需求得到了较为准确的定义。
这几项活动被称为软件需求工程活动中的需求开发活动。

需求开发活动的结果，会形成需求基线。
需求基线表现为需求规格说明书的形式，是后续所有软件开发活动的基础。

5）需求管理

主要是管理两方面：

在需求一系列活动结束后，要借助管理活动，保证需求的在软件产品的生命周期的各个阶段均被遵守。
对各阶段的需求变更进行控制和管理。

需求分析的方法

需求分析的方法就是对需求进行分析和建模，在需求分析时的模型称为需求分析模型。

需求分析模型

模型：是对事物的抽象，帮助人们在创建一个事物之前，有更好的理解。
建模：建立模型的过程。

需求分析的任务

建立分析模型，达成开发者和用户对需求信息的共同理解。
依据共同的理解，发挥创造性，创建软件系统解决方案。

为什么要建模？

失败的成本太高，必须有详尽的计划。
任务量庞大，且复杂，需多方合作完成。
每一方只负责完成总任务的一部分。
各方必须积极沟通与配合。

建模的目的

描述用户想要什么软件系统（系统信息）
建立软件设计的基础（系统功能）
提供一组可用的需求（系统行为）

需求分析模型分类

结构化分析：实体关系图，数据流图，状态转换图
面向对象分析：用例图，类图，动态模型，CRC Card

结构化分析模型（不考）

面向对象方法

面向对象的分析方法最主要的特点是：自然性。对人而言，面向对象的分析方法是自然的和直观的，因为人们倾向于按照可感知的对象来思考世界。
与结构化的分析方法相比，面向对象的分析方法能更容易地实现分析到设计的转化。

面向对象的分析方法主要有以下几种模型：

用例图 Use-Case Diagram
描述用户与系统的交互。从交互的角度说明了系统的边界和功能的范围。
类图Class Diagram
描述应用领域中重要的概念以及概念之间的关系。它捕获了系统的静态结构。
交互图（顺序图）Interaction （sequence） Diagram
描述系统中一次交互的行为过程，说明了在交互中的对象协作关系。
状态图State Diagram
描述系统、用例或者对象在其整个生命期内的状态变化和行为过程。

UML学习过，就重点写关乎软件工程的，具体方式就不多说了

用例模型

1）用例
一个用例是多个场景的集合。
场景是用户和系统之间的交互行为的序列，帮助实现用户的目的。

用例是面向对象分析方法中，用于需求获取和组织的主要手段。

注意：
与用例发生交互的人、设备、外部系统称为 “参与者”（Actor）。
用例是参与者使用系统的完整的目的。

2）用例图
用例图是以用例为基本单位的一个系统功能展示模型。
使用统一、图形化的方式展示系统的功能和行为特性。

3）用例图的建立

例：
根据描述，为ATM机系统建立用例图。系统描述如下：
用户可以使用ATM机自助完成取款、存款、转账、查询账户、修改密码业务。
用户插卡后，验证密码，并选择事务。
用户选择取款时，用户输入取款金额，ATM机检查输入是否有效，若有效则检查账户余额是否足够，如果足够，完成取款，并打印凭条；如果不足，则提示用户“账户余额不足”。
用户选择存款时，用户将现金放入点钞机，ATM机显示现金金额并请用户确认。用户确认后，ATM机处理存款，修改账户余额，记录存款信息，并打印存款凭条给用户。
用户选择修改密码时，ATM机提示用户输入原密码和新密码，用户输入后，ATM机验证原密码正确，则修改密码；若原密码错误，则提示用户密码错误，不发生修改处理。

例：
山里外卖订餐系统，每周由餐厅经理发布菜单。菜单以套餐为主。包括凉菜、热菜、主食和例汤，价格为套餐价格。
顾客使用系统可以查看菜单和订餐。订餐时要选择套餐，并生成订单。支付方式为在线支付。订单要记录送餐地址和签收人电话。
顾客订单支付后，若开始备餐（厨师会设置订单为备餐状态）。备餐完成后,设置为待取状态。取餐后修改订单状态为已完成。
顾客可以方便的查看订单状态。在消费完成后，顾客可以对菜品发表评价。
另外顾客可以修改订单或取消订单。但订单状态设置为备餐后，订单不可修改或取消。

例：每学期第一周，学生登录教务系统注册课程，查询课表，查询上学期课程成绩；学生使用教务系统可以查看“绩点系统”计算的平均绩点；每天的实验课程会显示在信息楼的LED屏幕上。

4）用例规约
用文本的方式将用例的参与者、目标、场景等信息描述出来。

常见的描述有以下几方面：

ID：用例的标识
名称：对用例内容的精确描述，体现了用例所描述的任务
参与者：描述系统的参与者和每个参与者的目标
触发条件：标识启动用例的事件，可能是系统外部事件，也可能是系统内部事件，还可能是正常流程的第一个步骤
前置条件：用例能够正常启动和工作的系统状态条件
后置条件：用例执行完后系统的状态条件
正常流程：在常见和符合预期的条件下，系统与外界的行为交互序列
扩展流程：用例中可能发生的其他场景，要求全面且合理。
特殊需求：和用例相关的其他特殊需求，尤其是非功能性需求

用例描述时注意：

围绕“交互”进行场景描述
保持“规格说明”级别，尽可能不要涉及界面、按钮、方法等软件系统的内部构造机制。

例：

概念类图（领域模型）

类图（Class Diagram）
描述系统中的类（对象）和这些类（对象）之间的关系。
是面向对象分析方法的核心技术。

概念类图（或领域模型）: 与设计阶段的类图不同，更关注用户的业务领域。

特点：不包含类型、方法、可见性等构造细节。

类图和对象图的基本概念

类和对象
属性（attribute）和操作（operation）
抽象（abstract）、封装（encapsulation）
关联和链
继承（inheritance）
聚集（组合）（aggregation）（composition）
多态（polymorphism）

类和对象： 对象是类的实例，类是对象集合的抽象

对象是现实世界的实体在软件系统中的映射。对象包含：

标识符：对象的唯一标识。
状态：对象的属性、属性取值，描述对象的特征。
行为：对象在状态发生改变或者接收到外界消息时所采用的行为。

类是对象集合的抽象，类包含：

名称：唯一标识一个类。
属性
行为

属性（attribute）和操作（operation）
属性是对象的静态特征的表述。
操作是对象行为（提供服务）的表述。操作的是属性。

关联和链
两个类会存在一定的联系。在UML中称为关联。
如果两个类存在关联，那么它们的实例（对象）之间就会存在链。反之亦然。

继承（inheritance）
继承把类组织成继承体系。
继承体系顶端的类具有所有类的一般特性（父类、超类）。
派生类（子类）继承父类的属性和服务，并添加自己的属性和服务。

聚集（组合）（aggregation）（composition）
聚集表示类的部分与整体的关系，部分组成整体。

建立概念类图

两个步骤：

根据每个用例的用例规约，尤其是场景描述，建立局部的概念类图
a. 根据用例的文本描述，识别候选类（词性法）。
b. 筛选候选类，确定概念类。
c. 识别关联。
d. 识别重要属性
将所有用例产生的局部概念类图合并，建立软件系统的概念类图。

例：请对ATM机“修改密码”用例进行概念类的分析，并将分析出的类补充到下图中。

例：根据概念类图建模方法，对山里外卖系统的用例建立概念类图。

系统顺序图、状态图

系统顺序图

顺序图（Sequence Diagram）用于描述一组对象的交互行为。
表示为一个二维图表，纵向为时间轴（向下为正方向），横向列数参与交互的对象，图中表示出按时间顺序的交互消息序列。

需求分析时的顺序图 将系统看做一个黑箱，描述参与者与系统的交互行为，重点展示系统级事件。

例：

系统状态（机）图

状态图（State Diagram）用于描述系统或对象所处于的状态及状态的转移。

识别系统/对象的状态，及导致状态转移的行为/事件，建立状态图。
仅为复杂系统/用例建立状态图。

例：为ATM系统的ATM机对象建立状态机图：

例：外卖订餐系统—订餐

需求文档化与验证

基本概念：

需求文档的使用对象
用户、项目管理者、设计人员和程序员、测试人员、文档编写人员、维护人员
常见的需求文档
1）用例文档（格式模板 P116）
2）软件需求规格说明文档（格式模板 P117）

写作要点：
（1）技术文档写作要点：简洁、精确、易读（查询）、易修改。

（2）需求书写要点

使用用户术语：使用用户语言和问题域概念，不要使用计算机术语。
可验证/测试：通过分析、检查、模拟或者测试等方法能够判断需求是否被满足。
用户查询界面应该友好。
用户完成任何一个查询任务时，鼠标点击数不能超过5次。
可行性。
技术可行性、在限定的成本、时间、人员约束内，实现需求的可能性。

二、评审软件需求规格说明文档

评审的重要性
文档评审 \(\to\) 形成基线（baseline）
评审注意事项
重视评审、人员合理、使用线索、使用需求检查列表

三、以需求为基础开发系统测试用例

由开发需求导出测试需求及测试要点
测试需求/测试要点
用例场景每一个步骤的测试要点。
保证用例描述的可测试性。
示例
开发测试用例
留到测试阶段来介绍和完成

四、将需求制品纳入配置管理
需求配置管理制品：需求分析模型、需求文档、系统测试用例等

以需求为基础开发系统测试用例

对同一个Bug（缺陷），发现和修复它的时间越晚，所发费的成本就越大。
因此要尽可能早的发现和修复缺陷；因此一般在需求工程阶段，就来以需求为基础开发系统测试用例。

测试用例
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行步骤以及预期结果，以便测试某个程序路径或功能是否满足某个特定需求。

测试开发的过程

整理测试需求
提取测试要点
建立测试需求跟踪矩阵（RTM）
开发测试用例
整理测试用例文档

1）整理测试需求：

确定系统中哪些需求需要被测试，即确定测试的范围。
需要被测试的需求，我们称为测试需求。
整理测试需求，需要按照一定的要求。就是整理成为输入-处理-输出的格式（格式正好对应到测试用例的三部分）

注意： 测试需求必须是可以核实的，也就说，要有一个可观察、可评测的结果才行。

方法： 根据用例规约的用例流程中一次交互整理出 “输入-处理-输出”过程

例：

2）提取测试要点

测试要点：对测试需求进行细化和分解，形成可验证项的描述。

测试要点提取要求

分析每条需求描述中的输入、处理、输出的限制、约束等，给出对应的验证要求。
对存在功能交互的功能项，分析各功能模块之间的业务顺序，及传递的信息和数据（功能交互分析），给出对应的验证内容。

如果是基于单页面的交互，我们需要分析每条需求描述的输入、处理和输出的约束、限制，整理出验证要求；
那如果是多页面交互的情况，我们还需要分析出页面或模块交互时传递的信息或数据的验证要求。

例：

例：
主功能界面显示“取款”按钮，且可以点击。
点击后能够显示取款界面，提示“请输入取款金额”，显示金额输入框，且只允许输入100元的整数倍数字。
能够显示“是否查询账户余额？”，以及“是”、“否”两个按钮，按钮可点击。
点击按钮“是”，能够显示账户余额。
点击按钮“否”，能够返回主功能界面。

3）建立测试需求跟踪矩阵（RTM）

测试需求跟踪矩阵：将测试需求与测试要点的整理为对应关系表。

格式

注

RTM中需要将测试需求对应的系统需求，提取的测试要点，都列清楚。
还要根据测试内容，确定测试方法的类型，比如是黑盒还是白盒，是功能测试还是性能测试。

例： ATM机取款测试需求跟踪矩阵

4）开发测试用例

对每一个测试要点，开发测试用例。
过程：
① 设计输入数据；
② 确定执行步骤；
③ 设计预期输出。

例：

例：
输入：
取款金额为10000元
执行步骤：
1.参与者输入取款金额为10000，
2.参与者点击“确定”按钮。
3.系统提示“账户余额不足，请重新输入取款额”。
预期输出：
系统显示提示信息，约5秒后，显示取款界面，请用户输入取款额。

5）整理测试用例文档

将测试用例整理形成测试用例文档。
将测试用例文档加入配置管理库，作为软件测试（发现缺陷）的依据。

posted @ 2022-10-29 21:39 kingwzun 阅读(357) 评论(0) 编辑收藏举报

刷新页面返回顶部

kingwzun