怎样的需求文档才是算良好的?

如题所述

你好,今天我来详细介绍交互设计师的输出物–交互文档的相关细节,其实,UX设计师在今天看来,仍然算是一个新兴职位,所以我多讲一些UX设计师的职位背景和相关工作内容,作为本篇文章的背景。

一、交互设计师的工作内容

UX设计师的存在,使原本产品经理工作中的原型制作工作逐步转让给UX设计师,使产品经理更关注需求的战略层面,更能进行战略层面的设计。同时,UX设计师也分担了UI设计师的布局设计、跳转设计等非本职工作,使开发流程中的角色更加专注自己的工作。

交互设计师,UX设计师,有的公司也称之为UE设计师。具体的工作内容可以认为有:

    需求消化,使其可实现化,并制作对应的交互原型;

    规定数据格式、样式,规定数据的展示方式、字段限制;

    规定控件的使用规范;

    从功能流程的高度,梳理功能的页面层级;

    规定数据的前后台交互;

    规定临界状态;

    页面切换动效的规定和模拟等等。

    不同的公司对交互设计师的工作内容可能有不同的界定,但是一般情况下,上述是大部分交互设计师的主要工作内容。在这样一份工作中,交互设计师基本上是填补了从产品经理到UI设计师之间的空白,从开发角度和设计角度对一款产品的细节进行补完。

    二、 交互设计师的输出物

    作为交互设计师的输出物,交互文档是联系开发流程上下游的重要文件,它需要具备良好的可读性、唯一性和时效性。

    可读性指的是不论产品经理、设计师还是开发人员,都需要读得懂;

    唯一性指的是,针对某个开发需求,必须有且只有一个交互文档。针对某个项目,其对应的交互文档也必须是独一份(可以是一个交互文档的集合)。即使存在多个版本,旧的版本必须标注为“归档备查”,并且明确备注过时时间;

    时效性指的是,某个需求或者某个项目,尚在使用中的交互文档,必须是最新的,符合当前需求要求和产品输出的。

    本文着重介绍的即是交互文档的构成和它的写法(基于中国移动交互文档规范)。

    三、交互文档的构成

    综合国内IT行业的从业环境,基于Axure的原型制作可能更便于打通开发上下游。

    大概碍于Axure做出来的原型不是那么美观和便捷,部分产品经理和UX设计师可能已经转战Sketch等交互设计软件,或者使用Flinto来模拟交互动效。但因为这些软件大多无法跨平台,考虑到很多公司并没有能力全面采用MAC办公,所以这里推荐使用Axure进行原型制作。

    交互文档一般由以下部分构成:

    1. 交互文档说明及日志

    说明交互文档所针对项目或者功能;

    日志记录它的创建时间、修改时间及修改原因和内容;

    记录文档的编写人和最新的更新时间。

    请点击输入图片描述

    请点击输入图片描述

    交互文档说明示例

    请点击输入图片描述

    请点击输入图片描述

    交互文档更新记录/日志示例

    交互文档的Title有效地保证了交互文档的唯一性,即该文档对应的是XX项目或XX项目的XX功能;

    通过编写人、版本号、创建时间和更新时间,方便在文档内容存疑时,找到对应的时间节点和该文档的负责人,便于对接和修正;

    在更新记录中,需要有效地标明版本号、更新时间、更新内容和修改人,便于文档内容出现存疑时,定位到是哪一部分出现了问题,该部分的对接人是谁,并且明确时间节点,便于版本的追溯和责任的厘清。

    2. 文档内容结构

    大致包括模块名称、功能流程图、页面说明、页面跳转关系图等。

    请点击输入图片描述

    请点击输入图片描述

    交互文档构成结构示例

    在文档内容的结构中,必须保证交互文档的说明和日志是位于头部,便于随时查阅;

    在正式内容中需要灵活运用Axure中的图层,如分组和页面图标等。一般我们认为将页面说明和页面跳转关系统一归到一个功能流程或者一个分组下,这样旣合乎逻辑也可以保证文档内容的层次感,便于查阅时的定位和展开;

    始终坚持“一个页面只描述一个功能”的原则,这样可以保证单个文档页面中的内容量适当,便于查阅。

    请点击输入图片描述

    请点击输入图片描述

    页面说明示例

    在确定以上内容后,就可以保证这份交互文档结构是足够清晰的,是便于查阅的。接下来,我们将讲解交互文档的正式内容应该如何写。

    我们用国内的一款软件摹客网页链接举例

    1.产品概述

    产品需求文档的第一部分,首先需要对整个项目的研发背景及整体规划进行说明,让阅读者可以快速理解需求背景和产品定位。其次是对产品需求文档本身进行阐述,在每一次修订后都需要进行记录,方便阅读者了解产品需求文档的修订更新。这一部分主要包括以下内容:

    项目概述

    词汇表

    文档修订历史

    版本说明等

    2.功能范围

    这一部分需结合用户、业务规则及市场环境,对产品的用户和市场需求进行分析梳理,找出差异性和优势,制定业务流程和需求清单。可通过业务逻辑图、流程图、产品结构图等图表,让产品逻辑和功能以最简单的方式陈列出来,团队成员可根据这一部分了解用户信息、行为信息等,也有助于对产品进行进一步的理解。

    3.功能详情和原型

    首先是列举功能总表,将产品功能进行逐条梳理,每一条功能都能对应前面的产品目标。

    其次是功能详情展示,通过Mockplus等原型工具快速绘制原型,配合关键部分的批注说明,详细描述业务模块的展示、交互和数据逻辑,以供开发人员查看和理解。

    4.全局说明

    这一部分包括设计规范、数据统计、通用规则说明等信息,方便设计师和开发人员查看产品细节信息。

    5. 测试需求

    产品一般在正式上线前都有BETA版本或者内测版本,产品经理需要定制测试产品的功能或者性能。

    6.非功能性需求

    非功能需求为用户常规操作产品时的极端情况,涉及很多内容,包括产品性能、安全性、可靠性、拓展性等方面。

    7. 产品运营和市场分析

    完成产品开发并不是终点,产品的最终目的是要赢得市场。产品上线后如何运营?建议的推广策略是什么?产品经理和运营人员该如何协作?等等问题。

    产品需求文档撰写技巧

    如何高效完成产品需求文档的撰写?我们可以从以下四个方面展开说明:

    理清文档结构

    详尽叙述每一个细节

    语义明确,没有歧义

    搭配原型图或设计稿进行说明

    1.理清文档结构

    一份产品需求文档的内容往往多而复杂,因此,产品经理在撰写产品需求文档时,必须理清文档的结构,才能提升产品需求文档的可读性,让阅读者可以快速了解文档的思路和查阅重要信息。

    将一份产品需求文档看做一个产品,首先需要梳理出它的结构,如上文中所呈现的文档内容,然后再按顺序进行撰写,这样才能写出结构清晰,层次分明的产品需求文档。

    2.详尽叙述每一个细节

    当我们站在产品经理的角度思考问题时,往往会出现这样的误区:产品的这一功能模块逻辑非常简单,业内常见,开发人员也一定能懂,不用再进行单独说明。

    产品经理对于产品的功能及逻辑往往非常了解,但如果从开发或测试人员的角度来看,往往对于许多产品的细节和逻辑关系都不太了解。因此产品经理在撰写产品需求文档时,一定要做到事无巨细。不仅需要详尽叙述页面逻辑、交互逻辑、数据逻辑等所有细节,还需要从开发、测试等角度检查是否有遗漏或错误,才能保证后续开发工作有条不紊。

    3.语义明确,没有歧义

    在撰写产品需求文档时,要做到语义明确,不能出现让阅读者产生歧义的词汇或语句,如:大概、可能、似乎等词语。另一方面,对于产品定义的表述方式,必须做到全文统一。比如在撰写一份APP的产品需求文档时,前文写了“首页轮播图”,后文就不能再使用“首页Banner”、“横幅”等名称。

    4.搭配原型图或设计稿进行说明

    产品需求文档往往包含大量文字描述,团队其他成员在阅读某些功能细节时,往往无法完全理解文字内容。此时如果使用原型图或设计稿进行说明,就可以补充文字内容很难描述的信息,帮助阅读者快速理解产品功能和内在逻辑。因此产品经理在撰写产品需求文档时,需要配合原型图或设计稿进行说明。

    一款产品的原型图或设计稿通常会进行反复修改,产品需求文档必须同步更新,才能让阅读者及时了解到项目的最新动态。但如果每修改一次原型图或设计稿,产品经理都必须手动去替换文档中的配图内容,那效率就太低了!其实,使用高效的产品需求文档撰写神器即可解决这一难题。

    产品需求文档撰写神器

    随着产品开发流程的不断发展,Office等传统办公软件已无法满足产品文档的撰写需求。今天为大家推荐的,是一款专门面向产品经理的文档工具——摹客。除了上述图文同步的难题外,摹客还能解决审阅沟通、版本管理等产品需求文档的写作困境,让产品经理可以更高效地创建专业的产品文档。一起来看看~

    1.富文本撰写,充分表达产品需求

    摹客全新的富文本在线写作模式,符合产品经理日常编辑习惯,可以快速完成文档撰写。撰写内容自动保存,可随时查看历史版本,方便对比修改。此外,产品经理也可以直接上传本地产品文档,会自动解析目录,并生成文档树,方便查阅。

    请点击输入图片描述

    2.与原型图、设计稿深度结合,相互说明论证

    产品经理在撰写产品需求文档时可插入设计稿,当对设计稿进行了更新修改,可在文档中设置内容同步,无需重复插入。另外,团队成员在设计稿上打点评论时,也可以引用文档进行说明,让团队成员可以一目了然地查看相关信息。

    请点击输入图片描述

    3.实时审阅,高效沟通

    文档编辑完成后可以通过链接一键分享给团队成员,团队成员可选中文字增加评论,对文档进行在线审阅,清晰表达项目意见,实现产品开发团队的高效沟通。

    请点击输入图片描述

    请点击输入图片描述

    4.追踪修改记录,备份历史版本

    通常,产品需求文档的写作不会一步到位,往往会根据团队成员的评审意见进行反复修改,因此会产生大量的迭代版本,对于产品经理来说,如何管理产品需求文档的历史版本,是一个很大的难题。在摹客

    撰写产品文档,每一次修改都可以自动生成历史版本,可以随时跳转查看和恢复,管理便捷。

    请点击输入图片描述

    请点击输入图片描述

    5.在线预览、分享更便捷

    在摹客中在线撰写或上传的产品需求文档,可通过链接快速分享给团队成员,团队成员获得链接后可自由查看,当产品需求文档有修改时,团队成员仍可通过链接查看最新版本。

    使用摹客等高效便捷的产品文档撰写工具,可以简化产品文档撰写流程,提升产品经理的文档撰写能力,让产品经理事半功倍。

