原创

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

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://fireball.blog.csdn.net/article/details/18765825

摘要:

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


大纲:

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)系统的大致架构应该如何考虑?

下面开始我们看几个图,按顺序逐一思考一下上述的几个问题。本小节回答问题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)架构设计是全面考虑各种需求、项目的工期限制预算限制,还有项目组人员水平后综合做出来的一种平衡。



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




作者:张传波

创新工场创业课堂(敏捷课程)讲师

软件研发管理资深顾问

CMMI首席专家

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

www.umlonline.org创办人


文章最后发布于: 2014-01-25 13:29:12
展开阅读全文
0 个人打赏

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览