软件工程中的功能需求是什么?
什么是功能需求?
A 功能需求 (FR) 是对软件必须提供的服务的描述。它描述了一个软件系统或其组件。功能只不过是软件系统的输入、其行为和输出。它可以是计算、数据操作、业务流程、用户交互或任何其他定义系统可能执行的功能的特定功能。软件工程中的功能需求也称为 功能规格.
在软件工程和系统工程中,功能需求可以从发送者必要性的高级抽象陈述到详细的数学功能需求规范。 功能软件 需求帮助您捕捉系统的预期行为。
功能需求文档中应包含哪些内容?
功能需求文档的编写方法如下:
系统的功能需求应该包括以下内容:
- 各画面的操作详情
- 数据处理逻辑应输入到系统中
- 它应该有系统报告或其他输出的描述
- 有关系统执行的工作流程的完整信息
- 应明确定义谁可以创建/修改/删除系统中的数据
- 系统如何满足适用的监管和合规性需求应在功能文档中体现
功能需求的好处
以下是创建典型功能需求文档的优点/优点 -
- 帮助您检查应用程序是否提供该应用程序的功能要求中提到的所有功能
- 功能需求文档可帮助您定义系统或其子系统之一的功能。
- 功能需求和需求分析有助于识别缺失的需求。它们有助于明确定义预期的系统服务和行为。
- 在功能需求收集阶段发现的错误是最容易修复的。
- 支持用户目标、任务或活动
功能需求的类型
以下是最常见的功能需求类型:
- 交易处理
- 业务规则
- 认证要求
- 报告要求
- 行政职能
- 授权级别
- 审计跟踪
- 外部介面
- 历史数据管理
- 法律和监管要求
功能需求示例
以下是常见的功能需求示例:
- 该软件根据 ABC 联系人管理系统自动验证客户
- 销售系统应该允许用户记录客户的销售情况
- 应用程序中所有窗口的背景颜色将为蓝色,并且具有十六进制 RGB 颜色值 0x0000FF。
- 只有管理层员工才有权查看收入数据。
- 软件系统应与银行API集成
- 软件系统应该通过 第508 可访问性要求。
非功能性需求与功能性需求
以下是功能性需求和非功能性需求之间的主要区别 软件工程:
参数 | 功能需求 | 非功能性需求 |
---|---|---|
它是什么 | 动词 | Attributes |
需求 | 这是强制性的 | 这是非强制性的 |
捕捉型 | 它是在用例中捕获的。 | 它被捕获为质量属性。 |
最终结果 | 产品特点 | 产品特性 |
捕获 | 易于捕捉 | 难以捕捉 |
目的 | 帮助您验证软件的功能。 | 帮助您验证软件的性能。 |
重点领域 | 关注用户需求 | 专注于用户的期望。 |
文件记录 | 描述产品的用途 | 描述产品的工作原理 |
测试类型 | 功能测试,如系统、集成、端到端、 API测试等等。 | 非功能性测试,如性能、压力、可用性、 安全测试等等。 |
测试执行 | 测试执行在非功能测试之前完成。 | 功能测试后 |
产品信息 | 产品特点 | 产品属性 |
功能需求最佳实践
开发功能需求文档的重要最佳实践如下:
- 不要将两个要求合并为一个。保持需求的细粒度。
- 您应该使每项要求尽可能完整和准确。
- 该文件应起草所有技术要求。
- 将所有需求映射到有助于成功软件交付的目标和原则
- 通过访谈、研讨会和非正式沟通来征求需求。
- 如果存在任何已知的、经过验证的约束对需求产生重大影响,那么它就是应该记录的关键状态。
- 您有必要在文档中记录所有假设。
创建功能需求时的错误
以下是创建功能需求文档时常见的一些错误:
- 添加不合理的额外信息,可能会让开发人员感到困惑
- 没有在需求文档中提供足够的细节。
- 您可以添加规则或示例、范围陈述或目标,除了需求本身之外的任何内容。
- 遗漏了一条对于完整、准确、明确地陈述要求而言绝对必须的重要信息。
- 当需求被修改时,一些专业人员开始捍卫他们记录的需求,而不是找到正确的事实。
- 未映射到目标或原则的要求。
重点学习
- 解释软件工程中的功能需求:功能需求定义系统或其组件
- 功能需求文档应包含数据处理逻辑和有关系统执行的工作流程的完整信息
- 功能需求和需求分析有助于识别缺失的需求
- 交易更正、调整和取消、业务规则、认证要求、报告要求、管理职能、授权级别、审计跟踪、外部接口、历史数据管理、法律或监管要求是各种类型的功能要求
- 作为一种好的做法,不要将两个要求合并为一个。保持需求的细粒度。
- 在功能需求文档中,应避免添加可能让开发人员感到困惑的不合理的额外信息。要了解这些要求如何转化为实际的测试程序,您可能需要探索本指南 功能测试.