温馨提示:答案为网友推荐,仅供参考
第1个回答  2013-12-22
软件需求规格说明作为产品需求的最终成果必须具有综合性:必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明那么它将不能作为协议的一部分并且不能在产品中出现。  构造并编写软件需求规格说明,并使用户和其它读者能理解它牢记以下可读性的建议:  ● 对节、小节和单个需求的号码编排必须一致。  ● 在右边部分留下文本注释区。  ● 允许不加限制地使用空格。  ● 正确使用各种可视化强调标志(例如,黑体、下划线、斜体和其它不同字体)。  ● 创建目录表和索引表有助于读者寻找所需的信息。  ● 对所有图和表指定号码和标识号,并且可按号码进行查阅。  ● 使用字处理程序中交叉引用的功能来查阅文档中其它项或位置,而不是通过页码或节号。  优秀需求具有的特性  怎样才能把好的需求规格说明和有问题的需求规格说明区别开来?下面讨论单个需求陈述说明的几个特点( Davis 1993;IEEE 1998)。让风险承担者从不同角度对S R S需求说明进行认真评审,能很好地确定哪些需求确实是需要的。只要你在编写、评审需求时把这些特点记在心中,就会写出更好的(尽管并不十分完美)需求文档,同时也会开发出更好的产品。  1、需求说明的特征  1)完整性  每一项需求都必须将所要实现的功能描述清楚,以使开发人员获得设计和实现这些功能所需的所有必要信息。  2)正确性  每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源,如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性,这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法:“那些毫无意义,这些才很可能是他们所要想的。”其实这完全是评审者凭空猜测。  3)可行性  每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求,最好在获取( e l i c i t a t i o n)需求(收集需求)过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作,由他负责检查技术可行性。  4)必要性  每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入,如使用实例或别的来源。
第2个回答  2013-12-22
1.具有清晰的格式和文档结构2.需求的内容正确3.需求的内容完整4.需求具有可行性5.需求的内容具有必要性6.对不同的需求的优先等级进行定义7.描述正确,无歧义、二义、上下文一致8.可证实和可测试性9.可修改性10.可追踪性,软件的需求与设计元素、源代码、用于构造实现和验证需求的测试也应该对应起来11.需求文档要被及时的更新本回答被网友采纳
第3个回答  2013-12-22
如果要做一个很全的需求,内容有很多简略一点要包括 项目介绍(背景,范围) 用户分类 需求分析(功能,性能,)数据流,数据字典,用例分析和用例描述 确定需求优先级 人力资源管理,项目计划,风险管理,原型介绍(如果有)等内容 0
第4个回答  2013-12-22
分拿过来
相似回答