说到MRD，就不得不说一下PRD，也有朋友提到了这个问题，MRD和PRD有什么区别呢？如果大家看过联盟的第一期和第二期杂志，那么就应该知道MRD和PRD的区别和关系了，在这两期杂志的“PM词典”栏目中，就对这两个工具进行了介绍，先来分别看一下。

       做个表格来说明一下两者之间的关系：

       从这个表中可以看出，MRD本身并没有什么特殊之处，按照产品管理者的工作内容来说，是必备的东西，但是，我们知道，现实的情况是，许多技术型的公司实际上对产品管理者的定位过于狭隘，非要生生地把产品管理者分为“技术型”、“市场型”，本来一个完整的产品管理过程和管理内容，就这样支离破碎了。
       关于这个问题抽时间，咱们再一块讨论，还是重点讲MRD。
       正是因为这个原因，许多技术型企业的产品管理者很少或者几乎没有接触过MRD，并不是说大家没有这个意识，其实，作为产品管理者，这些市场端的东西多少都会有了解的，但是，企业并没有把这个任务交给产品管理者来做，因此，就显的有些陌生了。
       在表格中，已经提到了，MRD起着一种“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。
       这个很容易理解的，那么，具体到这个文档中，都包括什么内容以及如何来完成好这些内容呢？
       接下来，我就自己的一些经验说说个人的想法，对不对的，大家见谅。
       刚才说到了，MRD就是对产品所在市场数据的整合，说白了，就是对市场分析后的结论体现，那么，在这个文档中，需要体现哪些内容呢？
       在我看来，需要体现的主要内容包括：
       1、市场的问题和机会；
       2、市场特征；
       3、用户特征；
       4、使用者特征
      5、市场的需求。

       分别解释一下：
1、市场的问题和机会。
       在这个主题中，主要是要求产品管理者说明自己负责的产品现在所处的市场都有什么问题和机会、面对这个现实的市场，产品有什么问题和机会，以及产品所需技术面临的问题和机会。
       其实就是要求从市场层面、产品层面、技术层面来阐述问题和机会。
2、市场特征。
        在这个主题中，主要是要求产品管理者说明目标市场的现状和趋势。应该包括的信息有：
        目标市场特征；目标市场趋势；目标市场细分；目标市场时间约束。
3、用户特征。
        这里的用户是个广义的概念，它其实包括两个方面的信息：1、客户（customer）；2；购买者（buyer）。
        在这个主题中，主要是要说明这产品的目标用户的特征、细分、动机、影响因素以及用户期望（目标）。
4、使用者（user）特征。
       之所以把这个主题独立出来，就是因为，无论什么产品，最终是要由具体的人来介入的，这类人才是产品的最终享受者，具体到产品上，其实我们日常分析的产品需求和功能都是基于他们考虑的。
       在这个主题中，要说明这类用户的特征、现实需要和相关联系。
       这里插一句话，我看到国外的一些公司是采用了原型塑造法来完成这个主题的，关于这个方法，抽时间再说，呵呵。
       备注：关于客户（customer）、购买者（buyer）、使用者（user）的区别和关系，如果有朋友还有不解的地方，可以一块来讨论，嘿嘿。
5、市场的需求。
       这个就比较简单了，就是把市场需求按类别描述出来即可，具体的标准，大家应该很清楚的，就是“描述性的语言来说明用户的期望”，主要包括的内容有：
       功能分类；开发环境说明；兼容性说明；性能说明；国际性说明；文档说明；外观说明；发布说明；支持和培训说明；其它说明；方案概述；技术概述。
       当然了，我是把可能出现的内容都列举出来了，在实际的情况中，肯定会根据行业和产品的不同有所删减，这个仅供参考哈。
       在这个主题的最后，我建议大家加一个表格，就是“需求概要表”，这个表格的作用就是用列举的形式来把所有市场需求记录下来，毕竟上面的内容都是描述性的，这个表格有助于快速浏览。
       这个表格应该包括的内容有但不仅限于：
       实现目标；约束条件；需求联系；原型；类型；优先级。

       简单介绍了一下MRD中主要体现的主题，大家看一下，其实内容很简单的，但是，我在看了一些MRD后，才感觉到，写好一份MRD，那是相当的不易呀。
       首先，在MRD中必须有许多的数据来支持你每个主题的结论描述，其次，在MRD中，涉及到了一些具体的方法，例如刚才说到的原型法，三，MRD是整个产品项目过程中非常重要的一份文档，或者说，这份文档奠定了接下来的一些列工作基础，MRD做好了，其它的工作都没有问题，这个作不好，其它的都不可能让人满意的。
       因此，要写好MRD，是不能脱离产品项目流程和思想的，这个说起来，就太大了，有时间咱们慢慢聊。

       大家在现实的工作中，偏重于PRD的居多，大家可以想想，是不是通常把主要精力放在了产品功能上了，而忽视了对产品所在市场的关注和分析，尤其是在一些软件和互联网公司，非常明显，有多少朋友做到了MRD中要求的呢？

       说到最后，还是我始终坚持的一个观点，产品管理文档，本身没有任何价值，网上到处都可以找到，但是，如果不懂产品管理的思想，不明白产品管理到底是什么，不知道产品管理者到底应该做什么，即使给你非常好的文档模板，又有几个人能真正理解这份文档的作用，并把它写好呢？

       对了，最后提一点，有些公司，是把MRD和PRD合并来做的，或者说，即使可以舍弃PRD，也不能舍弃MRD，因为PRD是由MRD延展而来的，MRD是根，PRD正是枝叶而已。

