16收集系统需求.pdfVIP

16收集系统需求

现在到了开发组开发未来餐馆的技术骨架的时

候了。开发组现在已经得到了业务过程模型和系统

的类图。下面就可以开始编码了吗?这种想法是错误

的，他们甚至离编写程序还有一大段的距离。首先，

他们必须要开发出—个系统的视图。

大部分项目都以“构造一个顾客信息数据库系统

并使它具有对用户友好的界面，以便于可以花费最

短的时间对用户培训”或者“构造一个尽量在最短时间

内解决问题的基于计算机的辅助桌面软件”。而现在，

开发组只能从一个不太明确的任务“使用技术建立未

来的餐馆”开始。开发组必须事先设想出这个餐馆是

什么样了，这样才能估计出餐馆中的各类人员怎样

在其中工作。他们现在处在一般的开发组所没遇到

过的情况。

开发组将使用他们所了解到的业务过程知识和

新获取的领域知识，为的是看看外出就餐的哪些地

方可以使用技术来改善。让我们来旁听一个开发组

的会议。会议的成员有一名系统分析员、一名建模

设计师、一名餐馆老板、一名服务员、一名厨师和

一名系统工程师。另有一名主持会议的协调员。

16.1开发系统的映像

协调员：“请看我们的业务过程模型图，我认为

大家都看得出有好几处可以引进计算机技术加以改

进。我在一块白板上做记录，哪位先发言?”

协调员给每位与会者散发一份下图的拷贝。

分析员：“很明显，与大部分其他企业一样，餐

馆的业务运做也要依赖信息的流动。如果我们能够

加速信息的流(这也是技术所擅长的)，就能够达到

我们的目的。”

餐馆老板：“我还不敢肯定已经理解了你的意思。

你所说的“信息流”指的是什么?我认为我的餐馆里

一直在流动的是食物。”

系统工程师：“我可以帮你说明什么是信息流动。

当顾客下一份定单后，他就在给服务员传递信息，

并且，当服务员将这个定单转交给厨师时，他就在

使信息继续流动。”

协调员：“还有什么地方有信息流?”

服务员：“我想我已经有些明白了，当一名顾客

叫我去问厨师定单完成情况时，也有信息流动，对不

对?”

分析员：“完全正确。”

厨师：“但是服务员来问我饭菜做的如何时，我

并不能真正做什么，一切还得照旧进行，在烹饪时我

不希望被打扰。”

协调员：“或许我们能找出一种使这种打扰降至

最低程度的方法。对信息流动诸位还有什么看法?”

这时，协调员试图缓和厨师的情绪，以使他集

中注意力开会。

餐馆老板：“当服务员为顾客背诵每日特色菜点，

或者回答顾客就菜单提出的问题时，这是不是信息

流?”

协调员：“肯定也是。”

厨师：“有时我也回答顾客提出的问题。顾客让

服务员到厨房来问我某个菜做的怎么样时，我或者

告诉服务员，由服务员转达给顾客，或者我不太忙

时，会亲自出去解答顾客的问题。顾客喜欢我这么

做。”

餐馆老板：“好主意。有了这项功能我们就知道

是不是要改进我们的工作以及如何改进。你是怎么认

为的？”

建模设计师：“在我们的Customer类中设置两个

属性arrivalTime和serveTime。我还准备再增加一个导

出属性waitDuration．它是serveTime和arrivalTime之

差。对此你有什么看法?”

餐馆老板：“好主意。这样我们就知道我们是怎

样招待顾客的了。”

分析员：“是的。还可以得到许多有用的数据—

—例如每天所有顾客候餐的总时间每名服务员招待的

所有顾客的平均侯餐时间，等等。”

建模设计师：“还有另一种可能。假设在

Customer类中再增加一个叫做depatureTime的属性和

一个导出属性mealDuration，它是depatureTime和

serveTime之差，这样做如何?”

协调员：“应该不错。还有其他好的想法吗?”

建模设计师：“既然我们使用了基于时间的属性，

不妨也为Server、Chef类中也添加一些这样的属性，

用来告诉经理每个雇员的工作时间?”

餐馆老板：“哦…不，这种监视别人工作表现的

做法不适合施加给员工——我也不能这么做。并不是

他们工作偷懒(他们不会的)，仅仅是他们不愿意有一

双眼睛始终盯着他们。如果能让每个人工作心情愉快