非功能性需求包括哪4种类型

Posted 2023-04-07

非功能性需求包括哪4种类型

(1) 性能需求：用户在软件响应速度、结果精度、运行时资源消耗量等方面的要求。

(2) 可靠性需求：用户在软件失效的频率、严重程度、易恢复性，以及故障可预测性等方面的要求。

(3) 易用性需求：用户在界面的易用性、美观性，以及对面向用户的文档和培训资料等方面的要求。

(4) 安全性需求：用户在身份认证、授权控制、私密性等方面的要求。

扩展资料

非功能性需求是随着软件系统的规模成长和复杂性增加这两个因素才逐渐成为软件工程师们的新着眼点和关注点的，早期的时候，甲方处于自身对软件技术的了解和自身对系统文件维护的方便性考虑等，对系统有了诸如：开发平台、技术流派、关键实现等等方面的要求，这被称之为“设计约束”。

从甲乙双方合同的角度，设计约束也是一种需求——一种“非功能”性的需求，后来，软件的质量问题越来越突出，描述软件质量目标的要求也成为非功能性需求的一部分。于是，目前业界关于软件的非功能需求，一般就包括：质量属性要求和约束性要求。

参考技术A

性能需求，可靠性需求，易用性需求，安全性需求。

对于非功能性需求描述的困难在于很难像功能性需求那样，可以通过结构化和量化的词语来描述清楚，在描述这类需求时候我们经常采用软件性能要好，查询要在多少时间内出结果，软件健壮性要好等较模糊的描述词语。

这类描述词语都是脱离了软件的执行环境，人和相关的场景的描述，因此信息很难体现到软件架构设计和具体的实现中。我们在架构设计中关注的安全，系统开发框架，并发和性能，异常日志等不是凭空产生出来的，而是来源于我们对非功能性需求的分析。

非功能性需求分析注意事项

在调研业务需求时，要时刻留意功能实现对非功能性指标所带来的影响，并在调研过程中有意识地了解系统运行的相关情况，例如客户提供的硬件设备，用户量，业务量，业务办理频率、峰值等问题。

对于一些客户明确提出的关键指标或可预见的问题，如大数据应用的性能问题，或者像可靠性、可用性等问题，需要让架构师提前考虑，在技术上给出解决方案，在工作中及时总结，记录问题和解决方案，并进行归类整理，在下一个同类的系统或项目时，做到提前考虑。

参考技术B 非功能性需求是指依一些条件判断系统运作情形或其特性，而不是针对系统特定行为的需求。
包括
安全性、可靠性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性、可扩充性。本回答被提问者采纳

软件需求

概念

软件需求是

(1)用户解决问题或达到目标所需条件或权能(Capability)。