附一个MRD目录吧，仅供参考，千万别照搬。
1、文档介绍
1.1 文档目的
1.2 内容概要
2、市场问题和机会
2.1 本章摘要
2.2 市场问题
2.3 市场机会
2.4 产品问题和机会
2.5 技术问题和机会
3、市场概述
3.1 本章摘要
3.2 目标市场描述
3.2.1 目标市场特征
3.2.2 目标市场趋势
3.2.3 目标市场细分
3.2.4 目标市场时间约束
4、客户和购买者
4.1 本章摘要
4.2 目标客户描述
4.2.1 目标客户细分
4.2.2 客户动机
4.2.3 影响因素
4.2.4 客户目标
4.3 目标购买者描述
4.3.1 业务决策购买者
4.3.2 技术决策购买者
5、使用者和用户原型
5.1 本章摘要
5.2 原型特征
5.3 现实需要
5.4 原型联系
6、市场需求
6.1 本章摘要
6.2 功能分类
6.3开发环境说明
6.4兼容性说明
6.5性能说明
6.6国际性说明
6.7文档说明
6.8外观说明
6.9发布说明
6.10支持和培训说明
6.11其它说明
6.12 方案概述
6.13 技术概述
6.14 市场需求概要表
7、支持信息
7.1 本章摘要
7.2 文档假设
7.3 参考资料
7.4 产品体系

链接：http://blog.chinapm.com.cn/u/tangyuan/91.html

      Use Case可以用很多方式来描述，我们可以用自然语言（英语，汉语，随您的便），可以用形式化语言（哇！太酷了吧！），也可以用各种图示。在UML中，通常用两种图来描述Use Case，它们就是顺序图（Sequence Diagram）和协作图（Collaboration Diagram）                   

      Use Case 由以下元素组成：
　　　　名称
　　　　简单描述
　　　　事件流
　　　　关系
　　　　活动图和状态图
　　　　Use Case 图
　　　　特殊需求
　　　　前条件
　　　　后条件

