很多的项目在需求分析上耽误的时间很长，动辄两三个月，这样做并不能带来更好的结果，留给需求实现的时间往往都非常紧迫，反而是造成项目deliver周期延长，风险更大。用户故事和快速原型，讲究的都是一个快字，都是可迭代的，讲究的是先make things happen，再improve.
User Story 从结构和表现形式上，实际上是Use case的变种，为啥又出来个User story, 应当要反方向思考一下，
1.极限编程需要快速地、大量频繁的与用户沟通、需求分析，需要一种容易适应用户理解的、白话方式的结构表现形式，容易得到用户的快速理解和双方确认。
2.迭代开发，需要一种切割千头万绪的需求为一个个可独立分配的需求单位的策略、原则、手段、形式。只有划分成可独立分配合适粒度的单位，才能谈的上工作量的可估算、优先级的划分、合理的制定计划、task的合理分配、端到端的测试、单位性质的可交付。
3.测试驱动，需求的编写无法转化成有效的test case，总体上来说，不能算是合理的需求，要想达到test case中要求的可测试的需求，则上下文、输入、输出的必要描述，不可缺少。
从上可以得出一个User story的结构或者模板：
1）上下文背景
2）用户要达到的目的，价值.
3）故事细节
4）前置输入
5）判断故事是否完成实现的输出
User story, 的前提是用户能够tell you a story, 不管这个story是粗糙的，还是精细的。但如果涉及到大量的可视化表现手段，才能在此基础上进一步说清楚的，往往需要原型来表示，比如犯罪嫌疑人画像，用户先给出一个不着边、不着调的罪犯描述，搁着一般人都不知道说什么，如：个子不高，嘴角有点歪，鼻子短，胖胖的，但画像专家，先快所素描一个人头像，用户看后说，不太像，那个人的眼晴比这个大，还有个小胡子，专家又修改了一下，用户在看看，这样在较短的时间，一个相对比较接近的描述就出来了。
白板和power point只是有限的可视化沟通手段，最好的还是HTML原型，应当是动态的可交互的，从链接、弹出、根据不同逻辑的页面跳转、逻辑判断都尽量的表现出来。
原型快要快在两个方面：
1）直观，半天说不清楚的，言语难以表达的，一个界面就搞定了，用户会说：“就是这样，这就是我要的"。
这需要分析人员就是原型制作人员，像上面的画像专家一样，即能分析，又能画像，而且画得像。不能说原型是出来了，但很丑，别别扭扭的，距离用户的想法太远，还不如不用这种方法，耽误时间得不偿失。
2）能够快速的做出原型，并且易于修改
制作原型的时间，不能太长，一两个星期，是适度的，当用户有不同的意见时，最好能当场修改，如果团队中的人多利哆嗦的，十天半个月搞不出个结果，还是不要搞。
很多的分析人员，不会做原型，所以快速原型的手段就用的很少，其实快速原型在很多的项目上都非常实用：
1）用户是分布式的，有的在美国，有的在印度，有的在国内，沟通都是通过IM、电话、邮件的方式，快速原型很方便。
2）XP要占用用户的很多时间，这一点在国内，不一定实用，如果用户不能抽出大量的时间参与其中，原型的优势就现出来了。
3）User story不会在界面交互需求、用户体验上的描述细节，而是依靠快速的实现，然后用户在可使用的交付系统上提出迭代修改的建议，在花一些不必要的，可以避免的时间去修改。所以时间还是要还回来的，不见得就是节省时间。对于新上马的网站项目等不适用。
User story 和 Rapid prototype, 都是方法，作为方法论的使用者，自然会汲取长处，灵活掌握，而不是亦步亦趋，照搬照抄，我最不喜欢听的就是"书上就是这么说的".
两者其实是互补的关系，User story由于XP的理念支撑，又从Use case中变种，基础很扎实，但现在随着Web2.0的奉行, Ajax, CSS, XTHML，大量的javascript framework如jquery, EXT, prototype等，在短时间内搞定一个原型，不是难事。
现在国外的很多的创业团队（Freelance)，都可以做出一步到位的原型，团队中的人擅长前端设计、开发，Ajax, CSS, XTHML，web standard, cross browser不在话下，Flash, Flex, Fireworks 等RIA技术也是有丰富的项目经验，很多人用flash, fireworks做的原型，非常棒。以用户为中心的、注重用户体验、准确把握用户业务的分析设计是他们的核心竞争力。
未来这种做法会进一步延伸到普通的项目团队中，用在合适的场景，它会更快：
1）CSS+XHTML+Javascript，遵循标准的一步到位的原型，需求分析完后，直接就是可开发的界面了，对那些不擅长前端开发，只会写Java累的团队，无疑节省了非常可观的时间。
2) User-centric, 将用户体验的部分需求包含在内，避免后期的rework.
3) 相对User story, 更容易理解和分工、开发，直接实现，而不是思考如何表现。
前提是：
1）要的不是美工，是分析人员要会前端技术。
2）它不能替代User story，它的目的是快速开发。复杂的逻辑、流程，仍然需要文档和文字描述。
3) 一定不要使用原型生成工具，他们生成的原型，不能用来做开发的。Editplus, 手写页面，搞定一切。
我的项目中就是这样做的，如果你处于On ready状态，就不难，页面模板，CSS库，javascript框架，都准备好了，就缺少一个有思想的组织者了。
需求分析的快，准，是快速原型的目标，一步到位，不丢弃原型，是原型设计的境界。