2、需求质量属性：完整性、一致性、可行性、可测试性、无歧义性

好，咱们来聊聊需求的质量属性。说实话，我见过太多项目翻车，根源往往不是技术不行，而是需求本身就有问题。你想想看，如果地基是歪的，上面盖的房子能稳吗？

我个人习惯，拿到一份需求文档，第一件事不是看功能，而是拿这五个属性去套一遍。就像质检员拿卡尺量零件一样，不合格的直接打回去。这五个属性分别是：完整性、一致性、可行性、可测试性、无歧义性。咱们一个一个说。

2.1 完整性——别让我猜

完整性，说白了就是需求有没有把话说全。用户操作到哪一步？系统该怎么响应？异常情况怎么处理？这些都得写清楚。

我在项目中遇到过最典型的例子：一个支付模块的需求，只写了「用户点击支付按钮，完成扣款」。结果上线后，用户网络断了怎么办？余额不足怎么办？支付超时怎么办？全都没写。开发只能自己猜，猜对了算运气，猜错了就是线上事故。

嗯，这里要注意，完整性不是让你写流水账。而是关键路径上的每一个决策点，都得有对应的处理逻辑。

2.2 一致性——别自相矛盾

一致性，就是需求文档内部不能打架。同一个术语，不能在这叫「用户ID」，在那叫「账号编号」。同一个业务规则，不能前面说「满100减20」，后面又说「满100减30」。

我建议，团队里最好维护一份术语表。所有关键名词、缩写、业务规则，统一登记。评审的时候，拿着术语表一条条对，能省掉很多扯皮的功夫。

常见不一致问题	示例	后果
术语冲突	「用户」vs「会员」	开发理解偏差，数据模型混乱
规则矛盾	A文档说「可退款」，B文档说「不可退款」	逻辑冲突，上线后投诉
数据格式不一致	日期格式「2024-01-01」vs「01/01/2024」	解析错误，数据丢失

为什么会这样？很多时候是因为需求文档是多人协作写的，各写各的，最后没人统稿。所以评审的时候，我习惯把文档从头到尾读一遍，专门找这种「前后矛盾」的地方。

2.3 可行性——别异想天开

可行性，就是需求在现有技术、资源、时间约束下，能不能做得出来。有些需求听起来很美，但实现成本高得离谱，或者当前技术根本做不到。

我曾经遇到过一个产品经理，要求「用户上传照片后，系统自动识别照片中的物体，并生成3D模型」。想法很好，但当时团队连基本的图像识别都没做过，更别说3D建模了。这种需求，评审时就得直接打上「不可行」的标签。

可行性评估，我建议从三个维度看：

• 技术可行性：现有技术栈能否支撑？
• 时间可行性：排期是否合理？
• 资源可行性：人手、设备、预算够不够？

2.4 可测试性——别让QA抓瞎

可测试性，是QA最关心的属性。说白了，就是需求能不能被验证。如果需求写「系统响应要快」，那什么叫「快」？1秒算快还是0.1秒算快？没有量化标准，测试就没法做。

我建议，所有涉及性能、容量、时间的需求，都必须给出具体数值。比如：

• ❌ 不好的写法：「页面加载速度要快」
• ✅ 好的写法：「页面加载时间不超过2秒（在4G网络下）」

另外，可测试性还要求需求描述中给出明确的预期结果。比如：「用户输入正确的验证码后，点击登录按钮，系统跳转到首页」。这个预期结果很清晰，测试用例就能直接写。

2.5 无歧义性——别让人猜谜

无歧义性，就是需求只能有一种理解。不能张三看了觉得是A，李四看了觉得是B。

我见过最坑的写法：「系统对异常订单进行处理」。什么叫「异常订单」？是超时未支付？还是库存不足？还是地址无效？每个人理解都不一样。开发按自己的理解做了，测试按自己的理解测了，最后上线发现对不上。

避免歧义，我有几个习惯：

• 用精确词代替模糊词：比如用「必须」「禁止」代替「应该」「可以」
• 用数字代替描述：比如用「3次」代替「多次」
• 用具体条件代替笼统说法：比如用「当用户余额小于0时」代替「当用户余额不足时」

嗯，其实这五个属性是相互关联的。比如，完整性差往往会导致歧义，可行性差会影响可测试性。评审的时候，别孤立地看，要综合起来判断。

最后说一句，需求质量不是评审会开完就完事了。我建议把每个属性的检查点做成检查清单，每次评审前发给大家对照着看。养成习惯后，你会发现需求文档的质量会明显提升，后面的开发和测试也会顺畅很多。