：）每天进步一点点

时间过得真快，经过一系列需求研讨、需求分析和整理确认，我们整理出了需求列表，编写出了需求规格说明书，一切似乎该到结束需求分析阶段的时候了。但是，敏捷大师的一句话让我们彻底心凉到了骨头里。敏捷大师说了，我们不可能在需求分析阶段完成所有的需求分析工作，它将延续到设计、开发，甚至测试阶段。一直以来，我对这句话非常困惑。既然需求分析阶段不能完成所有的需求分析工作，那么完成多少才算结束呢？80%？6

经过一番努力，我们终于在客户中找到了一批人，可以解答困扰我们多时的业务问题了，真是不容易呀。但是，如何以合适的时间、合适的地点、通过合适的形式与客户研讨业务需求，是摆在项目经理面前的一道难题。在我所经历的项目中，业务研讨会没有一个是相同的。我曾经做过一个政府机关的项目，在这个项目中，从总局到省、地市、区县，形成了一个多组织机构的管理系统。虽然全国管理流程大体相同，但各地因各地实际情况的不同

项目组经过一番努力，获得了一些初步的成果。首先是给客户留下了一个良好的印象，这是一个开端，但要在他们心目中树立自己的职业威信还要看你今后的表现。同时，我们与客户一起为项目制订了短期与长期目标。不要小看了这些目标，它们就是我们的尚方宝剑。正是因为有了它，今后项目中的有关各方就应当协助实现这个目标。我们应当清晰地向客户表达这样一个意思，要完成这样的目标，不是某一方的努力，而是双方共同努力的结果。这也是

又到新年了，日历又要从2011年翻到2012年了，这使我有太多的感慨，进而勾起了对太多往事的回忆。过去的10年，毫无疑问是中国软件业发展最快的10年。当我们刚刚毕业的时候，还在使用VB、PB开发一些简单的数据库应用，而现在却几乎看不到它们的踪影，换来的是诸如J2EE和.NET这样的大型web应用。而这期间，RUP、XP、敏捷开发、持续集成••••••一个接一个的新概念层出不穷，令人眼花缭乱。现在想

当我们进行业务流程分析时，只空对空而不落到纸面上是不可以的。过去，在面向过程的时代，我们绘制DFD图、流程图，以及编写流程说明来描绘这一部分分析；而现在，在面向对象的时代，我们则是绘制行动图、状态图，以及编写用例说明来完成这部分工作。在这部分工作中，编写用例说明应当是最主要的工作，之后在一些关键部分辅之以行动图、状态图。现在我们来看看用例说明应当怎样编写。毫不疑问，做用例分析首先是

——对用例模型及其应用的一次有益的探讨前言：这是一次对用例模型的探讨。怎样建立用例模型，怎样编写用例说明，它与需求规格说明书有什么区别，它能替代需求规格说明书吗？也许在这里可以找到你要的答案。进入软件业稍微久一点儿的人恐怕都不会陌生，软件开发的最初阶段都是谈需求、写需求规格说明书。需求规格说明书是与客户最终确认到纸上的，非常正式的公文。软件开发应当做什么，做成什么样子，什么东西不做，项

给大家几个建立用例模型中常出现的问题和应对遵循的原则：一．如何发现用例经过以上的讲解，相信大家对建立用例模型有了一个整体的概念，然后开始着手练习绘制用例模型。这时候，一个非常严峻的问题出现了：如何发现用例。大师曾经给出了答案，大致意思就是：首先选择系统边界，然后确定主要参与者，定义满足用户目标的用例，为其命名。然而，我在实践中证明，这套方法过于理论，并不实用。也许，我们换一种思路会更加符合

当需求分析结束、需求确认完成、需求讨论告一段落的时候，我们的需求分析员拿出了厚厚的一打用例分析模型、领域设计模型，需求分析阶段结束，开始进入开发阶段。但是，这时候虽然需求分析阶段结束了，却千万不要以为需求分析就结束了，如果你还这样认为，说明你还没有摆脱瀑布式开发的思维。瀑布式开发的思维的关键点就是认为，需求分析阶段应当完成所有的需求分析和确认的工作，否认需求分析阶段以后还会变更需求。拥抱变化是现代