一、谈谈对use case有关术语翻译的看法。

      笔者认为“用例”是目前较好的译法，这个词可能来源于大家熟知的“测试用例”。有人认为把use case翻译成“用例”是错误的，理由是：“‘例’是被列举出来以说明某种情况的个别事物，use case是对一项系统功能使用情况的普遍适应的描述，而不是对个别actor或者在个别条件下使用这项功能才适应，它也不是通过举例的方式来描述的”，所以不能叫作“用例”。此种说法不尽全面,而且有些牵强（先不管它正确与否），其实use case到底是个别的，还是群体的（普遍适应），取决于我们的视点。虽然对于单个的scenario来说，use case是多个情节的叠加，是一个整体的复合概念，但是我们知道，一个系统的功能必定是可数的、有限的，而每一个功能都可以表示为一个use case，所以在观察系统提供的所有功能需求的集合这个层面上，use case又是一个一个可数的个体（“椭圆”），每一个都代表了不同的用户目标，适用于个别的actor和个别特定的前置条件。同一个事物既是个体的又是整体的，这种现象并不足怪，例如在UML对象-类-类元关系中，通常对象是类的实例，而类又是类元的实例，对类元来说，类、接口、子系统、use case等等就是一个个个体的概念，类既是其对象实例的集合又是其类元集合的个别元素。可见，把use case的“case”译成“例”并没有错。

      有的地方把use case翻译成“用况”，即“使用的情况”之意，意思的确不错（use case的另一种说法是“使用的方式”）！可我总感觉这个词比较突兀、拗口，类似的还有“用案”，把scenario叫作“案况”，大概这些词读起来不太符合大家的习惯（类似地，既然可以叫“用况”，为什么不能叫“用情”呢？），所以现在“用例”的叫法还是越来越多了。

      其实“用例”这个译法还有个附带的好处，通过它我们很容易把原本就存在紧密联系的use case和test case（test case来自于对scenario的分析，而scenario是用例的一次执行）从中文名称上也方便地统一起来。不过，这里我们需要做一个小小的改进。中文的“测试用例”到底是指test case（带定语的名词词组）呢，还是指对用例进行测试（testing the use cases，动宾词组）呢？显然这两者不易分辨，而且若“用例”和“测试用例”两个词同时出现在一啰个句子或一段话中，常常会让人感觉嗦和便扭。为了消除歧义，干脆以后把test case都叫做“测例”，这样不但比以前的叫法更加简洁明了，而且无论字面上还是语义上都很贴切。当然，用例和测例是不同层面的“例”。

      现在市面上Actor也有多种译法，常见的包括“参与者、执行者、主角”等等。“参与者、执行者”的问题主要是不准确。首先，“参与者” 通常让大家马上想到的词是participant，而且请注意，一个用例的真正参与者决不是只有外部的Actor，它们必然还包括系统本身及其内部的各种元素。“执行者”的问题与此类似：一个用例的真正执行者应该是系统本身！因此严格地讲这样译是错误的，兴许叫作“外部参与者”、“外部执行者”才更为恰当。“主角”的译法同样存在着矛盾。如果把Actor叫作“主角”，那么Primary Actor就应该叫作“主主角”了。看来Actor的译法中是不能含有“主”的，那么就剩下“角”了，而UML已经有了一个专门术语role（角色），我们又不能把Actor直接叫作“角色”。
目前看来，把Actor意译成“使用者”是比较妥当的。在大多数情况下Actor的的确确就是用户（确切地说是系统用户所扮演的一种角色），所以我们可以用“使用者”这个词从字面上与“用户”（user）进行区分，但同时又保持两者语义上的联系。我们还可以把为系统服务的Supporting/Secondary Actor（见下文）叫做“被使用者”（为了简化可以省略“被”字）或“辅使用者”。除了指系统的用户之外，“使用者”还有另一层含义，即Actor是use case的使用者（或被使用者），这种关系在UML用例图上应该可视化地表示为它们之间的连线（关联）。这样解释不但说的通，而且更便于不熟悉软件技术的业务人员理解。
当然，我们也不排除将来会找到“use case”、“actor”等术语更好的译法。

二、USE CASE的来历

       Ivar Jacobson在1967年定义爱立信AXE系统的够架时开始书写使用场境usage scenarios。

      二十世纪八十年代中期Jacobson花了很多精力来思考过去十多年的工作方法。他造了一个术语anvendningsfall，大意是“使用情况”（situation of usage）或用况（usage case）。但当用英文出版的时候，他发现“useage case”在英语里说不通，所以写作用例“use case”

三、创建USE CASE的原则

      用例是短文
      用例可以是一个场景，包括动作和互交。
      用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求，业务流程，系统设计说明。
      用例里不要有系统设计
      用例里不要有界面设计
      用例里不要有特性列表
      用例里不要有测试
      用例应该描述行为需求
      用例的主场景不要超过九步。可以在适当的层次上得到子目标和移除设计说明。
      用例的最大价值不在于主场景，而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。

四、Use Case 事件流

　　Use Case具有一个基本事件流（可称为"理想路径"）、多个例外流，包括：
　　　　基本变化
　　　　特殊情况
　　　　处理错误情况的异常事件流

五、Use Case 说明书

　　Use Case 说明书应包括以下内容：
　　　　功能描述
　　　　可用性
　　　　可靠性
　　　　性能
　　　　可支持性
　　　　设计约束

六、Use Cases将做成多大？

　　试图决定Use Case的大小是一个很有趣的话题，处理这件事的一个方法是将Use Case的大小跟它的意图和范围关联起来，对于一个真正大的范围来说，一个Use Case并不要在一个系统中处理那么多，但这些系统都用于同一商业领域，称为Business Use Case，它把整个公司看作一个黑盒和Actor关于公司目标的说明。这些Business Use Case的场景不允许假定任何公司内部的结构，一个客户将向公司下一个定单而不是客户服务部门。

