别把洋垃圾当宝贝-评InfoQ中国“敏捷……”文章（一）
[20210429更新]软件方法（下）分析和设计 第8章 连载
譯揮 (252***66)13:37:20 问一个问题：操作界面是属于需求，还是设计？ /sun(20***677)13:41:07 这个是设计吧，如果涉众要求，可以记录下来作为设计约束潘加宇(3504847)13:45:40 书上有讲。(20***677) 说得对 譯揮 (252***66)13:48:37 知道。应该是属于设计。一些需求总是会涉及到一些单据，如报销单，这个报销单业务人员是有要求的，通常都会认为是需求。设计人员设计出来以后，再给业务人员去确认，这个确认动作叫什么？叫需求确认？或者叫设计确认？潘加宇(3504847)13:49:45 设计人员 不需要 和 涉众 确认 潘加宇(3504847)13:50:27 涉众也没有这个资格和责任 譯揮 (252***66)13:55:56 那向需求人员确认？潘加宇(3504847)13:59:02 确认不确认，这是一个交流手段的问题 但各工作流和所需要的不同技能，知识要理清楚。 譯揮 (252***66)14:00:53 是不是这样理解，业务部门提供的报销单据原始样子，是一个需求素材，其中可能包含了某些涉众利益，系统所设计的界面可以参考这个单据样本并充分吸纳涉众利益要求。潘加宇(3504847)14:01:27 【涉众】---需求素材，需求视图---【需求人员】-----需求规约-----【设计人员】-----分析，设计------- 潘加宇(3504847)14:02:26 就是因为 需求素材 和 需求 是多对多的， 需求 和 设计 也是多对多的，才需要人来思考啊 潘加宇(3504847)14:03:44 如果涉众拿出一张单据，就直接映射一条需求，然后也直接生成一段代码就用。还要那么多环节干什么 Thinker(11***314)14:04:35 潘老师分析好精辟潘加宇(3504847)14:05:21 你刚才提这个问题，实际上就有这个一对一的思想。 认为 业务人员提供的单据==需求=最终的实现，所以设计人员可以直接和涉众验证 譯揮 (252***66)14:06:38 明白了潘加宇(3504847)14:06:59 但是，一张单据背后，隐含各种不同稳定级别的需求：用例、路径、步骤、约束。同一份需求规约，也可以有不同的分析手段，即使是同样效果的界面，实现的手段也有很多种 譯揮 (252***66)14:07:47 换一个问题：需求人员在考虑完涉众的单据后，如何描述涉众的界面需求？潘加宇(3504847)14:08:08 复习第6章 譯揮 (252***66)14:11:55 书是是讲清楚了潘加宇(3504847)14:12:14 可以先写一下，再贴出来 潘加宇(3504847)14:12:36 把整个需求规约写一下，再贴出来，包括涉众利益 譯揮 (252***66)14:13:08 这个观念在大多数人脑子里是很难转过来的，现在大量的就是需求和设计不分，都写在一起了。 譯揮 (252***66)14:42:21 单据编码由系统自动生成，并要求编码连续 --- 这个可以作为需求写在业务规则里吗？潘加宇(3504847)14:43:37 "单据编码由系统自动生成，并要求编码连续"不这样，涉众在意吗 譯揮 (252***66)14:51:37 在意，人工编号，难于管理潘加宇(3504847)14:53:36 那"单据数据应该由系统保存好，并可以查询"是业务规则吗 譯揮 (252***66)14:54:30 不是 譯揮 (252***66)14:55:17 有一类提法，这个要由系统自动生成，那个要由系统自动生成，这一类"需求"，叫什么？潘加宇(3504847)14:56:22 这个也一样的。 系统生成******。这是一个步骤。 ******里的字段列表里有【单据编码】，还有涉众规定的单据编码的格式潘加宇(3504847)14:56:37 "自动"二字是废话 潘加宇(3504847)14:57:08 如实按照用例路径步骤写出来 譯揮 (252***66)14:57:16 生成编码的规则，是应该算算法，还是业务规则？ 譯揮 (252***66)14:57:49 可能对编码规则有要求 譯揮 (252***66)14:58:04 明白了潘加宇(3504847)14:58:28 涉众关心他想要的那种格式的编码是怎么生成的吗 譯揮 (252***66)14:58:30 需求阶段，可以写编码规则，不可以写算法 譯揮 (252***66)14:59:20 一般会有一个格式要求，如年+业务类型+序号，等等潘加宇(3504847)15:00:22 头脑不清的开发人员把所有逻辑都叫做"算法"，以为这样显得高大上。"算法"是计算机科学领域的概念，是实现的手段。 潘加宇(3504847)15:01:43 书中第六章讲了的 "业务规则不等于实现算法" Saturn(2***11)15:02:04 是啊，一般程序也就是输入、输出、增删改查。组合一下就完成了业务。 譯揮 (252***66)15:02:06 知道。是应该把业务人员对编码的这些格式要求，作为业务规则吧潘加宇(3504847)15:03:16 可以，但要仔细过滤，一定是来自涉众的知识，"不这样不行"的 潘加宇(3504847)15:03:22 来自开发人员的肯定不对
[2020.01加一套题]UMLChina建模竞赛题大全-题目全文+分卷自测（11套110题）
全程字幕-25套UML+Enterprise Architect/StarUML建模示范视频
5月20-23晚学员真实案例剖析专项公开课
[幻灯更新]5月27-30晚-剔除“伪创新”和“无领域”的领域驱动设计-网课
[新增：鸵鸟]软件开发团队的脓包：皇帝的新装、口号党、鸵鸟、废话迷
《软件方法》书中自测题-题目全文+分卷自测（1-8章）16套111题
《非程序员》电子杂志下载（39-51期）
《非程序员》电子杂志下载（1-38期）
中文书籍中对《人月神话》的引用（完结，共110本）：软件工程通史1930-2019、实用Common Lisp编程……
CTO也糊涂的常用术语：功能模块、业务架构、用户需求……[20210217更新]
UMLChina服务介绍
