User story VS. use case

本文探讨了用户故事与用例之间的区别,解释了两者如何分别从商业和系统角度描述需求。用户故事聚焦于业务目标,简洁明了,易于沟通;而用例则详细描述系统行为,用于系统分析。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

----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 ---

内容概要:本文档为《400_IB Specification Vol 2-Release-2.0-Final-2025-07-31.pdf》,主要描述了InfiniBand架构2.0版本的物理层规范。文档详细规定了链路初始化、配置与训练流程,包括但不限于传输序列(TS1、TS2、TS3)、链路去偏斜、波特率、前向纠错(FEC)支持、链路速度协商及扩展速度选项等。此外,还介绍了链路状态机的不同状态(如禁用、轮询、配置等),以及各状态下应遵循的规则和命令。针对不同数据速率(从SDR到XDR)的链路格式化规则也有详细说明,确保数据包格式和控制符号在多条物理通道上的一致性和正确性。文档还涵盖了链路性能监控和错误检测机制。 适用人群:适用于从事网络硬件设计、开发及维护的技术人员,尤其是那些需要深入了解InfiniBand物理层细节的专业人士。 使用场景及目标:① 设计和实现支持多种数据速率和编码方式的InfiniBand设备;② 开发链路初始化和训练算法,确保链路两端设备能够正确配置并优化通信质量;③ 实现链路性能监控和错误检测,提高系统的可靠性和稳定性。 其他说明:本文档属于InfiniBand贸易协会所有,为专有信息,仅供内部参考和技术交流使用。文档内容详尽,对于理解和实施InfiniBand接口具有重要指导意义。读者应结合相关背景资料进行学习,以确保正确理解和应用规范中的各项技术要求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值