通过用例、用户故事、角色和场景来定义需求――保持项目节奏实践之六

“lulurosemoon”通过精心收集，向本站投稿了3篇通过用例、用户故事、角色和场景来定义需求――保持项目节奏实践之六，这里给大家分享一些通过用例、用户故事、角色和场景来定义需求――保持项目节奏实践之六，供大家参考。

篇1：通过用例、用户故事、角色和场景来定义需求――保持项目节奏实践之六

系列文章目录索引：《保持项目节奏实践：掌控项目节奏，做到了如指掌》

要减少不必要的代码，有一个好方法：想想谁会使用系统，又该如何开发用户需要的系统，

有很多项目都试图通过定义功能性和非功能性需求来确定需求。可是这些需求没有说明一个人如何使用系统，以及一个功能在何种场景下必须运行。需求收集的方法应该为项目团队提供上下文，这样才能深入理解需求。

谁需要那个支票账户？

克拉丽莎，资深经理

我的项目团队陷入困境。他们实现了一堆只开发完一部分的功能，可是没有哪个能够真正运行。我召开了一个会议，以决定接下来该做什么。

在会议上，我想知道：为了完成项目，哪些用户是他们的首要服务对象。他们看着我，脸上毫无表情，

管理资料

“你们看，我们是一家银行。我们希望年满18岁、将要进入大学的人们首先使用我们的服务。还有住在郊外的妈妈们，她们还有其他资产，75岁的老奶奶，以及年方15已经靠做家务挣得零花钱的孩子们。我们可以为他们提供不同的理财服务。如果他们走进来，我们希望他们成为我们的客户。对于这些不同类型的客户，我们真地想过要给他们提供什么样的产品么？”

他们以前太过专注于系统的内部功能，忽视了系统真正要为之服务的用户。我们把期望捕获的用户重新进行了排序，项目团队因此得以完成需求定义，并完成系统的功能。

人，总是人的因素，不是么？

只要大家了解需求的上下文，开发人员、测试人员和文案人员就能知道如何开发、测试、编写文案。如果他们不能了解，要是需求以功能性和非功能性需求的方式罗列，他们也可以问一些更好的问题，从而深入了解需求。

来自：blog.csdn.net/MagBryan/archive//06/13/4266911.aspx

篇2：软件项目需求的关键：分解用例场景

做软件项目需求最重要就是分解用例场景，没有用例就不是需求，软件工程这类书要学，不过软件工程软件项目需求最关键就是用例场景的合理建立，这条，好象没有什么大学教科书谈到，仿佛中国的大学计算机科学系教师统统没有做过软件项目的，完全没有这个概念。所谓的软件项目需求，如果不是变成走不通的伪代码，就是用不上的美工方案，程序员对此除了干瞪眼是没辄的。

其中最大的原因就是从事网站或者类似的软件项目需求的许多人都不懂真正的软件项目需求是什么东西，包括我处理过的SAP/ERP项目这类都是同样的问题，尽管那不是网站;他们犯的一般共同的错误就是把网页表现形式(那其实是美工的工作)，以及内容的采排看作是需求，完全没有一个用例的观念。

用例，usecase，目前多见于UML下的对面向对象程序中的对象行为的表达;不过，这不是它的源泉;它之所以被看作是这类语言的标准URL描述手段，是因为面向对象本身就是在虚拟程序中模拟真实世界那样地工作;而真实世界，就是围绕着用例展开的。用例的观念其实也不能算是一个软件概念，只不过在软件领域定义得最为精确而已，今天从每个人的生老病死，婚姻嫁娶，其实都是一个个的用例的描述和实施。用例，顾名思意，就是假如(假设)出现某种情况，采取什么样的行动;可能会有什么样的结果;然后，根据这个结果，再采取什么样的行动……直到得到希望的某个最终结局。

