第2章需求分析与系统设计

第二章需求分析与系统设计：用户故事编写、功能模块划分、系统架构图设计、数据库ER图设计

好，咱们进入正题。上一章我们把风电软件的全景摸了个大概，这一章就要开始动真格的了——做需求分析与系统设计。

很多人觉得这步是「纸上谈兵」，恨不得直接撸代码。我年轻时也这么干过，结果呢？代码写了一半发现需求理解错了，推倒重来。嗯，那滋味可不好受。所以这一章，我会把我在多个风电项目里踩过的坑、总结的经验，掰开揉碎了讲给你听。

用户故事，说白了就是「谁想干什么，为什么」。它不是需求文档，而是沟通的桥梁。

核心公式：

作为 <角色>，我希望 <功能>，以便 <价值>。

举个例子，我们做风电场的监控系统，运维人员最头疼的是什么？是风机报故障了，但不知道严重程度，半夜爬起来去现场，结果发现只是个小告警。

所以用户故事可以这样写：

作为 风电场运维值班员，
我希望 系统能根据故障等级自动分级告警（紧急/重要/一般），
以便 我能在第一时间判断是否需要立即处理，避免无效巡检。

你看，这样写出来，开发人员就知道要做什么了。我在项目中遇到过最典型的问题，就是用户说「我要一个报表」，结果做出来发现他要的是实时曲线图。所以写用户故事时，一定要追问一句：「然后呢？你拿到这个数据之后要做什么？」

我的小技巧：

每个用户故事不要超过 15 个字的核心功能描述。如果写长了，说明这个功能可能太大了，需要拆分。

用户故事收集完了，接下来就是划分功能模块。我习惯用「高内聚、低耦合」的原则来切分。

对于风电软件，我一般会分成这几个核心模块：

你想想看，如果我把「数据采集」和「数据分析」揉在一个模块里，那以后要换采集协议，就得动分析逻辑，多麻烦。所以模块划分，其实是在为未来的扩展留余地。

避坑指南：

我曾经在一个项目里，把「告警规则配置」放在了「系统管理」模块里。结果运维人员每次改告警阈值，都要找管理员要权限，流程走半天。后来我学乖了，谁用谁配，权限下放。

模块分好了，接下来就是架构设计。我习惯先画一张「分层架构图」，把数据流走一遍。

下面这张图，是我在多个风电项目里沉淀下来的通用架构。你看一眼就明白了：

这张图我建议你保存下来。每次做新项目，直接拿这个框架去套，再根据业务特点调整细节就好。我个人习惯，每一层之间都要有明确的接口定义，比如数据采集层只负责「拿到数据并写入」，不关心上层怎么用。

经验之谈：

架构图不是画完就完事的。我每次评审架构图，都会拉着运维、开发、产品一起过一遍数据流。有一次，运维说「数据采集层如果断网了怎么办？」——好问题，于是我们加了「断点续传」和「本地缓存」机制。这个坑，幸好发现得早。

架构定下来，就该设计数据库了。风电软件的数据特点很明显：时序数据量大、关系数据复杂。

我一般会分两类来设计：

下面是一个简化版的ER图，展示核心实体之间的关系：

这张图里，一个风电场下有多个风机，每个风机可以产生多条告警记录和多个工单。用户则关联到工单（谁处理的）。

注意：

ER图设计时，最容易犯的错误就是「过度设计」。我见过有人把风机参数拆成几十张表，结果查询时关联得一塌糊涂。我的原则是：先满足核心业务，再考虑扩展。比如风机参数，直接用一个JSON字段存起来，比拆成10张表好用得多。

说实话，很多项目死在设计阶段。要么需求没对齐，要么架构不合理，要么数据库设计反人类。这一章我们走完了从用户故事到ER图的完整流程，你可能会觉得「就这？」——但真正做项目时，你会发现每一步都有坑。

我个人习惯，设计阶段至少要花掉项目总工时的20%。别急着写代码，把图画清楚，把故事写明白，后面会顺畅得多。

核心要点回顾：

好，这一章就到这里。设计文档写好了，下一章我们就要开始搭开发环境了——嗯，那又是另一番天地。

公众号:蓝海资料掘金营，微信deep3321