第1章：用户需求分析基础

1.1 需求分析的定义与重要性

先说说需求分析到底是什么。

说白了，需求分析就是搞清楚「用户到底想要什么」。在楼宇自控这个行当里，我见过太多项目，图纸画得漂漂亮亮，设备选型也高大上，结果交付那天用户说「这不是我要的」。为什么会这样？因为需求没搞清楚就动手了。

我个人习惯把需求分析比作「盖房子前先画图纸」。你想想看，没有图纸就砌墙，最后墙砌歪了，拆了重来，浪费的不只是时间，还有真金白银。楼宇自控系统也一样——用户想要的是节能？是舒适？还是运维方便？不同目标，系统架构完全不同。

嗯，这里要注意一点：需求分析不是一次性的工作。它贯穿项目始终，只不过前期投入的精力最多。

1.2 需求分析在项目生命周期中的位置

楼宇自控项目的生命周期，我一般分成这么几个阶段：

阶段	主要工作	需求分析占比
项目启动	明确目标、组建团队	20%
需求分析	收集、整理、确认需求	60%
系统设计	架构设计、设备选型	10%
开发实施	编程、布线、调试	5%
测试验收	功能测试、用户验收	5%
运维阶段	系统维护、优化	持续

你看，需求分析阶段占了60%的精力。这不是说其他阶段不重要，而是说需求分析是「地基」。地基没打好，上面盖的楼再漂亮也白搭。

我记得有个项目，甲方是医院。他们说要「节能」，我就按常规思路做了空调系统优化。结果交付后，院方说「我们手术室对温湿度要求极高，节能方案不能影响这个」。你看，如果需求分析阶段多问一句「哪些区域对温湿度有特殊要求」，就不会出这种问题。

1.3 需求分析的核心流程

需求分析不是拍脑袋，它有一套成熟的流程。我把它总结成四步：

第一步：需求收集

这一步是「听」和「问」。听用户说什么，问用户没说的。

• 访谈——跟用户面对面聊。别只跟领导聊，也要跟一线操作人员聊。他们才是天天用系统的人。
• 问卷——适合大规模收集，但问题要设计得具体。别问「您对系统有什么要求」，要问「您希望空调在什么时间自动关闭」。
• 现场观察——我习惯去现场走一圈。看设备布局、看人员动线、看现有系统的痛点。有时候用户自己都没意识到问题，你一眼就看出来了。

第二步：需求分析

收集来的需求是杂乱的，需要整理和分类。

• 功能需求——系统「做什么」。比如「能远程控制空调开关」。
• 非功能需求——系统「做得怎么样」。比如「响应时间不超过2秒」。
• 约束条件——预算、工期、现有系统兼容性等。

我曾经遇到一个项目，用户说「我要一个智能楼宇系统」。听起来很笼统对吧？我追问了三个问题：

1. 「智能」具体指什么？是自动调节？还是远程控制？
2. 预算多少？
3. 现有系统是什么品牌？

问完才发现，用户其实只是想要一个能手机控制空调的系统，预算有限，而且现有系统是某国产品牌。你看，需求分析就是要把「模糊」变成「清晰」。

第三步：需求确认

这一步是「签字画押」。把整理好的需求写成文档，让用户确认。

• 需求规格说明书——白纸黑字写清楚，避免后期扯皮。
• 原型演示——做个简单的界面原型，让用户「看到」未来的系统长什么样。

第四步：需求管理

需求是会变的。项目进行中，用户可能提出新需求，或者原有需求需要调整。

• 变更控制——任何需求变更都要走流程，评估影响范围、成本、工期。
• 版本管理——需求文档要有版本号，每次变更都要记录。

你想想看，一个大型商业综合体项目，从启动到交付可能跨两年。这两年市场环境会变、用户需求也会变。需求管理就是让系统「跟着变」，而不是「僵在那里」。

小结

需求分析不是什么高深的理论，它就是「搞清楚用户要什么，然后写下来，让用户确认，最后管好变化」。我做了十几年楼宇自控，最大的体会就是：需求分析做得越细，项目越顺利。别嫌麻烦，别图省事。你前期偷的懒，后期都会变成坑。

下一章，我们聊聊「如何跟用户有效沟通需求」。嗯，这个我踩过不少坑，到时候跟你细说。