人体的需求和设计
如果需求和设计不分，利润就会缩水。从需求直接映射设计，会导致功能分解，得到重复代码。如果从设计出发来定义需求，会得到一大堆假的“需求”。拿自古以来就有的一个系统“人体”来举例。人体对外的功能是会走路，会跑步，会跳跃，会举重，会投掷，会游泳……但是设计人体的内部结构时，不能从需求直接映射到设计，得到“走路子系统”、“跑步子系统”、“跳跃子系统”……人体的“子系统”是“呼吸子系统”、“消化子系统”、“血液循环子系统”、“神经子系统”、“内分泌子系统”……
确实如此，人体的子系统是各个模块，当你需要完成某个动作时是调用各个模块共同完成的。例如你想跑步就需要“呼吸子系统”“，血液循环子系统”，“神经子系统”和“消化子系统”等等共同合作。而不是你要完成什么动作就需要有什么子系统，那样就会出现一大堆的假的需求。所以应该是这样的：
“人体的“子系统”中很多是不能从需求直接映射出来的，需要设计人员的想象力。水店老板要雇一个送水工（即租用一个人肉系统），他只要求这个工人能跑能扛工资低就行，管他体内构造是心肝脾肺肾还是一块电路板。同样，也不能从设计推导出需求——因为人有心肝脾肺肾，所以人的用例是“心管理”、“肝管理”。送水工能这样找工作吗：“老板，我有心脏管理功能，你请我吧！” 很多时候我们说“本系统分为八大子系统……”，其实说的是“本系统的功能需求分为八大需求包……”。需求包是从外部对系统功能所做的简单分包，子系统应根据部件的耦合和内聚切割得到。”
关于设计和需求的区别，潘加宇老师进行了总结：设计源于需求而高于需求。
业务建模： 描述组织内部各系统如何协作，使得组织可以为其他组织提供有价值的服务。
需求： 聚焦于待开发系统的边界，详细描述系统要卖得出去必须具有的表现——功能和性能。这项技能的意义在于强迫我们从“卖”的角度思考哪些是涉众（Stakeholder）在意的、不能改变的契约，哪些不是。
分析： 提炼系统内需要封装的核心领域机制。
设计： 将核心域知识和非核心域知识结合，最终实现系统。说“代码就是设计”指的是这里说的“设计”。代码确实是设计，但代码不是分析，不是需求，不是业务建模。
把工件简单分割为代码和文档（或设计），背后还隐含着这样的误解：认为模型（文档）只不过是源代码的另一种比较概要或比较形象的表现形式。其实，不同工作流产生的工件之间的区别不在于形式，而在于内容，也就是思考的边界，见图1-4。如果清楚了解这一点，即使只用C#，也照样可以“建模”。后面我们可以看到，如果不能做到UML模型就是代码，那么设计工作流就不需要UML模型，代码就是设计
图1-4 核心工作流思考边界
“
一些不了解以上概念的开发团队干脆以“敏捷”为名，放弃了这些技能的修炼。就像一名从护士成长起来的医生，只掌握了打针的技能，却缺少检查、诊断、拟治疗方案等技能，索性说：“唉，反正再高明的大夫，也不能一个疗程把病人治好，干脆我也别花那么多心思了，先随便给病人打一针看看吧，不好再来！”“迭代”只是一个底线，确实，再高明的大夫也没有把握一个疗程就治好病人，但是检查、诊断等技能越精湛，所需要的疗程就越少。不能把“迭代”作为偷懒的庇护所。
唱曲的名家，唱到极快之处，吐字依然干净利落；快节奏的现代足球，职业球员的一招一式依然清清楚楚；即时战略游戏高手要在极短时间内完成多次操作，动作依然井然有序。在激烈竞争的年代需要快速应变，掌握技能才能真敏捷。世上无易事，偷懒要不得。
刚入行的开发人员体会不到建模的重要性，是正常的。就像下象棋，初学者面对单车对马双士、单马对单士等已经有共识的局面还需要思考良久，最终还拿不下来甚至输掉。这时中局和布局的书在他看来多半是枯燥无味的，还不如把一本实用残局汇编看熟了，学到一些奇技淫巧，也能在菜市场赢几盘棋。不过，要迈向职业棋手的境界，参加更残酷的竞争，就体会到中局和布局的重要了
”
潘加宇老师讲的通俗易懂，我也没啥好说的，所以就截取了一些比较精彩的部分与大家一起分享。