（多年前的读书笔记，从ITEYE迁移过来）
在选择“需求游戏”这个标题名称的时候，我犹豫再三，但还是用了这么一个标题。这并不是说在做需求捕获和分析时持有游戏的态度（当然这也是很不应该的），而是说我们在做需求捕获和分析时用到的一些方法很像是在做游戏，形式轻松，效果也不错。
在上一篇文章里我们提到过“一个软件或项目起源于用户的一个主意”，在多数时候用户的主意是笼统的、模糊不清的、不完整的。那么，我们作为软件开发者就有义务帮助用户挖掘所有关注点、细化他们的主意、弄清细节、评估需求并排列优先级。
首先我们要在项目开始的时候最大限度的挖掘出客户的需求，当然我们不可能获取全部的需求，也不可能完全正确的获取每一个需求。但是随着迭代开发持续进行，我们会从用户那里得到反馈，并根据用户的反馈信息来调整我们的需求列表，所以 这些问题都会被慢慢解决掉 。我们有三种方法可以获取需求： Bluesky brainstorming,Roleplay ,Observation .
- Bluesky brainstorming ----无限制头脑风暴，对软件有需求的所有人员都开动脑筋，去想我需要软件为我做什么？希望软件能满足我什么样的功能？每个人都应该有平等的发言权，都能说出自己的想法。而作为开发人员的我们，则记录所有能收集的想法，不管想法是不是切合实际。因为我们在开始的时候需要了解所有的潜在需求，而我们的项目或软件依然会基于最核心的需求进行开发。什么需求最核心？这将由我们的客户自己来决定！然而，有时候头脑风暴的效果不是很理想时怎么办。比如，用户不愿意去想自己需要软件来做什么？或者不习惯这种方式，或者确实想不出来....那么这就是下边这两种方法登场的时候了！
- Roleplay------ 角色扮演，如果你的用户觉的很难去描述“他需要软件做什么、如何去做”.那么就用角色扮演把它演出来吧，你扮演软件的角色，而用户就试着命令你做他们想要做的事情。通过这种更形象、直观的方法，获取到用户的需求。
- Observation -----实地观察，有时候了解用户将如何使用你的软件的最好方法就是观察他们的日常工作，找出来在什么地方软件可以切入。第一手的资料是最真是、最准确的，而通过实地观察我们可以获取详细的第一手资料。对于同一个活动我们要多观察几个不同的人，来获取通用的信息，而不受个人的行事风格的影响。同时我们也能通过”实地观察“，获取在头脑风暴或角色扮演中遗漏的细节或约束。
然后我们就需要把获取的需求整理一下，为什么这些需求还需要整理呢？这是因为我们获取到需求是客户的简单描述，可能不完整或者不是很准确。另外我们也需要一种技术来对所有的需求按统一的格式进行编写和命名，这也有利于我们对需求的管理，这就是User Story显身手的时候了：User Story（由两部分组成标题和描述）
关于User Story有很多的书籍和资料可以参考，我在这里就不详述了。只列出书写User Story时有需要遵守的一些准则。
- 每一个User Story只描述一件软件为用户做的事情.
- 使用用户可以理解的语言，不要使用专业的技术词汇.
- 由户书写或以用户的视角书写.
- 简短明了，不要用太长的文字描述。如果不能用简短的文字描述的话，就是这将其进一步的拆分.
总之，User Story应该从用户的视角描述，使用户和开发者都能很好理解。User Story定义了“What the customer need?”，而需求评估则定义了“When we can deliver them?”.关于如何做需求评估将在下一篇文章中说明。