最狂热的用例编写者也承认，用例对客户与需求人员都是一种heavy的相互折磨。
    客户看用例时总要收摄心神来阅读整个交互的流程，还有那些该死的扩展流异常流，没经过程序员专业抽象训练的客户，对着这些伪代码一般的情景脚本，刚开始的一两个还好，看多了，就是白天也能睡去。客户只是看都如此了，负责写的人当然也不会好过。

    但heavy的工作总有heavy的好处，否则早被唾弃于舞台的背面。
    在用户的角度，用例比模棱两可的功能点描述要清晰，也更直白于系统的价值。
    在开发团队角度，RUP的核心方法论之一---用例驱动的口号，明白人自然明白他的妙用。
    设计人员有了新的设计手段：“用时序图分析用例的实现，在描述过程中确定构件或类，分配它们的职责和方法”，通过对用例覆盖率的追踪，将需求与设计之间的信息损耗这个famous problem大大降低。
    测试人员和文档人员，更可以直接把系统用例笑纳为《测试用例》和《用户手册》。

    来到亿迅后，被这里的用例文明给震住了，每个项目的软件规格说明都是屯门清一色的几百页的前景，用例规约，业务规则，词汇表，补充规约组成.......难得有情郎啊。
    昨天又看到了一批新的用例诞生，但实在有好些明显的不足啊，忍不住旧事重提的记下一批经典的错误。不过.....只要能和客户达成需求共识，就是一份好的用例了，也不用花太多时间在学术性的讨论上。

    1.客户没有能力阅读用例
      如果客户实在没办法撑住困意看完用例的细节，即使草草签了名，得不到用户真正确认的用例，依然无法用来驱动设计和测试。
      解决方法：放弃编写用例，改回用户容易看的传统方式。

    2.团队没有能力实现用例驱动
      如果开发团队在设计与测试时，根本不依照用例细节驱动，那用例对开发团队就只是个摆设，花瓶。
      解决方法：对设计、测试人员进行用例驱动的培训，如果事不可为就干脆放弃，怎么省事怎么做。 

    3.在用例中描述系统内部工作
      经典错误，开发人员把用例当作设计文档来写，如“系统将销售信息写入数据库”，实际上应该写的是“系统记录销售”。
      解决方法：站在客户的角度，把系统视为黑盒，删除所有内部设计描述。

   4.在用例中描述界面
      另一个经典错误，不说了，如果在意用户信息包括了姓名和密码，可以在词汇表里记录，而用例写成--显示<用户信息>。

    5.在用例中越出系统边界描述整个业务流程
      要建立的系统只是整个业务流程里的一部，善良的需求人员为了大家清楚来龙去脉，将系统外的处理步骤也写进了用例的情景。
      如：
      1.用户去营业厅开户
      2.用户拨号接入
      实际上去营业厅开户不属于宽带接入认证系统的职责。
      解决方法：开户的描述应该放到用例的前置条件中。前置与后置条件是说明系统边界外的业务流程的好地方。 

  6.过多的用例，让人晕菜
      国外的惯例，一个用例一般有半个以上人月的开发量。
      解决方法：
      1.开户，销户这样的CRUD型用例可以合并成一个管理用例，以四个主场景分别表达。
      2."老板问：你每天做什么阿?"，"我每天登陆系统"。这就是用例没有提供足够价值的明显标志。
      3.用例中的每一个步骤，其实都可以写成一个独立的用例，分 or  不分？
      4.用例的打包组织是一门艺术，功能包、顶级目标用例，Actor，开发团队与版本号等。

    7.过多的扩展事件和异常事件流，让人晕菜
      即使是受过训练的程序员，2a, 3b1看多了也要晕掉，记住阅读者是人而不是机器。    
      解决方法：
      1.如果逻辑不多，可以一句话讲完，不影响主场景的，不建议新起一个事件流。
      2.可以使用活动图来辅助说明。在RSM7.0的模版里，每个用例都会带上一个活动图。

    8.过多的关系，继续让人晕菜
     “不要花一个月的时间去讨论应该include还是extend”。大家对include, extend and generalize都不熟悉，那就干脆都不要用了。   

