上一节我们对需求进行了评审，经过对细节的沟通之后，产品对需求进行了修改和明确。
-
网站需要对SEO友好，具体可参考搜索引擎站长白皮书，另外需要给搜索引擎提供xml格式的sitemap文件。
-
博客需要提供搜索功能，搜索范围限定在标题，分类，标签上。博客每天的增量数据为10篇文章。
-
能够根据某个分类查看所有关于这一分类的文章，分类没有层级的关系，只有一级分类。一篇文章只能属于一个分类。
-
访问首页需要能看到有新到旧的文章列表，以便于查看最新的文章，作者可以通过设置置顶某篇文章，可以同时置顶多篇文章，多篇文章置顶时，排序规则为从新到旧。
-
列表分页需求，针对首页，频道页，标签页，都需要提供分页需求，每页展示10条文章。列表页展示文章是，需要展示摘要，默认为文章的前140个文字。
-
需要能够通过RSS阅读器订阅博客的文章, 可参考RSS规范
-
要能够对某一个文章进行评论，评论不需要支持盖楼的模式，只需要在文章页面展示评论。页面侧边栏也需要能展示最新评论。
-
能够配置友链，方便与网友进行链接，一个页面中展示即可，不需要分类，但是需要能够制定某个友链的权重，权重高者在前面展示。
-
博客后台需要登录后方可进入，目前没有多用户需求，以后可能会有，要考虑扩展。
-
能够创建分类和标签, 一篇文章只能属于一个分类，但是可以属于多个标签。标签和分类都没有层级关系。
-
作者在后台需要设置文章标题，摘要（如果为空则展示文章前140个文字），正文，分类，标签。不需要实时保存。文章格式默认为Markdown，开发周期够的话，增加可视化编辑器。
-
导航只是分类，默认展示在顶部。同时每篇文章都需要有面包屑，以告知读者目前所处问题，面包屑组成如下:首页>文章所属分类> 正文。导航的顺序作者可以进行设置权重，权重高者在前。顶部最多展示6个分类，多余的分类展示到底部。
-
作者更新后，读者能够收到通知(暂时不开发)
功能分析的目的是从产品经理所提的需求中提炼出这个系统有哪些功能点，最终落实为功能列表/清单，可以按照模块，或者按照相关功能来划分，进而再进行任务分配。
从上面最终已经确定过的需求列表中，我们可以逐条的列出，博客系统所需要的功能点有哪些。
- 后端渲染页面，对SEO友好；
- 提供sitemap.xml文件，输出所有文章；
- 搜索功能，能够针对标题，分类，标签进行搜索；
- 根据分类、标签、查看文章列表；
- 文章可以设置置顶，可以同时多篇文章置顶；
- 首页（列表页）需要展示文章摘要，140以内，可以作者填写，或者自动展示文章前140个字；
- 首页（列表页）需要分页展示，每页10条；
- 提供rss页面，根据RSS2.0规范，输出内容；
- 文章页面支持评论，不需要盖楼，侧边栏能够展示最近评论；
- 评论模块需要增加验证码功能，避免被刷；
- 后台能够配置友链，所有友链在一个页面展示；
- 用户可以通过用户名密码登录后台，之后才能够创建文章；
- 需要考虑多用户的扩展情况，多用户时需要多分类，标签，文章，友链进行隔离；
- 分类增删改查——需要字段id，名称，创建日期，创建人，是否置顶导航，权重；
- 标签增删改查——需要字段id，名称，创建日期，创建人；
- 文章增删改查——需要字段id，标题，摘要，正文，所属分类，所属标签，状态（发布，草稿，删除），创建日期，创建人；
- 侧栏模块用来展示侧边栏需要的数据，需要字段id，类型，标题，内容，创建日期，创建人；
经过上面的分析，我们得到了足够细节的功能列表，有了这些细节的描述，技术人员就能够确定要做什么样的功能出来。不过这个时候，需要有人来做一个整体的梳理，把相关的功能整理为一个模块，同时需要抽象出实体。
在早些时候做软件开发，都是需要先画出ER图（Entity Relationship 对象关系图），理清楚每个模块之间的关系。然后再做系统设计，画出时序图，理清每个模块之间的交互逻辑。这些都是通过UML工具来做，当然还有最初的用例图。
现在理论上来讲产品经理会整理出所有的用户需求，输出PRD(产品需求文档）给开发人员。开发人员需要从中提取出实体，以及各模块之间的交互关系。
我们可以通过思维导图来梳理下我们的功能点。
下一节我们来具体操作。