BRD

指的就是基于商业目标或价值所描述的产品需求内容文档（报告），其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。很可能以ppt的形式出现
BRD里面章节很像上一个章节《决策者是如何开展一个新项目》，只不过产品的功能只有一个概念，没有考虑到细节的=>所以很多投资人都被“PPT”，“概念”骗了不少钱
主要给产品、运营、研发、财务、老板等管理层人看的，主要是决定是否要开始某个产品或者说服管理层给你的项目投资资源、人力、物力、所以写商业需求文档更像是写一个商业计划书，不同的是商业计划书是给资方看的，而你的商业需求文档是给你的管理层看的。具体的内容分为以下几个方面：

• 产品介绍（用一句话来清晰的定义你的产品=>一句话要总结用户需求分析+领域局面分析+功能构思）
• 产品的商业模式（如果你的项目值得做，那项目如何赚钱。可能是广告、可能是会员等级、可能是网上商城、可能是通过游戏...）
• 产品市场分析（宏观的行业趋势、微观市场分析等等）
• 竞争对手分析（竞争对手有那些，我们该如何和他们竞争）
• 团队（我做这样一件事情需要那些开发人员，需要那些产品人员，需要那些设计人员、需要那些运营人员，这些人员的人力成本是多少，都需要列出来）
• 产品路线图（产品路线图也叫做roadmap,版本规划是啥样的，每一个版本的大概功能模块有哪些，每个版本的时间安排是啥样的，当然不用那么细，对技术人员来说有个大概的了解就行）
• 财务计划（收入的来源和渠道有那些，如何才能达到收支平衡，产品的收益增长率是怎样的）

MRD

主要是描述什么样的功能和特点的产品（包含产品版本）可以在市场上取得成功
MRD是给产品、运营、研发等项目组人员看的，主要解决如何开始做的问题，所以侧重点主要在以下几个方面：

• 目标市场分析（包含目标市场、市场规模、市场特征、发展趋势等）
• 目标用户分析（用户分析、用户画像、使用场景、用户动机总结）
• 竞品分析（竞品分析对象、竞品商业模式、竞品目标用户、竞品运营/推广/营销策略、技术分析、竞品市场份额）
• 产品需求概况（产品定位、产品核心目标、产品结构、产品路线图、产品功能性需求、非功能型需求）

MRD是不是多余的？ 很多人认为MRD是可以和BRD合并的，辅助决策的东西。 但其实MRD和BRD重合的部分只有目标市场分析+目标用户分析+竞品分析+产品需求概况。
BRD的目的是总结出“在这个领域搞这样一个（带这样功能的）产品是有利可图的”的结论，仅此而已。 而MRD的目的则不同，要根据目标市场分析+目标用户分析+竞品分析+产品需求这些东西明确“产品的具体功能”+“产品模式”+“业务模式”+“运营模式”+“市场模式等（明确客户及市场方向”

PRD

是非常具体的产品设计方案，PRD是项目启动之前，必须要通过评审确定的最重要文档=>怎么写？这里
项目经理可以根据PRD拆分工作包，并分配开发人员;
开发可以根据PRD获知整个产品的逻辑。
测试可以根据PRD建用例;
交互设计师可以通过PRD来设计交互细节。 主要给研发部门看的，用来体现功能和性能。侧重点主要在以下几个方面：

• 文档产品名称
• 版本历史
• 目录
• 文档介绍（主要介绍文档的目的、文档面向的主要用户，读者对象、参考文献、术语与缩写解释等）
• 产品概述（从大的方向，讲讲项目的相关背景，有什么目标、有没有竞品对象？阶段性计划是什么，传递做这个需求的目的是什么？要达到什么样的目标？让项目开发人员对你的项目背景有了解，程序员知道的越多，做起项目来越有方向性。）
• 产品需求（也就是功能清单，feature list）
• 产品结构图（这个也称作脑图，用xmind或者mindmanger来画）
• 全局功能说明（UI设计会出一个UI设计规范，当然我们做产品的也会对产品中经常用到的一些公共情况做一些说明，可以作为一个全局说明）
• 产品详细功能说明（一般用用例表来进行说明，以登录注册模块为例，有流程图的话，先把任务流程图画出来，然后是用例表，用例表包含简要说明、行为者、前置条件、后置条件、功能说明、备注。功能说明一定要排版简洁、层次清晰，功能说明无遗漏）
• 非功能性需求（非功能性需求主要包含性能需求、适配需求、环境需求、统计需求、预留接口等）
• 相关文档（如果一个项目分解成多个团队，多个需求文档协同合作，比如数据埋点文档）
• 上线需求（设计什么时候OK、什么时候测试，具体的上线时间，具体一些特殊的流程需求等）

版本二：被动进行一个新项目（大部分）

一般来说，决策层会直接扔一个“新项目”下来让员工来实施，根本不需要员工自己写BRD什么的去争取

注：web后台开发

这种情况会涉及重要三个文档，分别是《软件需求规格说明书》，《概要设计说明书》，《详细设计说明书》=>点击这里
《软件需求规格说明书》搞清楚“要解决什么问题”，即搞清楚要实现的最终状态是什么？
《概要设计说明书》搞清楚“总体解决方案”，即规划出这个软件的大体结构，每个结构（模块）之间的功能和联系
《详细设计说明书》搞清楚“每个模块怎么实现功能”，每个模块对应一份

这时候，项目的开发流程应该是这样：

第一步：需求调研分析

1.系统分析员向用户初步了解需求，写需求列表

• 用word列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，
• 对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。

