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