功能与非功能需求分类

§1摘要与结论

别名：functional requirements、nonfunctional requirements、功能需求、非功能需求、质量约束　|　英文：Functional and Nonfunctional Requirements　|　类型：方法 / classification

§2局部关系图

§3原理 · 为什么

需求若只以功能列表呈现，质量诉求就会被系统性忽略。功能需求描述系统做什么，非功能需求描述系统在做这些事时应达到什么水平与受何限制，二者是正交的：功能不决定质量属性的水平，架构选择才决定各质量属性的相对达成度。把质量诉求单列并显式表达，才能在架构设计前形成可操作的约束，而不是在交付时才抱怨系统慢、难改或不可用。技术约束（如必须遵循的接口、平台或法规）与服务质量约束也需单独识别，它们往往不可协商，却容易被淹没在功能描述中。分类的目的不是贴标签，而是确保各类需求都获得相应的分析与验证手段。分类还揭示了功能的实现方式会显著改变其质量代价，因此同一功能的不同设计选择需要与质量诉求一并权衡。分类之后，团队才能在架构讨论中把功能问题与质量权衡分开处理，使决策更清晰：功能回答系统做什么，质量与约束回答它应当做到何种程度、受何限制。分类也提醒团队，质量诉求需要在需求阶段就被表达，而非留待架构阶段补齐，否则选择余地已被大幅压缩。

§4机制 · 如何运作

分类通过两个维度运作：一是「行为与属性」，把系统要完成的动作与动作应满足的质量水平分开；二是「可协商与强制」，把可权衡的功能与难以妥协的约束分开。功能需求通常以行为与输入输出描述，非功能需求则需转化为可操作、可度量的表述，否则「系统应易用」一类陈述无法验证也无法据以设计。分类之后，功能需求交由功能设计与测试覆盖，非功能需求交由架构决策与专项度量覆盖，技术约束则作为设计前提管理。识别时应主动追问每项功能的质量期望与运行环境限制，因为干系人通常只陈述功能而隐去质量诉求；对每个质量维度还应判断其目标水平、可接受下限与相互间的张力，避免把所有维度都设为无限高。对每条功能需求，若能同时说明其性能、可修改性等期望水平，就能避免质量诉求在实现中被无声牺牲，也能让架构师在方案选择时看到功能与质量之间的真实关联。对每类需求指定相应的验证方式，可使其在评审中不被笼统带过，也便于在交付前判断是否真正满足。

§5工程 · 怎么落地

实践中维护分开的需求类别，避免把质量诉求写成功能需求的附注。对每条非功能需求追问其可度量形式，必要时转化为具体的运行条件与判定标准。在评审中单独核查质量属性与约束是否被覆盖，而非只看功能是否齐全。把技术约束登记为不可协商项，并在架构决策中显式回应。用追溯连接功能需求与其相关的质量诉求，避免两者在后续变更中脱节。对约束类需求确认其来源与依据，防止把可协商的实现选择误当作强制约束。分类结果应驱动设计与测试的资源分配，而非停留在文档分类；对同时具有行为与质量含义的需求，可允许其跨类引用，而不必强行归入单一类别。把质量诉求纳入评审检查项，并在架构决策中回应，可使其从抽象愿望变为可跟踪的承诺，避免出现功能齐全却在关键质量上不达标、难以投入使用的系统。把分类结果写入检查清单，有助于在评审中系统性地覆盖各类需求，降低因关注功能而遗漏约束的概率。

§6权衡卡

权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。

§7学习路径条

§8案例带

§9信源与核验

§10原始关系清单