1 写出用户级的需求用例。在现在的需求调研中，更多的是把客户提出的需求用流程图的方式表达。但是
在给客户讲解的时候效果不是很好，主要存在以下问题：
1）流程图不适合描述分支很多的流程。分支过多，将导致流程图十分复杂，不具有可读性。
2）流程图的受众比较少。在实际的业务业务调研中，面对的用户往往是系统的使用者，而不是作为
技术人员的维护和开发者，由于不具备相关技术背景，因此这些人在阅读流程图的时候，往往觉的眼花缭乱，更不要说提什么修改建议了。这将会使很多本应在需求调研阶段发现的问题，遗留到了用户正式使用的时候，由此带来的损失不可估量。
3）由于流程图是一个粗线条的流程描述，因此许多客户提出的细节问题，需要以另外的方式进行记录
这可能会导致在设计阶段遗漏掉。如 系统使用这在使用时的心态，等等
2 采用用例和流程的结合形式来描述客户的需求，原因如下：
1）由于用例采用自然语言描述，所以任何人可以轻松的进行阅读。
2）在一定格式的辅助下，用例描述不必受流程分支多少的约束。
3）采用自然语言描述，可以详细的描述处用户的使用细节，这些细节可能会对这个项目的开发起着
决定作用。
4）加入流程图，让具有相关背景知识的人迅速的了整个流程的全貌。如果分支不是很多流程图
还是可以画的十分简洁易懂的。
5）好的用例对后期的设计，开发，测试都是很有帮助的。甚至可以直接作为客户的培训素材
3 如何写用例
1）写用例需要结合用例图，用例图可以让用例的读者了解整个系统提供的功能，和与其他系统的关系。 这样可以使读者的在阅读用例时，在一个限定的范围内思考问题。
2）用例的格式大体上可以分为前提条件，主成功用例，扩展。当然，作者可以丰富用例的格式，这里
仅仅是一个最简单的框架。
3）由于是在需要阶段的用例，因此用例尽量用轻松的语调来写用例。你甚至可以把用例当作一片散文来写。这里需要注意的是，在写用户级用例的时候需要把系统当作一个黑盒，不要去描述系统内部是如何工作的
此时作者一定要以一个客户的角度来考虑问题，来描述系统。
4）用例可以也可以想写函数是的写一些通用性比较强的模块，以便其他用例可以复用。如用户身份验证模块。
5）在写用户级的用例时候，对用户使用系统的细节需要描述，如使用者的心态。这可能决定着用户易用度的设计。
6）在写用例的时候一定需要用完整的主谓宾来写。及谁，在做什么
4 用例描述仅仅是对用户需求一个梳理的过程，我们还需分析出其中的主要实体，和他们的关系，在分析
的过程中可能会对产生新的疑惑，可以和客户及时沟通。当然在设计的过程中，也可以继续和客户沟通
但是，客户方不一定能够随时协调到合适人员，这将导致项目的推后。因此，在集中讨论期间
多做一些分析，乃至设计（原型的设计），可以大大减少后期的工作了量，提高客户满意度。用例，分析，和原型 可以是在需求期间一个小的迭代周期。
5 在讨论需求的时候，最好是以集中会议的形式进行，参会者应为 相关领导，系统将来的实际使用者
，技术把关人员。为什么者样作，和如何利用其中的微妙关系，需要大家自己去体会，去琢磨。呵呵