软件设计是怎样炼成的（2）——优秀设计从分析需求开始

摘要：

设计应该针对需求来作，这个大道理彷佛人人都懂，但实际操做时每每就不是这样。因此咱们也不说大道理，直接经过一个“很简单”的案例来体验一下优秀设计应该如何从分析需求开始，体验架构设计是如何全面考虑各类需求、项目的工期限制预算限制，还有项目组人员水平后作出来的。

 

大纲：

1.什么是优秀的设计？
2.优秀的设计能节省项目工做量
3.优秀设计从分析需求开始
4.软件系统不是木桶型的
5.软件设计的“大道理”
6.规划系统骨架——架构设计
7.打造系统的底蕴——数据库设计
8.细节决定成败——详细设计
9.用户感受好才是真的好——用户体验设计
10.持续提高设计水平

 

本文章是系列文章之一，若是你尚未看过以前的文章，建议先看完前面的文章再看本篇，这样效果更好。

 

3.优秀设计从分析需求开始

 

设计应该针对需求来作，这个大道理彷佛人人都懂，但实际操做时每每就不是这样。因此咱们 也不说大道理，直接经过一个“很简单”的案例来体验一下优秀设计应该如何从分析需求开始。

 

3.1 案例挑战：考勤系统的软件设计

 

某公司要作一个内部用的考勤系统，但愿达成如下目标：

1）规范员工的上下班、请假、外出工做等行为。
2）方便计算员工的薪金。
3）方便管理各类带薪假期。

你如何考虑本系统的设计呢？

你可能会说：我靠，才三句话的需求，怎样作设计呢？

说得太好了！咱们作软件设计的，第一步并非直接去设计，而是分析需求！

 

3.2 如何分析需求？

 

当你接受一个项目的设计任务时，可能会遇到比较尴尬的状况，那就是需求有问题！

具体的状况可能有：

a）需求很简单，几句话或者是一页纸的需求。
b）需求很详细，可能有几十页甚至上百页，这些需求是招标书中提供的，或者是客户直接提供的。不要觉得有这么多需求是好事，这些需求一般是先后有点矛盾、逻辑有点混乱，甚至是不知所云滴！

c）大家有专门的部门或者专职完成了需求工做，提供了一份需求文档。你也不要觉得这是好事，由于极可能会出现这样的状况：需求文档的提供者认为本身写的需求文档很牛逼，水平很高；但负责实现的开发部门认为该文档质量太差，比方说：不考虑实现的可能性和难度，没有考虑到客户的真正需求等等。有时候甚至出现开发部门忽略掉需求部门，直接找客户从新调研，从新编写需求文档的状况。

 

上述三种状况一句话总结就是：需求的质量有问题！

咱们须要从新分析一次需求，先从业务角度审视一次，而后再从软件设计的视角审视一次。一般咱们须要按顺序思考如下问题：

1）什么人会使用这个系统？
2）不一样的人将会使用这个系统的什么功能？
3）还有哪些不肯定或不具体的需求点？
4）哪些需求对技术提出了怎样的要求？
5）系统的大体架构应该如何考虑？

下面开始咱们看几个图，按顺序逐一思考一下上述的几个问题。本小节回答问题一、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）这些人（角色）分别须要用系统的什么功能？

需求分析实际上是一个负责的高难度的话题，回答上述两个问题仅仅是需求分析的第一步而已，咱们还须要深刻分析业务，包括业务流程、业务数据结构等等。若是以前的需求工做不到位，就须要咱们立马开展软件设计工做，其实将会埋下不少地雷，后患无穷。关于需求分析的更多分享，请留意个人其余文章。

 

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）架构设计是全面考虑各类需求、项目的工期限制预算限制，还有项目组人员水平后综合作出来的一种平衡。

  

本文是系列文章的第2篇，要作软件设计师一点都不简单啊，请留意后续文章！

 

若是本文对你有帮助，麻烦点一下“推荐”啦，谢谢！

 

 

做者：张传波

创新工场创业课堂（敏捷课程）讲师

软件研发管理资深顾问

CMMI首席专家

《火球——UML大战需求分析》做者

软件知识原创基地创办人