用Use Case获取需求的方法是否有缺陷,还有哪些地方需要改进
(提示:是否对所有应用领域都适用?使用的方便性?......)
Use Case使用原则:
1.通过讲简单的故事来传递消息
讲故事是最有效的人与人交流信息的途径。通过讲故事(Use Case),团队成员能对需求有统一的了解。当我们用自然语言讲故事时,我们会不自觉的把复杂的系统当作一个黑盒子,把重点放在用户的愿望,行动上面,这种做法非常有利于我们找到用户的需求和软件的功能点。当然,故事要包含具体的行动(Actionable),并且是可以验证的(Testable),所以讲故事也要有技巧。
2.保持对全系统的理解
虽然每一个用例都是一个简单的故事,但是不要忘了它是整个系统的一部分。
3.关注用户的价值
别迷失在长长的功能列表中,牢记软件的价值在于给用户提供价值
4.逐步构建整个系统,一次完成一个用例
一个用例的完成可能要触及整个系统的各个层面(例如,“用户在ATM上完成跨银行的取款”这一用例需要银行系统各个子系统协同修改,才能完成),不同模块间复杂的依赖关系对团队是一个大的考验。
5.增量开发,逐步构建整个系统。
6.适应团队不断变化的需求。
但Use Case的使用也有其局限性。
1.故事/人物/场景非常适合交互式的系统,但是对于其他类型的需求(算法,速度,扩展性,安全性,以及和 系统技术相关的需求)则不适用。
2.故事的粒度没有统一的标准,和每个具体项目有关。初学者比较难以掌控。
3.如果软件的关键在于用户体验的细节,那么如何把这些UI的细节嵌入每个故事中,并仍然保持故事的简明 性?这是一个难题。有些团队把目前的技术扩展为Use Case Storyboard,当一个简明的故事加上很多附加 说明和图画的时候,这事实上就成为了功能说明书(Function Specification)以及各种帮助建模的图形工具。