人人都来产品经理【起点学院】，BAT实战派产品总监的手把手系统带你学习产品，学习运营。
本文介绍了如何从各种详细问题中创建需求文档，而不强调什么是需求文档，以及需求文档的重要性等。
好的要件书的标准是什么？ 虽然根据项目的规模不同评价标准也不同，但是我个人认为可以清晰准确地把握需求的各个要素。 写完后，如果各相关部门的同事能清楚地理解，那就是好的需求文件。 弄清楚并不容易。 作为一个没有经验的产品新人，我想可以从细节问题开始。
有人可能会认为有需求的文档不需要那么严密和细致。 那样的话，会浪费很多时间。 写产品需求文档是一个锻炼自己逻辑思维、求证的过程，严谨细致的态度可以让我们更全面地思考问题，从而制定好的需求文档，减少团队成员的理解障碍。 在这里，我给大家分享一些我平时写需求文档时遇到的细节问题。 我希望大家避免这些不必要的错误。
排版规格
我们写各种各样的文件。 如图所示，所有文档都可以统一合成，便于各部门同事阅读。 的格式标准包括文档标题、每种类型的字符的字体模型、大小和颜色； 表单规格； 流程图的统一规范等。
命名文档
如果能够进行高级摘要和准确定义，团队成员就能够快速准确地掌握文档的内容，避免偏差。 要件文件的命名可以从文件的含义、作用和性质方面进行考虑。
名词的定义
文档中首次出现的特殊名词一定要准确描述，不能缺失。 产品一定明白自己写的内容是什么，但并不是团队里的人能理解。 因为每个人对事物的理解方式不同，所以如果不好好地解释名词的定义，就容易产生歧义，就容易产生分歧。 以普通电子商务网站为例，如果只是在需求文档中简单说明“在后台实现XX功能”，就很麻烦了。 这个“后台”可以指购买者的个人中心、销售者的后台系统、甚至整个网站的后台管理系统等，如果不正确命名说明，开发会很痛苦。
没有必要用尽可能长的文章说明需求，也不是所有的开发都能耐心地持续下去。
尽量用表和流程图进行说明。 例如，要明确不同角色之间的不同功能权限，可以用表列举来明确表示和核对； 另一个是流程图。 正是被称为一图胜千言。 建议学习和使用一些关于UML的知识，包括用例图、类图、序列图、活动图和状态图。 这些可以清楚地描绘出什么样的事物和各种各样的逻辑关系。 从开发的角度来看，他们很喜欢这个表达。 如果你能正确使用的话。
涉及专业术语时要搞清楚再写
例如，有些登录输入框需要正则表达式，但是如果您不知道什么是正则表达式，则最好不要写在要求文档中。 要求文件不是开发文件。 如果明确了功能逻辑，就不需要用开发的语言进行记述。
请不要留下空白
很多时候，我们在写文档的过程中总是有些内容不确定，但是请养成不要留空白的地方的习惯。 请填写“保留”或“TBD”以明确说明未确定的地点是与谁保留的。 这有助于与你的下一个工作对接。
善于举例
要求书的目的是向团队的相关人员明确要求。 在说明要求时，可以举出很多例子，让读者更好地理解要求。 我们可以像故事一样说明需求，但绝对不要跑偏。
文字和文字一致
要求书中使用交互式的原型图。 原型的屏幕快照和文本说明必须一致，屏幕快照必须与实现情况一致。
本文的主要目的是重视文档的细节，从细节中发现问题，找到制作需求文档的技术和方法。 上面列举了一些详细的问题，如果在编写文档的过程中发现了更多详细的问题和文档技术，欢迎交流学习。
本文为@samuel (微信号： suns_up )原创，人人为产品经理，未经许可禁止转载。