　　对于系统发展而言，Use Case的范围限制一个单一的系统，这是Use Cases最通常的形式，我们称之为System Use Case，它把整个系统看作是一个黑盒，它不指定任何内部结构并且仅受限于问题域的语言描述。

　　Use Cases的另一范围是设计子系统和系统内部组件的，称为Implementation Use Cases，它把组件看作一个黑盒，并且这些Actors是区分它的成员。例如：可能会用Implementation Use Cases去说明应用系统中email组件的需求。

　　给出了这些分类，关于Use Case的大小话题变得容易了，设计这些项的范围来调整整个大小。帮助系统设计者，每个Use Case只描述没有大的分支的行为的单个线索。违背这个规定，Use Case看起来通常是不准确的或含糊的，作为测试说明的资源和参考，它也是很难使用的。

七、Use Cases的说明

      Use Cases的好处是一些情节能用不同程度的正规化的文字说明。每个情节涉及Use Cases中单一的途径，细节是条件组。

      不正规的文本描述也能使用，不过当条件较多和可能失败的情况下它们很难跟随下去。开始试图理解需求时，不正规的叙述风格也是非常有用的，然而随着Use Cases的进展，使用更加正规的机制去说明Use Cases才是有用的。

      下面是客户对Use Case“下定单”的粗略概略：

      “确定客户，找出需要的并且仓库里还有的物品并检查客户信用额是否够用”

      结构化叙述的格式已经被证明是非常有效的。这个格式所做的事是描述每一个情节的行为者：目标语句对顺序的叙述。在这个顺序中，每一个行为者：目标的语句对都假设前一个的目标是成功的，右面是一个简单的范例：

      Use Cases认为我们正在设计的系统是一个单一的黑盒，根本没有任何内部结构被记录下来，并且它被认为是一个情节产生的目的及对应单一的行为者（Actor）。这些Use Cases没有表示任何关于系统内部的东东，只是表示系统将达到什么样的目标及由什么（人或其它系统）操作和负责。

八、Use Cases使需求有利于回顾

　　Use Cases已经得到越来越广泛的应用，它与其它需求捕获技术相比，它成功的原因在于：
　　　　1 　Use Cases把系统当作一个黑盒
　　　　2 　Use Case 使在需求中看到实现的决定变得更加容易

　　最后一点源于第一点的补充，一个Use Case没有指定任何这些需求相关的系统的内部结构，所以说，如果这个Use Case中陈述了"提交改变到定单数据库"、"显示结果到Web页面"等的话，那么内部结构是显而易见的，并造成对设计的潜在约束。

　　为什么这些需求不指定内部结构的原因是，说明的内部结构给设计者带来了额外的约束，没有这些约束设计者们能更自由地建立一个正确实现客观可见行为的系统，并存在出现突破方案的可能性。

九、Use Cases的图形符号

　　这里是Use Cases的图形符号描述，UML中一个单一的"Stick-Man"符号标示角色（Actor），用椭圆标示Use Cases，如

（图一）所示。这些图对于你想看到Use Cases之间如何关联的"大图"和获得系统上下文的大体描述来说是非常重要的。

　　Use Cases图没有显示不同的场景，它们的意图是显示角色和Use Cases之间的关系。所以Use Cases图需求用结构化叙述文本来补充。UML提供一些可供选择的图来显示不同的场景，这些常规的图形有交互图、活动图、顺序图、状态图等（本文暂不讨论这些图）。使用这些图的主要缺点是它们不象文本一样是紧密的，但它们能用于给出Use Case的整体感觉。

十、Use Case 的评价标准

　　是否每个Use Case 都包括至少一个actor？
　　是否每个Use Case 都独立于其他Use Case？
　　是否每个Use Case 都有一个简单的行为或事件流？
　　是否每个Use Case 都有一个唯一的、直观的、可扩展的名称，使它不至于在后期被混淆。
　　用户是否容易理解Use Case 的名称和描述。

十一、Use Case 模型的评价标准

　　Use Case模型显示系统中的Use Case与Actor 及其相互关系。其评价标准有：
　　　　Use Case 模型是可理解的吗？
　　　　通过对Use Case 模型的研究是否能对系统功能有一个清晰的概念。
　　　　所有的actor都定义了吗？所有的功能需求都满足了吗？
　　　　Use Case 模型是否存在多余的行为。
　　　　从模型到Use Case包的划分是否是恰当的。

十二、使用Use Case 的误区

