项目需求原型设计

项目需求原型设计的意义和目的

前言：
项目失败的大部分原因是因为那前期不充分，需求不明确，而造成了项目参与人员理解上的误差。
比较严重的情况：开发和设计无从下手。
所以项目初期的需求调研是重中之重，必须有产出物，让所有的项目参与人员在一个可视化，在一个标准的出发点，来理解和执行这个项目。

———————————————————无奈的分割线—————————————————————–
这是我整理的一个项目需求原型建立过程的结构图：

 

在实际项目生产过程中主要的参与者有以下一些角色：
1 需求方
需求提出方，这里可能是客户，也可能是产品负责人等。

2 项目管理人员
项目经理是整个项目的管理者。他负责指派任务、记录和跟踪进度、向老板们汇报…总之，项目经理的工作就是要保证整个项目处于正常状态，并能顺利完成。在小型团队中，项目经理有可能同时兼任业务分析人员。

3 需求分析人员
需求分析人员与需求方充分交流，弄清楚需求方的业务需求、流程等等信息（越详细越好），撰写出项目的功能原型说明书。
这份功能原型说明书包括：
(a) 整个项目要解决的问题和目标
示例：”动态域名是一个动态IP解析平台，它目前总共有160万会员，有2个客服人员。会员希望在这个平台上，能够注册平台提供的二级域名，和收费的顶级域名，并通过在线支付的方式进行付费。客服人员希望能即时了解到平台的注册情况，管理每个会员拥有的动态域名情况，并且能通过在线的方式帮助客户解决问题…”

(b) 针对用户使用场景的Story 或者 User Cases
这里的User Cases，应当详尽的描述出用户使用系统的每个具体场景，它将作为整个团队的一个“基础文档”，系统设计开发人员根据这些信息，才能知道程序最终要实现的效果。每个Story里面都要包含用户几乎每个操作的描述和说明，以及每个主要界面的图示（使用Visio或Axure RP Pro），也就是说，它不能含糊，而应该清晰、明确、有针对性。

示例：” User Cases 15 - 动态域名管理首页”
“客户通过登录后点击页面头部的控制面板，能够打开动态域名管理首页，自动校验当前浏览用户的身份和权限，显示出用户当前拥有的动态域名信息(参考图15-1),头部包含五个链接，分别是…,点击其中的…，页面跳转到…(参考User Cases 21)…”

功能原型说明书不涉及具体的技术细节，不包含如何实现每个场景的技术说明，不包含系统的设计内容。我们可以这样想象，假设团队中突然来了一个陌生人，他希望能了解这个团队到底在做一个什么项目，这个项目是干嘛的，实现了什么功能，我们可以将这份功能原型说明书给他，而他确实可以从这份文档中了解到他希望了解的这些信息。

这份文档不能由需求分析人员一个人独自写成，而一定要有系统设计开发人员共同参与。一方面，系统设计开发人员参与可以保证规格说明书中的内容，在技术上是可行且合理的，另一方面，也有助于系统设计开发人员业务角度了解系统，明白客户的需求。

在项目中，可能我们不会写详细的设计文档或者详细的部署文档，但一份详细的功能原型说明书确是不可缺少的。

(a) 让团队中的所有人都明白我们要构建的是一个什么东西。如果没有这样的一份清晰的功能原型说明书，就不能保证团队的所有人都一致了解团队的目标。如果没有它，需求分析人员会根据客户的描述，在自己的大脑中想象出系统应该有的样子，然后口述给开发人员，并假设开发人员完全明白了自己大脑中的想法，而开发人员则会根据自己从需求分析人员那里听到的，在自己的大脑中又试图去想象系统做出来应该是什么样子的，并假设这就是需求分析人员想要的样子…总之，每个人都会根据自己的“想象”，去猜测别人的意图。而最后当开发人员把最好的东西给需求分析人员演示的时候，通常是需求分析人员大吃一惊：“这根本和我告诉你的是完全不一样的东东…”而开发人员则会辩解：“这分明就是我根据你告诉我的要求做出来的…”

(b) 我们有了一个可以和需求方讨论的东西。这份文档可以尽早的交给需求方审阅，需求方可以根据这份文档，了解到系统做出来会是什么样子，如果不满意，需求方也可以及早的和开发团队进行沟通：“嗯，不对，在这个地方，其实我们更希望看到一个选择框，而不是用户自己填…”

(c) 它是需求分析人员与开发人员之间的一份“合同”。需求分析人员可以充分的假定，开发人员最后交付的，就是功能原型文档中所描述的样子，而开发人员也可以充分的假定，需求分析人员需要的，也是文档中所描述的样子。

值得一提的是，功能原型说明书并不会（也不应该）限制开发人员的“自由”。它仅仅包含对业务场景、系统功能的详细描述，但是不会写上应该如何实现。它肯定不会包含诸如“在这里，我们要创建类，前者用于从数据库中查询表…”，也不会包含诸如“我们将使用3层结构，并由5个主要模块来构成整个系统框架…”之类的信息。如何设计、如何实现，应该由技术负责人和开发人员讨论并确定，而没有必要写到功能原型说明书里面。

4 表现层设计人员
信息架构或交互设计人员
根据规格说明书中的Story 或者 User Cases，使用 Visio或Axure RP Pro 设计出相应的页面布局或框架图。

美工
 根据规格说明书和信息架构人员设计出的页面布局或框架图进行设计和切片。

前端开发人员
 根据规格说明书和页面布局或框架图，对美工出来的图进行切片或者根据切片出来的页面编写相应的JS脚本。

5 系统设计开发人员
技术负责人
技术负责人首先应当与业务分析人员一起撰写功能原型说明书，以保证其中所包含的内容在技术上的可行性，这同时也能保证技术负责人非常了解整个系统的业务需求。其次，技术负责人应该以功能原型说明书为基础，为整个系统设计物理架构和逻辑架构，将整个系统合理的拆分成各个更小的模块与组件，并将模块与组件的开发任务分配给开发人员。技术负责人还要与开发人员非常紧密的一起工作，与每位开发人员讨论并确定每个模块的实现方式。技术负责人应当确保整个项目在技术上畅通无阻。

开发人员
开发人员的工作就是理解自己所负责的模块与组件相关的业务需求，仔细阅读（并可能参与编写）功能原型说明书，与技术负责人紧密合作，将功能实现出来。

6 业务测试人员
 根据功能原型书对项目进行集成测试。

7 部署维护人员
后期部署维护人员，如果系统出现BUG，或者需要扩展功能。可根据原型书，了解相关功能的业务流程，如果修改会影响的其他功能。

这里有一份我写的功能原型书示例 点击下载

转载请注明出处 http://www.iisol.cn/?p=860
作者：欧拉 QQ：4465618