一份良好的需求文档,应该包含哪些部分.docx

一份良好的需求文档,应该包含哪些部分.docx

  1. 1、本文档共6页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
一份良好的需求文档,应该包含哪些部分 PAGE 6 一份良好的需求文档,应该包含哪些部分 一份良好的需求文档,可以很好地传递产品经理的思路,更好地实现与开发的沟通。 一份可读性强、文脉和思路清晰、流程和功能阐述明白、页面元素、输入和输出都定义明确的需求规格说明书、通常都是需要经过几次持续的迭代和梳理,才能逐渐完善起来。 到底需要迭代几次,就取决于你对业务的理解能力和需求分析能力了。然而不论你迭代多少次、最终也是为了让程序员读到它的时候,能够心领神会,不用BA和PM解释过多。愉快地实现玩耍和编码,最终实现系统/产品(后统称产品)的功能。 所以需求规格说明书的目的,不是为了给领导和User看(领导和User并不关心这个,领导和User在乎的是这个产品啥时候能用,能为他们带来什么样的价值!!!)。工作留档?也完全没有必要,除非你今天做了一半要辞职回家去种田,需要工作交接。因为交付一个良好的产品比这个都重要100倍。如果为了纪念,你曾把大把的时间和精力投入到这个产品的规划、设计、功能交互、后台逻辑梳理等等上面。你倒是很要必要给自己留个档案。多年后,无意中再打开,你会看到自己成长的轨迹和脉络。 基本内容 时间、版本、修订者、 编写目的、编写背景诸如此类的内容,就不必再多说了。我不是说这些不重要,而是这些与要实现的产品具体的需求功能均无关系。不要在这些点上浪费时间,但这些小细节会体现出你做需求的规范、流程及专业性。 1.用户及应用场景 不同层次、不同角色的User有不同的诉求和应用场景。对于BI类的产品不同类型的User使用数据的场景均不一样,明确用户群体、用户角色、用户权限等,根据业务场景,梳理、构建并完善用户应用场景有助于让需求分析更准确,让产品功能更全面,更贴近用户需求。 比如一个数据分析系统,针对不同的User,对需要做业务的一线业务人员,在设计的时候,基本上就是要通过界面展现关键指标,不涉及详细分析功能。并且在某些指标异动时能及时通过手机通知。而运营分析的数据分析师,则必须提供多维度分析、灵活分析、对比分析、趋势预测分析、假设分析等功能。 另一方面,不同层级User关心的功能、数据粒度都不一样。需要站在User的立场上去规划和引导应用场景。而每一个应用场景的设计是否刚好符合用户的需求,又解决了User的痛点问题。这是一个大的前提和关键。因为只有在实现基础功能之上再考虑用户粘度和用户体验度才是有意义的,否则锦上添花的东西有时候会变的华而不实。 用户群组、角色权限、应用场景等内容需要反复Check和逐一假定演绎系统的应用场景,而在这样的过程中,很有必要和User保证紧密的联系和沟通。这也是产品规划和设计的关键,只有在一开始,就尽最大程度的努力让User参与进来,关注产品的功能、应用场景和体验,你的设计才不会距离User太远。 2.系统/产品的目标 通俗一点讲,就是要解决什么问题、带来什么价值。这本质上是要明确产品需要满足用户的什么需求。但凡需求,均有价值和优先级。判断需求的价值,可用 PST方法分析,但通常这个理论都比较繁琐。其实优先级很容易得出,通常User急切想要的东西,或者急切想要借助一个系统或一款产品来帮助他解决业务当中棘手的问题时,这些都是优先级比较高的需求。 这一章节的内容,它决定了,我们要设计什么样的产品,用这个产品能够用来做些什么。比如一个绩效系统,主要就是要实现企业不同部门,不同层级、角色的绩效指标的自动化计算、汇总、可视化呈现。做的好一点,时间维度、能够自由而灵活界定, 准确而便捷地评鉴个体的绩效趋势和走向方便绩效的精细化管理和追踪。另一方面能够从全面的职责维度出发,对比和观测不同职责的绩效表现与趋势。能够更加容易、全面、公正地绩效考评并有效联动奖金激励机制。 3.功能模块概要介绍 这一章节是概要地介绍,你要设计和规划的产品都需要具备哪些功能模块、功能点、大致会有哪些主要的功能页面来支撑这个功能模块。 模块的定位、模块间的划分与交互都需要有基本的介绍。目的主要有2个: 一方面,是为了方便PM清晰地将产品规划的功能落地下来,因为这些琐碎的创意和设计,只有在你具体去描述它的时候、并画出它的Mockup的时候,它的局限性、用户交互、用户体验等种种缺陷才会展现出来,你才能进行持续的思考和摒弃。通过这样的过程,PM把这些星星点点的创意和设计,经过一个产品化(系统化)的体系思考、演绎之后变得生动和流畅起来。 另一方面,功能概述的意义旨在为程序员服务,程序员前期不参与需求、系统规划和设计,拿到需求规格说明书后,如果立马进入到具体某个页面、功能点的详尽规格描述里,通常都会一脸懵逼,然后开骂和抱怨。 所以功能模块概要需要用尽量简练的语言将各个功能模块里的主要功能点提炼概述而过,不拖泥带水、不

文档评论(0)

177****2305 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档