。

我们可能下意识以为这些是功能性需求#xff0c;但实际上这些特性都是与用户体验相关的非功能性需求。

非功…我们在选购新车时会预设一些选购的标准比如GPS导航必须能够保存目的地或者必须要买黑色的车。

我们可能下意识以为这些是功能性需求但实际上这些特性都是与用户体验相关的非功能性需求。

非功能性需求是对软件系统的全局性约束包括但不限于开发成本、运营成本、性能、可靠性、可维护性、可移植性和扩展性等。

一个与功能无关但与可靠性、效率、可用性、可维护性和可移植性等属性相关的需求。

在系统工程和需求工程中非功能性需求是一个指定可以用来判断系统操作的标准而不是特定行为的需求。

在描述非功能性需求时常会用到一些副词或修饰语如“系统应能快速打印发票”或“系统应在确保信息安全的情况下打印出发票”。

软件的非功能性需求关乎用户体验。

忽视这些需求可能会导致项目延期预算超支用户满意度降低也可能会导致项目目标不明确进而导致产品偏离用户的期望。

非功能性需求弥补了开发者认为客户想要的和客户真正想要的之间的差距。

研究显示软件开发成本中的60%到80%用于修复产品存在的问题完善的非功能性需求可以消除约50%到80%的产品缺陷。

既然我们已经知道了非功能性需求的重要性那么问题来了如何有效地将非功能性需求融入到产品开发过程中呢

产品的”性能”包括质量、可靠性、可制造性、可用性、可服务性、可升级性等。

非功能性需求关注用户体验定义了系统的质量、约束条件或外部接口等方面的要求。

如果我们想设计出一个具有可扩展性的系统仅凭口头描述往往不够清楚需要将目标具体化比如“构建出一个在未来24个月内能够管理至少50,000名用户的系统以防止系统崩溃对用户造成困扰”。

法律法规或相关规定。

定义软件的质量属性。

确保关键领域的性能表现例如可靠性、可用性和可扩展性。

提升用户体验使系统更易于操作并最大程度地减少返工。

就像购车一样不同的人获得最佳用户体验所要求的产品特性不同。

你可能需要加热座椅而其他人则可能想要三排座椅。

所以你为项目定义的非功能性需求会根据客户期望而变化。

然而一个可能的非功能性需求类别列表可以作为你的起始点帮助你思考在你的需求列表中应该包含哪些非功能性需求。

把非功能性需求想象成一种容器里面装载的是与用户体验密切相关的重要属性。

要记住非功能性需求并不是关于产品将要完成什么任务那是功能性需求的范畴而是关于这个项目将要达到的目标或理想状态。

如果你选择了正确的容器并且衡量了正确的事物那么你就可以放心你交付的产品会满足客户的期望——因为你已经明确地定义了这些期望。

每个人都在同一认知水平上这在你集中管理你的需求时会进一步增强。

性能和可扩展性确定所需的响应时间、性能标准和其他与性能相关的属性。

系统生成结果的速度有多快系统在高负荷下的性能如何操作限制这部分涉及产品开发过程中必须遵守的特定软件需求、系统需求以及运行时候的约束。

平台限约束大多数软件都会有平台限制需提前明确这些限制。

可修改性需要考虑修改软件所需的工作量。

提前预知修改带来的工作量可以帮助客户更有效地规划项目时间。

可移植性需求和能力思考软件在不同平台运行的难易程度以及适用的硬件和操作系统还需要考虑软件是否会与其他程序产生冲突。

可靠性需要考虑软件发生错误的频率和后果以及检测错误和修复错误的手段。

安全性关乎系统保护和数据保护的需求例如破解系统的难易程度以及如何降低这些风险。

可用性指用户体验例如学习和操作系统的难度实际使用软件可能出现的问题或者困难。

合法性涉及到的法律问题例如数据隐私和知识产权。

系统的可用性系统是否易于使用、容量系统能处理多少任务或用户、可靠性系统的稳定性或故障率和安全性系统防止非法访问或攻击的能力。

可先从这些基本的需求类别着手逐渐扩展到其他需求领域最终构建出属于自己的新产品开发项目需求模板。

功能性需求Functional

这些需求关注软件应执行的具体功能或行为。

例如一个电子商务网站的功能性需求可能包括用户能够浏览产品目录、添加商品到购物车、进行购物结算等。

功能性需求通常以用户故事、用例或系统功能列表的形式进行文档化这些需求是用户或系统需要完成的具体任务。

非功能性需求Non-Functional

Requirements

这些需求关注系统的质量、性能或约束。

它们描述了系统应如何工作而不是系统应该做什么。

例如一个电子商务网站的非功能性需求可能包括系统必须能够处理高并发访问性能需求、必须有良好的用户界面可用性需求或必须遵循某些数据安全标准安全需求。

非功能性需求有时也被称为系统属性、质量属性或系统约束。

两者都是必不可少的功能性需求解释了系统应该执行的任务而非功能性需求解释了完成这些任务的方式、限制和其他期望。

非功能性需求文档是软件需求规格说明SRS文档的关键组成部分。

SRS描述了软件应具备的性能、约束特性及其实现方式定义了用户对产品的性能、可靠性、安全性等方面的需求。

序言对系统进行简要概览提供相关的背景信息对需要提前定义的术语进行阐释。

详细需求这部分明确规定了系统所需的特定属性、功能要求以及与之相关的数据库需求等。

在整个软件和硬件开发生命周期中团队需要共同参与定义功能性和非功能性需求。

如果使用的工具各不相同就会影响团队协作。

统一化的需求管理方式能够提高效率增强协作能力确保团队开发出高质量、合规的产品。

单一的真实数据源团队成员能够共享相同的信息和数据整个产品开发周期内信息的透明度较高。

实时更新的优点可实时了解所有开发团队的进展随时沟通有助于团队做出更明智的决策增强协作能力。

强大的可视化能力我们可以看到测试如何追溯到需求这样有助于提升产品质量和规范性。

复用已验证的需求可以重用已验证过的需求在不同产品上复制验证过的功能。

统一的需求管理平台如PingCode等可帮助我们更有效地定义和处理非功能性需求提高产品开发效率。

所有数据、对话和决策都可被集中在同一个系统中确保了信息的一致性和准确性有助于减少误解和混淆。

统一的需求管理平台也可以避免重复输入数据或者重复讨论同一个问题更好地跟踪项目的进度避免错过重要的时间节点可极大提高客户对产品的满意度。

需求管理指南