(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。

(3)一种反映上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。

需求层次

软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。

• 业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

• 用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。

• 功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示。

作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。 值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。

Frederick Brooks在他1987年的经典的文章“No Silver Bullet：Essence and Accidents ofSoftware Engineering ”中充分说明了需求过程在软件项目中扮演的重要角色：

开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。如果前期需求分析不透彻，一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难，容易导致项目失败。

需求分类

从严格意义上的软件需求分类具有：功能需求（functional requirement），非功能需求（non-functional requirement），就好比我在某宝想买一双鞋子，球鞋、高跟鞋、过膝靴、红色、黑色等是明显可知的（功能需求），但鞋跟牢不牢固、鞋底会不会脱胶等是不清楚的（非功能需求）。其中非功能需求包括性能需求（performance requirement），质量属性（quality attribute），对外接口（external interface），约束（constraint）。

• 功能需求
  

  是最常见和最重要的需求，体现在系统与用户之间的交互，帮助用户解决问题，完成任务。功能也有复杂简单之分，对于复杂的功能需要一层一层分离，如公司做的核销功能，在账单模块，分离各种支付类型，支付类型又分为具有流水号和无流水号的等等。或者独立成多个部分，如公司的某项目，分成机票模块、酒店模块、用车模块等等，然后再分别交给开发人员进行开发。

  功能需求是整个系统产生价值的基础，是使得一个软件应用得以存在的原因。

• 性能需求

  我们会经常讨论到手机性能怎么样，卡不卡，耗电量怎么样，存储量有多大……而软件也具有性能，是指某指定功能的程度，如速度，精确度，内存使用程度等

  常见的性能：

  1. 速度：系统完成指定任务的时间。如航班搜索出来的结果必须在3s内展示出来。
  2. 容量：系统所能存储的数据量。如财务系统能存储至少10万条的核销数据。
  3. 并发性：系统可以承载的并发工作量。如某软件允许多少个用户同时使用。
  4. 实时性：严格的实时要求。如降舱软件中当发现合乎条件的舱位，系统需在1s内执行降舱指令。

  对于性能需求，如要不是很大的用户量或大公司，其他则比较少去考虑该方面的需求，但对于系统的后期发展，这也是一个极其重要需求探讨。

• 质量属性

  质量属性包括性能需求，只是性能需求比较特殊，所以单独出来。

  常见的质量属性：

  1. 可靠性：指在一定时间或条件下，系统执行所要求功能的无故障执行能力。
  2. 可用性：系统在使用中可操作或访问程度。
  3. 可维护性：为改进系统或修复bug而修改系统或某功能模块的难易程度。
  4. 安全性：阻止对其程序和数据进行未授权访问的能力。
  5. 可移植性：将系统从一个硬件或软件的运行环境换置到另一个环境。
  6. 易用性：系统易于使用的程度。
• 对外接口
  

  对于接口需要进行说明：

  1. 接口的用途；
  2. 接口的输入输出；
  3. 数据格式；
  4. 命令格式；
  5. 异常处理要求；

  如某数据包为XML格式，HotelProduct表示酒店接口，接口的输入为Destination目的地，Date住店及离店日期，输出的数据类型为数字文本，0代表操作正确，1代表数据错误，2代表网络故障，3代表其他错误，而对于0还输出具有目的地的酒店信息，其中一个字段为HotelID，酒店编号，Number类型，18位数据代码。

• 约束

  常见的约束：

  1. 系统开发以及运行的环境：包括计算机，操作系统，编程语言、数据库管理系统等
  2. 问题域内的相关标准：包括法律法规、合作协议等
  3. 社会性因素：文化、信仰等社会性因素

过程标准

NASA的软件开发过程中的概念中软件需求过程的标准是：清楚(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable)。

此外还有其他的概念，如可跟踪的、可修改的等等。

分析方法

软件需求分析方法大体分为如下四类：结构化方法、面向对象方法、面向控制方法和面向数据方法。限于篇幅，将主要从结构化方法和面向对象方法以及RUP三个方面进行简要的探讨。

结构化分析方法

结构化分折(Structured Analysis, SA)方法是一种单纯的由顶向下逐步求精的功能分解方法。分析员首先用上下文图表(称为数据流图DFD)表示系统的所有输入/输出，然后反复地对系统求精，每次求精都表示成一更详细的DFD从而建立关于系统的一个DFD层次。为保存DFD中的这些信息，使用数据字典来存取相关的定义、结构及目的。SA方法是目前实际应用效力广泛的需求工程技术。它具有较好的分别、抽象能力，为开发小组找到了一种中间语言，易于软件人员所掌握。但它离应用领域尚有一定的距离，难以直接应用领域术民与软件设计也有一段不小的距离因而为开发小组的思想交流带来了一定的困难。

面向对象分析方法

面向对象（Object Oriented, OO）的方法把分析建立在系统对象以及对象间交互的基础之上，使得我们能以3个最基本的方法框架——对象及其属性、分类结构和集合结构来定义和沟通需求。面向对象的问题分析模型从3个侧面进行描述，即对象模型(对象的静态结构)、动态模型(对象相互作用的顺序)和功能模型(数据变换及功能依存关系)。需求工程的抽象原则、层次原则和分割原则同样适用于面向对象方法，即对象抽象与功能抽象原则是一样的，也是从高级到低级、从逻辑到物理，逐级细分．每一级抽象都重复对象建模(对象识别)一动态建模(事件识别)一功能建模(操作识别)的过程，直到每一个对象实例在物理(程序编码)上全部实现为止。

面向对象需求分析(OORA)利用一些基本概念来建立相应模型，以表达目标系统的不同侧面。尽管不同的方法所采用的具体模型不尽相同，但都无外乎用如下五个基本模型来描述软件需求：

整体—部分模型：该模型描述对象(类)是如何由简单的对象（类）构成的。将一个复杂对象(类)描述成一个由交互作用的若干对象(类)构成的结构的能力是OO途径的突出优点。该模型亦称聚合模型。

分类模型：分类模型描述类之间的继承关系。与聚合关系不同，它说明的是一个类可以继承另一个或另一些类的成分，以实现类中成分的复用。

类—对象模型：分析过程必须描述属于每个类的对象所具有的行为，这种行为描述的详细程度可以根据具体情况而定。既可以只说明行为的输入、输出和功能，也可以采用比较形式的途径来精确地描述其输入、输出及其相应的类型甚至使用伪码或小说明的形式来详细刻画。

对象交互模型：一个面向对象的系统模型必须描述其中对象的交互方法。如前所述，对象交互是通过消息传递来实现的。事实人对象交互也可看作是对象行为之间的引用关系。因此，对象交互模型就要刻画对象之间的消息流。对应于不同的详细程度，有不同的消息流描述分析，分析人员应根据具体馆况而选择。一般地，一个详细的对象交互模型能够说明对象之间的消息及其流向，并且同时说明该消息将激活的对象及行为。一个不太详细的对象交互模型可以只说明对象之间有消息，并指明其流向即可。还有一种状况就是介于此两者之间。

状态模型：在状态模型中，把一个对象看作是一个有限状态机，由一个状态到另一状态的转变称作状态转换。状态模型将对象的行为描述成其不同状态之间的通路。它也可以刻画动态系统中对象的创建和废除，并称由对象的创建到对象的废除状态之间的退路为对象的生存期。

状态模型既可以用状态转换因的图形化手段，又可用决策表或称决策矩阵的形式来表。