注意：一定要弄清对方要求具体要做什么，充分理解。把其中有疑问的，不是很清楚的，或者觉得可以改善的地方都列出来。充分讨论之后确定最终的。

2.转化需求文档，同时思考技术可行性

《软件需求规格说明书》大致包括概述、功能性需求、非功能性需求、约束等几大块。

• 概述主要描述系统的上下文、关键性功能场景、角色以及角色能够使用的功能即用例。
• 功能性需求主要描述用例、报表、接口三大类。
• 非功能性需求通常情况下有性能、安全等，视具体要求而定。
• 约束同非功能性需求一样，需要才补充，有技术选型、软硬件、使用场景、UIUE的要求，法律法规等。

注意：这个文档完成之后还要找用户确认

第二步：概要设计

首先，开发者需要对软件系统进行概要设计，即系统设计。
概要设计需要对软件系统的设计进行考虑，为软件的详细设计提供基础。
概要设计文档最重要的部分是分层数据流图、结构图、数据字典以及相应的文字说明等。以概要设计文档为依据，各个模块的详细设计就可以并行展开了
一般的重点是系统的总体设计，模块划分，模块之间的接口定义及调用关系，也可以将数据库的总体设计，表设计，以及系统的架构设计也放在概要设计文档里（E-R图）。

• 包括系统的基本处理流程
• 系统的组织结构
• 系统的模块划分
• 系统的功能分配
• 系统的接口设计
• 系统的运行设计
• 系统的数据结构设计
• 系统的出错处理设计等

需要注意的是：

• 概要设计阶段过于重视细节实现是个误区.
• 需要评价总体设计的可行性。
• 需要检查设计的模块是否完整，保证每一个功能都有对应的模块来实现。
• 需要评估开发工作量、指导开发计划（在不写详细设计的情况下）。

第三步：详细设计

在概要设计的基础上，开发者需要进行软件系统的详细设计。
在详细设计中，描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试。
应当保证软件的需求完全分配给整个软件。详细设计应当足够详细，能够根据详细设计报告进行编码。
一般包括：

• 引言，包含：编写目的，背景，参考资料，术语定义及说明
• 设计概述，包含：任务和目标，需求概述，运行环境概述， 条件与限制，详细设计方法和工具
• 系统详细需求分析，包含：详细需求分析，详细系统运行环境及限制条件分析接口需求分析
• 总体方案确认，包含： 系统总体结构确认， 系统详细界面划分
• 系统详细设计，包含： 系统结构设计及子系统划分，系统功能模块详细设计，即用结构图描述各模块的组成结构、算法、模块间的接口关系，以及需求、功能和模块三者之间的交叉参照关系

第四步：编码

在软件编码阶段，开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，
开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。　

研发人员的主要职责

从“详细设计”到“项目运行维护”这几个流程中，
主管，开发人员，测试人员的职责分配如下：

1. 首先，这时候主管级别的Leader手上已经有“需求分析说明”，“概要设计说明”这两个文档了。
2. 主管（Leader）将项目划分好模块，分配模块给相应的开发人员；
3. 开发人员按照“概要设计说明文档”，对分配到对模块进行详细设计，并编写“详细设计文档”
4. 开发人员根据自己编写的”详细设计文档“按部就班地进编码
5. 开发人员开发好一个模块就进行单元测试；
6. 等所有的模块都开发完成之后，由项目经理对所有代码进行集成；
7. 集成后的项目由项目经理部署到测试服务器上，被交由测试人员进行集成测试；
8. 测试过程中出现 Bug 就提把问题记录进行 Bug 列表中；
9. 项目经理分配 Bug 给相应的责任人进行修改；
10. 修改完成后，项目经理再次对项目进行集成，并部署到测试服务器上；
11. 测试人员在下一次的集成测试中进行回归测试；
12. 通过通过之后就部署到生产环境中；
13. 如果测试不通过，则重复上述“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试”工作。

例如：前后端不分离的公司

要构建集成测试的：

1. 单元测试阶段无问题后,提交 gerrit 进行代码 review,代码合并至 master
2. 发布平台创建新版本,jenkins 编包并绑定发布版本号
3. 提预发布审核单,测试审核,预发布,验证
4. 提现网发布审核单,测试审核,现网发布,验证
5. 期间有任何问题,发布平台都可以进行版本回滚

dev环境自测+test环境（创业公司占大多数）

1. 开发完成部署到 dev 环境自测。
2. 自测通过部署到 test 环境，发邮件给产品验收。
3. 验收通过产品发邮件给测试。
4. 测试完这个迭代的所有需求后部署到预发布进行预发布测试。
5. 预发布测试通过部署到线上，进行线上测试。
6. 线上测试通过，完成。上线成功。

例如：前后端分离开发的公司

1. 产品经理提出需求，写出PRD文档。
2. 产品经理和部门经理沟通，确定开发方案，获得时间节点（美工、前端页面、接口、前端PHP、QA）
3. 美工画图，设计PSD，前端页面切图，写css+js
4. 前端PHP和接口开发，当然接口开发时间在开发方案确定的时候已经可以开发了
5. 内测，前端PHP邮件发出内测信，比如注意事项、如何模拟数据等等，QA进行测试
6. 外测，前端PHP邮件发出外测信，部门经理把svn的分支合并，以及相关和程序有关的设置和操作，QA进行测试
7. 发布生产

优质内容筛选与推荐>>
1、PowerBuilder 数据窗口实例四(用户信息查询)
2、实验二总结
3、Cisco 交换机修改密码
4、设计模式学习总结-迭代器模式（Iterator Pattern）
5、前端放大镜效果