早先在求职的时候，收到了一道题目，长相是这样的：
“从教学的角度剖析一下一份系统功能的文档该如何制作（结合自己做过的项目作为案例） ”
老衲在蛋疼了几秒后，还是默默的答出了以下若干屁话：
- 需求分析
- 需求分析的出发点与必要性
- 系统文档的制作是为了完成一个系统化的需求而引发的。
- 在开始文档撰写之前，搞清楚需求是什么才是一个好的开始。
- 除了一些老板拍脑袋，老大拍桌子的非理性情况外，严谨的系统设计通常都需要一个合理且充分的需求分析过程。
- 需求分析的方式根据公司和团队架构不同大致有以下几种分类：
- 头脑风暴会：策划内部对需求的发散性思维分析，力求以尽量多的角度和观点，对需求进行尽量全面且具有建设性的分析
- 需求碰头会：需要策划及执行部门一同列席的会议，侧重围绕系统的可行性展开讨论，可行性不高、考虑不全面的方案会在这个过程中被毙掉
- 竞品分析：有两种形式，一种是当对象系统较为复杂时，需在体验竞品后撰写评测体验报告再进行碰头分析；若系统较简单且策划方面都有体验经历，则跳过分析报告直接碰头分析，这期间也可以邀请执行部门参与，有利于分析可行性。
- 案例：
- 以我做过的3Dmmorpg端游和页游arpg为例，由于两款游戏同属rpg类游戏，所以战斗系统是该类游戏的核心玩法；而技能系统则是战斗系统中最核心的组成部分。所以在制作这两款游戏时，技能系统的需求分析是耗时最长、讨论最为激烈的一个系统功能。
- 由于技能系统与职业设定、世界观设定、数值设计、动作特效、引擎支持、双端逻辑业务等游戏的核心内容都存在关联，因此前面提到的几种会议形式都有在需求分析期间被召开。
- 需求分析的过程可以这么归纳：
- 根据已有的世界观、人物、职业设定，确定设计的大方向：如战士近战强力，法师范围伤害技能多，弓箭手射程远等概念。
- 根据属性数值设定，参考竞品效果，确定需要什么类型的战斗节奏：如3Dmmo游戏更倾向长一些的战斗节奏，页游arpg则通常节奏较短。
- 根据采用的引擎技术，确定技能的表现方式：如在3D游戏中，可以通过上下身分离的引擎技术，实现边移动边施放技能的效果。
- 根据美术人员的配备情况，分析技能表现力能做到什么程度：例如arpg项目中，美术组有成熟的3D美术成员和AE特效制作者，所以在技能的动作特效表现上，就考虑采用3转2动作+AE贴图特效的制作方案来实现目标。
- 要点：方向性限定——在需求分析的过程中各方面的人员都有可能站在自己立场上对分析结果施加影响，如果不在大方向性上加以限制，则会造成整体方向跑偏，没有重点，思路混乱等后果。
- 文档编辑
- 在明确需求之后就要进行文档的编辑了。要对系统功能进行完整的描绘，就需要以下几种文档的共同协力：
- 系统案：由于各类公司的标准文档格式各有不同，我仅列举出一些个人认为较通用的架构模块。
- 系统概述：以尽量简练的语言描述目标系统的制作目的，以及完成后要达到的效果，起到引导阅读者的作用。
- 界面设计：通过简单的绘图对对象系统的各个界面进行介绍，让阅读者对系统建立初步的直观印象。
- 体验及逻辑流程：详细描述使用系统功能时的每个步骤，以及每种步骤在各种条件、情况下的表现效果，和在不同情况下的程序逻辑处理方法。通常以文字描述辅以visio流程图的方式进行编写，力求达到让程序员按照描述就能完整编写整个系统的业务逻辑的效果。
- 相关数值设计：当系统功能牵涉数值框架的内容时，需要列举该系统使用到的数值公式，以及公式中所用到的已经定义好的变量值和需要进行新增定义的新变量。
- 数据库设定：当系统功能需要通过在数据库新建表，或在旧表上新建字段来存储系统相关的数据时，就需要列出新表的表结构，新字段的字段定义、存储格式、数值上限等。
- 脚本设定：若游戏的程序对一些数据和逻辑进行了一定程度的封装，形成了可调用的接口，就可以使用脚本语言进行脚本编辑。在这个情况下就可以考虑在新系统完成后也进行封装，将新系统纳入到脚本编辑的范围内。有脚本语言基础的策划可以在文档中提出新接口封装和在旧接口添加参数的需求。
- 资源需求：将系统功能所牵涉到的各类表现效果列举出需求，比如UI、动画、动作、特效、音效等
预配置表\数据库脚本：如果新系统有数据库的修改设定，则需要配置测试性质的预配置数据，或是一步到位配置正式数据，通过表格、数据库脚本或配置文件的形式交给程序方面，方便新功能的制作调试。
- 落实与修改
- 完成文档并交付执行部门后并不是就此万事大吉了，且不论文档质量如何，阅读者看得是否认真用心就是个问题，这时候策划还肩负着跟进与督促的工作。
- 在执行制作过程中，往往会暴露文档一些内容细节上的漏洞和欠缺。在发现后进行补充和修改也是必要的工作。
以上纯属老衲说的梦话，没人看最好，南无基督耶稣~~
| 
发表于 2014-11-5 09:50:01