前面我们讲了如何从业务领域获取知识，创建领域模型，那么建立领域模型应当注意什么呢？建立领域模型应当注意的问题1．领域模型不是数据模型，也不是软件对象模型一个创建领域模型的过程中非常容易犯的错误就是，将领域模型当成了数据模型，或者软件对象模型。领域模型，又称为概念模型、领域对象模型或分析对象模型，是“专用于解释业务领域中重要的‘事物’和产品”[RUP]。领域模型专注于现实世界的对象（概念

前面讲了为什么我们要使用分析模型，现在我们看设计分析模型的基本原则。分配职责和职责驱动设计 我们在开始分析模型的时候，首先要弄清楚一个非常重要的原则，就是以职责为中心。OO分析设计的核心原则之一，就是软件系统中的所有元素都必须具有高度相关的职责，也就是说，软件系统中所有的模块、包、对象类，都应当拥有一个清晰的职责，并且与它相关的所有元素（即模块中的所有包、包中的所有对象类、对象类中的所有属

前言：你写过用例模型吗？也许有；你写过领域模型吗？也许还没有。在这里，我们可以尝试写写领域模型，看看它的作用、带给我们的好处。随着RUP在中国的传播，人们开始尝试用RUP统一过程来指导软件的设计和开发，但这些尝试并不成功。比较普遍的，大家都开始使用用例模型来进行需求阶段的分析和设计了。当然，能做出第一步已经非常不错了，但这远远不够。要做好需求分析，用例模型可以帮助我们分析清楚软件需求中要求

需求需要表达出来（将需求文档化），其表达方式有多种多样。近年来，使用“用例”来表达已逐步成为主流，特例是“用例”的图形符号是UML的基本符号之一，纳入了面向对象的分析与设计的标准化体系中。　　用例(use case)有如下特点：　　用例是需求开发的结果，它的表述形式使它在这些方面的作用更加突出：a、涉众交流的工具；b 、开发与测试的依据；c、具有重用性（作为今后类似需求的参照和重用）。

今天把项目的第二部分的需求用例提交给了客户，从公司CTO前辈的口中得知客户还是较满意的，这周的任务也算圆满完成了。这几天病得越来越厉害了，看来我得在开发任务下来前好好休息休息了。今天我就先把我对分析和书写需求文档进行一个简短得总结。    在写需求用例的之前，一定要对所涉及的业务流程有一个比较完整认知，最好先和客户进行一次交流。    现在就可以写需求用例了。主要分为一下几个步骤：

用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。当用例视图在外部用户出现以前出现时，它捕获到系统、子

购物网站需求分析发布时间: 2012-10-08 13:55    浏览: 386 ——功能性业务要求4．1购物网站首页展示网站总体格局，发挥导航作用。它包含商品购物模块、商品搜索模块、商品后台管理模块、用户管理模块、新闻信息管理模块。以上模块可便于顾客了解购物网站的主要功能，以便进行有效的操作。业务需求需求编号需求内容

微信的平台化发展方向是否真的会让这个原本简洁的产品变得臃肿？在国际化发展方向上，微信面临的问题真的是文化差异壁垒吗？腾讯高级副总裁、微信产品负责人张小龙给出了自己的回复。　　日前，最新一期《腾讯月刊》刊发了以《产品之上的世界观》为题的张小龙专访，其中，张小龙从实践经验出发，分享了他对互联网产品开发的体会，以及微信下一步的思考。腾讯科技从中精选了核心内容，希望通过张小龙的所思所想让产品经理、业务

1、也许会买东西，第一感觉是否不错？    2、也许会买东西，但不知道这家网站怎么样？评价如何？    3、也许会买东西，就看是否有很多其他网站没有的好东西？    4、也许会买东西，就是看看是否有自己喜欢的东西？    5、也许会买东西，就是看看是否有大优惠？    6、想买东西，但不知道该买什么样的？    7、想买东西，但这个网有没有我需要的？    8、想买东西

http://www.balsamiq.com/Organization name:leexij@gmail.comSerial Key:eNrzzU/OLi0odswsqslJTa3IzHJIz03MzNFLzs+tMTQyNrcwsTQyAIEa5xpDAIFxDy8=   转载：http://lynncheng3.diandian.com/post/2013-