　　由于具有简单的图形符号、易理解的自然语言说明书，Use Case在文档系统和软件需求领域成为一 项越来越受欢迎的技术。Use Case对开发小组极具吸引力，即使小组成员对正式的需求文档没有经验，但这些简单性却具有欺骗性，即使项目小组在开始使用Use Case 时没有任何麻烦，当他们将其应用于大项目时常常会遇到许多同样的问题。

    1 使用 use case 十大误区

　　1． 系统的boundary 没有定义或经常改变；
　　2． 从系统观点而不是actor观点来定义Use Case；
　　3． Actor的名称不一致；
　　4． Use Case 定义过多；
　　5． Use Case 和actor之间的关系象蜘蛛网一样错综复杂；
　　6． Use Case的说明太长；
　　7． Use Case的说明不清楚；
　　8． Use Case没有正确的描述功能需求；
　　9． 用户无法理解Use Case；
　　10． Use Case 无法正常结束。

       2 如何避免以上问题

      清楚的确定系统的boundary.
　　简单来说，系统的boundary就像一个加了标签的盒子，actor在盒子外，而Use Case在盒子内。我们称之为系统的这个盒子究竟是什么呢？一个计算机系统？一个应用系统？或一个完整的企业？…Use Case 可以用来合理地描述任意系统。但一次只能用来描述一个系统，在一个系统中恰当定义的actor和Use Case用于另一个不同的系统中就会出现错误。

      使用标准模板书写Use Case 说明书
　　Use Case 图形符号已经被标准化并作为对象管理小组UML的一部分，但自然语言的Use Case 说明书还没有被标准化。为了成功书写Use Case 说明书，我们需要一个标准模板来保证Use Case 的一致性。

      关注actor的真正目的，从actor的观点而不是系统观点来命名Use Case
　　面向Use Case 的需求与传统的功能性系统需求之间最显著的区别在于actor ，以面向Use Case的观点，系统存在是由于actors 要通过该系统实现某些目标，actor与系统进行交互来实现其目标，我们将这些交互行为定义为Use Case 。

      不要将Use Case 说明书与用户接口设计相混淆
　　现在有一种很流行的观点：由于Use Case 是actors 与系统之间的交互，所以将所有的用户接口设计图放在Use Case说明书中是一个好办法。初看时，这的确很有用，因为它将在说明书中描述的actor/系统之间的交互行为以图的形式表示出来，非常直观。但是这样做的负面影响却远远大于其好处，用户接口设计可能会随着时间而改变，我们不应该让系统需求依赖于用户接口设计，相反地，用户接口设计应该满足Use Case 需求。如果我们将用户接口设计置于Use Case 说明书中，当需求需要被认可和定为基线时，很自然地，这些设计元素可能仍然在改变，这就使得用户接口设计成为不完整的、不正确的和/或不一致的。

　　将用户接口设计置于Use Case 说明书还会出现另一个问题，为了在Use Case 之间和接口之间建立一对一的通信，我们会选择反映用户接口的Use Case块而不是反映用户目标的Use Case 块，这样，为了表达一个完整的用户目标，我们使用交互Use Case 关系，将不同的、基于用户接口的Use Case 联接起来，结果在Use Case 模型中，我们得到了一幅类似蜘蛛网的关系图。实际上，这副图是用户接口说明图，虽然它在系统文档中是很重要的一部分，但他属于用户接口设计文档，而不是Use Case 需求文档。

      实现用户接口和Use Case 交互之间的松散耦合
　　松散耦合是比较合适的，低逼真度的用户接口图有助于理解Use Case ，但要注意不要过度的将基本交互与用户界面机制相连，用户界面很有可能会改变。在功能说明书中，要注意actor做些什么（如"提交请求"）而不是交互是怎样完成的(如"双击提交按钮")。

       不要在Use Case 和用户接口之间建立通信
　　试图在Use Case 和用户接口之间建立通信可能会存在潜在的、不正确的功能操作。Use Case 不仅与只能访问某个接口的actor相联，而且与那些能够更新该接口的actors相连（这可能是例外流），结果就造成了不正确的功能操作。我们应该在基于实际用户目标和功能操作的基础上拆分Use Case ，而不是在基于用户接口的基础上组合Use Case ，只有这样才能得到正确的Use Case 模型。

       回顾Use Case 模型和Use Case 说明书，如果你不能防止所有的误区，你应该尽早认识问题并确定问题
