如果你曾经负责过软件项目开展的全过程，就会知道需求定义在项目后期的重要性。清晰、明确的需求定义不仅有助于有效地管理客户期望，也有助于指导项目的顺利开展。
在项目前期阶段，如果需求定义不清晰，就会导致项目范围和成果定义模糊不清。Carnegie Mellon软件工程研究所的研究表明，60% 到 80% 的软件开发成本都消耗在返工上，有效的需求管理可以减少 50% 到 80% 的项目缺陷。
那么，如何确保需求定义清晰且明确呢？首先我们要理解功能性需求和非功能性需求之间的差异，并了解不同需求对项目成功发挥着什么样的作用。
功能需求是指产品或系统应具有的特定功能或行为。而非功能需求则关注系统如何执行这些功能或任务。本文将为大家介绍功能性需求和非功能性需求的区别。
一、什么是功能性需求?
功能性需求是指定系统或产品应具有的特定功能或行为，它描述了软件应如何运行以满足预定目标。例如，当系统满足特定条件时，需要向新用户发送一封电子邮件；或者只有管理层员工才能查看工资数据。功能性需求涵盖多个方面，包括但不限于：
- 审计追踪
- 报告要求
- 授权级别
- 法律或法规要求
- 商业规则
- 行政功能
- 认证要求
- 外部接口
二、什么是非功能性需求?
非功能性需求关乎软件系统的可用性，如果未予以精确定义，可能会影响终端用户的体验。非功能性需求可能涉及网站加载速度，比如：网站必须能够同时处理一千万用户的访问量；非功能性需求也涉及安全问题，例如，要求用户在首次登录时必须更改初始密码。其他非功能性需求还包括：
- 合规性
- 文档要求
- 隐私问题
- 系统的可移植性
- 系统质量
- 可靠性
- 抗入侵能力
- 响应时间
- 可扩展性
- 稳定性
非功能性需求主要关注的是系统的运行表现，而不是功能表现。例如，在用户使用期间，系统必须能在三秒内为用户更新数据。非功能性需求通常是通过一些具体的、可衡量的指标来定义。随着系统的改进，非功能性需求也可能会发生改变或需要被重新定义，如系统的可管理性和文档化程度等方面。
三、功能性需求和非功能性需求的区别？
功能性需求和非功能性需求示例
功能性需求与非功能性需求的差异可以这样理解：功能性需求是确保当用户点击某个按钮时，系统会加载指定的网页。而非功能性需求则决定了这个网页加载的速度。网站加载太慢会影响用户体验，因此，非功能性需求主要关注用户体验。
四、用户故事是什么？作用是什么？
用户故事（User Story）可以帮助我们分析需求和定义需求。用户故事从用户的视角出发，描述他们如何与软件或系统交互，以及他们希望通过这种交互获得什么样的体验或效果。
用户故事的基本框架如下：
一个 <用户类型>希望<实现某个目标>是为了<获得预期的效果>
在定义用户故事时，还需要包含验收标准。验收标准是产品为了被用户接受必须达到的条件。每个用户故事都至少包含一项验收标准。例如：
- 搜索栏应位于网站的顶部导航栏中
- 当用户点击”提交”按钮后，搜索功能应立即开始运行
- 系统显示的语言应为英语
- 搜索框内最多可输入150个字符
在讨论非功能性需求的情境时，用户故事尤其有助于深入理解用户体验，且有助于改善整个产品或服务的流程。
五、为什么指标更多地用于非功能性需求与功能性需求？
非功能性的度量能够帮助企业评估系统成功与否，所以他们必须是定性和定量且可衡量的。例如，我们希望系统具备扩展性，这是一个定性目标，但让我们更进一步，也让它定量化。你可能要求系统在未来三年内至少能处理30,000个用户。
专注于定量目标的好处是目标容易测量，你和客户可以达成共识，明确成功看起来是什么样的。
六、什么是需求规范？什么是需求规范文档？
软件需求规格文档，也称为SRS文档，说明了软件将要做什么以及对其性能的期望。该文档还强调了产品在用户功能性方面的需求。大多数文档包括了一个总体目标，并定义了功能性和非功能性需求。
一份标准的SRS通常会包含以下部分：
- 序言：对系统进行简要概览，提供相关的背景信息，对需要提前定义的术语进行阐释。
- 总体描述：阐述项目的全局目标、商业价值及项目愿景。
- 详细需求：这部分明确规定了系统所需的特定属性、功能要求，以及与之相关的数据库需求等。
七、追踪需求: 为什么传统的文档工具不再适用
需求的可追踪性对于项目的成功至关重要。Gartner 强调了需求可被追踪的优势：
“需求的最广泛采用工具仍然是通用文档软件如Microsoft Office或Google Docs（占40%到50%的市场），原因是成本低，可用性好，且大家都熟悉。
然而，人们使用这些通用的文档软件往往导致需求管理上的困难，进一步导致这些工具在实际操作中的成本效益被抵消，甚至超过了工具本身应有的成本效益。也就是说，尽管这些软件的成本较低且容易获取，但由于它们使需求管理变得混乱不堪，实际上增加了项目的总成本，反而失去了原本的优势。
在应用此类文档时，需求散布在各类文档和电子表格中，甚至是在未经管理的记事工具中，这导致需求无法被追踪或重复利用，从而导致用户验收测试阶段的成本大规模提高，无论在执行时间还是在后期修正问题时，团队都需要付出高额成本。” – Gartner研究
在整个软件和硬件开发过程中，团队必须共同合作来定义功能需求、非功能需求、测试用例和其他关键信息。如果团队使用的是不同的工具、术语和方法，就会带来一系列问题。
为了有效解决这个问题，在开发过程中，我们要把数据、相关讨论内容和决策汇集到同一个系统中，以确保需求可以被追踪。团队能够从系统中随时查看相关信息，共同协作解决问题，随时记录下决策和行动，并将这些信息与需求进行关联。如果将来需要重新审视决策，所有数据都储存在了一起，方便团队进行查找。
八、推进功能性需求与非功能性需求的管理
开发的软件不同，所要实现的愿景、目标也不同。在定义功能性需求和非功能性需求时，也就为项目定义了明确的边界，能够帮助团队快速达成目标。功能性需求和非功能性需求解答了关于产品的关键问题，确保团队朝着正确的目标努力。
功能性需求和非功能性需求同等重要，虽然非功能性需求主要关注用户体验，但并不意味着其重要性要高于功能性需求。理解这两类需求的差异可以帮助团队定义和追踪每个类别的需求，创造出能满足客户要求的产品路线图。