参考材料：
    《编写有效用例--Wriging Effective Use Case》Corkburn 2001，大家现在使用的用例模版都是他创下来的，此书无可替代。
    《用例模式与蓝图--Use Cases Patterns and Blueprints》我觉得比另一本名字相近的《Patterns for Effective Use Cases》要实用一些

是什么造就了一个成功的专业项目团队？浏览一下成功的项目团队所固有的特点是
很好的。对每个因素的重视程度对于项目的成功和评价业务客户的信任度将有很大的
影响。
 
System Building Competence
   系统建造能力
 
This is absolutely critical. The ability to succeed is
established within the minds of the clients as well as the
project team members in the early stages of the effort. An
essential component of this perception is both the
management ability, the technical skills, and the sense of
direction possessed by the project leadership. Both the
business clients and the team can detect fairly quickly if
the project leaders have "what it takes" to take them to a
final product. Without question this feeling has a
tremendous impact on morale.

   这是绝对关键的。成功的能力是在努力的早期阶段在客户的思想和项目团队成员中
建立起来的。这个观点的本质在于管理能力和专业技术和由项目主管拥有的方向感
上。业务客户和团队能够快速清楚的察觉项目主管是否有带领他们向最终目标前进的
思想。毫无疑问这个感觉对士气是至关重要的。
 
Humphrey Watts in his book Managing the Software Process,
describes a model for measuring the maturity of a software
development organization. These ideas were further refined
by the Software Engineering Institute (SEI) at Carnegie
Mellon University. A brief summary of the maturity levels of
the model (in terminology which will relate to some of the
central themes of this white paper) are presented below:

   Humphrey Watts在他的书《管理软件过程》中描述了一个衡量软件开发组织成熟
度的模型。这些观点由Carnegie Mellon大学的软件工程组织作了进一步精炼。有关
模型（有些术语与本文的一些要点有关）成熟层的简短概括如下：
 
Initial Level
   初始层
 
A team or organization at this level tends to take a
chaotic, ad-hoc, "invent as we go" approach toward every new
systems building effort.
   处于这层的团队和组织试图以一种混乱的，特别的，"如我们所想的"方法对待每一
个新的系统建造工程。
 
Repeatable Level
   可重复层
 
A team or organization at this level uses planning
techniques, gathers requirements in a systematic fashion,
utilizes software quality assurance techniques, and follows
a patterned approach on each subsequent effort.
   处于这层的团队和组织通常使用编制计划技术，收集体系模式的需求，使用软件质
量保证技术，并在后来的开发中使用模式化的方法。
 
Defined Level
   被定义层
 
A team or organization at this level follows defined
methodological steps, uses process improvement techniques to
enhance the methodological approach, conducts regular
training programs, views the entire systems development
process from an integration perspective, and utilizes more
disciplined information engineering and structured
development techniques.
   处于这层的团队和组织使用定义好的方法步骤，使用改进过程的技术来提高方法，
管理有序的练习程序，从综合的观点看待整个系统开发过程，使用更加严格的信息工
程和结构化开发技术。
 
Managed Level
   被管理层
 
A team or organization at this level actually captures and
utilizes software development metrics for future estimation
and process analysis purposes. In addition, some of concepts
of Total Quality Management (TQM) are employed to reinforce
the effectiveness of the entire development process.
   处于这层的团队和组织通常为将来的评估和过程分析捕获并使用软件开发度量。另
外，整体质量管理的一些概念也被使用来增加整个开发过程的效力。
 
Optimized Level
   优化层
 
