需求

当我们初次接触 产品需求文档 时，首先会从网络上寻找 产品需求文档模板 ，希望从中了解和学习具体的写作要求，但实际上，现在网络上绝大部分的 PRD文档 都是与实际工作不相符的，或者说是复杂的。 前几天一位从事产品类工作的朋友，发来一份他写的产品需求文档目录截图给我(下图)，当时我就郁闷了，这些类目更像是 MRD文档 ，而不是 PRD文档 了，因此我决定写几篇讲述写作PRD文档的文章，分享一些我关于PRD文档的见解和写作方法。 PRD 是英文 Product Requirement Document 的缩写，中文的意思是产品需求文档，具体的名词介绍大家可以询问 Google 。 PRD文档 是基于 BRD 、 MRD 的延续文档，主要用于产品设计和开发使用，因此阅读这份文档的人群绝大多数是设计与技术人员。在这类人群中，设计师更多依赖于原型进行交互或视觉的设计，因此看这份文档的人就会偏向于技术人员。相对于技术人员，他们不太关注产品的商业需求和市场愿景，因为在进行产品讨论立项时，产品的定义就已经向参与设计和研发的人员宣讲过，因此技术人员更多的是关注界面、功能、交互、元素等等内容，因此PRD文档是一份详细的产品功能需求说明文档，是产品文档中最底层和最细致的文档。 PRD文档 是一份没有闲话，直入主题的功能说明文档，因此我们在写作时，脑海里构思的是成品产品的界面功能的逻辑线框图

学习了《软件开发沉思录》中的实用主义性能测试，对重点内容做下记录： 性能测试应该囊括确保产品性能符合要求所需的一切行动。这里有四个关键点:需求、产品性能数据、沟通和流程。 1.需求采集 需求采集中的几个重要问题:要度量什么?如何知道我们需要什么?以及如何得到确实有用(而非帮倒忙)的数据? @要度量什么 最重要的性能度量点有两个,最大吞吐量以及给定吞吐量下的响应时间。一个好的做法是:分别度量几种不同吞吐量下的响应时间,从中分析负载对响应时间的影响。 需要通过度量找出两项数据:当响应时间恰好可以接受时的吞吐量,以及达到预期吞吐量时的响应时间。伸缩性度量的关键则在于:随着数据规模、用户数量或者运行系统的硬件变化,起初得到的性能度量数据会发生怎样的变化。 可靠性的关键度量点是:当负载量高得超乎寻常,或者连续运行了很长时间以后,系统是否仍然正常工作。 @如何设定目标 要想知道系统需要达到怎样的吞吐量,你首先需要知道有多少用户会使用这个系统,以及他们的使用模式。用户会多频繁地使用某个功能?这个功能需要多快完成? 需要有一个可靠的沟通流程与机制来获得所需的信息,及时获知支撑业务需求所需的性能指标。 总之： 需求采集是为了让所有人都清楚最终交付的产品需要有怎样的性能才能支撑业务目标。之所以要让客户参与,是因为他们最了解自己的业务,这样才能确保采集到的需求足够准确

最近手上并行的跑了好几个项目，弄得自己都抽不出时间来更新博客啦，前面说的好好的要坚持的，没想到才几天，就停止啦，看来是计划赶不上变化啦，哈哈~~，不扯淡啦，说写完，怎么着都得完成。 目前市场有的阅读软件是相当的多，我这里简单列举下，不算做广告啦，我的目前是学习，温习旧的知识点，算是做笔记，留作后用，另外，也是为了学些新知识，和大家交流。 （下面的软件介绍文字，都是摘自互联网，大家可以进入网页，直接看效果，介绍顺序为随意，不包含个人意见） （1）掌阅IReader iReader是在Android平台广受好评的一款阅读软件，支持EBK2/TXT/UMD/PDB/CHM/EPUB全主流阅读格式,个人比较推崇。软件介绍官方网站为: http://www.zhangyue.com/products/ireader/ (2) 百度文库 3000万海量文档，全面覆盖教育文档、专业文献、应用文书、PPT等精品资源。提供书架功能，本地文件便捷导入，提供便捷的文档管理方式；多格式支持，3D翻页，昼夜模式，提供贴心的阅读体验；通过在线文库，3000万文档，指触即达，百度应用介绍网址： http://as.baidu.com/a/item?docid=83592638&f=web_alad_1 （3）塔读 塔读是一款外观精致,功能彪悍的小说阅读的Android软件,让手机阅读有如纸质阅读般沉静和随性