rolt的专栏

A、B、C三个赛道都有人赚到钱，也都挤满了竞争对手

​直接写系统需要反馈的结果就行。按“不这样不行”要求

这个问题涉及到我们常犯的一些微妙的错误。

也未必，实事求是就可以。

往另一个抽象级别探究，所有的行为最终都会是"异步"的，但这是另外的领域、另外的开发人员关心的事情

"系统根据当前是销售员还是组长显示的数据略有不同"这只是一个步骤。给谁用？

这个问题可以帮助练习区分需求和设计。

只画最最要改进的流程，然后寻找改进点，找出最最重要的系统用例

你这几个问题，背后的模糊知识点是一样的。行为和数据的混淆。

（1）执行者不等于权限管理（2）用例名字动宾结构（3）尽量从业务序列图映射系统用例

很多人会乐意把“启动”当成用例，然后每个项目都写一遍，不用思考，还可以凑工作量，爽！

好好复习第二章，第四章，需要补很多知识点。

这里的最大问题是：先入为主的思想太多，例如，无根据判断“大小”、“本系统将来要涉及设备管理领域”

我们单位做需求挺随便的。都是领导一个意见，我们就估摸着做

这个和取现金是最后系统要出一张小票一样的，不能武断认为“不是一个事情”。

开发使用自己做的组件，类似医生给自己看病，有两种角色

需求是研究系统作为一个整体的行为，6-11写的这些都是系统内部做了什么，不存在扩展的问题

这个和医生给自己看病一样，要把"医生"和"病人"的角色分清楚。

（5）没有质量诉求，这些道理没有用场。

以为没有“深入到系统内部”的内容，却有可能涉及到了“系统内部”。

《黑神话·悟空》的成功，需要开发团队领导有坚强的意志，定位合适的愿景，并坚定不移地让每一个细节不违背愿景。

根本原因就是你涉众利益没有找到

你要问他，为什么要用这种算法

即使没有计算机，计算机不存在

但我们很多人喜欢把这种当成需求

还有这个，为什么要更新账户信息，不更新不行吗

请问这些游戏的源代码是需求吗

产品经理训练题

比如说，假设你跟你的同事有矛盾

跟愿景最相关的，越容易做，说明什么

我们做需求的时候，不能先设想一个答案，然后再根据答案去“探索需求”，那就使得所做的工作没有意义了。

至少人家没有像革命性创造和划时代洞见的领域驱动设计一样隔三差五就造一个新词。

我们把它定义成基于人脑的信息系统

他明明自己是场上的奴隶

认真学习并掌握了严谨的方法，再回头看某些伪创新

从建模需要警惕的“批量刷废话”也可以看出来：

等级高阶介绍软件开发中，需求是解决“系统怎样好卖”的问题，设计是解决“降低开发成本”的问题。本训练聚焦第一个方面，在点上强化业务建模和需求的技能。每期的教材都会根据当期学员所整理的学习《软件方法》的过程中以及工作中碰到的各种困惑来定制。本训练可以作为接受UMLChina“软件需求设计建模方法学全程实例剖析”或阅读《软件方法》之后的进阶课程，更进一步强调细化A-业务建模和B-需求实践中的相关细节和技能；专注于业务建模和需求技能改进的人员，也可以单独选择本训练。学习本训练

zzj 2023-2-15 9:35老师，如果某位排位特别靠前的涉众向建模人员提供了一张精美的界面图片，要求系统的界面按照图片来做，这张图片能不能算设计约束？UMLChina潘加宇首先，还是需求的素材。如果（1）经过揣摩，确实是该涉众认为“不这样不行”的，而且（2）经过权衡，没有损害他以及别人更高的涉众利益，那么，可以作为设计约束。zzj 2023-2-15 17:36那我明白了，就像第仨题，业务序列图也是素材，不过是高质量的素材，我们建模人员经过审核，可以直接把它当工件用UML

需求是从用的角度看问题，不是做的角度。

需求如果是''时间--统计历史记录''（可能性不大），性能需求就没有了。