用户文档怎么写(用户文档主要描述)

如何写好文档

1. 弄清读者是谁：给最终用户（小白）的、给系统维护人员、给后来的技术人员交接的的文档肯定不一样，给小白的重截屏，给维护的重操作，交接的重原理。2. 切换“无知者”模式：很多东西是在做项目的过程中试错积累出来的。做着做着：这么干原来不行啊，应该这样这样，改设计！做着做着：哎呀，原来有这个问题没有考虑到，现在加进去，改设计！做着做着：哦？什么？客户要改需求？好吧，我改设计！这样下来大型的IT项目做到最后，和最开始的设计已经大相径庭了，按照原来设计的思路来写文档肯定是不行的，按照时间顺序把修改加上会更加混乱。写文档的时候需要切换到“无知者”模式，把自己想象成一个刚刚接受项目要开始设计的人，面对已知的这些“新要求”和对技术全新的理解，重新写一份文档，这样才能脉络清晰，可读性高。3. 遵循标准构架：大型项目牵扯的东西多，有实际的设备有虚的概念，有用户界面也有关键性配置，杂七杂八什么都有，如果不按照一个标准构架来写文档，很容易就眉毛胡子一把抓。这时候就一定要找一个标准构架，比如OSI七层构架，TCP-IP四层构架等等，从上到下或者从下到上，写着也方便，看着也舒服。

--------

1、尝试编写个人简历和经历，用文字来认识自己是不错的方法。要想别人认识你，首先自己要认识自己。

2、养成良好的程序注释习惯，而且要用准确的语句描述注释的内容，从写注释的一句话开始锻炼文字表达能力。准确而简明的注释有助本人和他人阅读你的程序代码，语义不清或者错误的注释反而浪费了自己和他人的时间。

3、从编写较简单的文档（如：《XXX系统使用说明》）开始，锻炼文档编写的组织能力和文字表达能力

4、写博客。其实这也是我写博客的原因之一，想通过多写文章，用文字来准确的表达日常自己的所思所想来提高文档能力。还可以通过他人的评论和建议来改正不足之处。

6、阅读一些写作技巧方面的文章提升技术文档编写能力也是显而易见的。

当然，要切实提高文档编写能力，需要勤于学习、勤于思考、勤于实践、长期积累，毕竟丰富知识和阅历才是写好文档的基础。

用户需求说明书文档模板怎么编写？

