软件工程中对于需求的定义是用户解决问题或实现目标所需的条件或能力; 统或系统组件为满足合同、标准、规范或其他正式规定的文件而必须满足或拥有的条件或能力; 条件或能力的记录表示。

软件工程中的软件需求分类

软件需求分类在软件开发过程中非常重要。它将我们的需求分为不同的类别,使其更易于管理、优先排序和跟踪。软件需求的主要类型是功能性需求、非功能性需求 1和领域需求。

1 什么是软件需求?

根据 IEEE 标准 729,需求定义如下:

  • 用户解决问题或实现目标所需的条件或能力。
  • 系统或系统组件为满足合同、标准、规范或其他正式规定的文件而必须满足或拥有的条件或能力
  • 条件或能力的记录表示,如 1 和 2 所示。

2 软件需求的类型

软件需求主要分为三类:

  • 功能要求
  • 非功能性需求
  • 领域需求

2.1 1.功能需求

定义:功能需求描述软件应该做什么。它们定义系统必须具备的功能或特性。

例如

  • 用户身份验证:系统必须允许用户使用用户名和密码登录。
  • 搜索功能:该软件应该允许用户按名称或类别搜索产品。
  • 报告生成:系统应该能够生成指定日期范围的销售报告。

解释:功能需求指定软件需要执行的操作。这些是用户期望软件具有的基本特性和功能。

2.2 2.非功能性需求

定义:非功能性需求描述的是软件如何执行任务,而不是它应该做什么。它们定义了质量属性 2、性能标准和约束。

例如

  • 性能:系统每秒应处理 1,000 笔交易。
  • 可用性:软件应该易于使用并具有用户友好的界面。
  • 可靠性:系统必须有 99.9% 的正常运行时间。
  • 安全性 3:数据在传输和存储过程中必须加密。

解释:非功能性需求与系统的行为、质量和约束有关。它们确保软件满足一定的性能、可用​​性、可靠性和安全性标准。

2.3 3. 领域需求

定义:领域需求特定于软件运行的领域或行业。它们包括与该特定领域相关的术语、规则和标准。

例如

  • 医疗保健:软件必须符合处理患者数据的 HIPAA 规定。
  • 财务:系统应遵守 GAAP 财务报告标准。
  • 电子商务:该软件应支持各种支付网关,如PayPal、Stripe和信用卡。

解释:领域需求反映了特定行业的独特需求和限制。它们确保软件与行业特定的法规和标准相关且符合该法规和标准。

3 什么是功能需求?

功能需求是最终用户明确要求系统应提供的基本设施。它可以是计算、数据处理、业务流程、用户交互或任何其他定义系统可能执行的功能的特定功能。所有这些功能都必须作为合同的一部分纳入系统。这些以要提供给系统的输入、执行的操作和预期的输出的形式表示或陈述。

它们是用户提出的需求,与非功能性需求不同,可以直接在最终产品中看到。例如,在医院管理系统中,医生应该能够检索其患者的信息。

每个高级功能需求可能涉及系统与外界之间的几次交互或对话。

为了准确描述功能需求,必须列举所有场景。

表达功能需求的方式有很多种,例如自然语言、没有严格语法的结构化或格式化语言、以及具有适当语法的形式化规范语言。

软件工程中的功能需求也称为功能规范。

4 什么是非功能性需求?

这些基本上是系统根据项目合同必须满足的质量约束。非功能性需求与系统功能无关,而是定义系统应如何执行。这些因素的实施优先级 4或程度因项目而异。它们也称为非行为需求。它们主要处理以下问题:

  • 可移植性
  • 安全性
  • 可维护性
  • 可靠性
  • 可扩展性
  • 性能
  • 可重用性
  • 灵活性

非功能性需求分为以下类型:

  • 接口约束
  • 性能约束:响应时间、安全性、存储空间等。
  • 操作限制
  • 生命周期约束:可维护性、可移植性等。
  • 经济限制

指定非功能性需求的过程需要了解系统的功能,以及系统运行的环境。

它们主要分为两类

  • 执行质量:这些包括安全性和可用性之类的东西,可以在运行时观察 5
  • 演化品质: 包括可测试性、可维护性、可扩展性和可伸缩性等,体现在软件系统的静态结构中。

5 领域需求是什么?

领域需求是特定类别或领域的项目所特有的需求。领域需求可以是功能性的,也可以是非功能性的。领域需求工程是一个持续的过程,它积极地定义软件产品线中所有可预见的应用程序的需求。特定领域的系统必须具备的基本功 6能属于这一类别。例如,在保存学校或学院记录的学术软件中,能够访问每个年级的教师名单和学生名单的功能就是领域需求。因此,这些需求是从该领域模型中识别出来的,而不是特定于用户的。

5.1 软件需求的分类

其他常见的软件需求分类包括:

  • 用户需求:这些需求描述了最终用户对软件系统的需求。用户需求通常以自然语言表达,通常通过访谈 7、调查或用户反馈收集。
  • 系统需求:这些需求指定了软件系统的技术特性,例如其架构、硬件要求、软件组件和接口。系统需求通常以技术术语表达,并经常用作系统设计的基础。
  • 业务需求 8:这些需求描述了软件系统预期实现的业务目标和目的。业务需求通常以收入、市场份额、客户满意度或其他业务指标来表达。
  • 监管要求:这些要求指定软件系统必须满足的法律或监管标准。监管要求可能包括数据隐私、安全性、可访问性或其他法律合规性要求。
  • 接口要求:这些要求指定软件系统与外部系统或组件(例如数据库、Web 服务或其他软件应用程序)之间的交互。
  • 设计要求:这些要求描述了软件系统的技术设计。它们包括有关软件架构、数据结构、算法和软件其他技术方面的信息。

通过对软件需求进行分类,可以更轻松地管理、确定优先级并有效地记录这些需求。它还有助于确保在开发过程中考虑到系统的所有重要方面。

5.2 对软件需求进行分类的优点

对软件需求进行分类的优点包括:

  • 更好的组织:对软件需求进行分类有助于将它们组织成更易于管理、确定优先级和在整个开发过程中跟踪的组。
  • 改善沟通:明确的需求分类,让与利益相关者 9、开发人员和其他团队成员的沟通变得更加容易。它还可以确保每个人对需求都有相同的理解。
  • 提高质量:通过对需求进行分类,可以在开发过程的早期发现潜在的冲突或差距。这降低了出现错误、遗漏或误解的风险,从而提高了软件的质量。
  • 提高可追溯性:对需求进行分类有助于建立可追溯性,这对于证明符合监管或质量标准至关重要。

5.3 软件需求分类的缺点

对软件需求进行分类的缺点包括:

  • 复杂性:对软件需求进行分类可能很复杂,尤其是当有许多利益相关者有不同的需求或要求时。识别和分类所有需求也可能很耗时。
  • 僵化的结构:僵化的分类结构可能会限制在开发过程中适应变化或不断发展的需求的能力。它还可能导致一种孤立的方法,阻碍新想法或新见解的整合。
  • 错误分类:错误分类需求可能会导致错误或误解,而这些错误或误解在开发过程的后期纠正起来可能会花费高昂的成本。

总体而言,对软件需求进行分类的优点大于缺点,因为它有助于确保软件系统满足所有利益相关者的需求,并按时、在预算内、以要求的质量交付。

6 总而言之

对软件需求进行分类有很多好处,例如更好的组织、改善沟通、提高质量和增强可追溯性。通过系统地对需求进行分类,开发团队可以确保软件满足利益相关者的要求,同时遵守标准并高效、有效地交付。