前面我们讨论了，需求分析工作是一个迭代的过程：需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始，也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作？但是，非常遗憾，按照我以往的经验，需求捕获是我们最薄弱的环节。前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题，而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整

另一种就是客户压根儿没有想到的需求。也许你会提出这样的疑问，客户压根儿没有想到的需求我们还提出来做什么？这种压根儿没有想到的，实际是在业务需求阶段压根儿没有想到的，并不代表最终都没有想到。很多开发人员总在埋怨，说客户需求总是在软件项目的后期改来改去，为什么？客户并不是软件研发领域的专业人员。在业务需求阶段，由于没有可以展示和操作的实物，客户总是在空对空的凭空想象今后的软件应当做成什么样子。这就注定

原文分析法（Textual Analysis），是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。当我们完成了用例图的绘制，为每个用例编写出用例说明以后，原文分析的工作就可以开始了。要讲解原文分析，我们还是用一个实例更简单明了：这是一个实际项目的用例说明。在进行原文分析的时候，我们首先要做的事情就是对用例说明中事件流部分的文字描述，提取其中

我们将从客户调研现场拿回来的需求，经过一番功能角色分析，整个系统的整体脉络与轮廓已经被勾画出来。在这个过程中，我们首先将系统划分成了几个功能模块（如果系统规模较大，还应先划分为几个子系统，然后再划分出各个功能模块）。然后，我们为每个功能模块绘制用例图。用例图是站在用户角度去观察的系统，即系统为用户提供了哪些功能，这就是功能分析。同时，这些功能是为哪些用户服务的，这就是角色分析。我们绘制的用例图应当

前面我一直在反复强调这样一个观点，需求分析不是一蹴而就的，是一个反复迭代的过程。它将从第一次需求分析开始，一直持续到整个项目生命周期。为什么这样说呢？让我们一起来分析分析。在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获••••••需求捕获，就是我们与客户在一起开研讨会，讨论需求的

前面我们探讨了业务研讨会应当怎样组织，下面我们再具体讨论一下我们应当怎样与客户讨论业务需求。如果说组织业务研讨会是项目经理的功底，那么讨论业务需求就是需求分析人员的功底。以往我们常常认为，需求分析是一件最简单的事情。客户说他们需要做一个什么软件，有些什么功能，我们照着做就可以了，所谓的需求分析员就是需求的记录员。我要说，这是一个极大的错误，许多失败的软件项目，或者说软件项目中的需求问题，大

很多需求分析的工作是从需求调研开始的，我们就从这里说起吧。需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。在一个阳光明媚的下午，项目经理带领着项目组成员，参加了客户组织的见面会，一个新的软件研发项目就这样开始了。双方在一种友好的气氛中进行，相互寒暄，介绍与会

曾经有项目组拿着用户编写的原始需求就开始开发，随后状况不断，一次令人崩溃的研发过程。拿着用户编写的原始需求，编写我们自己的需求规格说明书，之所以重要，就在于用户编写的原始需求，是脱离了技术实现，编写的一份十分理想的业务需求。理想与现实总是有差距，我们之所以要编写自己的需求规格说明书，就是要本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。这就是

常常听到许多朋友跟我埋怨，需求分析之难，就在于用户自身就常常弄不清楚自己的需求。起初在需求确认的时候说得好好的，一到软件上线的时候就不是那么回事了，这可没法整。但我们只要坐下来仔细分析就会发现，在需求分析的时候我们跟用户是在空对空地讨论问题。用户不是专业人士，他也搞不清楚软件到底会做成啥样，所以你跟他确认的时候他就点头了。但是，用户不是傻子，当你软件上线时，他拿到了实物了，知道软件做成啥样了，一旦

现在我举一个具体实例来看看需求列表是怎样编写的吧。这是一个公司内部的评审系统，它分为制订评审计划、执行评审、制作评审报告与问题跟踪四部分。经过初次与评审人员的业务讨论以后，我们整理出这样一个需求列表：1．评审发起人填写一份评审计划，详细记录评审时间、评审内容、评审者、评审地点，制订评审组长，并预计评审工作量，发起一个评审任务。2．评审者在收到邮件后，进入评审任务中，对评审内容进行评审，

