写系l用例是Z更清晰的展示pȝ的业务场景的功能实现。也是ؓ了给E序员参考的一个图。同时也是与客户沟通的桥梁。很多东西，千言万语Q不如一张图那么直观。但在很多项目中Q用例分析这个过E被忽略而过?br />
E序员往往只看到文本的需求，p己开始做了，对于项目或许这样可以，如果是大目Q后期肯定崩溃?br />
一个良好的pȝ用例Q用囑Ş的方式描qC客户的要求：
1. 有那些hd与这个事件?br />
2.q些人具体要做什?Q可以理解ؓ调用的方法）
3.q些人做q个事情Q需要什么先x?(可以理解为参敎ͼ包括权限{等)
4.q些在做q些事情的时候，需要第三方帮忙吗？或者需要第三方pȝ接口吗？
5.做完q些事情Q应该达C个什么样的目的，也就是结果，q个l果会是下一个用例的输入吗？
当你有着人物Q事Ӟ参数Q输入，输出的一张图 摆在眼前的时候，所有的事情的都清晰了?br />
看着q张图，可以写?相关的接口程序，实现Ҏ{?br />
通过大量的系l用例，可以提取出公q用例Q比如权限等。从而抽象出公共的实现方法，才不会导致同一个方法，不同的程序员各自实现了一套?br />
以图书ؓ例子Q列表说明一个用例的主要部分Q以及要表达清楚的地斏V?p>
用例名称 | bu_借阅图书 |
用例描述 | 借阅人通过此用例向pȝ查询q提交借书h |
执行?/span> | 借阅?/span> |
前置条g | 1. 借阅人借阅证g在有效期?/span> 2. 借阅人没有逾期未归q的图书 |
后置条g | 1. 创徏借书定单 2. 更新借阅人借阅记录 |
主过E描q?/span> | 1用户用借阅证提供的帐号dpȝQ计机昄我的图书馆界?/span> 2.用户选择查询图书Q计机昄查询界面 3.用户按书名、作者、出版社查询Q计机昄查询l果 4.用户可单选或多选书本，q确认借阅。计机昄认借阅图书清单?/span> 5.用户选择认借阅Q计机昄借阅定单及费?/span> 6用户选择提交定单Q计机昄提交l果和定单号 7.计算机执行后|条件。用例结?/span> |
分支q程描述 | 2.1.1用户选择查看原有定单Q计机执行4; 4.1.1用户可单选或多选书本，攑օ借书，计算机显C借书现有内?/span> 4.1.2.1.1用户选择l箋借书Q计机执行2Q?/span> 4.1.2.2.1用户选择提交借书，计算机执?span>4 4.2.1 用户选择攑ּQ计机执行2Q?/span> 6.1.1用户选择保存定单Q计机保存q执?span>1Q?/span> 6.2.1用户选择攑ּQ计机执行1Q?/span> |
异常q程描述 | 1.1.1借阅证已q期Q拒l登录，用例l束 1.2.1借阅人有逾期未归q书本，启动bu_归还图书用例 5.1.1用户余额不Q计机昄余额和所需金额 5.1.2.1.1用户选择l费Q启?span>bu_交纳借阅费用?/span> 5.1.2.2.1用户选择攑ּQ计机执行1 |
业务规则 | 4.臛_选择一?span>,臛_选择三本 |
涉及的业务实?/span> | Be_费用记录 Be_图书 Be_借书?/span> Be_借阅定单 Be_借阅?/span> |
]]>
]]>
]]>
t踏实实地做具体工作Q这没有错。但只会q样那错大了，因ؓq永q只是新手的方式Q仅靠这个，永远也成不了高手。甘心一辈子本本分分只当个菜鸟，到头来，肯定q菜鸟也做不成，现在的职场，逆水行舟Q原C动，早晚被浪打翻?
标志二、不会踏t实实地工作
q轻人喜Ƣ惻I本n也没错。但若是一天到晚光qLQ那麻烦了。脱M现实Q好高骛q，白日做梦Q眼高手?#8230;…漫步云端的感觉是不错Q但梦醒时分Q从云上跌落_n骨的时候，p悔莫及了?
标志三、瞧不v上司
受过高等教育的h都清高，别h不如自己的地方很Ҏ攑֜眼里Qƈ嗤之以EQ尤其是寚w对{让不如自己的h来领D己，实在不公q뀂但是，领导之所以是领导Q就有原因，不管合理不合理都存在了。也总学识不行Q也许能力不行，但他赢可能就赢在关系上了Q可能就赢在心机上了Q好的也好，坏的也ŞQ都是实实在在存在的现象?
标志四、崇拜上?
相比起刚才的q种行ؓQ对上司盲目崇拜Q则更显得幼E。对上司的话全盘接受Q无条g服从Q缺乏了L的分析能力，最l会让你在职Zq失自我?
标志五、容易被Ȁ发、被感动、被忽悠
有些人比较感性，我本Z是这栗对于领g些比较有煽动性东西，难以抵制Q很Ҏ用头脑发热。但无论如何Q事后一定要冷静思烦思烦Q站在不同的角度来考虑考虑问题Q切莫一时意气用事?
标志六、甘当云梯默默无?
甘当云梯Q默默无闻，q本是一U很高尚的情怀。在如今更是隑־。但隑־归难得，天不佑此cMhQ生zM助此cMhQ时代更是难ҎcMh。对q种人，只能_老兄Q别那么单纯了?
标志七、习惯忍?
喜欢争斗的h让h厌恶Q但现在的职ZQ也只是q种人才得势。h善被人欺Q习惯忍让，别h会觉得你好欺负，q已l成为现在职Z的一U思维定势了。谁也打不破它?
标志八、锋芒毕?
有h则相反，不忍不让Q锋芒毕霌Ӏ这也不好，q样会树敌太多，而且太容易让人看透，很容易中了别人的招儿。适当的时候露露锋芒，展示一下自q立场可以了Q大多数的情况，q是应该韬光L的?
标志九、排斥关p?
q几q来Q新兴v一门学问，叫做关系学。这里面学问可大了，大到关系职场中的Ҏ面面。可有h是排斥它，认ؓ靠自q打拚已l够了。其实，职场不比学术Q不是把自己兛_实验室里p出成果的Q闭门造RQ最l自食苦果?
标志十、知无不aa无不?
对别Z么都_而且什么话都说真的Q这很诚实，但太不成熟了。职ZPp下棋一P可能地Ҏ的心理，而不是尽可能地让别h了解自己的心理。道理很显?br />
]]>
目正式开发前创徏原型可以帮助用户和开发者理解系l，使用WireframeSketcher在Eclipse中创够更好的集成q入你的目开发流E?/p>
WireframeSketcher 如何工作Q它提供了一个pre-drawnQtext-driven 预制图，文本驱动的widgetsQ能够展现通用UI界面Q你可以拖拽他们q入~辑器迅速画Z的界面。界面用XML存储?/p>
本篇开始之前先扯点闲话Q商业应用系l开发经历了三个阶段Q?br />
W一个阶D以计算Z心，分析设计围绕E序的运行效率，法优劣Q存贮优化来q行?0q代的大学课E讲的都是这些?br />
W二阶段以数据ؓ中心Q分析设计围l数据流q行Q以数据程来模拟业务流E。这也就是所谓的面向q程的分析模式?br />
W三阶段以hZ心，分析设计围绕人的业务需求，使用要求Q感受要求进行。这也就是现在的面象对象分析模式?br />
使用OOҎ建立商业模型必须先定义涉众。商业系l无论多复杂Q无Z么行业，其本质无非是人，事，物，规则。h是一切的中心Qh做事Q做事生物Q规则限制h事物。h驱动pȝQ事体现q程Q物记录l果Q规则则是控制。无论OO也好QUML也好Q复杂的表面下其实只是一个简单的规则Q系l分析员弄明白有什么hQ什么h做什么事Q什么事产生什么物Q中间有什么规则，再把人，事，物之间的关系定义出来Q商业徏模也基本完成了。这时候可以说Q系l分析员已经完全了解了用户需求，可以q入pȝ建模阶段了?br />
书归正传Q上笔者归U了一些典型的涉众cd及他们的普遍期望。接下来Q就是要他们这些期望定义出来。这个过E，是业务用例获取的过E。笔者可以跟大家分n的经验是通过以下步骤q行Q这些步骤ƈ非唯一正确Q对于经验不多的pȝ分析员来_q些步骤很有指导意义?br />
W者做了一个徏模实例，有需要有读者请到笔者的BLOG资源中心下蝲Q实例以上一所q网上图书馆需求ؓ蓝本建立了业务用例模型，之后的概忉|型、系l模型则抽取了其中的借阅q程作ؓ例子。不记得了可以后头找找?br />
建模W一步，从涉众中扑և用户。ƈ定义q些用户之间的关pR在ROSE中，应该使用business actor cd。参考上一的需求描qͼ下蝲实例
W二步，扑և每个用户要做的事Q即业务用例Q在ROSE中应使用Business use casecd。请参考《用例的cd与粒度》一文以帮助定用例的粒度。笔者强烈徏议ؓ每一个business actorl制一个业务用例图Q这能很好的体现以hZ心的分析模式Qƈ且不Ҏ漏掉business actor需要做的事。至于以参与者ؓ中心的视囑֮易漏掉某个业务用例的参与者的担心Q可以在W四步中得到消除。下载实?br />
W三步，利用业务场景囑ָ助分析业务流E，在ROSE中，q个阶段最好用活动图Activity diagram。在q个阶段Q业务场景图非常重要Q在l制q程中，pȝ分析员必采用第一步中定义的用户名字作为泳道名Q用第二步中定义的业务用例名作为活动名来绘制。必这么做的原因是Q如果你无法把利用已l定义出来的 business actor ?business use case完备的描l业务流E，那么一定是前面的定义出问题了，你需要回头审视是?business actor ?business use case定义不完善或错误。如果不是所有的business actor ?business use case 都被用到Q要么应该检查业务流E调研时漏了什么，要么应该查是否定义了一些无用的business actor ?business use case 。同Ӟl制业务场景图也非常有助于选择合适的用例_度q保持所有的用例都是同一_度。下载实?br />
W四步，l制用例场景图。与业务场景图不同的是，用例场景囑֏针对一个用例绘制该用例的执行过E。笔者仍然强烈推荐用activity diagram。在用例场景囄l制中，必须使用W一步中定义的业务用户作为泳道。必这么做的原因是Q它能帮助你发现在定义业务用例图时的错误Q比如是否漏掉了某个业务用例的潜在用者。不是每个业务用例都需要绘制场景图Q只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍焉要在业务用例规约文档中写明。下载实?br />
W五步，从第三步或第四步中绘制的zd图中扑ֈ每一步活动将使用到的或生的l果。这是找到物的过E。找到后Q应当徏立这些物之间的关pR在ROSE中，q称Z务实体模型。应该用business entity cd。下载实?br />
W六步，在上q过E中Q随时补充词汇表Glossary。将此过E中的所有业务词汇，专业词汇{一切在建模q程中用到的需要解释的名词。这份文档将成ؓ模型建立Z读者就模型达成一致理解的重要保证?br />
W七步，Ҏ上一中提到的业主，老板{涉众的期望审视建立好的模型Q确定业务范_军_哪些业务用例在系l徏设范围内。那些不打算U_范围内的业务用例有两U情况，一U是该业务用例是被调用一方，那么应该把它改ؓ boundary cdQ意味着来它是一个外部接口。另一U是该业务用例主动调用系l内业务用例Q那么应该将它改为business actorcd。与普通business actor不同的是Q由业务用例转换而成的business actor不是人，而通常是一个外部系l进E，因此应该在被调用的系l内业务用例与它之间增加一个boundary元素Q意味着我们的系l将样一个外部进E提供一个接口。严格来_那些需要纳入徏设范围的business use case 应当对应的生成一?business use case realizationQ?以后的设计工作将归纳到这些实现用例中。但W者觉得这一步ƈ非很关键的，实际中本Zl常省略q一步，而将协作图，象活动图Q类交互囄直接在business usecase下说明。不q本实例中笔者还是按照正规方法来建模的。下载实?br />
需要说明的是，上述的步骤ƈ非一ơ性完成的Q在每一个步骤中都可能导致对以前步骤的调整。即使徏模已l完成，当遇到变化或发现新问题时Q上q步骤应当从头到ֆ执行一ơ。这也是RUP倡导的P代开发模式?br />
l过以上的步骤，我们已经建立了一个完整的业务模型。但q决不是建模工作的全部，以上q程只说明了建立一个完整业务模型的q程Q不能说q样徏立了一个很好的业务模型。因Zq的q程中ƈ没有提及业务分析q程。分析过E全凭系l分析员的经验，对OO的理解和对行业业务的把握能力Q对原始业务模型q行归纳Q整理，抽象Q重构，以徏立一个更高效Q合理，扩展性更强的模型。这个过E无法以步骤说明。或总后笔者会专门针对模型分析写点东西。另外除了模型，q至需要写业务架构文档、用例规U和补充用例规约三种文档。因为模型虽然可以较好的体现业务架构Q但很不好表达业务规则和非业务需求，q些需要在文档中说明。例如用例的前置条g和后|条件就是一U业务规则。读者可以在RUP文档中找到这些文档的模板?img src ="http://www.aygfsteel.com/paulwong/aggbug/382215.html" width = "1" height = "1" />
]]>
本篇开始之前先扯点闲话Q商业应用系l开发经历了三个阶段Q?br /> W一个阶D以计算Z心，分析设计围绕E序的运行效率，法优劣Q存贮优化来q行?0q代的大学课E讲的都是这些?br />
W二阶段以数据ؓ中心Q分析设计围l数据流q行Q以数据程来模拟业务流E。这也就是所谓的面向q程的分析模式?br />
W三阶段以hZ心，分析设计围绕人的业务需求，使用要求Q感受要求进行。这也就是现在的面象对象分析模式?br />
使用OOҎ建立商业模型必须先定义涉众。商业系l无论多复杂Q无Z么行业，其本质无非是人，事，物，规则。h是一切的中心Qh做事Q做事生物Q规则限制h事物。h驱动pȝQ事体现q程Q物记录l果Q规则则是控制。无论OO也好QUML也好Q复杂的表面下其实只是一个简单的规则Q系l分析员弄明白有什么hQ什么h做什么事Q什么事产生什么物Q中间有什么规则，再把人，事，物之间的关系定义出来Q商业徏模也基本完成了。这时候可以说Q系l分析员已经完全了解了用户需求，可以q入pȝ建模阶段了?br />
书归正传Q上笔者归U了一些典型的涉众cd及他们的普遍期望。接下来Q就是要他们这些期望定义出来。这个过E，是业务用例获取的过E。笔者可以跟大家分n的经验是通过以下步骤q行Q这些步骤ƈ非唯一正确Q对于经验不多的pȝ分析员来_q些步骤很有指导意义?br />
W者做了一个徏模实例，有需要有读者请到笔者的BLOG资源中心下蝲Q实例以上一所q网上图书馆需求ؓ蓝本建立了业务用例模型，之后的概忉|型、系l模型则抽取了其中的借阅q程作ؓ例子。不记得了可以后头找找?br />
建模W一步，从涉众中扑և用户。ƈ定义q些用户之间的关pR在ROSE中，应该使用business actor cd。参考上一的需求描qͼ下蝲实例
W二步，扑և每个用户要做的事Q即业务用例Q在ROSE中应使用Business use casecd。请参考《用例的cd与粒度》一文以帮助定用例的粒度。笔者强烈徏议ؓ每一个business actorl制一个业务用例图Q这能很好的体现以hZ心的分析模式Qƈ且不Ҏ漏掉business actor需要做的事。至于以参与者ؓ中心的视囑֮易漏掉某个业务用例的参与者的担心Q可以在W四步中得到消除。下载实?br />
W三步，利用业务场景囑ָ助分析业务流E，在ROSE中，q个阶段最好用活动图Activity diagram。在q个阶段Q业务场景图非常重要Q在l制q程中，pȝ分析员必采用第一步中定义的用户名字作为泳道名Q用第二步中定义的业务用例名作为活动名来绘制。必这么做的原因是Q如果你无法把利用已l定义出来的 business actor ?business use case完备的描l业务流E，那么一定是前面的定义出问题了，你需要回头审视是?business actor ?business use case定义不完善或错误。如果不是所有的business actor ?business use case 都被用到Q要么应该检查业务流E调研时漏了什么，要么应该查是否定义了一些无用的business actor ?business use case 。同Ӟl制业务场景图也非常有助于选择合适的用例_度q保持所有的用例都是同一_度。下载实?br />
W四步，l制用例场景图。与业务场景图不同的是，用例场景囑֏针对一个用例绘制该用例的执行过E。笔者仍然强烈推荐用activity diagram。在用例场景囄l制中，必须使用W一步中定义的业务用户作为泳道。必这么做的原因是Q它能帮助你发现在定义业务用例图时的错误Q比如是否漏掉了某个业务用例的潜在用者。不是每个业务用例都需要绘制场景图Q只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍焉要在业务用例规约文档中写明。下载实?br />
W五步，从第三步或第四步中绘制的zd图中扑ֈ每一步活动将使用到的或生的l果。这是找到物的过E。找到后Q应当徏立这些物之间的关pR在ROSE中，q称Z务实体模型。应该用business entity cd。下载实?br />
W六步，在上q过E中Q随时补充词汇表Glossary。将此过E中的所有业务词汇，专业词汇{一切在建模q程中用到的需要解释的名词。这份文档将成ؓ模型建立Z读者就模型达成一致理解的重要保证?br />
W七步，Ҏ上一中提到的业主，老板{涉众的期望审视建立好的模型Q确定业务范_军_哪些业务用例在系l徏设范围内。那些不打算U_范围内的业务用例有两U情况，一U是该业务用例是被调用一方，那么应该把它改ؓ boundary cdQ意味着来它是一个外部接口。另一U是该业务用例主动调用系l内业务用例Q那么应该将它改为business actorcd。与普通business actor不同的是Q由业务用例转换而成的business actor不是人，而通常是一个外部系l进E，因此应该在被调用的系l内业务用例与它之间增加一个boundary元素Q意味着我们的系l将样一个外部进E提供一个接口。严格来_那些需要纳入徏设范围的business use case 应当对应的生成一?business use case realizationQ?以后的设计工作将归纳到这些实现用例中。但W者觉得这一步ƈ非很关键的，实际中本Zl常省略q一步，而将协作图，象活动图Q类交互囄直接在business usecase下说明。不q本实例中笔者还是按照正规方法来建模的。下载实?br />
需要说明的是，上述的步骤ƈ非一ơ性完成的Q在每一个步骤中都可能导致对以前步骤的调整。即使徏模已l完成，当遇到变化或发现新问题时Q上q步骤应当从头到ֆ执行一ơ。这也是RUP倡导的P代开发模式?br />
l过以上的步骤，我们已经建立了一个完整的业务模型。但q决不是建模工作的全部，以上q程只说明了建立一个完整业务模型的q程Q不能说q样徏立了一个很好的业务模型。因Zq的q程中ƈ没有提及业务分析q程。分析过E全凭系l分析员的经验，对OO的理解和对行业业务的把握能力Q对原始业务模型q行归纳Q整理，抽象Q重构，以徏立一个更高效Q合理，扩展性更强的模型。这个过E无法以步骤说明。或总后笔者会专门针对模型分析写点东西。另外除了模型，q至需要写业务架构文档、用例规U和补充用例规约三种文档。因为模型虽然可以较好的体现业务架构Q但很不好表达业务规则和非业务需求，q些需要在文档中说明。例如用例的前置条g和后|条件就是一U业务规则。读者可以在RUP文档中找到这些文档的模板?br />
http://hi.baidu.com/parryblog/blog/category/%CF%B5%CD%B3%B7%D6%CE%F6
http://hi.baidu.com/parryblog/blog/category/%D0%E8%C7%F3%B7%D6%CE%F6
]]>
在第一ơ的需求分析阶D，我们在一D|期内需要与客户q行反复地讨论，q个q程往往是这样一个反复@环的q程Q需求捕?>需求整?>需求验?>再需求捕?#8226;•••••
需求捕P是我们与客户在一起开研讨会，讨论需求的zd。客户可能会描述他们的业务流E，q时我们在纸上绘制简单的程草图Q及时地记录下来Q客户在描述业务的同Ӟ可能会反复提C些业务名词，详细询问q些名词的含义，以及它们与其它名词的关系Q用cd或者对象图l制单的草图Q客户在描述业务的同Ӟq会提出今后的Y件希望实现的功能Q如能够展示某个报表、能够导出文Ӟ以需求列表的形式记录下来。一个功能，在需求列表中会有多个需求，而每个需求应当能够用1?句话Q在20个字以内可以描q清楚。需求列表是客户提出的最最原始的需求，他不掺杂M分析设计Q是我们的每功能必d现的内容。需求列表是需求验证以及日后的用户验收试的依据，不论我们今后如何分析和设计这些功能，都要能如实地实现q个列表中提出的需求。（需求列表应当如何编写，在后面的章节详l描q。）
需求整理，是在需求研讨会后，需求分析h员对研讨内容的分析和整理的过E。首先，需求分析h员应当通过用例模型Q划分整个系l的功能模块Q以及各个模块的业务程。用例模型分析是一个由_到l的q程Q这样一个过E也是符合hc认识世界的思维习惯的一个过E。最先，我们应当Ҏ个系l绘制用例图Q设计用例场景，q依ơ对q些用例q行用例描述、流E分析、角色分析等分析q程。当Ӟ在整体用例分析的同时Q我们还应当q行一个整体的角色分析Q绘制一个角色分析图Q进行一个流E分析，l制一个流E分析图Q可以是传统的流E图、UML中的行动图，甚至一个简单的C意图，{等Q?
然后Q我们再在整体用例图的基上，依次Ҏ个用例绘制用例图。每个用例图中，会更l致地划分出多个用例Qƈ依次q行用例描述、流E分析、角色分析等分析工作。如此这般地不断l化Q直到我们认为需求已l描q清楚ؓ止?
在一个系l中Q用例需要细化几ơ，是由q个用例的业务复杂程度决定的。对于一个简单的用例Q只需要细化一ơ就够了Q而对于比较复杂的用例Q则需要细?~3ơ，甚至更多?
用例分析的过E，之所以称之ؓ分析Q它掺入了很多需求分析h员对业务的理解与设计Q模块如何划分、流E如何设计、业务如何{换，{等。用例分析，q需要让需求分析员与架构师、设计师{技术h员共同协作来完成Q因为用例分析还包含对业务需求的技术可行性分析。只有一份可行的需求分析，才能为后l的设计开发扫清障，有效降低目风险。最后，需求分析员应当需求列表中的内容，逐一C用例q行核对Q以避免分析人员忽略用户的某业务需求。（后面详l描q用例模型的搭徏q程。）
在用例分析的同时Q需求分析h员还需要对业务中的相关事物Q制作领域模型。领域模型，是对用户业务领域中相关事物、相互关pR相互行为操作的描述Q它是以对象囑֒cd的Ş式表辄。需求h员对领域模型的分析，对业务理解的深度Q对日后软g的设计，以及软g的功能扩展、升U演化，都vC臛_重要的作用。（后面更加详l地讲述领域模型。）
最后，当我们完成了一pd的分析整理ƈ形成文档以后Q应当对及时C客户q行反馈Q确认我们的理解是否正确Q也是需求验证工作。需求验证工作应当诏I整个研发周期，q且在不同时期表现出不同的Ş式。首先，在需求分析阶D，需求验证工作表Cؓ寚w求理解是否正的信息反馈。需求分析h员与客户再次坐在一P一一Ҏq我们对需求的整理和理解，客户则时不时地对一些问题进行纠正，或者更加深入地加以描述。我们则认真地记录，回来整理Qƈ{待下一ơ的验证。在需求分析后期，我们q可以制作一些简单的原型Q更加Ş象地描述我们寚w求的理解Q会使我们与客户的沟通更加顺畅。随后的设计开发阶D，我们则应当以q代开发的形式q行。每开发完一个P代周期，开发的成果与客户反馈。这样做的结果是Q客户可以及时地提出我们寚w求理解的偏差Q或者及时提出对我们设计不满意的地方Q我们存在的问题得到及时地发现与解冟뀂问题及时的解决Q我们修复问题的代价得以降x。之后，当开发进入到验收试阶段Q我们则是与客户一道，一一地验证我们的Y件是否满需求列表中要求的业务需求。最后，当Y件迎来下一ơ升U开发时Q我们将开启另一ơ轮回?
因此Q需求分析就是按照这Lq程Q每ơ多理解一些，再多理解一些，更多理解一些，逐渐深入的过E。每深入一步，我们的Y件就更接q客L满意?
我们应当怎样做需求分?/font>
我们应当怎样做需求调研：初识
我们应当怎样做需求调研：拜访
我们应当怎样做需求调研：研讨?/font>
我们应当怎样做需求调研：需求研?/font>
我们应当怎样做需求调研：q代
Q箋Q?
]]>
但更令我印象深刻而难以忘怀的，是我亲自l历的、亲眼目睹的、道听途说的一个又一个的软g目Q它们有的获得了成功Q但更多的是令h沮的失败。套用一下大文豪托尔斯泰体：q福的家庭都是一LQ不q的家庭却各有各的不q；q福的Y仉目都是一LQ不q的软g目却各有各的不q；或者说Q成功的软g目都是一LQ失败的目却各有各的问题。我常常在想Q我们的目开发到底怎么了，q而把它们一个一个的剥开来深入分析，竟然触目惊心。它们有的是需求的问题Q有的是客户关系的问题，q有设计的问题、技术的问题、时间管理的问题、h员培ȝ问题••••••但归根到底更多的q是需求的问题。需求分析既是一份体力活儿，更是一份技术活儿，它既是h际交往的艺术，又是逻辑分析与严密思考的产物。正是我们在需求分析过E存在的巨大隐患Q最l导致了那么多项目的p|。也怽认ؓ我在p耸听Q好吧，我来丑և个典型事例分析分析吧?
我的W一个故事来自大名鼎鼎的东Y。我?005q接一个项目的时候，听说q个目之前是东软做的。当时东软在做这个项目的时候，整个q程l历?0多次l构性的大变_局部性的调整更是不计其数。据说某天早上，客户Ҏ个功能不满意Q他们不得不对几癑֤E序q行修改。之后客户对修改的内容还是不满意Q又不得不将几百处修攚w新改回来。最后这个项目导致的l果是，整个q个目l的所有成员都d了东软，q似乎从此不愿涉Y件开发领域。多么惨痛的教训啊！我常常听到网友抱怨客hL寚w求改来改去，但客户对需求改来改ȝ真正原因是什么呢Q当我们对客L需求没有真正理解清楚时Q我们做出来的东西客户必然不满意。客户只知道他不满意Q但怎样才能使他满意呢？他不知道Q于是就在一点儿一点儿试，于是q种反复变更p样发生了。如果我们明白了q一点，深入地去理解客户的业务，q而想到客L心坎儿上去，最后做出来的东西必然是客户满意的。记住，当客hZ务变更的时候，我们一定不能被客户늝赎ͼ客户说啥是啥。我们要从业务角度深入的d析，他ؓ什么提出变_提得合不合理Q我有没有更合理的方案满个需求。当我们提出更加合理的方案时Q客h乐于接受的，变更也变得可控了?
W二个故事来自我自己的项目，一个早期的目。在q个目中，客户扔给了我们很多他们目前正在用的l计报表Q要我们按照报表的格式做出来。这些报表都是手工报表，许多格式既不规范Q又很难于被计算机实现。这些报表o我耗费了不闹l胞Q直到最l项目失败都没法完成。这件事留给我的深刻教训是，不能客户怎么说Y件就怎么做。客h出的原始需求往往是不考虑技术实玎ͼZ非计机理的操作模式提出来的。他们提出的很多需求常常比较理惌不切实际，毕竟人家是非技术的。但我们作ؓ技术h员，需求分析必d事求是地、基于技术可以实现的角度去考虑。那U?#8220;有条件要上，没有条g创造条?#8221;的鲁莽行事，l果必然是悲惨的。所以我们必要Z技术实现去引导客户的需求。同Ӟ计算Z息化理是一ơ改革，对以往手工理模式的改革。如果我们上了信息化理pȝQ采用的理模式却依然是q去的手工模式，新系l的优势从何而来呢？因此Q我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度d视他们的理模式是否合理Q最后一步一步地dg们按照更加合理的方式L作与理?
2007q_我参与了一个集团信息化的项目。这个项目中的客h一个庞大的体Q他们分别扮演着各种角色。从机构层次划分Q有集团领导、二U机构h员、三U机构h员；从职能角色划分，有高层领对{胦务h员、生产管理员、采购h员、销售h员，{等。在q样一个复杂场景中Q不同h员对q个目的需求是各自不同的。非帔R憄是，我们在进行需求分析的时候没有认真分析清楚所有类型h员的需求。在q行需求调研的时候，L集团领导带领我们到基层单位，然后基层单位各斚w的h员叫来开大会。这L大会Q各cd的h员七嘴八舌各说各自的需求，q有很多基层人员在大会上因ؓӆҎ没有提q需求。这Lq数ơ开会，需求调研就草草收场。我们拿着一个不充分的需求分析结果就开始项目开发，最l的l果可想而知。直到项目上U以后，我们才发现许多更加细节的业务需求都没能分析刎ͼpȝҎ没法q行Q不得不宣告p|。一个Y仉目的需求调研首先必要q行角色分析Q然后对不同的角色分别进行调研。需求调研的最初需要召开目动员大会Q这是十分必要的。但真正要完成需求分析，应该是一个一个的会Q?~3个业务专Ӟ只讨论某个领域的业务需求，q且很多问题都不是能一y而就完成的，我们必须与专家徏立联p，反复沟通后完成。需求分析必遵从的是一定的U学ҎQ而不是盲目的大上快上?
我的最后一个故事可能典型到几乎每个人都曄遇到q。我们的目从需求分析到设计、开发、测试都十分利。但C目q行的后期，快到达最后期限时Q我们将我们的开发成果提交给客户看，客户却对开发不满意Q提Z一大堆修改Q而且q些修改工作量还不小。怎么办呢Q加班、赶工，试旉被最大限度压~。最后项目倒是如期上线了，但大家疲惫不堪，q且上线以后才发现许多的BUG。需求分析不是一y而就的，它应当诏I整个开发周期，不断的分析确认的q程。以上这个事例，如果我们提早开发成果给客户看，提早解决问题Q后面的情况将不再发生。这是敏捷开发倡导的需求反馈。敏捷开发认为，需求分析阶D不可能解决所有的需求问题，因此在设计、开发、测试，直到最l交付客Pq整个过E都应当不停地用开发的成果与客户交，及时获得反馈。只有这h能及时纠正需求理解的偏差Q保证项目的成功?
以上的故事各有各自的不幸Q各自都在不同的开发环节出C问题。但l过深入的分析，各自的问题最l都归结为需求分析出C问题。ؓ了我们今后的Y仉目不会重y覆辙，g真的有必要讨Z下我们应该怎样做需求分析?
]]>