A team or organization at this level utilizes continuous
organizational change management techniques to optimize its
own operations (as well as the company's), emphasizes defect
prevention rather than defect detection, and constantly
seeks technological innovation opportunities.
   处于这层的团队和组织使用持续的有组织的变化管理技术来优化他们的操作，强调
避免错误而不是发现错误，并经常寻求技术革新的机会。
 
Project Team Experience
   项目团队的经验
 
Even within organizations with high success rates, one
factor which never changes on each new effort is the amount
of experience possessed by the chosen project team members.
Will the project team include a business expert? If not,
will the assigned members be able to effectively comprehend
and discuss the business requirements and issues in the
client terminology? Having someone on the team (even if only
in the initial phases) who understands the business is a
great confidence builder! It allows the analysts and
designers to ask the dumb or simplistic questions to someone
other than the client. This actually makes more effective
use of everyone's time and it adds an subsequent level of
security. In addition, it puts someone in the position of
making sure that "creative thinking" stays within reasonable
boundaries.

   即使是拥有高成功率的组织中，每个新努力中从不改变的因素是被选择的团队成员
拥有的经历的程度。项目团队应该包括一个业务专家？如果不是，指定的成员能够有
效的理解和讨论业务需求和客户术语中的组织？在团队里有没有理解这项业务的人士
个很自信的开发者？允许分析员和设计员向任何人询问简单的问题，而不是向客户。
这能充分利用每个人的时间，并增加后期工作的安全性。另外，它是每个人在合理的
范围里进行创造性的思想。
 
What about technical expertise? Is the project entering
uncharted waters without a guide? Having someone on the team
who is familiar with the specialized knowledge surrounding a
selected technological environment provides the same
confidence creating benefits as those listed above. A
technical expert can assist others, make suggestions,
develop standards, and prevent time consuming mistakes. In
addition, he or she can provide leadership by example. By
spearheading the work and creating examples for others, a
technical expert can transfer knowledge and experience in a
timely and effective manner. The prevents the "invent as we
go" situation teams often find themselves in when embarking
on a new technology.
 
   专门的技术怎样？是不是项目进入了没有向导的水域？有没有团队中的成员熟悉指
定技术领域的特定知识提供上面提到的同样的信心？一个技术专家能够帮助别人，做
出建议，开发标准，阻止耗时的错误。另外，她或他能通过例子提供领导能力。通过
传播工作并为他人创造例子，一个技术专家能够以及时有效的方式传播知识和经验。
这能阻止当一个团队在着手于一项新技术时通常发现他们处于按自己所想进行的处
境。

Project Control and Coordination
   项目的控制和合作
 
Large, complex undertakings which require the participation
of many people throughout the development process, demand
both high-level and detailed guidelines to assist in the
channeling of the individual results into an integrated
final product. As each person focuses on his or her's part
of the system, a clearly defined set of standards and
specifications must exist insure that the final result will
"mesh" with the results being produced by others. In many
ways, a systems building project can be thought of a series
of specifications, each level spiraling from broad
requirements into highly detailed procedural instructions.
The collection of these efforts into a unified whole
presents the ultimate challenge for the group. What are some
of the ways to successfully make this happen?

   大型的复杂的事业需要在开发过程中很多人的参与，需要高水平详细的设计细节来
辅助独立的成果融入最后完整的产品中。当每个人专心与它所负责的系统的一部分
时，一个清楚的已经定义标准和规范的集合必须存在以保证最后的结果能够和其他人
的结果相吻合。在很多方式下，系统的建造项目可以看成是一系列规范，每层从广泛
的需求螺旋发展成为高度详细的过程指令。这些努力的集合就构成了一个整体，给整
个团体展现最后的挑战。那些方法能使这件事情成功的发生？
 
Ultimately, three major factors contribute to the level of
success that systems building team will enjoy at each of the
required integration points. One of these factors is the
creation of "consistency" standards. During each phase,
guidelines should be developed for both the content as well
as the format of the final work products. A second important
factor is cross-team communication. Common requirements,
similar issues, shared data, and reusable functionality all
should be openly discussed and coordinated. Sub-teams should
participate in the development of overall high level shared
goals and objectives which encourage cross-team interaction
and decision making. A third factor is the insistence on the
part of the top team leadership that individual and sub-team
successes be innertwined. Consistent deliverable, quality
assurance, methodological, and review standards must apply
to all team members equally.

   最后，三个关键的因素将对系统建造团队将会享受每个需求的综合点成功级别起作
用。这些因素之一是一致性标准的建立。在每个阶段，详细的细节必须为内容和最后
的运行产品的形式所制定。第二个重要的因素是跨团队的交流。通常的需求，相似的
组织，共享的数据和可复用的功能都应该被公开的讨论和协作。子团队应该参加整个
高层的开发，共享鼓舞跨团队交互作用和决策制定的目标。第三个是代表高层领导的
坚持性，个人和子团队的成功相交互。交付的一致性，质量的保证，方法和复审标准
必须对团队的所有成员一视同仁。
 
Team Goals and Individual Objectives
   团队目标和个人目标
 
A project team seems to develop a unique "personality" over
time. It becomes a reflection of everyone involved,
radiating confidence and certainty if spirits are high,
seething with doubts and confusion when direction is
lacking. How can project dynamics be so different from one
team to the next? Leadership certainly plays a vital role,
but individual team member attitudes make the difference.

   一个项目团队看起来时在开发一个独一无二的个性软件。成为每个参与者的反映，
如果士气高的话则充满自信和确定性，当缺乏方向时则由于疑虑和混乱而沸腾。怎样
才能使项目因团队的不同而不同？领导能力当然起了一个很关键的作用，但团队成员
的态度也会造成不同影响。
 
Two fundamental questions illuminate the spirit of the group
effort. First, is everyone on the team driving toward a well
defined and articulative objective? Second, whose objective
is it? An amazing thing can happen on development projects;
everyone is busily working away on whatever it is that they
individually perceive as his or her's most important tasks.
Hopefully, each person's work will mesh with the rest of the
group's results. This will probably happen if everyone
clearly and precisely understands the ultimate phase
objectives. But what if they don't?

   两个基本的问题说明了组织努力的精神。首先，是不是团队的每个人都朝着已经制
定的清楚的目标前进？第二，这是谁的目标？在开发项目中可能发生这样令人惊讶的
事情，每个人都忙于她或他认为最重要的任务。希望是每个人的工作都能与其他人的
工作相吻合。如果每个人都很清楚并精确的指导最终的目标则可能，但如果不是呢？
 
This is where human nature begins to step in and things can
begin to get interesting. If the attitudes of the team
members tend to be goal driven (which is good) but the team
leadership is fuzzy about what the objectives really are
(which is bad), individual and sometimes scattered goals
begin to pop up. Unique and potentially conflicting agendas
take shape. Before you know it everyone is busily working
away and the atmosphere appears to be productive. But an
time of reconciliation lies ahead. At some point the
individual results must be combined, and depending on the
fit, the attitude of the team will ultimately be affected.
The group's mission or purpose at this point becomes very
real, because it is at this moment that the team realizes
that there may not have really been a common direction in
the first place, and that fact is painfully obvious.

   当人类开始涉足的地方并且能过的兴趣。如果团队成员是目标驱动，而领导者对最
终的目标而疑惑，独立的或分散的目标突然出现。独自的潜在的议程出现。在你知道
之前每个人都忙于工作，而且是生产性的气氛。但要调和的时间摆在前面。在某个点
上独立的结果必须合并，以来与合适性，团队的态度最终会被影响。这时组织的任务
或目的变得很真实，因为这时团队才意识到在开始时就没有统一的方向，事实显然是
很痛苦的。
 
Why even take this risk? Insuring that goals and objectives
are clearly spelled out, and the activities and tasks which
will be followed to ultimately reach them are uniformly
understood, will only give the team a shared sense of
purpose. Everyone needs to have a stake in, and a share of,
the responsibility for the outcome of each phase. Doing this
can have an incredible impact on people's attitudes. Clearly
comprehending the relevance of the work and how it will
contribute to the final product, is a powerful motivator for
creating an air of cooperation and open channels of
communication between team members. Individual goals can be
visualized as a part of the larger team objectives. The goal
driven attitude of the team will truly be reflected in the
quality of the results.

   为什么冒这个险？确保目标很清楚的确定，他们所从事的任务和活动被一律的理
解，将会给整个团队一种目的共享的感觉。每个人都需要由对每个阶段成果的责任
感，共享感。这样做肯定会影响每个人的态度。清楚的理解工作的关键和怎样影响最
终产品，是产生合作环境及创造成员界交流通道的强有力的因素。独立的目标可以被
想象成为大型团队目标的一部分。团队的目标去动态都会在产品的质量中有所反映。
 
Systems Building Vision
   系统建造的蓝图
 
A "vision" doesn't do anyone any good if it is only in one
person's head. Only when it has been absorbed and adopted by
the team does its usefulness begin to emerge. A business or
system "visionary" plays an important yet sometimes
unenviable role in making this happen. His or her
willingness to share insight and understanding of a
situation, and the necessary steps he or she envisions to
arrive at a desired outcome, tend to be dependant on two
factors: the level of confidence he or she has in the ideas,
and his or her tolerance for scrutiny and criticism.
Regardless of these personal risks, a professional system
builder must strive to be a system "visionary". With each
passing phase of the project, he or she must constantly
develop and communicate his or her vision of both the system
functionality and the project approach.

   如果蓝图只存在于一个人的脑中则不会给任何人带来好处。只有被团队吸取和采纳
才能使它的作用发挥出来。一个业务或系统的“蓝图”作用重要但有时仍不能实现。
她或他的希望是共享对情况的理解和见识，并采取了步骤以达到理想的结果，依赖于
两个因素：她或他的自信程度，忍耐审查和批评的能力。不管这些个人的冒险，一个
专业的系统建造者必须为成为一个系统设计者而奋斗。随着每个阶段的完成，她或他
必须持续开发和交流她或他对系统功能和项目方法的构想。
 
Putting forward this vision assists in accomplishing two
important results. First, it creates a baseline foundation
for continuing discussion. In many cases, the original
system/approach vision may not survive for long as better
ideas are presented and improvement discussions occur.
Second, the vision promotes constructive, critical thinking.
 
   提出构想能有处于实现两个重要的结果。首先，它创造了继续讨论的基础。在很多
情况下，最初的系统/方法构想不能比好的思想提出和改进的讨论维持的时间长。第
二，构想提供建设性的严格的思考。

People tend to provide more input in a "review and improve"
mode rather than a "create from scratch" mode. The
presentation of a baseline vision stimulates this process.
In addition, if the "visionary" can relinquish ownership of
the original idea, and subsequently encourage it to become
the property of the group, the effectiveness of the process
can be even more enhanced. The system builder serves to
plant the "starting point" ideas, and the team members and
business clients assist with, and take responsibility for,
the ultimate direction and composition of the shared vision.
 
   人们更倾向于提供更多的输入给“复审和提高”而不是“从零开始”的模式。最初
的构想的提出促进这个过程。另外，如果“构想”能够放弃最初的思想的所有权，而
成为组织的财产，这个过程的效果将会更加提高。系统建造者负责产生开始点的思
想，团队成员和业务客户辅助并负责共享的构想的方向和合成。

Project Team Confidence
   项目团队信心
 
Another important team attitude is confidence. The
development of a complex system presents tremendous
challenges to a project team. Sometimes it can even feel
like an act of faith. An enormous amount of detail is
collected, analyzed, organized, and assimilated into a
functional "whole". On very large efforts, only a few key
individuals may possess the total "big picture", and this
may be at varying levels of completeness. This ambiguity can
from time to time test the confidence of the project team
members. Given these uncertainties, how does a team feel
assured and confident of success throughout the process, and
have this reflected in the individual team member attitudes?
 
   另一个重要的团队是信心。开发复杂的系统将会给团队带来很多挑战。有时感觉是
一种信仰的活动。大量的细节被收集、分析、组织并吸取为整体的功能。在非常大的
付出中，仅有一些关键个人支配整个“图纸”，并随完成的不同层次不同。这种不确
定性时不时的检验团队成员的信心。给出这些不确定的事情，一个团队怎样才能在通
向成功的过程中感到有保证和信心，并反映到团队个人的态度呢？

Clearly, the realization on the part of the team, that a
system design is formed as a gradually evolving solution,
from a process which tends to be iterative in nature, helps
everyone to be patient with the slowly disappearing level of
ambiguity. The more team members who participate on the
project who have been through the complete system building
life cycle, the more likely the overall team awareness will
be that everything will come together at each major
milestone. This is an important confidence builder for the
less experienced members of the team. The higher the level
of confidence possessed by the team, the more secure the
business clients feel, and the more likely the team will
actually "see" themselves succeeding, even in the face of
the unknown.

   很明显，在团队方面的实现，系统的设计在逐渐演化的过程中形成，从本质上交互
的过程，帮助每个人在不确定性逐渐消除的过程中保持忍耐。参加项目并经历整个系
统建造生命周期的成员越多，整个团队意识在每个主要里程碑所有事都具备的可能性
就越大。这对于一个缺乏经验的团队成员是一个重要的信心缔造者。团队拥有的信心
水平越高，，业务客户的安全感越大，团队就更加可能看到他们的胜利，即使是面对
未知的事情。