程序员需要的是一个清晰的交互图,在关键位置的交互图显示,有一些边界条件,交互图不需要使用乱七八糟工具输出,一张纸和铅笔描述清晰,但恢复需求描述的所有元素就可以了,虽然没有UI设计,但程序员可以开始开发演示。
一、产品介绍和行业简介。首先，给程序员简单介绍一下产品的价值，比如产品的作用，产品可以提供的服务，以及产品相对于竞争对手的优势。还要介绍产品的目标用户和使用场景。第二点是简要说明行业的现状，未来的趋势是什么，同行业竞争对手的情况如何?
二是产品的介绍。第一，实体关系图很重要。当您将产品从0变成1时，为了使数据库开发人员更快地了解您的产品，实体关系图(e-r图)将发挥很大的作用，数据库开发人员可以参考图来做数据表结构设计。
第二是用户角色表的访问。当涉及到角色和权限时，需要一个全面的角色权限表单来促进开发人员的参考。第三是业务流程图。通过业务流程流程图，可以从总体方向了解产品的整体逻辑，通过拆卸业务流程流程图得到流程流程图。
三是各种细节问题。产品的要求、功能和交互指示。写功能描述，交互说明，不能漏掉一些细节，导致逻辑不严谨。可以从以下几个方面来考虑，它会让你更全面地思考:字段，字段描述，数据源；先决条件，排序机制，刷新机制；状态流(页面可能有多个状态，需要解释)；交互操作(正常操作，异常操作)
需求是什么？程序员的需求和我们口中的需求不一样，我们的需求是我们需要个什么东西，而程序员口中的“需求”，一般指“软件需求规格说明书”、“Software Requirement Specification (SRS)”。那么什么样的需求文档对于程序员来说是好的需求文档呢？
一般人认识的需求规格说明书，包含且仅包含用户需求，这应该算最基本的了。有了用户需求说明书，不能算好的需求文档，只能算基础。用户需求使用功能列表和用户用例来描述。而用户需求作为整个需求体系的第三层次，变化是相当剧烈的。当然，对于程序员最蛋疼的人机界面的变更等等，并不是用户需求的主体，属于用户需求的边角余料。
对于一篇好的需求文档，由需求工程师们或产品经理们开发，最终交付给开发团队。这样的一篇文档下来，其中的内容是很多的，而且很丰富。而我们的“程序员”们，到底看了其中的多少内容呢？他一般的是直接跳过背景、目的、范围，跳过业务描述等所有内容，直接找到跟自己相关的功能描述，开始干活。
所以，在程序员眼里，一本好的需求，一个好的需求文档其实就算你写的天花乱坠，那么估计也不会看太多，他会直接越过去，找到和自己相关的部分，然后开始工作。
能将纷乱的业务描绘清晰易懂，文档方式不限要能方便查阅。
原型图、流程图是少不了的，图形方便人明白。原型图不愿定全要有交互结果，但要害部分、易疏忽部分照旧需求的。流程图特殊能表现一个人的逻辑思想、系统思想以及严谨水平。
标准化的笔墨性文档。明晰精确的描绘题目，内容前后一致，种种关联阐明得逻辑严谨，种种业务术语，标准、一致且有备注。
从需求的视点来说，如果你觉得需求改变没完没了，诲人不倦，那么，你应当希望需求标准说明书包含愈加高层次的需求，这样，你就能把我用户需求的编制根据，这样，需求中的过错，遗漏，自相矛盾，你就能够第一时间发现；你也能够反思自己的编码是否契合事务意图，唯有契合事务意图的代码才干不朽。
所以，在我眼里，一本好的需求，必定也有必要包含尽可能完好的事务描绘和事务意图描绘。好的需求是从背景开始打开的，从职业谈起，到该项事务的规划，到用户需求的规划，层次明晰，条理清楚。这样才干帮助读者掌握整个文档的思路和头绪。
还有一点，案件的最后要把一些数据运用表格的形式汇总，这样愈加的一望而知，用到的时分也不需要再去从案件的正文里边去找出来了。比如说道具价格、奖赏的物品id和个数什么的，因为有一些表单需要开发来保护，这样就清晰便利多了~