用户需求说明书模板 文档标识：当前版本：1.0当前状态：草稿发布日期：2009-1-1发布ü修改历史日期版本作者修改内容评审号变更控制号目录1 引言... 31.1 编写目的... 31.2 项目背景... 31.3 术语定义... 31.4 参考资料... 32 综合描述... 32.1 产品介绍... 32.2 目标范围... 32.3 用户特性... 42.4 约定假设... 43 用户需求（可剪裁）... 43.1 总体需求（可剪裁）... 43.2 内容需求（可剪裁）... 54 功能需求... 54.1 数据需求（可剪裁）... 54.2 接口需求（可剪裁）... 64.3 权限控制需求（可剪裁）... 64.3.1 系统安全要求（软硬件）... 64.3.2 用户角色... 64.3.3 角色权限控制... 65 非功能需求... 65.1 用户界面需求（可剪裁）... 65.2 性能需求（可剪裁）... 75.3 压力需求（可剪裁）... 75.4 主流技术应用需求（可剪裁）... 75.5 安全需求（可剪裁）... 75.6 故障处理需求（可剪裁）... 75.7 环境需求（可剪裁）... 75.8 产品质量需求... 75.9 其他需求（可剪裁）... 86 需求优先级... 87 附加说明（可剪裁）... 81 引言 1.1 编写目的 本节描述编写该用户需求说明书的目的，并指出预期的读者。1.2 项目背景 本节描述用户需求说明书中所定义的产品的背景和起源，以及同其他系统或其他机构的基本相互关系等。当在已有的系统上进行特性开发时，如果新特性与已有系统的特性之间存在关系，则应在本节说明其相互之间的关系。1.3 术语定义 本节可列出本文件中用到的专门术语的定义、外文首字母组词的原词组等。1.4 参考资料 本节列举编写用户需求说明书时所参考的资料或其他资源，这可能包括用户合同、公司规范、技术书籍等。在这里应该给出详细的信息，包括资料名称、版本号、作者、日期、出版单位或资料来源，以方便读者查阅这些文献，可用以下格式表示： 资料名称版本号作者日期出版单位/资料来源备注 2 综合描述 2.1 产品介绍 本节简要描述产品的特性。2.2 目标范围 本节简要描述产品的应用目标、作用范围等。2.3 用户特性 本节可能包括本产品各类最终用户的特点，如操作、维护等人员的知识水平和技术专长等，也可能包括用户组织关系结构图以及组织、部门、岗位的隶属关系与职能。这将是后续工作的重要依赖条件。2.4 约定假设 本节列举出在对软件用户需求说明书中影响需求陈述的假设因素（与已知因素相对立）。这可能包括将要使用的组件、特殊的用户界面设计约定、产品预期使用频度等。如果这些假设不正确、不一致或被更改，就会使项目受到影响。3 用户需求（可剪裁） 每一项需求必须进行唯一标识，并给出该项需求的优先级。需求优先级的定义，一般需要根据用户意见结合商业价值、交付成本、交付日期、复杂程度、风险等因素来进行考虑。高优先级需求表示本系统产品中必须实现的需求，中优先级需求表示必须但是根据时间情况有可能会被推迟到下一版本的产品中去实现的需求，低优先级需求表示如果没有充足的时间或资源就可以被放弃的需求。具体描述请参考《需求跟踪矩阵》！需求编号方式可以根据项目实际情况进行自定义，也可以采用“项目代号”＋“-”＋“R”＋“需求类型”＋“序号”的形式。其中“R”表示Requirement，“需求类型”可用下表表示，“序号”以自然数表示，位数不限。 需求类型英文名称中文名称FFunction功能PPerformance性能DData数据UUser Interface用户界面IInterface接口SSecurity安全MMalfunction故障处理OOther其他示例：OLTP-RI5表示为OLTP项目的第5项用户界面需求。3.1 总体需求（可剪裁） 描述项目总体需求，简述项目特性等内容。3.2 内容需求（可剪裁） 按照内容（如产品包、组件等）展开用户需求。4 功能需求 详细列出系统各模块/主题/子系统的功能需求。提示：将功能性需求先粗分再细分，下表中的 Feature A, Function A.1等符号应当被替换成有含义的名称（可考虑加上需求的优先级别）。在描述中要简要阐述该需求项将依赖于哪些需求项。 功能类别标识符子功能名称描述Feature AFunction A.1…Feature BFunction B.1…Feature CFunction C.1…产品包提示：针对本功能进行说明描述（包含其要做什么、什么流程、相关的财务、特殊要求、需要的数据等），可以采用相关的图表来更容易地表达信息。① 功能描述：描述需求项的功能。② 业务描述：描述该需求项的业务流程、相关的对象的状态、涉及到的业务角色等。③ 数据描述：描述需求项的数据项、数据精度、输出的格式等要求。④ 输入描述：描述该需求项的相关依赖（包括业务依赖和需求项的依赖）和输入条件。⑤ 输出描述：描述需求功能执行后，相应的输出产物、数据、对象状态等。4.1 数据需求（可剪裁） 详细列出系统的数据需求，可能包括数据类型、载体、格式、数值范围、精度、规模等需求。4.2 接口需求（可剪裁） 详细列出系统的接口需求，可能包括与其他系统之间的接口、数据通信协议、内部模块之间的接口等需求。4.3 权限控制需求（可剪裁） 4.3.1 系统安全要求（软硬件） 提示：说明对本产品系统的功能方面的安全的要求，如用户名密码加密、系统访问安全等。4.3.2 用户角色 提示：阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。角色例如：系统管理员（SuperAdmin-Lowest Level）内部操作管理员（OperatorAdmin-Mid Level）外部操作管理员（ResellerAdmin-Midhigh Level）终端用户管理员（UserAdmin – High Level） 角色名称职责描述 4.3.3 角色权限控制 提示：描述上述各用户角色的权限控制要求5 非功能需求 5.1 用户界面需求（可剪裁） 详细列出系统的界面需求，可能包括图形用户界面标准、产品系统风格、屏幕布局或解决方案的限制、快捷键、错误信息显示标准等。5.2 性能需求（可剪裁） 详细列出系统的性能需求，可能包括时间特性要求、软件灵活性、容错性、容量需求等。提示：说明本产品的整体性能必须达到程度，特别是一些关键功能点。5.3 压力需求（可剪裁） 提示：说明本产品使用必须满足的压力峰值要求5.4 主流技术应用需求（可剪裁） 提示：说明本产品需要使用何种主流技术。如果不清楚或不明白可以不填后面由项目开发组提出技术方案再进行选择。5.5 安全需求（可剪裁） 详细列出系统的安全需求，可能包括安全设施需求和安全性需求等。安全设施需求是指产品使用过程中可能发生的，与损失、破坏或危害相关的需求。定义必须采取的安全保护或动作，还有那些预防的潜在的危险动作。明确产品必须遵从的安全标准、策略或准则。一个安全设施需求的范例如下：“如果油箱的压力超过了规定的最大压力的95%，那么必须在1秒钟内终止操作”。安全性需求是指与系统安全性、完整性或与私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。定义用户身份确认或授权需求。明确产品必须满足的安全性或保密性策略。一个安全性需求的范例如下：“每个用户在第一次登录后，必须更改他的最初登录密码。最初的登录密码不能重用。5.6 故障处理需求（可剪裁） 详细列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。5.7 环境需求（可剪裁） 详细列出各种环境需求，可能包括开发环境、测试环境、运行环境等需求。具体内容可能涉及到网络、服务器、数据库、前台、测试工具等的软件、硬件方面。5.8 产品质量需求 描述产品预期达到的质量要求，包括多个质量特性，以下的质量属性仅为参考，各项目可以根据需要补充或删除某些质量特性。 主要质量属性详细需求正确性 可靠性 健壮性 性能、效率 易用性 清晰性 安全性 可扩展性 兼容性 可移植性 … 5.9 其他需求（可剪裁） 详细列出在前文中没有包括的所有需求，可能包括用户对可维护性、可补充性、易读性、可移植性等方面的特殊需求，或者国际化或法律上的需求。6 需求优先级 根据用户的需要程度，初步列出各需求的优先级，参见《需求跟踪矩阵》。7 附加说明（可剪裁） 描述该用户需求说明书采集的方法，如访谈、现场体验、惯例综合等。参见的竞争产品和相应的用户需求获取文档，如用户故事、需求采集表等类似文档。Download: template-requirement-analysis.rarREF:软件设计文档国家标准(GB8567--88)GB8567——88

