User story VS. use case

----clip from http://alistair.cockburn.us/A+user+story+is+to+a+use+case+as+a+gazelle+is+to+a+gazebo ---

User Story is simply, a user’s story. It is business ppl’s version of describing the world, their way of “starting an idea”

basically starting a conversation (requirements elicitation) of whether their idea (to get some business benefit) is

feasible?

 

Stories should be simple and business-focussed, because when faced with complex things which make profit & loos look like a

gamble, human mind always wants to cut through all crap and see things in simple and convincing way.“Divide & Conquer” the most intuitive of human manipulation skills can be applied with Stories so you can break or merge stories as well.

 

Let the “user” (the business man) freely express his idea, uninfluenced and undeterred by “system-hardened” developers.

Once he has spoken completely, which means the Story has been written (in say half an hour), then is the time to “start the

conversation” which means start scrutinising the idea, check its feasibility, uncover missing links/detail, design, plan and

when sufficient confidence and consensus exists, make it a decision . The Story can undergo some changes, but still is in a

format that is simple. It is better if it restricts to WHAT and not tries to do HOW.

System ppl or Techies model a complex “real world” into a virtual software world for manupulation, so they will have to analyse the Story to death . Basically as the software does not have a mind of its own, it needs to be told everything preciserly and hence what is very simply said in a Story then has to become elaborate and formal so that it can be implemented.

 

Welcome to the realm of Use-Cases. Systems folks will have to analyse and carry out “thought-experiment” and conceive how

their system (black-box) should precisely work in order to realise the agreed Story. And Use-Cases are a very effective tool

to do that.

 

1 User Story can relate to 1 or multiple Use-Cases. And they may realte only to some parts of these use-cases, simultaneously (they are being written by someone who doesnt know what use-cases are)

If there is a science of Modelling a real-world in abstract way e.g. Software then - it will perhaps say Use-Cases is what will happen to the system in consideration.
Thus Use-Cases are the “Stories” of that System, when viewed with the business benefit.

So fundamentally given a concrete system definition, finite actors and Business Logic Rules that dont contradict Computation

Theory, there is a finite (but large) set of possibilities that can occur and they group together as Scenarios and Use-Cases. Use-Cases are something really fundamental, but only when considered from a Modelling perspective.

 

But surely when Stories are written all these complex thoughts cannot be factored in, and not required as well, lest Business ppl will lose the focus. Also Business ppl dont have that expertise or outlook and why should they? 1 Human Brain cannot do all these varied things in reasonable time. Thinking about everything at once is only a fantasy.

If Business ppl were “system-intelligent” then they would write User-Stories that perfectly mapped with Use-Cases or could

write use-cases themselves. Then systems ppl are not reqd to be “domain-intelligent” they need to be just dumb coders. May

be robots could do the coding job!!!

Thankfully or otherwise that is not tru. In reality, its actually a team-effort: Business ppl with business intelligence, Technical ppl with system intelligence.

Yes maybe with training and experience, Business ppl can write good stories that are more prone to be easily mapped to the

systems, but that is really a bonus.

 

THUS USER STORIES AND USE CASES IS A QUESTION ONLY FROM SYSTEMS’ PERSPECTIVE, THE “USER” ONLY KNOWS “USER STORIES”. IT IS NOT THE SAME AS USE-CASES AND ARE NOT THE MEANS TO DO SYSTEMS ANALYSIS, THEY ARE JUST AN SIMPLE ABSTRACTION OF USE-CASES FOR BUSINESS USERS.

 

YOU NEED BOTH!!!


-by Nikhil Shah on 3/5/2009 at 12:58 PM

----clip from http://alistair.cockburn.us/A+user+story+is+to+a+use+case+as+a+gazelle+is+to+a+gazebo ---

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
资源包主要包含以下内容: ASP项目源码:每个资源包中都包含完整的ASP项目源码,这些源码采用了经典的ASP技术开发,结构清晰、注释详细,帮助用户轻松理解整个项目的逻辑和实现方式。通过这些源码,用户可以学习到ASP的基本语法、服务器端脚本编写方法、数据库操作、用户权限管理等关键技术。 数据库设计文件:为了方便用户更好地理解系统的后台逻辑,每个项目中都附带了完整的数据库设计文件。这些文件通常包括数据库结构图、数据表设计文档,以及示例数据SQL脚本。用户可以通过这些文件快速搭建项目所需的数据库环境,并了解各个数据表之间的关系和作用。 详细的开发文档:每个资源包都附有详细的开发文档,文档内容包括项目背景介绍、功能模块说明、系统流程图、用户界面设计以及关键代码解析等。这些文档为用户提供了深入的学习材料,使得即便是从零开始的开发者也能逐步掌握项目开发的全过程。 项目演示与使用指南:为帮助用户更好地理解和使用这些ASP项目,每个资源包中都包含项目的演示文件和使用指南。演示文件通常以视频或图文形式展示项目的主要功能和操作流程,使用指南则详细说明了如何配置开发环境、部署项目以及常见问题的解决方法。 毕业设计参考:对于正在准备毕业设计的学生来说,这些资源包是绝佳的参考材料。每个项目不仅功能完善、结构清晰,还符合常见的毕业设计要求和标准。通过这些项目,学生可以学习到如何从零开始构建一个完整的Web系统,并积累丰富的项目经验。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值