第3章：需求工程基础——需求层次与需求属性
各位同学，今天我们来聊聊需求工程里最基础、也最容易搞混的一块内容——需求层次和需求属性。说实话，我在航天软件这行干了快二十年，见过太多项目栽在需求上。不是需求写得太模糊，就是不同层次的需求对不上号。嗯，咱们今天就把这个根儿给捋清楚。
3.1 需求层次：从业务愿景到代码实现
我个人习惯把需求想象成一个倒金字塔。最顶层是业务需求，最底层是软件需求。每一层都有它存在的意义，缺一不可。
3.1.1 业务需求
业务需求回答的是「为什么要做这个系统」。说白了，就是客户或者用户到底想要达成什么业务目标。比如，我们要研制一套卫星在轨健康管理系统，业务需求可能是「将卫星故障预警准确率提升到95%以上」。
关键点：业务需求通常由出资方或高层管理者提出，它不关心具体怎么实现，只关心最终的业务价值。
我在项目中遇到过一件事：某型号任务，业务需求写的是「提高遥测数据处理的实时性」。结果开发团队直接开始优化算法，忙活了大半年。后来一复盘才发现，客户真正想要的是「操作员能在5秒内看到关键参数的变化」，而不是「把处理延迟从100ms降到50ms」。你看，业务需求没写透，后面全白干。
3.1.2 用户需求
用户需求是业务需求的细化。它描述的是用户使用系统时，能做什么、不能做什么。举个例子，业务需求是「提高预警准确率」，用户需求可能就是「系统能自动识别异常遥测参数，并给出置信度评分」。
这里有个坑，我提醒大家注意：用户需求一定要从真实用户那里来，别自己拍脑袋。我曾经参与过一个地面站项目，需求文档里写「操作员可一键切换卫星跟踪模式」。结果到现场测试，操作员说「我从来不用一键切换，我需要的是分步确认，防止误操作」。嗯，这就是典型的用户需求没摸准。
3.1.3 系统需求
系统需求是站在系统整体角度，描述系统应该具备的功能和性能。它把用户需求翻译成了工程师能看懂的语言。比如用户需求是「自动识别异常参数」，系统需求可能就是「系统应支持基于阈值的异常检测算法，检测延迟不超过2秒」。
| 需求层次 | 典型表述 | 关注点 |
|---|---|---|
| 业务需求 | 提升故障预警准确率至95% | 业务价值 |
| 用户需求 | 操作员可查看异常参数置信度 | 用户交互 |
| 系统需求 | 系统应实现阈值检测，延迟≤2s | 系统功能 |
| 软件需求 | 检测模块接口应支持XML输入 | 软件实现 |
3.1.4 软件需求
软件需求是最底层、最具体的一层。它直接指导程序员写代码。系统需求说「延迟不超过2秒」，软件需求就要细化成「数据处理线程优先级设为最高，缓存队列长度不超过100条」。
我的建议：写软件需求时，一定要做到可测试。如果你写「系统响应要快」，那测试人员怎么验证？改成「从收到遥测数据到界面刷新，时间不超过1.5秒」，这才叫合格的软件需求。
3.2 需求属性：衡量需求质量的那把尺
光有层次还不够，每个需求本身还得有质量。我一般用以下几个属性来卡需求。你想想看，如果需求连这些基本属性都不满足，那后面的设计、编码、测试全得跟着遭殃。
3.2.1 正确性
正确性就是说，需求是不是真实反映了用户或系统的需要。听起来简单，做起来难。我记得有一次评审，一个需求写的是「系统应支持所有卫星型号的遥测解析」。我问了一句：「所有型号？包括退役的？包括国外的？」需求提出者当场愣住了。后来一查，其实只需要支持在轨运行的5个型号。
避坑指南：我曾经见过一个项目，需求里写「系统应兼容历史数据格式」，结果开发团队花了两个月适配一个已经废弃了十年的格式。正确性没把关，浪费的不只是时间，还有经费。
3.2.2 完整性
完整性要求需求不能有遗漏。说白了，就是该说的都得说到。比如一个遥测处理需求，只写了「处理遥测数据」，但没写「处理失败时怎么办」、「数据格式不合法怎么办」。这就是不完整。
我个人的习惯是，每写完一个需求，就问自己三个问题：正常情况怎么做？异常情况怎么做？边界情况怎么做？三个问题都回答了，完整性基本就差不多了。
3.2.3 一致性
一致性是指需求之间不能互相矛盾。这个在大型航天项目里特别容易出问题。比如A模块的需求写「数据采用小端序」，B模块的需求写「数据采用大端序」，两个模块要对接，这不就打架了吗？
我在项目中遇到过更隐蔽的不一致：一个需求说「系统应在10秒内完成故障诊断」，另一个需求说「系统应收集至少30秒的遥测数据用于诊断」。你想想看，10秒内完成诊断，但数据要收集30秒，这怎么可能同时满足？
3.2.4 其他重要属性
- 可验证性：每个需求都要能通过测试来确认。别写「系统应稳定运行」，要写「系统在72小时连续运行中，CPU占用率不超过60%」。
- 可追踪性：每个软件需求都能追溯到系统需求，每个系统需求都能追溯到用户需求。这样改需求的时候，才能知道影响面有多大。
- 无歧义性：一句话只能有一种理解。比如「处理大量数据」，什么叫大量？100条？100万条？改成「处理不少于10万条遥测参数」就清晰多了。
核心总结：需求层次帮你理清「谁在说什么」，需求属性帮你判断「说得好不好」。两者结合，才是合格的需求工程。
3.3 一点个人体会
讲了这么多，最后说点实在的。我见过太多团队，一上来就写代码，需求文档随便糊弄两页。结果呢？后期返工的成本是前期好好做需求的10倍不止。尤其是航天软件，出了问题可不是重启一下就能解决的。
所以我的建议是：花30%的时间在需求上，一点都不浪费。你想想看，地基没打好，楼盖得再高也是危楼。需求就是软件工程的地基。
好，这一章就到这里。下一章我们聊聊需求获取的具体方法——怎么跟用户聊，才能聊出真需求。
公众号:蓝海资料掘金营，微信deep3321