一、需求分类影响架构

"系统要快""要能扛住大并发"这类说法，开发根本没法落地。临沂物联网应用公司在物联网应用项目中写性能指标时会结合真实业务测算：峰值出现在什么时候、大概多少并发、数据涨到多大。有测算支撑的数字，才是可设计、可验收的需求。

兼容性需求在多端时代尤其重要：系统要适配哪些浏览器与版本、要覆盖哪些手机机型、要不要与旧版数据共存迁移。这些约束如果晚提，前端与数据迁移的返工量会非常大。需求评审时专门过一遍兼容性清单，是成本很低的检查动作。

非功能需求之间也会互相牵制：极致的可靠性要靠冗余与灾备，成本随之上升；开放的扩展性会牺牲一部分交付速度。写需求不是越多越好，而是要把业务真正在乎的那几条写清楚、写量化，其余的按合理默认处理，避免为并不存在的要求付出过度设计的代价。

二、非功能需求包括哪些

总结起来，功能需求回答"做什么"，非功能需求回答"做到什么程度"，两者合起来才是一份完整的需求描述。成熟的需求文档，两类需求篇幅往往相当；只写前者的项目，几乎一定会在上线后为后者补课。

功能需求描述系统"应当做什么"：用户登录时校验账号密码、连续输错五次锁定半小时、下单后扣减库存并生成流水。它直接定义软件的行为，每条功能需求几乎都能对应到具体的页面、接口与业务规则，是需求文档中最显性的部分。

三、给需求编写者的建议

非功能需求描述系统"应当做到什么程度"，它不定义功能，而是给功能加上质量约束：这个查询要多快、系统一年要多稳定、数据要存多久、谁能看到哪些数据。它之所以叫非功能，是因为去掉它系统照样能跑，但跑出来的东西用户完全不敢用。

一个常见的项目教训是：功能做了一大堆，上线后响应慢得没法用，或者一到大促就宕机。事后复盘发现，需求文档里全是功能描述，性能与并发指标一个字没有。功能决定系统能不能用，非功能决定系统好不好用、敢不敢用，后者对架构的影响往往比前者更大。

指标有业务依据，设计与验收才有共同语言。

性能需求最常见的写法是拍脑袋。"系统要快"不是需求，"日常百分之九十五的查询在三百毫秒内返回、促销高峰支持两千人同时在线下单"才是。写性能指标时要结合真实业务量预估：订单峰值出现在什么时候、大概多少并发、数据会涨到多大，数字背后要有业务测算支撑。

安全需求在企业系统中越来越不可忽视。用户密码怎么存储、哪些角色能看到敏感数据、操作日志保留多久、外部接口怎么鉴权，这些都应当在需求阶段写清楚。安全约束往往渗透在每一个功能里，事后补做等于把已经上线的系统翻出来重改造，成本成倍上升。

备注：性能指标要量化，且要有业务测算支撑。