今天，一位部门同事在上午的tea time时间，突然问我：“能否告诉我，如何学习做系统设计呢？对一个新系统，如何从一开始的想法变成一套具有可执行性的设计方案？”

面对这么一个复杂的而庞大的问题，我以为，任何人的第一感觉是，“这个不是一下子能说清的事！”，至少在那一时刻，我的脑海里蹦出的第一念头就是这个。当时，我没有用我的第一感觉回答他。一是因为，问我问题的这位同事，虽然刚毕业，入司不到半年，但他是一个非常认真上进的人，他问我的态度也是那么诚恳的希望有一个正式的回答；二是因为，这个问题是一个对大多新人来说，都挺有意义的提问，但我自己似乎从没有认真的去思考过。因此，我沉默了.......

再回想了自己历年的项目经历后，我跟他说，以我个人的感受，进行系统设计大体分以下几个阶段：
1.用户需求分析
分析用户的初始需求，弄清楚，并尽可能的挖掘用户没说明白的，真实的潜在需求。

2.将用户需求转化成软件需求
用户需求是我们现实世界的客观需求。而程序设计很重要的过程就是使用计算机上能操作的行为模式来描述用户需求的实现，比如：用户说要收邮件，变成软件需求，就是要设计什么样的操作按钮，什么样的展示窗体，是web形式的，还是客户端形式的。收邮件是用户需求，而使用web应用的操作来收邮件就是软件需求了。

3.在软件需求的基础上运用你学到的各种架构和模式
比如：开发传统的MIS系统，采用web应用形式，就可以使用人见人知的MVC模型；而如果开发的是网络协议通讯平台，就可能要参考IOCP模型，等等。。

我的同事又问，那设计是否一定要使用UML呢？

我对他的建议是，UML是一门对设计模型描述用的语言，目标是将你的设计思想使用统一的模式固化下来，以便在团队协作中，你的设计能有一致的理解和继承，但UML本身并不能帮助你实现设计。对于刚开始学习系统设计的人，你完全可以抛开UML，用你自己最自由的方式去开拓你的思维，哪怕是一把白板笔，在白板上乱涂乱画，没人看得懂，都没有关系。如果你的一开始就学习UML，那么你的心思将会重于如何使用UML的符号，而不是如何设计好系统。就好比一个开始学习英语的人用英语作文，他的重点会集中在英语的语法上，而不是文章的构思上。

交流的时间很短，只有3分钟。我的那位同事听了后若有所思，而对于我自己，却有一种“温故而知新”的痛快感受。