　　这个观点并不是什么新东西，有关代码检查的经典算法已有大约25年历史了，但怎样将其应用于Use Case 呢？ 首先，回顾Use Case 模型，回顾一下Use Case 的简单说明（Use Case 名称、目标、简单描述）。这项工作应在绘制草图时尽早执行，并在写详细的Use Case 说明书之前完成。接着是回顾Use Case 草图，保证图是正确的，并且详细的Use Case说明书是完整的。最后是正式回顾最终的Use Case 图和Use Case 说明书。

　　我们发现这种三阶段式回顾比单一的"宇宙大爆炸"式回顾有效，在我们花大量的时间写说明书之前，Use Case图中存在的许多实质性问题可以被发现，这种方法减少了当需求改变时需要做的重复工作。

十三、Use Cases应用当中的复杂性和危险

      主要行为者（Actor）和Use Case之间没有连结

      一些情况下，从Use Case中取值的行为者（Actor）和积极参与这个Use Case的行为者（Actor）之间没有清晰的连结。如：财务主管能成为“发票确认”的行为者（Actor），但他未必是创建发票的人。这不是什么问题，这个Use Case仍然是正确的，它正说明行为者取值和设计的系统的范围外的Use Case发生的初始化之间的关系。主要行为者是有用的，因为这个人扮演的角色是当你说明Use Case时需要跟他说的人。

     情节步骤不需要连续

      情节中步骤顺序的情况是没问题的，这里有一些机制去突出可能的并行步骤。在UML中活动图是首选的机制，通过非正式地看Use Case的情节你可以注意到可能的平行步骤；可以看Use Case内一些邻近的步骤；也可以有相同的行为者（Actor）对步骤负责。之前我们举过的例子里，确认数量和确认信用额可能是平行的。有时候在Use Case的说明文档中标记这些可能的平行步骤是有用的。

      Use Cases的大小

      当开始做Use Cases的时候有个很显然的危险就是它要么有很多步骤要么就很少步骤。如果在Use Case中有超过15个步骤，它可能包含一些实现明细。如果它只有非常少的步骤则检查它的目标是否是达到一个没有很多分支的活动的单一线索。

      较少的人类行为者（Actor）

      如果Use Case有较少的人类行为者，而大多数行为者是其它系统，通常的做法是修改这个Use Case。寻找系统必须做出反映或公认的事件胜过会见这些行为者。

      需求捕获和系统复杂性

      总而言之，这些情节捕获到系统复杂度的同时行为者：目标语句对容许大的系统以相对压缩的格式说明。Use Case的格式的作用是用户和开发者能标志出行为者，然后确认这些行为者工作职责对应（或不对应）的目标，代替一个大的很难读的功能规格说明书。

      仅仅这样，用户和开发者就有足够的兴趣进而研究那些情节的细节。

     系统不仅仅有应得的功能性需求

      一些Use Cases并没有捕获所有的客观需求，仅仅是捕获了系统怎么用的那些功能性需求。然而还有许多方面的需求需要去捕获的。其中有的非功能性需求使用关联以至于也能隶属于个别的Use Case，如性能需求和系统容量的需求。另外的一些不是关联的而是要单独地去捕获，它们是以下的需求：

      · 系统范围
      · 系统用户的目标
      · 用户界面原型
      · 一般规则
      · 约束
      · 算法

      运行时期和建立时期的需求比较

      一个重要的因数要记住，就是系统的赞助者是大过用户团体的。系统中有许多的风险承担者，Use Cases仅仅捕获其中一些风险承担者的需要，具体说，Use Cases仅仅捕获系统运行时期的需求而忽略做为系统开发组织的风险承担者的需求，开发组织最有兴趣的是对建立时期需求的描述。

      运行时期需求包括：系统范围、用户组织对产品的期望和目标、Use Cases、其它非功能性需求。

      建立时期需求包括：减少开发成本、较少的变更处理、现存组件的重用。

      建立时期的需求可以部分的由Use Cases把握。但许多方面是需要由开发组织的处理的。

          · 项目范围和目标：项目必须提交什么。（和系统范围的区别是它提交的是所有项目的东西）

          · 增长性和变更请求：这些可以在捕获为常规Use Cases格式中的“Change Cases”

          · 开发负责人的约束：包括标准、习惯、工具、品质度量标准、品质保证原则、及品质保证的习惯。

十四、Use Cases的适用性

      Use Cases首先用于需要响应客观事件的系统。它们能用于提供了一个有很容易理解的目标的清楚的行为者的环境。当结果不可定义或不清晰时不能用Use Cases。意思是如果目标成功或目标失败不能有一个明确的定义，那么Use Cases不能用来捕获需求。

      然而说到这，现在大部分对象方法都使用Use Cases。因为Use Cases被证明是捕获需求的非常有效的机制。

