项目需求原型设计.docVIP

项目需求原型设计 项目需求原型设计2010/10/24 12：45 P.M.项目需求原型设计的意义和目的 前言： 项目失败的大部分原因是因为那前期不充分，需求不明确，而造成了项目参与人员理解上的误差。 比较严重的情况：开发和设计无从下手。 所以项目初期的需求调研是重中之重，必须有产出物，让所有的项目参与人员在一个可视化，在一个标准的出发点，来理解和执行这个项目。 这是我(作者：欧拉，QQ：4465618)整理的一个项目需求原型建立过程的结构图： 在实际项目生产过程中主要的参与者有以下一些角色： 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个主要模块来构成整个系统框架…之类的信息。如何设计、如何实现，应该由技术负责