你的位置:软件知识原创基地 >> 知识海洋 >> 需求分析 >> 详细内容 在线投稿

疯狂的订餐系统-软件需求分析挑战之旅

排行榜 收藏 打印 发给朋友 举报 来源: 原创   发布者:张传波
热度5003票  浏览6898次 时间:2009年9月15日 10:48
摘要:
说教性质的需求分析理论,各位看了也白看,所以咱们就来一个真实个案——“订餐系统”体验一下。
“订餐系统”貌似简单,但陷阱重重,各种需求分析的经典场景将会一一重现,各位做好准备接受这个挑战没有?

特别声明:
如需转载此文,请给出指向本网站的连接,如下:
作者:张传波
摘自:http://www.umlonline.cn
如不能按此要求,请不要转载此文。

1.1某IT公司员工的吃饭问题

咱们出来干活的,天天需要吃午饭,所谓“午饭吃不好,工作干不好”。某IT公司深知这个道理,为了让大家方便吃午饭,由公司统一订餐,并且费用全包。
这样的做法,大家当然开心了,不过行政部的同事就要辛苦一点,每天要“服侍”大家吃饭,我们看看怎样个做法:
  • 文员每天都要向餐厅索取最新菜单,然后拿着菜单找每个人确认今天吃什么。
  • 大家都确认后,文员以电话或者传真的方式,向餐厅订餐。
  • 餐厅送来午饭,文员通知大家,然后大家来取餐。
这样的做法维持了一段时间,但是问题逐渐就来了。
员工A抱怨:我明明点了酸菜鱼,干嘛给我送来红烧鱼。
员工B抱怨:我刚才去开会了,没有点餐,怎么就这样把我的餐给漏了?
员工C抱怨:我对中午饭要求不高,每天吃麻辣牛肉就可以了,不需要天天来问我吃啥,打断我的工作。
......
大家都开始来责怪文员了。

文员受了一肚子的委屈,她解释如下:
有些人写的字不太清楚,有时会搞错;
公司这么多人,有人上厕所有人去开会,我哪能保证每次都不漏人。
我按员工C说法做了,没有再问他了,但有一天取餐的时候,他说上火,不吃麻辣牛肉,要我换!都定了,怎么换啊?保险起见,我以后天天都问他了。
呜呜......

公司领导觉得问题责任不在于文员,而是这样的订餐方式太落后了,导致诸多问题!好歹是一个IT公司嘛,订餐也需要信息化!于是领导萌生了要做一个订餐系统的想法。

于是咱们的好戏就开始了......

1.2 需求分析的大道理

你非常光荣地接受了这个任务,领导任命你为订餐系统的项目经理,你会如何展开需求分析工作呢?
可能你会这样想:那还不容易,这么简单的系统,直接编码就行了,还写什么需求!
伙计,不要冲动,看到这里请你先停止阅读,找张纸和笔,用你自以为合适的方式列出这个系统的需求。
请写完后才继续往下看噢!

不听话了?没写完就往下看?

咱们先说说需求分析的一些大道理:
首先我们需要明确项目的背景,我们要回答这些问题:也就是为什么会有这个项目?客户为什么想做这样的一个项目?如果没有这个项目会怎样?
了解背景的基础上,我们需要进一步了解以下内容:
1)本项目解决了客户的什么问题?
2)本项目涉及到什么人、什么单位?
3)本项目的目标是什么?
4)本项目的范围是怎样的?
5)本项目的成功标准是什么?
以上这些内容,我们称之为客户的“需要”。

接下来,就可以定详细的需求规格说明书了,一般我们会对功能性需求和非功能性需求都列出详细的要求,我们这里把这些要求定义为“需求规格”。


图1 背景、需要、需求规格


对于功能性需求,我们往往会描述成用例图。


图2 用例图

对于非功能性需求,往往会对系统稳定性、性能、兼容性等提出要求。

什么是背景?
背景这东西比较笼统,简单地说就是这个项目的来由,我们需要用说故事的方式讲清楚项目的背景。

什么是需要?
需要就是客户真正想要的东东,是高层次的需求,我们可以把需要解决的问题、关键涉众、项目的目标、范围、项目成功标准等全部统称为需要。

什么是需求规格?
需求规格是很细级别的但又没有细到详细设计程度的需求了,描述出系统与用户是如何交互的,系统要满足怎样的一些非功能要求。

需求分析过程,无非就是由背景到需要到需求规格的过程,这个过程是螺旋前进的。需求分析中最难解决的问题往往就是搞不清需求之根源,把握不清背景和需要,往往就会被繁琐的需求规格所困住,被客户牵着鼻子走。理论是完美的,现实是残酷的,我们现实的需求分析工作,往往会出现这些问题:

  • 背景啊背景,我该如何写你呢?
我们公司的需求规格说明书中,第一章节就是“背景”,但往往大部分项目写出来的背景写了等于没写。有些写了诸如此类的内容:某年某月某日与某某公司签订了某某合同,成立了改项目组,项目人员有谁谁谁,客户联络人是谁谁谁。有些项目更懒,直接复制前期需求文档的背景,以致项目已经做到第三期了,第三期的背景仍然是抄第一期的。不知道如何分析背景,背景不知道写啥,这是项目的普遍现象。
  • 目标在哪里?
对于“项目的目标”,项目组普遍的问题有:
1.根本不知道“目标”这回事。
2.目标写出来了,但被扣上“大而虚”的帽子。
3.没有用目标来指导下一步工作,后面遇到具体问题时,没有用目标来思考。
4.目标写出来就不变了,没有持续去思考是否需要调整。
  • 需求规格优先
很多需求分析人员喜欢将系统要做的事情,以用例或者功能点的方式记录下来,但往往没有记录为什么需要这样一个用例或者是功能点,没有去思考这个用例或者功能点背后隐藏的客户需要是什么。更甚者进入具体的界面设计,在需求文档中写清楚界面上放什么按钮什么菜单等,一开始就将需求“僵化”,这样会让后面的工作陷入“万劫不复”之地。

本小结开始的时候,要求你先写下本系统的需求,再继续往下看。不知道你写的需求中是否有背景、需要这些内容呢?你写的需求是不是几乎全部是“需求规格”呢?
下面,我们将来挑战“订餐系统”的背景、需求和需求规格。


图3 某需求规格说明书目录

TAG: 软件需求 需求分析 需求开发 需求管理
顶:338 踩:275
对本文中的事件或人物打分:
当前平均分:-0.25 (1323次打分)
对本篇资讯内容的质量打分:
当前平均分:-0.48 (1290次打分)
【已经有1777人表态】
289票
感动
154票
路过
160票
高兴
154票
难过
116票
搞笑
165票
愤怒
203票
无聊
536票
同情
上一篇 下一篇
软件知识大学