关于系统的定义，《软件方法》一书给出了2个关键点，后来在答疑时补充了系统要满足充分,必要条件。现实中做系统增量开发时，并不是很好分辨。先举个例子，IBM卖笔记本电脑，后来技术先进了，可以加一个USB插件，语言就转成文字了，先假设这个插件只有IBM能开发。老用户去商店买USB插件，从卖的角度，USB插件就是一个系统，同时商店也有带插件的整机，你要是新用户，可以直接用带插件的整机。对于买整机的用户来说，USB插件就不是一个系统。只能算子系统，这个从卖的角度，很好理解。但是对于软件来说，并不好区分，举个例子：微信支付推出了一个功能，你说句话，如 向潘家于转100元，系统就转账了，里面有高科技，通过声音,地理分析等等，这里是新开发一个语言转账系统，还是在原来的微信支付系统上增加了一个功能分包。从卖角度，用户不会管你系统内部的交互，他要的是一个整体系统，但是从IBM的例子看，语言转账系统作为一个新系统是合理的。（作为功能分包与独立的系统在业务序列图上的交互是不一样的）5.1.1 系统是独立对外提供服务的整体，对外提供服务，对于买整机的用户来说，USB插件就不是一个系统。只能算子系统，这个从卖的角度，很好理解。书中提到积分兑换系统不是一个系统，数据是共享的，从语言转账系统看，用户数据都是微信支付系统系统的，语言转账系统并不成立，与之前也推论矛盾的。欢迎学员讨论这个问题说难一点都不难，如果没有掌握要点就很难，一辈子都想不通的大有人在。(1)认清竞争的残酷，抛开一厢情愿的想法和“我爸是李刚”的幻觉.张三买A+B，李四买A，王五买B，哪个场景（或者哪些）是IBM认为最符合自己当前的竞争态势，这是有最佳答案（注意：不是标准答案）的，这个最佳答案决定了谁是合适的目标客户（张三李四王五）以及需要卖的系统（A、B、AB、AAABBB...）。另外要说的是，“子系统”不卖。目标客户加插件不是买“子系统”（这是设计人员没杀干净污染的），可能是为原系统增加功能（只不过碰巧这个功能以通用插件的方式实现，实际上如果专门给他贴心定制他更爽），可能是买了一个“系统”。同样，这里面有微妙的区别，哪一种才是商家在当前竞争态势希望看到的最佳场景，需要好好去思考。就像钟表由零件组装而成，如果经过定位思考，认为卖钟表是本商家目前最佳策略，那么零件可以替换、外包，如果认为卖零件的战场也要占领，那么就要投入很多精力来研发能赢得竞争的零件。各个领域（钟表、零件、零件的零件、零件的零件的零件……）都有残酷的竞争，不能轻飘飘地说“如果我们是卖**的呢？”我们的爸爸不是李刚，实际上市场留给我们的选择并不多，需要花心血去找到能让我们活下来的最佳答案。补充：一厢情愿不只是往“零件”方向想过头，还包括一厢情愿往“钟表”方向想过头。假如经过思考，本团队的适合定位是做零件，那么要满足的是做闹钟的团队（目标客户）的零件要求，不需要关心做闹钟的团队的各种决定是否正确，闹钟能不能卖出去。潘老师主要从组织建模的角度分析加功能，还是做新系统是最佳的选择问题原意想讨论在分析工作流时，增加一个系统，还是增加一个系统用例(功能),本来这不属于分析工作流的内容,只是为了分配系统的职责去推导应有的业务序列图分析/开发人员拿到积分兑换需求(包括了积分规则，兑换规则等等)，其实此需求并没有需求工作流那样完整，产品人员有自己的套路，软件方法只是在局部流程改进分析/开发人员推导业务序列图后, 可能按 顾客->兑换积分(网店系统的用例) ，也可能按 顾客->兑换积分（积分兑换系统），即把系统用例当作系统来做，多了积分兑换系统与网店系统的系统间接口是否从做的角度，这两种区别不大。主要核心域复用即可，怎样简单怎样做，但是从业务序列图的责任分配上，决定了系统提供的接口。对原有的系统改动还是有区别“问题原意想讨论在分析工作流时，增加一个系统，还是增加一个系统用例(功能),本来这不属于分析工作流的内容,只是为了分配系统的职责去推导应有的业务序列图”---这句话概念乱掉了……这是业务建模工作流的工作，离分析工作流差两格呢。“是否从做的角度，这两种区别不大。主要核心域复用即可，”--需求有不同，分析设计会有一些不同，但工作量相同的可能性比较大。这些思考实际上就是把“不这样不行”和“这样行”分开。如果没有体会到把这两个分开的重要性，很难得到正确的思考结果。我上面表述是 不属于分析工作流的内容，这个没问题吧没问题。分析设计人员杀干净了就不会有人讨论这些问题了。很多开发人员是情不自禁把自己带进来，医生自己躺在病床上。嗯，其实是相当于 需求别人给定了，在实现时 要画分析序列图，分析序列图从系统用例来， 就把系统用例找出来“定了”那是假的。边界还在扯皮，那就是没定，只是说反正我写了个“需求文档”扔给你，就是定了。软件方法的使用是局部的使用， 并不是按SRS的方法交付就像考试一样，没考100分考60分或作弊也没关系，只要不骗自己（可以骗人）说自己真的到了100分水平就行了。需求没做好，分析设计人员从自己利益出发，可以替他做好，也可以不管不顾照着做，也可以拒绝做，也可以歪着做。但是，没做好就是没做好，不要骗自己说“他已经做好了”就可以。分析设计人员从自己利益出发，可以替他做好----就是这个意思，把业务序列图，需求规约重新做那就是业务建模和需求工作流，不是说做的人的职务是分析设计人员，所以工作流就是分析设计。然后，按照每个工作流的要点做，不存在什么“从程序员的角度”做需求之类的东西。
有难度就克服，克服不了拉倒。还是上面这个：就像考试一样，没考100分考60分或作弊也没关系，只要不骗自己（可以骗人）说自己真的到了100分水平就行了。很多时候，考60分已经压过很多人了。所以，这个问题想到这里已经比很多团队要强了，想不透到底怎样才是“不这样不行”，得不到100分答案，也无所谓。UMLChina建模竞赛题大全-题目全文+分卷自测（10套100题）
《软件方法》书中自测题-题目全文+分卷自测（1-8章）16套111题
2020年4月11-12、4月18-19晚网络软件需求设计方法学全程实例剖析公开课
UMLChina建模示范视频（升级到EA 15.1和StarUML 3.2）
UMLChina视频哔哩哔哩频道（20200322更新）