开发或者做一个项目，是要有一个需求过来的，而不是无缘无故的，启动一个项目，或者推动整个项目进行下一步迭代。这个需求可能是根据用户反馈增加的，可能是老板提出来的，也有可能是产品经理提出来的，但是无论是什么样的需求，重要程度如何，最终到开发人员这里都需要转化为功能点——可以被量化的功能点。因为产品经理或者老板需要知道，这个需求多久能够开发完成，多久能够上线让大家使用。
因此，就有了软件工程中的几个步骤——需求分析、软件设计和软件测试等。对于开发人员来说，需要对需求进行评审，这是为了避免产品经理提出无法实现的需求，最终导致需求被迫变更或者项目流产。
在需求评审之后，开发人员把需求转换为系统的功能点，然后评估开发时长。最终需要评估出来一个可把控的开发周期给产品经理或者项目经理，同时也给开发团队定下截止时间，避免出现无效的行为，比如某开发同学觉得时间还很长，就开始在一些小的问题上死磕，力求得到一个完美的答案等等。
做功能分析这个事，往往需要有独立项目开发能力的人来做，这样的人一般经历过几个项目的开发周期，经历过各种各样的困难与挫折，因此能够很好地把控开发的各个阶段，处理开发过程中出现的各种意外，比如需求变更或者人员变更等情况。而刚刚入行的初级工程师或者是没有独立承担过项目的工程师，很难在重要的项目上被委以重任，因为企业做项目是要盈利的，是要实打实的实现的操作，这跟个人写几个小系统是截然不同的。所以对于新人来说最重要的事是自己能独立完成某个项目，去涉足项目开发的各个阶段，为以后独立承担项目开发储备经验。在现实社会或商业社会中也是如此，用事实说话。而对于想要独立承担项目的人来说，能够分析清楚需求是至关重要的，否则那便是：差之毫厘失之千里。
有些开发人员会在社交圈上吐槽说又要跟产品经理开撕了。这其实是一个正常的情况，工种不同，责任不同，各司其职，在正常不过。产品经理梳理用户需求，开发人员来实现。招聘经理在做需求时不会考虑系统实现的问题，满足用户需求为第一位，因此开发人员在接到需求的第一件事就是考虑各个需求点是否能够实现，以及实现起来的复杂度（工期），然后反馈给产品经理。这个时候开发人员经常犯的一个错误是，以系统好实现、好维护为由而拒绝一些需求。这是一个错误的认知，系统的实现应该满足用户需求为第一要务。试想一下，不能满足用户需求的产品怎么会留得住用户呢，没有用户的系统，维护它就没有必要了。在工期紧、任务重的情况下，往往需要排出个一、二、三期来，划分需求优先级，分期完成。
所以优秀的工程师应该是尽量满足用户需求的前提下，构建一个稳定、容易维护、容易扩展的系统。但这也不意味着一味地满足产品的需求，有时产品的构想出来的需求，可能是脱离了技术实现的，比如说在移动端的网页中，拿到所有用户的网络状况——是WIFI还是3G、4G等等信息，这是一个只能实现一半的需求。所以，开发人员或者项目负责人要及时地告诉产品经理，哪些需求在实现时会基于现有的技术打折扣，以避免在后期进行无效的努力或者返工。
对于一个优秀的工程师来说，把握住需求很重要，同时也需要像产品经理那样去思考用户的需求，也需要像工程师那样去考虑功能的实现等问题。需要不断去权衡、尝试和总结。
需求文档
需求文档是产品经理跟开发人员交流的必不可少的东西，很多东西如果不落实到文档上，出了问题很难追溯。尤其是对于企业开发中长期开发的项目来说，一个项目可能由无数个开发人员参与的，所谓铁打的项目流水的开发，文档是新人在接手项目时必须阅读的，另外，交流基本靠争吵的方式也很容易丢失信息，还会出现开发后期不知道需求是谁提出来的这种尴尬问题。所以无论是什么需求，无论是需求变更还是追加，都要尽量落实到文档上。
下面就是博客开发的需求，后面需要实现的也是博客这样的一个项目。
介绍
博客（英文：Blog，为Web Log的混合词），意指log on the web，即在网络上记录，是一种由个人管理的网站或在线日记，可以张贴新的文章、图片或者视频，用来记录、抒发感情或分享信息。博客上的文章通常根据张贴的时间，以倒序方式由新到旧排列。许多博客作者专注评论特定的课题或者新闻，其他则作为个人日记。一个典型的博客结合了文字、图像、其他博客或网站的超链接以及其他与主题相关的媒体，能够让读者以互动的方式留下意见，这些是许多博客的重要要素。大部分的博客内容以文字为主，也有一些博客专注艺术、摄影、视频、音乐和播客等主题。播客是社会媒体网络的一部分。——维基百科
播客也是一个与他人分享和交流的平台，通过书写自己的想法、学习技巧和工作经验，来结识不同领域的读者，交流和探讨技术、思想、文化或者公司等话题。
需求描述
简单来说，播客系统分为两部分：读者访问部分（用户端）和作者创作部分（作者端）。
用户端的需求如下：
1、要能够通过搜索引擎搜索到博客内容，进而来到博客；
2、可在博客中进行相关关键字搜索，然后展示出文章列表；
3、能够根据某个分类查看所有关于这类的文章；
4、访问首页时，需要能够看到由新到旧的文章列表，以便于查看最新的文章；
5、能够通过RSS阅读器阅读博主的文章；
6、要能够对某一篇文章进行评论；
7、能够配置友链，方便与网友进行链接。
作者端的需求如下：
1、博客后台需要登录方可进入；
2、能够创建分类和标签；
3、能够以Markdown格式编写文章；
4、能够上传文章配图，要有权限版权声明；
5、能够配置导航，以便引导读者；
6、作者更新后，订阅读者能够收到通知。
上面就是一个简单的需求描述。从这个需求描述上看，无法确定需要做个什么样的东西，因为很多细节没有说到。这时如果技术人员尝试以自己的理解去开发一个博客系统，可能会导致跟产品经理或者跟用户想要的不一样，从而无功而返。
下面的需求评审和分析阶段就是帮助产品经理整理清楚需求，让技术人员在开发时能够知晓具体的需求点是什么，需要开发哪些功能，如何设计系统、建立模型等。
需求评审与分析
对于有经验的产品经理来说，在做任何需求的时候，都会计划得足够的细致，落实到一个功能点。更好的情况是能够出原型稿，之后可以通过原型来对每一个功能点进行逐一核对。
对技术来说，评审的目的有如下三个：
1、明确所有的需求点，避免出现理解上的歧义；
2、确认技术可行性，避免延期或者后期再修改需求；
3、确认工期，是否需要分期开发。
博客需求评审
针对产品经理提出的每个需求，我们都需要仔细核对，尽量避免歧义或者沟通不畅。下面我们来逐条分析。
用户端部分
1、要能够通过搜索引擎搜索到博客内容，进而来到博客；
从技术上来说，这个属于SEO的部分，只需要提供sitemap（网站地图）到搜索引擎即可。同时，页面需要对爬虫友好。需要跟产品经理明确的事情是，技术上无法保证一定能够通过搜索引擎搜索到博客，这最终取决于搜索引擎。
2、可在博客中进行相关关键字搜索，然后展示出文章列表；
需要明确搜索哪些字段，比如标题、标签和分类等。如果需要全文搜索，就需要考虑数据量的问题。如果数据量大，就不能直接使用Mysql的LIKE语句，需要增加全文搜索相关的技术栈，比如引入Whoosh、Solr或者Elasticsearch这样的搜索引擎。
3、能够根据某个分类查看所有关于这类的文章；
对于分类，要明确的是有没有子分类这样的需求，如果有子分类，那么子分类的文章要不要在父分类下展示，以及子分类的层级有没有限制。
4、访问首页时，需要能够看到由新到旧的文章列表，以便于查看最新的文章；
首页排序从新到旧没有问题，是否有特例，比如某些文章必须顶置。另外，是通过分页的方式展示列表还是页面可以不断下拉加载的方式。每个页面/每次加载多少条数据。
5、能够通过RSS阅读器阅读博主的文章；
需要提供RSS格式数据的页面。
6、要能够对某一篇文章进行评论；
是否需要前台（用户端）查看所有评论的页面。
7、能够配置友链，方便与网友进行链接。
友链在前台如何展示，是单独的页面还是一个列表页。
作者端需求
1、博客后台需要登录方可进入；
是否有多用户登录的需求？如果有，那么用户之间的权限如何划分？
2、能够创建分类和标签；
跟上面的问题一样，是否有多级分类和标签的情况，如果有，需要明确父级分类或者标签是否包含子级所关联的内容。
3、能够以Markdown格式编写文章；
作者编写文章时，有哪些是必填的，在网页上编写是否需要实时保存。
4、能够上传文章配图，要有权限版权声明；
版权声明具体表现是什么？
5、能够配置导航，以便引导读者；
导航是否是指分类？是否包含标签？需要产品经理给出明确的需求。
6、作者更新后，订阅读者能够收到通知。
在博客的整个需求中，并没有需要读者登录的账号系统，无法对读者进行实时通知。但是可以考虑增加邮件订阅功能，通过邮件的方式通知读者。此时需要明确邮件的内容格式，以及作者是否需要控制发送邮件的开发。
评审之后
其实在实际的需求评审中不需要每个需求点都抛出问题来确认，因为大部分都是专业的产品经理，知道用户想要什么的同时，也知道技术能实现什么。这主要是基于过往的经验。所以，这类的产品经理会给出很明确的需求，配合起来会比较默契。但是无论对于什么样的产品经理，所以的需求都需要当场讲解一下，对于不太理解的需求，需要反复讨论确认。
所有开发人员都有必要理解产品经理的需求，这个需求点的作用以及背景，通过消化需求点来进行开发，而不是单纯地把需求文档翻译为可执行的代码。
经过这么一轮的问答，产品经理也会在产品文档上更加明确自己的需求点，最终的描述应该包含了开发人员对所提问题的解答。
另外有一点需要注意的是，对于产品经理自己也不是特别明确的功能点，比如技术方面的，开发人员应该能够根据以往的开发经验以及技术积累，给出合适的建议，在满足同等功能的情况下，让技术上实现起来更加容易些。但是，需要记住的是用户需求是第一位的，技术复杂度是第二位的。
在这之后，我们应该能得到一份详细的需求列表。下面我们将对需求进行拆分，把需求转为技术上需要实现的功能点或技术点。
功能分析
需求列表
用户端部分
网站需要对SEO友好，具体可参考搜索引擎站长白皮书。另外，需要给搜索引擎提供XML格式的sitemap文件。
博客需要提供搜索功能，搜索范围限定在标题、分类和标签上。博客每天的增量数据为10篇文章。
能够根据某个分类查看所有关于这一分类的文章，分类没有层次的关系，只有一级分类。一篇文章只能属于一个分类。
访问首页时，需要能看到由新到旧的文章列表，以便于查看最新的文章。作者可以设置顶置某篇文章，也可以同时顶置多篇文章。多篇文章顶置时，排序规则为从新到旧。
列表分页需求。针对首页、频道页和标签页，都需要提供分页需求，每页展示10篇文章。列表页展示文章时，需要展示摘要，默认为文章的前140个字。
需要能够通过RSS阅读器订阅博主的文章，具体可参考RSS规范。
要能够对某一篇文章进行评论。评论不需要支持盖楼的模式，只需要在文章页面展示评论，在页面侧边栏，也需要能展示最新评论。
能够配置友链，方便与网友进行链接。这在一个页面展示即可，不需要分类。但是需要能够指定某个友链的权重，权重高者在前面展示。
作者端需求
博客后台需要登录方可进入。目前没有多用户需求，以后可能会有，要考虑可扩展。
能够创建分类和标签，一篇文章只能属于一个分类，但是可以属于多个标签。标签和分类都没有层级关系。
作者在后台需要设置文章标题、摘要（如果为空，则展示文章前140个字）、正文、分类和标签。不需要实时保存。文章格式默认为Markdown。开发周期够的话，增加可视化编辑器。
增加文章配图时，图片需要增加水印，其内容为网站网址。
导航只是分类，默认展示在顶部。同时每篇文章都需要有浏览器路径，以告知读者目前所置权重，权重高者在前。顶部最多展示6个分类，多余的分类展示到底部。
作者更新后，读者能够收到通知（暂时不开发）。
功能点梳理
功能分析的目的是从产品经理所提的需求中提炼出这个系统有哪些功能点，最终落实为功能列表/清单（可以按照模式或者相关功能来划分），进而在进行任务分配。
从上面最终确定过的需求列表中，我们可以逐条列出博客系统所需要的功能点有如下这些：
后端炫染页面，对SEO友好；
提供sitemap.xml文件，输出所有文章；
搜索功能，能够针对标题、分类和标签进行搜索。
根据分类和标签查看文章列表；
文章可以设置顶置，可以同时设置多篇文章顶置。
首页（列表页）需要展示文章摘要，140字以内，可以作者填写，或者自动展示文章前140个字。
首页（列表页）需要分页展示，每页10条。
提供RSS页面，根据RSS2.0规范输出内容；
文章页面支持评论，不需要盖楼，侧边栏能够展示最近评论；
评论模块需要增加验证码功能，避免被刷；
后台能够配置友链，所有友链在一个页面中展示；
用户可以通过用户名和密码登录后台，之后才能创建文章；
需要考虑多用户的扩展情况，多用户时需要对分类、标签、文章、友链的操作权限进行隔离；
分类增、删、改、查——需要字段id、名称、创建日期、创建人、是否顶置导航以及权重；
标签增、删、改、查——需要字段id、名称、创建日期和创建人。
文章增、删、改、查——需要字段id、标题、摘要、正文、所属分类、所属标签、状态（发布、草稿或删除）、创建日期和创建人；
侧栏模块用来展示侧边栏需要的数据，需要字段id、类型、标题、内容、创建日期和创建人。
模块划分
经过上面的分析，我们得到了足够细化的功能列表。有了这些细节的描述，开发人员能够确定要做出什么样的功能来。不过这个时候，需要做一个整体梳理，把相关的功能整理为一个模块，同时抽象出实体。
有了足够明确的需求后，下一步需要做的就是建模了。建模的意思就是：建立系统模型以及数据模型，这里需要提到一门语言UML（统一建模语言）。这是以前非常常用的一种建模方法，通过UML画出用例图，整理用户需求；然后画出序列图，整理出系统各个模块的交互逻辑；最后会用这些模型来实现。另外，针对数据模型部分，一般会先画出ER图（Entity Relationship Diagram,实体关系图），理清楚每个数据模型之间的关系。好的ER工具可以直接帮你生成建表语句以及模型代码。
从理论上讲，产品经理会整理出所有的用户需求，输出产品需求文档（PRD）给开发人员。开发人员需要从中提取实体以及各种模块之间的交互关系。
我们可以通过思维导图来梳理功能点，然后拆分为一个个独立的任务并将其放到Trello的card上或者jira的任务中，这会方便我们管理开发进度。
模块划分
现在我们知道一个需求需要经过产品经理跟开发人员的沟通或者PK之后，才能确定下来的，有了完整的需求之后，接下来就是做功能分析、技术型以及架构设计。
下面就是抽取实体和划分模块，这里可以考虑使用UML工具进行建模。
文章：
id、标题、作者、分类（多对一）、标签（多对多）、摘要、正文、状态、发布时间
分类：
id、名称、状态、作者、创建时间、是否顶置导航
标签：
id、名称、状态、作者、创建时间
友链：
id、网站名称、链接、作者、状态、创建时间、权重
评论：
id、文章（多对一）、用户名、邮箱、网站地址、内容、创建时间、作者
侧栏：
id、标题、类型（最新文章/最热文章/最近评论）、内容、创建时间、作者
到此，实体及其关系就梳理清楚了。可以看到，文章是所有实体的中心。我们可以通过在线的ER图工具，把结构画出来。
与参考书作者不同，我自己使用的是ERwin Data Modeler，这是下载链接https://getintopc.com/softwares/erwin-data-modeler-free-download/
（由于软件正在下载中，这里的ER关系图后面更新会补充...）
建立好实体了接下来便是模块划分
划分的好处是让系统结构更加清晰，模块和模块之间相互解耦。同时对于多人协作的项目来说，可以分配一个独立模块进行开发。
首先，对于网站功能整体来说，分为用户端和管理后台。这算是一个大的分类。
用户端的功能又可以分为4类。
内容模块：首页、分类列表页、标签列表页和友链页。
评论模块：用户添加评论、展示评论的部分。
侧栏模块：博客侧边栏展示的内容。
功能模块：sitemap页面和RSS页面。
管理后台的功能分为以下两类。
用户管理：登录、权限控制
内容管理：分类、文章以及侧边栏等内容的增删查改。
实际上，从实际出发的角度来看，管理后台在进行模块划分或者说任务划分时，还可以进行横向或者纵向分割。
横向是指按照模型层、页面层、业务层来划分任务，每个模块是独立的层。这种方式的好处是每一层只涉及当前的操作，比如：模型层，都是在做跟数据库打交道的工作。但是缺点是相互之间有依赖，需要先行定好接口才能开发。
纵向是指把文章管理的部分——模型、业务和页面划分到一起，侧边栏管理的部分——模型、业务和页面划分都一起等，即按照业务的方式来划分，而非按照层的概念来划分。这种方式的好处是没看内容相互独立，不会有依赖的情况产生。当然，其缺点是每个模块都需要有人从前到后进行开发。
我们通过思维导图来看看最终的结果，如图：
上面这张图可以从这个链接获取：http://t.cn/R14lkXe；密码：GTDL
到此为止，我们通过对需求的评审和整理，最终得到了明确要开发的功能，然后对功能进行了实体抽取以及模块划分。后面的工作便是在已经清楚要开发什么功能之后，如何进行技术选型。好的技术选型不仅能够提高开发效率，而且也能够降低维护成本。以及开发人员怎么去开发实现项目的过程了。
（正在更新中....本博文是基于：胡阳编写的《Django开发企业开发实战》一书需求编写）