十五、小结

　　Use Case 是系统提供的功能块，换句话来说Use Case演示了人们如何使用系统。通过Use Case观察系统，能够将系统实现与系统目标分开，有助于了解最重要的部分――满足用户要求和期望，而不会沉浸于实现细节。通过Use Case 用户可以看到系统提供的功能，先确定系统范围再深入开展项目工作。

　　如果当初猪八戒扔掉钉耙，而是拿起来这些的话，也许他早就回高老庄，跟高翠兰一起，从此过上快乐、幸福的生活了。

武器一：贸然加入陌生人

　　团队来了新人，不要介绍他给大家认识，不要让大家知道他的技能和长处。人们会根据他的一些细微行为做出自己的判断，而不是先去深入了解他。 要是新人的兴趣癖好跟大家完全相反，那就再好不过了。

　　把两个死对头加入到一个团队中，而且告诉大家他们的技能对于团队来说很重要。这样一来，他们之间的摩擦就会成为加速团队分裂的催化剂。

武器二：限制沟通

　　别让大家谈天，这样会增进他们的感情。不断提醒他们“你们还有活要干！”要是能在办公室里面贴上一个“静”，就再好不过。实际上，如果团队分布 在不同的地方， 甚至彼此之间的文化背景都不同，效果就更好了。不到迫不得已，绝不要把一个团队的人安排在一起。不要公布通讯录。让人们的惰性发挥效果，如果想找一个人很 麻烦，他就不会找了。

　　告诉团队时间紧迫，发邮件也是浪费时间。这样人们就不会发送不必要的信息了。

武器三：分清长幼尊卑

　　最佳的装备给最棒的人。最快的电脑、最好的办公室、额外的假期等等等等，只给这些精英人物。当人们看到有人可以享受特权时，嫉妒暗自滋生。基督教的七宗罪，“嫉妒”跻身其中。更美妙的是，一旦这种致命武器在团队中出现，不用人浇灌，敌意就会不断蔓延。

武器四：打人要打脸

　　每个人都有自己的弱点，找到它！把人们的弱点公开出来，并且使其个人化。要指名道姓！在表达方式上也要无所不用其极：羞辱，责怪等等，不一而 足。传播方式，可以通过备忘录、邮件、会议上的发言。用红色的大字体可以加强效果。更棒的是，你还可以散布流言。要想让人信服，不妨在流言中加入一些真 相，这就更有效啦。。。

　　曾经有一个公司的总裁，向全公司发送了一个备忘录，其中责备了软件团队新产品的种种不足。这种做法太牛掰了！这个总裁也就成了公司的杀手，不久之后，公司成功散伙了。

武器五：限制信息的访问

　　如果已经有了项目需求，可以做这样两件事：一是把它藏起来，因为程序员们习惯不看需求了；二是把其中几页拿掉，因为程序员们习惯看模糊不清的需 求了。在审核别人工作的时候，要埋下疑问的种子。比如：“上个月这个功能很重要，不过现在客户可能不需要了。”或者就用简简单单三个字：“你错了。”言简 意赅，多好。

　　让团队使用全新的、只存在于口头上的流程，而且要用新的技术。也别给他们上课和学习的机会。跟他们说没时间，而且要夸他们聪明。这样的迷魂汤可以给他们以压力，团队士气的崩溃，指日可待啊。

武器六：一山之内放二虎

　　同时要切分项目范围，把相关工作分成两部分，给不同的小组。制定竞争性的目标，告诉他们：“我想看看你们谁是更好的程序员。”这种特别的技术可 以消除信息的共享。可能有人不喜欢这种状况，并会因此而离职。那也没关系，别忘了第一种武器。可以中途加入新的陌生人嘛。所以要想在团队甚至是小组之内保 持稳定就基本上是不可能的了。

　　给竞争的小组之间分配职责的时候，可以让他们的责任有所重复。这可以确保减少协作的发生。想想政府职能机构的安排设置。相信你一定露出了心领神会的微笑。。

武器七：强制要求加班

