编程快20年，写了一些的文档。
之前也一直在思考如何写文档，这个过程中，有几次提升。
一次是在华为，学习如何写设计文档。
另外就是写需求文档，这次的项目，以前需求写得也比较多，但都是有足够的思间来慢慢写，这次时间比较紧张，所以，思考如何写作需求。
==============================
开始之前，
我们还是先回下头，想想到底什么是软件。什么是硬件。
这是因为，许多公司，特别是中国现阶段，实际上大多数公司是硬件公司，然后去开发软件，然后用硬件的思维去写软件文档，各方都很别扭。
有的人，以为，用代码写出来的，就是软件，这有些片面。比如CPU也是代码写出来的，但它似乎是很硬的。
所以，有人说华为是家软件公司，理由是大家都在写代码，这有点让人哭笑不得。
===========================
这里，我来斗胆定义一下吧：与人打交道的，特别是人机界面相关的，就是软件。
另外，是状态相关的。
比如，windows的win32API，算不算软件？以前我以为是，现在我觉得不是，当然，也不能算是纯硬件，属于一种中间态吧，因为它不满足状态相关这件事。显然，我们人类是有记忆的，对吧。
列一下，软件两个必要条件：
1. 与人打交道，人机界面相关。
2. 状态相关的。
还有一个最好满足的条件：
3. 用来赢利的，不是给自己公司人使用的。或是管理自己的硬件设备产品的。
比如，华为的网管软件，其实不能算是软件。
================================
我们开始吧。
先从需求开始。
如上所述，需求的要点是从人开始。
也就是从使用者的角度来看。而不是从实现的角度来看。
设计文档，则是在需求明确的前提下，从设计的角度，来描述，如何实现的。
需求文档的输入是用户的述说，输出给项目经理，项目经理，进行全面的评估，比如，查看范围是否划的明确（这是最最重要的一点），能否实现，如果能实现，公司的资源，能否支撑，质量、进度、成本目标是否能够达成？
然后下达给技术经理，进行设计。
当然，不得不吐槽，中国的软件业乱七八糟，怎么干得都有，往往是项目经理，自己组织立项，自己组织写需求。
最后项目经理，需求经理，技术经理，还有产品经理各人一嘴毛，谁都想跨过自己的边界。唉，不扯这些了。
最后所有的人，都可以指责项目经理，唉，不做事不犯错，实际是因为边界。所以，下辈子，不当项目经理，要当给自己的公司当。
需求实际上，的确不应当由项目经理定，虽然他要参与需求的制订，但他不是写需求的人，他只是负责执行。
技术经理，负责实现的图纸。
产品经理，负责验收结果，也就是代表业主方。或者需求方。算是一个只在关键点有话语权的财主，可实际上，地主来干涉长工干活的事情，在中国很普遍，我说过无数次了：对于中国人来说，边界是个大难题，无数人，到死也没搞清楚边界，谁不想把别人的老婆变成自己的呢？当然，真变成了，也肯定是悲剧了。
吐槽也有好的一面，如果你真看明白上面的文字，你可能了解你的公司的问题在哪里。
有人总是在纯想技术，项目失败，实际上多数时候，70%以上吧，来自于组织的问题。
=======================================
如何写需求
1. 准备一下：写写前因后果，给系统起个名字，然后试图划清边界和规模。这个很难，但必须要做。
2. 分清角色。
3. 站在每个角色的视角，提出，有哪些需求。这一点，回顾一下上面的描述，就出来了，要站在人的角度，如果与人无关，就没有需求，交给实现方就可以了。比如，用户的需求，是把数据从A地传到B地，我们可以选装硬盘里用车拉过去，还是用TCP/IP协议传过去，用户是不在意的，这种情况，比如，“首先雇辆车，然后硬盘装车，诸如此类的”，就不要写了，这虽然也是与人打交道，但这人不是你的用户；如果把TCP/IP协议栈当作人，自然更离题了。
4. 然后是细化。每个动作的详细的描述，包括：输入（前置状态或允许条件等），输出，状态的改变
=========================
设计文档，
相对就更好写一些。
主要是层层分解。
每一层都要先描述出：
1. 自己在上一层的位置
2. 自己与同层的模块或系统或子系统之半的关联关系，这时，这些接口，已在上一层的接口描述中定义，只需要提一下即可。同层的模块间的流程，也不要写，因为在上层已写过。
3. 自己的内部构成，也就是模块分解。每模块功能简要描述。
4. 内部模块间关联关系和接口描述。
5. 子系统的主要流程，主要说明每个流程，各内部子模块之间的协作，主要是指信息流动，和各子系统的状态变化。也就是输入，动作，输出。