用例也叫场景，软件，实际上就是对场景操作过程的描述，而不是一堆版面框架网页的集成。没有用例支持就不叫软件，更加不叫项目——连垃圾都算不上。很多时侯我们说需求不明确，其实就是说这个用例不清晰;在电子商务网站中，除了人员素质导致对基本概念方法不明白外，最可能的导因就是商业模式不明确，或者不成立。这个成立与否，实际上可以从上面的假如如何那般的推导中进行初步的可行性推演。所以，程序员实际上有两个层次，一个是你说什么他做什么，但永远没有结果的。他却的确实现了你(需求人员)提出的所有要求，但这个项目却必然是永远没有结果的，因为，它本身只是把这个程序员当成网页编辑用了，项目没有基本用例的支持。我想90%的程序员是这类程序员，没有用例明确定义也就没有软件能力的评估，因为软件人员不是美工。另一种程序员则可以从上诉推演中发现整个项目本身有没有用例，以及用例是否合理(理论上没有明显的逻辑障碍);虽然程序员一般不应该关心商业模式是否合理，但实际上他有这个能力，常常是第一个发现商业模式的问题，假如他也关心的话。

可惜大部分用户需求人员不明白这个道理，反而可能会以为程序员是在推卸责任，或者是刁难需求;也正因为这个原因，需求人员和实现人员的冲突在项目中屡见不鲜，倒不是个人矛盾的冲突，而是由于双方没能有一个基本的立足点。我见过这样的项目，需求人员建一个大型网站的需求就是一大箩的每个网页的非常详细的描述，到每个字每个连接……直至每个网页出现的次序，项目经理说一个笑话：万一他摔一跤，这箩子东西鬼才能再捡回原来的模样。的确，负责需求的客户方副老总和一帮企业需求编辑辛苦做了两个月，但其实这不是需求，而是使用这个项目软件的具体编辑排版的安排;根本不是程序员要看的东西。程序员需要的是使用这个网站时需要有那几种用例逻辑，然后抽象出其中的对象，根据对象建立存储方式(象数据库存储结构)和内容采摘方式。那大箩东东，实际上什么用处也没有的，

开发软件如同建房子，旁观者可能问一句：建房子啊就拍手说明白了，但对于开发员来说，如果得不到准确的房子细到砖砖瓦瓦的准确设计(需求定义);要知道建小平房和建金茂大夏都是建房子，建宾馆还是建殡仪馆也是建房子，到底客户要的是什么房子合适，不搞清楚干下去的程序都是不负责任的，或者是冒牌货。

不懂软件项目需求的需求人员一般会犯如下错误：

一是把版面美工形式看作需求，其实程序员看程序如同医生透过X光看一个人，看到的是骨架，至于是美人还是丑八怪如果能看出来，那个医生一定是变态的;

在开发过程中都强调实现用例功能实现，而不是首先色彩如何花梢漂亮，后者不但不是主要的，也不是次要的，在开发过程中什么都不是;一开始把精力放在这里当成需求实现是浪费时间浪费金钱。

二是把静态网页当成需求，特别是当把静态网页当成prototype时更经常犯这个错误;

常常说：按prototype做出来不就行了?实际上prototype本身如果不是看不出清楚的用例逻辑，就是可能有几种用例解释;何况真正变成动态程序，与静态的东西是不一样的。我在网上看到的美女明星下了台到眼前成了丑八怪，就是这个道理。而且更遭的是，客户还同时犯第一个错误，看着那里不顺眼就改一改版面还一天三变，不知不觉的基本用例就变成了另外一个东西，原来是宾馆现在成了盖殡仪馆，原来搞错了因为不知道躺的人不同叫不同的馆(死人还是活人)，试问，如何实现?项目开始和后期看到的同一个版面成为不同的故事绝对是经常出现的故事，软件上称为需求变迁，这是项目经常延期的最主要原因。

三是需求人员把定制了解成按客户所有想法迎合静态页面，而不是按客户的业务用例要求建立相应的程序;还要求程序员也这样做;