需求分析是一个我们与客户不断沟通的过程，这个过程就如同我们与老板的一次对话。老板把你叫去，给你交待了一大堆任务。我们首先是仔细聆听任务的内容，然后整理个一二三四。然后我们复述一遍老板的意思：“老板，我复述一遍，您看看我理解得对不对。首先，您要求我×××，然后×××，最后×××。”老板：“恩，就是这意思，你照着办吧。”之后，我们开始了我们的工作。这个复述的步骤相当重要，因为人与人的沟通最大的问题就是

我曾经看过许多关于需求分析的书籍，老外写的，国人写的，都有。但我总体就是一个感觉：累。各种各样的分析、各种各样的视图，让人眼花缭乱。为什么会这样呢？不得不说，需求分析是一个太宽泛的概念了，不同的行业（商业的、管理的、游戏的），不同类型的软件（底层的、桌面的、网络应用的），不同的设计方式（面向过程的、面向对象的），需求分析的过程都存在着巨大的差异。要制订放之四海而皆准的方法谈何容易。即使同一类型的软

2007年，世界级的软件分析大师Eric Evans发表了他的经典著作《领域驱动设计》，进而形成了一套独特的软件分析与设计方法，简称为DDD（Domain-Driven Design）。在领域驱动设计思想中，有许多是涉及到需求分析领域的先进方法，我把它归纳为有效建模、统一语言和持续学习。有人说：大师所站的高度实在太高了，是生活在太空里的，所以我们要追随大师就只有因为缺氧而死掉。我认为这句话

在需求分析工作中，最后一项分析工作就是业务领域分析啦。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。前面我们谈到了功能角色分析，或者说用例分析，它是从整体的角度对整个系统人机交互的分析与整理。随后我们谈到了业务流程分析，它是在对系统人机交互的分析与整理的基础上，更加细致的去分析和整理那些业务流程，以及组成这些流程的一个个业务操作。业务流程分析是对系统进行的一种动态

前面，我们耗费了大量的篇幅来讨论用例分析及用例图。用例图，无疑是功能分析、角色分析，以及流程分析的利器，它将我们要开发的系统，清晰而详尽地描述出来。但是，正如任何事物都有两面性，用例图也不例外，也有自己不利的一面。在我看来，这集中体现在两个方面：只见树木不见森林、不生动形象。什么叫“只见树木不见森林”呢？就是说，用例说明中对业务流程的描述，过早地将系统的整体流程，分散到了各个用例中了，丢失

用例模型作为UML中4+1视图中非常重要的一员，非常集中地体现了面向对象的分析与设计思想。用例模型将现实世界中连续的一个一个业务流程，按照场景划分到了一个一个的用例中。由于场景的出现，使得用例中的业务流程存在着高度的内聚性，从而成为了日后各种对象的雏形。同时，在用例分析中，又将那些存在于各个用例中的，相同或相近的业务操作提取出来，形成一个一个的子用例或扩展用例，又体现了面向对象设计中的复用性。现在

在我以往的用例分析中，使用这样格式的用例模式，对于大多数业务操作流程来说是得心应手的，但对于有些功能来说总感觉不对劲。感觉不对劲的，就是那些查询、汇总与报表功能。对于这部分功能，需要我们描述的不是什么操作流程，而更重要的是那些数据项、数据来源、报表格式、数据链接，以及使用者、使用频率的说明。而这些，在以往的用例说明格式中统统都没有，怎么办呢？俗话说“东西是死的人是活的”，把我们的用例格式改改吧。

另外，业务流程分析的另一个重要的分析内容就是流程差异化分析。不同的领导有不同的思路，不同的单位有不同的情况。因此，我们在进行流程分析的时候，常常面临流程差异化的问题。我们说企业信息化就是一次改革，这首先体现在业务流程的规范化操作，也就是消除这种流程差异。但不同的单位有不同的情况，这特别体现在不同地域和文化的不同，又常常造成这种流程差异不可避免。分与合，分治与一统，常常是一个都要兼顾的问题，非常微妙

在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。但是，当我们经过一番

软件需求的概念　　（1）宽泛地讲，需求来源于用户的一些"需要"，这些"需要"被分析、确认后形成完整的文档，该文档详细地说明了产品"必须或应当"做什么。　　（2）是用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。　　（3）期望？！ 一种心理活动、笼统、不细致、不懂过程　　需求的重要性　　（1）Frederick Brooks在他1987年经典文章"