最近这几篇blog里说的内容其实实质上都是usecase。这个理论及具体的方法我也是最近才接触，但感觉非常适合用来做需求，很是有点兴奋:)

1、形式上感觉很一样，而且UML已经有了一套比较成熟的方法和理论已经追随者

2、但本质上的一些思考方式和方法还不一样，

3、实际上很大程度上我们是在借鉴他们处理问题的办法和形式来贯彻UCD的设计方法和思想..
（当然，UCD本身其实就是一种概念和意识， 虽然我们都在试图让他有一套更合理更科学的理论和方法）

我不知道我说清楚了没有。 :) 

这并不是说 UML 建模和 UCD 方法孰优孰劣，看如何运用了。现在越来越多的开发人员使用面向对象、以人为中心的方法去开发，但据我看到大部分操作的时候还是面向过程。。。而且这里所谓的“用户”和 UCD 的“角色”，是不同的，就像 usecase 的 actor 很弹性一样，不具体。

我用usecase做需求的过程中就发现只要涉及到前台界面的usecase或者交互性强的usecase，uml就有些无能为力，用例能帮助用户跟开发人员理解整理需求，能帮助开发人员做设计，但并没有能够很好的帮助ui人员做界面。

但就这篇文章里举例描述的工作流程，我担心会有人误解需求是这么做出来的。这里边的任务分解出来的其实只是界面、交互的需求，描述的过程是流程式的，没有描述异常情况。而异常情况就影响到界面、交互需求，从而改变工作目标。（在这里我想了一想，没想到这3个任务中有什么异常^^，但如果需求中不强调要描述异常情况这个过程，那往往大家做需求时都不考虑这个方面，就大有可能把问题遗留在测试阶段了，严格的说，我不知道每个流程的退出或返回的用户可能的操作算不算０１０２０３中的异常情况）

恩，总之我的观点是，如果能以uml为基础来进行描述，会有助于这套方法论的被接受，也有助于相关人员对整个项目的认识的提高，因为有usecase driven整个一套成熟的思想及例子来让大家明白应该怎么做。但如果大的业务需求、用户需求还是面向过程的，只在界面设计、交互设计这一块的需求面向对象，届时会有风险的。

 几个月前看各位的blog还觉得这交互设计做得是够细致了，但真烦琐，虽然应该这么做但我肯定不会这么做:)

但最近接触了uml的usecase driven的思想后，就觉得恍然大悟，觉得就该这么做，所以才建议各位结合着uml的思想来改进ucd，要怎么得到面向对象的设计，毕竟归根结底还是怎么得到面向对象的需求。

 这里就有两个问题：

１、赋予了使用者名字，这会有助于场景描述，但不有助于系统设计

２、熟练的编辑和新手这样的划分就是纯粹按业务熟练度来分，而这业务熟练度不是永恒的，如果这么划分来做需求，那理论上说，新手一个月后就变成熟练的编辑了。当然如果重心在１里的名字，括号内的身份只是补充说明，那我也能理解。

如果是我分，就会分成普通编辑和高级编辑，普通编辑可以创建调查＼管理调查＼发布调查＼浏览统计，高级编辑除继承普通编辑的操作外，还能关闭调查，写到这里就发现可能有修改统计的需求^^，也许要人工操作统计结果，那这个操作肯定是不能让普通编辑做的，否则风险就大。

如果以这么来划分，使用者的角色就是固定的，我认为人名只是用来帮助描述场景，帮助人理解虚拟的场景事件中是什么样的，具体到任务的时候，还是要映射回来固定身份。

另，感觉siva是程序工程师吧？因为他提到的问题感觉都是编码要是实施的方式，也反映了具体编码实施对ucd工作表现形式的期望。

 三个页面这样排开，加上一些箭头和注释，看起来很清晰。

@mansonjie: 这是根据具体使用情况决定的。根据使用者的角色，该系统要达成的目标：高效（编辑很忙），稳定（不容易出错），易学（因为调查不是编辑的工作重点）。上一步、下一步按钮会让人感到烦躁，由于流程较短，所以中间不提供上一步按钮，在最后预览的下面提供了返回编辑的链接（同时这也考虑了开发上的问题）。至于 JS 代码和预览，前者占用高度不多，而且是这个界面上最重要的任务点，反而预览在界面的第一屏总能看到。至于命名，这不是“我的命名”，这是通过使用者沟通出来的。文中也没有出现“投票”这两个字。