实际上，如果不能拨乱反正的话，任何项目到此为止已经是死路一条：那不是软件，无非是静态网页人员出租!需求人员常犯的另一个错误仍是不懂用例，就是把用例的使用方式当成了需求;这种错误有时连初级程序员都会犯，最典型就是把一个菜单栏目当成需求，而程序员无法从菜单中看出明显的简洁的用例逻辑——这是一个没有意义的菜单，天晓得里头是什么?同样地，里头的要干的东西还一天三变。事实上，同一种逻辑用例可以用到N个栏目，那是软件的使用而不是软件本身。

以上的错误常见于网站建设，所以网站建设最通常的结局是不了了之，大概占了50%以上，无论设入多少钱多少人花多少时间都是如此的;除非有人能够拨乱反正，让项目需求走上正道。而在ERP/DRP这类项目中，需求人员一般情况下是业务的行家，他们反而很容易理解用例是什么东西，象医院收费，绝对不会把精力放在收费界面有没有 女让收费员提神上，收费这个用例有多少个环节是他们理解的。这种项目需求最易犯的错误是让先进的计算机工具重复原始状态下的不合理的流程。最典型的笑话就是：手工审批要盖五个章，用五天时间;现在电算化效率提高了一百倍，所以可以盖五百个章(电子签名呢!)，时间嘛，仍然是五天!在这里，矛盾不是有没有用例，而是用例是不是合理的，最高效率的。

所以对于需求由于用例的冲突，程序员如果不想不了了之最后责任全部背上身的话，最好就是坚持原则；程序员迎合网页编写是没有意义的，迁就需求也不是没有意义的，因为……无法迁就的，越是迁就就越是没有办法实现，或者客户没有办法满意的。软件其实很简单的，无非是分析好用例，然后让计算机一步步实现而已，用例，是所有软件实现的前提：不然，软件到底要干什么?好的软件项目都有一个共同的特点，就是简单的逻辑，明确用例。

篇3：分离需求与GUI设计――保持项目节奏实践之七

系列文章目录索引：《保持项目节奏实践：掌控项目节奏，做到了如指掌》

我们希望系统解决的问题通过需求得以体现，GUI设计是要体现出GUI如何引导用户使用系统以解决他们的问题。很多项目都将GUI设计混同于需求的假面之下，这很让人讶异。如果你的项目总是陷于无尽的需求工作之中，看看问题是不是出在GUI设计上。

GUI是设计，不是需求

凯伦，程序经理

我在一家新公司工作时，试图拯救一个陷入“需求地狱”的项目。需求文档已经达到300多页，而且远未完成。

阅读这些文档后，我找到了原因。所有的GUI设计都被记录在需求文档中。GUI设计没有放在项目的设计阶段，业务分析人员和GUI设计人员试图将所有的GUI需求都放在需求文档中，

管理资料

他们使用了功能强大的图形设计工具，并在需求文档中定义GUI。

我向他们询问原因，他们看着我，说道：“这些是GUI需求。”我建议他们认真看看GUI设计，并且考虑这些设计是否应该跟希望系统解决的问题放在一起。GUI设计不应放在需求文档中。

最终，他们同意采纳我的建议，我们也可以逃离需求地狱了。而且，由于我按照逐个功能重新组织了项目，GUI设计也就跟各个功能结合在一起了。我们定期检查整个GUI的一致性，但是这与需求无关，这属于设计。

人们很容易在项目开始阶段设计GUI，并称其为需求。如果要这么做，项目就永远无法找到自己的节奏。它会一直陷于需求的泥沼之中，直到最后，无法完成任何客户需要的功能，虽然到时候能够得到精美无比的GUI。

来自：blog.csdn.net/MagBryan/archive/2009/06/15/4271003.aspx

【通过用例、用户故事、角色和场景来定义需求――保持项目节奏实践之六】相关文章：

1.按功能实现，而不是按架构――保持项目节奏实践之三