谢谢。哪里有使用用例技术分析客户需求的资料
这是一个很大的主题，不是很好回答。我个人认为用例方式借鉴了很多的软件需求分析思想，其中包括结构化的思想。引入用例的终极目标是：不用令用户望而生畏的数据流图、数据字典、结构化和自顶向下的各种图饰，使得设计人员和用户之间的沟通不再产生鸿沟。用户不关系繁冗的技术，我们也不应引入过多的专业技术术语。即便引入我们也应让用户看的明白、容易的理解。更为重要的是需求的目标是弄清楚到底“做什么”，不是“怎么做”。引入过多的结构化只会让我们过多的陷入到实现细节而非用户目标。
问题应该是OO方法与结构化分析方法有什么区别吧。 如果从一个软件工程的全程看，前期的信息系统规划、可行性分析、系统边界定义、业务调研、需求的整理，以及最后的测试、实施这些步骤都是类似的。 开始分为两个路线是在需求的表达开始：OO以用例表达需求，结构化以功能需求表达需求。 OO以顺序图、状态图和类图来逐步细化需求，最终实现一个迭代周期的产品，如果使用RUP作为开发过程，则用以上的几种同样的技术，每次迭代实现一个完整的周期，直至完成整个系统。 结构化在需求之后，首先以数据流图表达，再以实体、对话和功能事务三个视角表达对数据流图的实现。在三个视角之间互相验证迭代。分析之后的结果同样可以用面向对象的语言实现，只是需要重新设计类而已。 两种方法可以说互有优劣，特别是对于对客户的业务并不非常了解的系统分析员而言： 面向对象技术具有容易与客户沟通（如果你的客户可以看懂UML的表达），与程序实现之间衔接更容易的特点。缺点是每次迭代周期比较长，需要的迭代次数也比较多。 结构化方法比较难以和客户沟通，与程序实现的衔接部分设计起来比较麻烦。但由于用几个不同角度观察客观事物，因此可以在前期分析中实现小步骤地迭代，而且需要的迭代次数可能会比较少。 对于那些对客户业务非常了解的系统分析员，老实说，随便用什么方法都可以。 最后的一点，结构化分析方法比较容易达到量化管理（即对每个步骤地规范和时间做出明确的要求）的层次，而OO目前还没有进化到这个程度（所以大家才经常问，为什么我做的用例是增删改查？）。 有关结构化分析设计技术，可以参看IDEF和SSADM的相关理论。OO就没必要说了，大家每天都可以看到。
