转载自：http://blog.csdn.net/fireball1975/article/details/18765825
摘要：
设计应该针对需求来做，这个大道理似乎人人都懂，但实际操作时往往就不是这样。所以我们也不说大道理，直接通过一个“很简单”的案例来体验一下优秀设计应该如何从分析需求开始，体验架构设计是如何全面考虑各种需求、项目的工期限制预算限制，还有项目组人员水平后做出来的。
大纲：
1.什么是优秀的设计？ 2.优秀的设计能节省项目工作量 3.优秀设计从分析需求开始 4.软件系统不是木桶型的 5.软件设计的“大道理” 6.规划系统骨架——架构设计 7.打造系统的底蕴——数据库设计 8.细节决定成败——详细设计 9.用户感觉好才是真的好——用户体验设计 10.持续提升设计水平
本文章是系列文章之一，如果你还没有看过之前的文章，建议先看完前面的文章再看本篇，这样效果更好。
设计应该针对需求来做，这个大道理似乎人人都懂，但实际操作时往往就不是这样。所以我们 也不说大道理，直接通过一个“很简单”的案例来体验一下优秀设计应该如何从分析需求开始。
3.1 案例挑战：考勤系统的软件设计
某公司要做一个内部用的考勤系统，希望达成以下目标：
1）规范员工的上下班、请假、外出工作等行为。 2）方便计算员工的薪金。 3）方便管理各种带薪假期。
你如何考虑本系统的设计呢？
你可能会说：我靠，才三句话的需求，怎样做设计呢？
说得太好了！我们做软件设计的，第一步并不是直接去设计，而是分析需求！
3.2 如何分析需求？
当你接受一个项目的设计任务时，可能会遇到比较尴尬的情况，那就是需求有问题！
具体的情况可能有：
a）需求很简单，几句话或者是一页纸的需求。 b）需求很详细，可能有几十页甚至上百页，这些需求是招标书中提供的，或者是客户直接提供的。不要以为有这么多需求是好事，这些需求通常是前后有点矛盾、逻辑有点混乱，甚至是不知所云滴！
c）你们有专门的部门或者专职完成了需求工作，提供了一份需求文档。你也不要以为这是好事，因为很可能会出现这样的情况：需求文档的提供者认为自己写的需求文档很牛逼，水平很高；但负责实现的开发部门认为该文档质量太差，比方说：不考虑实现的可能性和难度，没有考虑到客户的真正需求等等。有时候甚至出现开发部门忽略掉需求部门，直接找客户重新调研，重新编写需求文档的情况。
上述三种情况一句话总结就是：需求的质量有问题！
我们需要重新分析一次需求，先从业务角度审视一次，然后再从软件设计的视角审视一次。通常我们需要按顺序思考以下问题：
1）什么人会使用这个系统？ 2）不同的人将会使用这个系统的什么功能？
3）还有哪些不确定或不具体的需求点？ 4）哪些需求对技术提出了怎样的要求？ 5）系统的大致架构应该如何考虑？
下面开始我们看几个图，按顺序逐一思考一下上述的几个问题。本小节回答问题1、2，后面的小节回答其他问题。
1）什么人会使用这个系统？
不少技术人员分析需求时往往是技术的视角，当你问他系统有什么用户时，你可能得到的结果有两种：
a）没有什么用户啊，所有人都是用户，因为系统只需要配置一下权限，谁都可以用。 b）系统有两种用户，就是：用户和管理员。
我们从业务的角度来审视一下考勤系统的可能用户，请看下图：
图2.1 系统可能用户分析
此图列出了如下可能用户：
employee：员工 finance：财务 receptionist：前台 manager：经理 senior manager：高级经理 administrator：管理员
而上述用户还有这样的关系：finanace（财务）、receptionist（前台）、manager（经理）继承employee（员工）；senior manager（高级经理）继承manager（经理）。
用户之间的继承关系，是什么意思呢？
我们都知道代码中B类（子类）继承A类（父类)，子类就具备了父类的特点。用户之间的继承关系是相同的意思，我们继续看看下图你就可以理解了。
下图将会回答这个问题：
2）不同的人将会使用这个系统的什么功能？
图2.2 系统的需求分析
图2.1和图2.2都是UML的用例图，两个图加在一起比较完整系统地表达了以下问题：
a）什么角色会用本系统？ b）这些角色通过本系统分别能干什么事情？ c）角色之间有可能会有继承关系，请留意父类能干的事情，子类也能干，例如：employee可以打卡，manager也可以打卡，尽管图2.2中manager没有直接与”打卡“相连，但图2.1中已经说明了manager继承employee。
UML是需求分析的有力工具，我的工作中很喜欢用UML。但你的工作中、你的需求文档中可能会没有UML图，不管你们是否用UML图，分析需求时都需要从业务的角度思考这些问题：
a）什么人（角色）会用这个系统？ b）这些人（角色）分别需要用系统的什么功能？
需求分析其实是一个负责的高难度的话题，回答上述两个问题仅仅是需求分析的第一步而已，我们还需要深入分析业务，包括业务流程、业务数据结构等等。如果之前的需求工作不到位，就需要我们立马开展软件设计工作，其实将会埋下很多地雷，后患无穷。关于需求分析的更多分享，请留意我的其他文章，或者买一本我的书籍《火球——UML大战需求分析》看看（广告一下，哈哈）。
3.3 找出设计关注点
本小节我们回答这两个问题：
3）还有哪些不确定或不具体的需求点？ 4）哪些需求对技术提出了怎样的要求？
软件设计师需要有敏锐的需求及设计触觉，看着图2.1和图2.2 嗅出一些问题，你能嗅出一些问题吗？
请看下图：
图2.3 系统的设计点分析
图2.3主要从设计的视角对需求再进行一次审视，以下是一些建议：
a）你需要更加深入思考需求，考虑到各种不同的业务场景和特殊情况，例如：领导不在公司时如何审批请假？ b）你需要思考需求的细节，例如：报表的具体形式？ c）你需要思考各种技术方案，例如：打卡数据的同步方案，财务软件是否要对接等等？ d）你要做出平衡，用合适的方案和尽量少的工作量来满足需求。
3.4 针对需求做初步的架构设计
本小节将会回答这个问题：
5）系统的大致架构应该如何考虑？
接下来你要做初步的架构设计了，架构设计是难度很高的事情，需要你全面考虑需求，考虑工期限制预算限制，考虑项目组人员的水平，而做出的一种平衡。请看下图：
图2.4 系统架构的考虑
图2.4是UML的部署图，这个图比较粗糙，而且为了降低大家阅读难度，我仅仅是用了部署图的最基本最少的语法来表达。
图2.4中的每一个立体的矩形，表示的就是物理上或者是逻辑上的一台设备，设备之间 有物理连接的话就用线条连接，每台设备中”{ }“括起来的文字是对该设备的进一步说明。
图可能是表达设计的最好方式，建议大家用UML，表达系统架构时，用UML的部署图、组件图和包图是比较合适的。我们设计的系统多数是分布式系统，不是单机系统，用部署图来表达分布式系统的架构设计可能是比较合适的。
图2.4针对图2.3中提出的问题进行了初步的回应，图2.4 就是一个初步的架构设计，当然后续我们还需要继续细化这个设计。
3.5 小结：如何需求驱动设计？
本篇的例子告诉我们：
1）优秀的设计是需要从分析需求开始的。 2）需求的质量可能有问题，那么我们需要从业务的角度重新审视一次。 3）从设计的角度审视需求，我们会提出很多需求细化及设计方案的问题。 4）架构设计是全面考虑各种需求、项目的工期限制预算限制，还有项目组人员水平后综合做出来的一种平衡