　　人们会因此而远离他们的朋友、家庭，压力也不断上升。要想让一个人失去工作热情，施加过度的压力是不二之选！当每个人都感觉压力倍增的时候，办 公室中就会怒气满盈、怨气冲天。告诉他们这个项目很重要，告诉他们质量也很重要。他们就会觉得自己必须付出更多的努力和更长的时间来保证项目成功。取消所 有的假期。也许有人会因此而离职，这不是正合你意么？最棒的是，压力会影响质量，作为头目的你就可以找到各种问题，把他们的小辫子攥在自己手里了；你还可 以加入专长于QA的陌生人，或是将团队分成竞争的小组，也就是使用第六种武器。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

　　上面这七种武器，单独使用就可以发挥很大作用了。如果你要是掌握两种甚至两种以上，wow，恭喜你，你已经成为名副其实的“破坏之王”！

　　说明:本文主要部分译自《Amplifyin g Your Effectiveness》中《Maneuvers to Di sable a Team》一文。

产品原型设计软件Axure，我把发现的一些好资料分享给大家！

    先说说这款产品，Axure RP Pro是一套整合6大功能的网站策划软件-架构图/线框图/流程图/互动设计/原型设计/规格文件，比PowerPoint或Visio更适合策划工作。    

    http://wowtree.com/tree.php?aid=220

    http://userxper.com/blog/archives/246

    http://groups.google.com.tw/group/axure-rp-groups

    http://userxper.com/axure/download/download-form1#usermessagea

    http://userxper.com/blog/archives/36

    http://userxper.com/axure_tutorial     http://www.axure.com/expert.aspx

    Axure RP能够快速提高网站企划的效率，除了个人在单一网站项目上应用Master的功能，来大量减低重复编辑的工作之外，还可以利用Master的Custom Widget自订对象的功能，来建立网站接口元素的接口库(UI Design Pattern Library)。这里有一篇大陆Axure RP应用于网站界面库的实际案例 - 利用Axure封装视觉标准，非常值得学习。

    Prototype範例
    http://userxper.com/axure/sample_prototype

    http://userxper.com/blog/page/5 4 3 2 1

    Axure的富交互应用实例
    http://lovelyrosa.blogbus.com/logs/23839905.html

    http://blog.csdn.net/hu_zhenghui/category/418803.aspx

    http://www.bubbling-library.com/eng/examples

    Shared Projects

    http://www.google.cn/search?hl=zh-CN&q=axure+share+project&meta=&aq=f

    http://www.axure.com/p401_1.aspx

    http://www.zhuaxia.com/pre_channel/4922477/?logId=181

    AXURE—3秒钟后自动隐藏提示层

    http://y2816.blog.163.com/blog/static/86768325200862892514967/

    http://groups.google.com/group/axure

    一本不错的设计杂志

    http://www.newwebpick.com/

    http://www.newwebpick.com/shop/index.php

      经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供货商自动结算，卖场通过扫条形码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”

      分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”

      经理觉得奇怪：“我不是刚告诉你我的需求了吗？”

      分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”

      经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”

      分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”

      经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”

风险躲在需求的迷雾之后

      以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。

拨开需求分析的迷雾

      像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：

     ·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

     ·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

     ·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

     ·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作接口的具体细节和构造上的限制。

     ·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。

      前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其它任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。

      下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。

      经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。

      在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。

      优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。

      由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。

客户的需求观

      客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。

      1、 分析人员要使用符合客户语言习惯的表达

      需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。

      2、分析人员要了解客户的业务及目标

      只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。`

       3、 分析人员必须编写软件需求报告

      分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其它信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

      4、 要求得到需求工作结果的解释说明

      分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

      5、 开发人员要尊重客户的意见

      如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

      6、 开发人员要对需求及产品实施提出建议和解决方案

      通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

      7、 描述产品使用特性

      客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“ 接口友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

      8、 允许重用已有的软件组件

      需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。

      9、 要求对变更的代价提供真实可靠的评估

      有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。

      10、 获得满足客户功能和质量要求的系统

      每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。

      11、 给分析人员讲解您的业务

      分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。

      12、 抽出时间清楚地说明并完善需求

      客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其它获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。

      13、 准确而详细地说明需求

      编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。

      在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。

      14、 及时作出决定

      分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。

      15、 尊重开发人员的需求可行性及成本评估

      所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的资料。开发人员会对此作出负面的评价，客户应该尊重他们的意见。

      16、 划分需求的优先级

      绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。

      在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。

      17、 评审需求文档和原型

      客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。

      更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。

      18、 需求变更要立即联系

      不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。

      19、 遵照开发小组处理需求变更的过程

      为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。

      20、 尊重开发人员采用的需求分析过程

      软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。

“需求确认”意味着什么

      在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”

      这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”

      同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”

      这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。

      对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。

      需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。