这两天在写一个报警系统的需求文档。
事实上，在没有写需求文档之前，我已经开发报警系统有一阵了，整个框架差不多已经搭出来了，才回过头来写文档。这样就导致我出现了写需求文档时，满脑子都是如何实现需求的，这样写出来的文档有根本性的错误。
站在开发者的角度思考需求实现思路，却没有站在用户的角度思描述实际场景需求。
很显然需求文档要求的是需求的描述，而不是描述实现思路。
之后，我转换角色，重新写需求文档。在写的过程，我发现很多时候都捉襟见肘，主要原因是我描述不清我想要的需求，而描述不清的原因是我没有一个很好的需求描述思路。
在慢慢的摸索中，我发现以下一种思路还算可行。
需要一种需求的描述时，可以：
1）大略描述这个需求的全过程，注意描述过程所使用的各种名词，这非常重要。
2）详细解释大略描述过程中出现的重要名词
3）在详细解释重要名词过程中，可以注重以下两个角度：1、举例子；2、考虑这个名词是否具有输入输出特性
总之，根据我现在的理解，
1）说明"能干什么"，但不要"如何"，写需求文档一定要从真实场景出发，分为两条思考线，一是以用户的思路为主线，想想我需要什么功能；二是以开发者的思路为辅线，想想这个需求的基本实现思路，然后转以需求的形式描述出来。
2）说明"是什么"，具体写文档时，各种名词的界限、定义以及如何将它们解释清楚，是非常重要的。