如何写系统的使用文档

软件的使用文档分为两种常见的写法，一种是俗称“点点点”的帮助手册类使用文档，告知用户每一步需要点击的按钮，用系统的截图及指示去展现；另一种是偏需求文档的形式，告知用户为什么这样操作，怎么操作。下面具体分析两种写法风格的场景选择及写发分析。

此类使用文档多用于业务逻辑简单的系统，大多数的逻辑在页面上可以展示，用户只需要知道系统的使用流程，在哪些模块实现哪些操作即可。用系统截图+箭头/符号的视觉指引来引导点击区域，附带着一些注意事项类的文字，基本可说明使用情况。具体的内容划分如下：

功能模块的划分

系统截图

操作步骤

注意事项

此类使用文档多用于复杂逻辑的系统，很多隐藏的逻辑在页面上无法看出，很多后台设定的流程或逻辑，需要文档中说明；另一种情况是针对于强业务系统，尤其B端的系统居多，业务逻辑很多，需要以此文档给使用者讲清楚业务逻辑后，再加入“点点点”的操作。具体内容划分如下：

部分业务流程讲解

系统截图

功能模块的划分

操作步骤

注意事项

使用文档一般按照用户角色区分，每一种用户都有一份使用文档，常见的系统有前端，后台两个大块，即分为后台管理员使用说明书和用户使用说明书，如系统较大，比如OA系统，后台可以继续拆分，如财务人员使用说明书，crm管理员使用说明书，业务管理员使用说明书等等。

正规的文档的格式，可以按以下的结构去写，主要包括：文档控制部分、前言、使用说明和注意事项。详细说明分别如下：

这部分主要说明文档的更新迭代及编辑情况，便于文档的管理，也给阅读的人清晰的版本说明。此部分主要包含以下几点：

标题、版本号、修改记录

编制日期，编制人，版本号，编制内容（这部分多用一个表格去展现。）

前言部分主要给使用者一个概述性的引导说明，概述说明系统的逻辑，适用的用户群，以及主要的业务场景。另一方面指出本份文档针对的用户是哪一部分，给出一个简短的说明。前言部分概括为以下两点：

系统概述：逻辑说明、用户群、业务场景。

文档目标人群：本实用文档主要针对于xxx用户，便于用户了解系统的使用方法，系统逻辑...便于用户尽快上手尽快使用本系统。

此部分为说明书的核心部分，通常是按业务逻辑，将系统分为不同的业务模块分别说明，如注册登录，浏览商品，下订单，结算，红包金额提现…各模块可以分别作为一个二级标题，分段去说明。

注意事项部分主要指出一些业务的边界，法律上的声明，文档的版权保护等等内容。文档版权归属一般放置在页眉，业务边界等内容，如果有必要的话，可单独放成一个模块，也可以在业务说明后，写注意事项的部分。

xxxx系统使用文档

编制：xxx

生成日期：2018-09-08

版本：v2.0

系统介绍

本系统是xxxx

目标人群

通过阅读该操作手册，可以帮助xxxx尽快熟悉在xxxx系统的相关操作。

功能一

功能二

.

.

.

免责声明...

版权声明...

业务边界...