分享到:

刚好这阵子也在写产品需求文档,在知乎看到这样一个问题,转过来,以此共勉。

需求文档注定是给所有人看的,它就是产品的定义。

  • 文档围观的人包括:你的老板(如果产品够大,还会需要老板的老板),设计师,工程师,测试工程师。有时还应该包括产品前端:如运营,销售,甚至市场部同事。
  • 在通过各方的评审和签字后,一般来说,这个文档就是一锤定音的事。若有更改,就是需求变更了。
  • 所以,在需求文档撰写前和撰写中,对产品方向和用户的把握要足够强,从产品目的,到每个链接的含义,都需要准确地定义。基本上,当你开始写文档时,应该万事俱备。一边想一边写,那说明你还没有想明白这个产品是怎么回事。
  • 在有些公司,需求文档会包括产品的最终设计界面。即在文档提交给大家围观前,产品界面已经确定完毕。

需求文档写作的一些建议

  • 格式无所谓。用WORD的多,HTML,在线文档都成,我还见过PPT写的!
  • 产品定义部分一定要详细描述。按功能模块写,跨功能的定义用流程和关系来描述。多站在用户的角度上,去定义用户任务,用户流程,页面逻辑关系等。
  • 使用准确的用语,注意边界情况。比如,一个文本框最多输入多少个字符?是阿拉伯数字还是皆可?超过字数会怎么样?
  • 多画图。把原型包括进去,或者把产品界面包括进去,不然就画出来。否则除了你,没多少看得懂。

一个需求文档,一些通用部分是必须要包括进去的,我总结了一个示例。
当然, 很多时候有可能是创业公司,或是小版本快速上线,要求会宽泛得多得多。
比如现比较推崇的Agile敏捷开发,会更强短平快,削弱文档的沟通而加强团队的直接交流,简化流程,快速反馈,快速迭代等等。这种情况下,需求文档会极大简化,咱就不在这探讨了。

———————————————————————————————-

  1. 文档信息,版本记录,责任人等
  2. 项目背景,产品目的
  3. 文档约定(采用的标准,通用名词等)
  4. 可行性分析
    • 前期调研
    • 产品预期
    • 对其他产品的影响
  5. 产品定义功能详述(文档主体部分)
    • 功能模块
    • 用例
    • 用户流程
    • 数据需求
    • 业务规则流程
  6.  产品非功能需求
    • 对性能的需求
    • 安全性需求等
  7. 产品风险或潜在问题

知乎:http://www.zhihu.com/question/19586231?rf=20503715

 

 



Tags: ,,.
首页

无觅评论,优化体验,加强品牌价值

无觅相关文章插件,快速提升流量