“需求开发”，写文档
3.3.1 真的要写很多文档
BRD、MRD、PRD、FSD
BRD：Business Requirements Document，商业需求文档，通常是给大老板们演示的PPT，比较短小精炼，没有产品细节，有点像创业者给投资人看的商业计划，主要为了获得认可，争取资源。
MRD：Market Requirement Document，市场需求文档，有更细致的市场与竞争对手分析，包括可通过哪些功能来实现商业目的，功能、非功能需求分哪几块，功能的优先级，等等。实际工作中，PD在这个阶段常见的产出物有产品的Feature List、业务逻辑图等，这是从商业目标到技术实现的关键转化文档。
上述两份文档都是给老板看的。
PRD：Product Requirements Document，产品需求文档，是对产品功能的进一步细化，是PD新人写得最多的文档，也就是我说的“需求开发”过程。文档主要包含整体说明、用例文档、产品Demo等，会对产品功能做具体描述。
FSD：Functional Specifications Document，功能详细说明。比较像我们常写的用例文档，经常包含在PRD中，从这步开始会出现很多技术的内容，产品界面、业务逻辑的细节都要确定，比如网页上的某个表格中的数字，应该左、中、右对齐？保留几位小数？等等。有一点像“概要设计”，与此同时，硬件系统的设计、数据库设计、表结果设计等工作，也开始由架构师、系统分析师们编写了。
用例文档
UML：类图、用例图、状态图
“人治-->法治-->德治”
UML 统一建模语言，它试图将软件工程的过程规范化。“字不如表，表不如图”
《UML基础、案例与应用》
类图：Class Diagram，描述系统中出现的各个对象之间的关系，以及和外部系统的关系，这是对业务领域的描述，一个外行看了以后就应该了解此系统是做哪方面事情的。
用例图：Use Case Diagram，描述各个用例之间的关系
状态图：State Diagram，表达系统里实体的状态转换，同样也是贯穿多个用例的。
上述几种图也可以看作是由整个产品最顶级的业务逻辑图细化而来的，而对于商业演示场景所用的业务逻辑图的画法，团队内没有统一的意见，但一定要简洁清楚，因为受众都是大老板，他们可没有那么多时间看细节，所以这也意味着业务逻辑图最难画。
用例文档，UC，需求人员写给开发人员看的一种最基本的文档。早期的需求人员是通过对应用场景（Scenario）的分析来细化需求的。
理想状态下，一个UC代表了产品需求列表里的一行，但实际上并不绝对，也可能多个UC满足一个产品需求，或者一个UC涉及多个产品需求。
UC里对语言的要求比较高，需要做到：无歧义、完整、一致、可测试等，相信为此吃过苦头的同学都有体会。
再学一点UML：时序图、活动图及其他
时序图：Sequence Diagram，也叫顺序图
活动图：Activity Diagram，比较接近我们常说的流程图。
协作图：Collaboration Diagram
把要做的事情跟受众说清楚！
Demo 也要我们做么
User Experience，简称UE的部门。
概要设计与详细设计
有人希望你写得越详细越好，而有人希望你交给他决定。
第一，不以写的东西是需求还是设计区分职责，而以“业务”或“技术”区分。
第二，细枝末节的设计经常重复，PD应该和开发工程师一起协商，渐渐沉淀出产品规范。如产品中出现的各种字段的各种限制规范。
3.3.2 需求活在项目中
需求必须在项目中经过各方评审，方可进入开发阶段。
“写作-->评审-->修改-->评审”循环展开。
PRD通过以后，PD们会和UE的同学一起细化UC和Demo，而开发的同学也会同步进行开发前的准备工作
“改动较多的话必须再次评审，异议不大可以通过”。
会议上需要
一是能做决定的人 二是与此项目有关的产品接口人
