16收集系统需求幻灯片.ppt

达到这一目标，需要各位告诉我们你需要系统为你做什么。换句话说，如果系统已经就位的话，那么你将怎样使用系统? 这个问题在本次会议中将会反复被提出。会议结束时，我们将得到每个人都满意的一组系统需求。我们将使用它做为程序员构造实际系统所依据的系统蓝图的基础。我希望大家时刻记住：我们需要你们每个人对系统提出各种需求，不论你们的职位是什么。” 分析员1：“我们能不能从系统的功能模块划分开始?” 协调员：“理所当然。那么如何开始呢?” 餐馆老板2：“上一次讨论我没参加，但我认为这是一个好主意。我们可以按照餐馆中的空间区域组织系统的功能模块吗?大家知道，服务区需要一组功能，厨房需要另一组功能，候餐区也有一组功能，等等。” 协调员：“这么做是一种可能性。” 分析员2：“我看了业务过程图后，觉得它已经为我们提供了组织功能模块的方法了。” 程序员1：“怎么组织?” 分析员2：“按照角色。厨师必须做某些事情，服务员也必须做自己的一些事情，等等。” 协调员：“听起来很不错，大家同意这种组织方式吗？” (全体同意) 协调员：“好！根据业务过程图和类图，人员角色有Server、Chef、Busser、Assistant和Manager。” 餐馆老板2：“你是不是遗漏了两个?还应该有Coat-check clerk和Bartender吧?” 协调员：“我将他们补充进角色列表，还将使用UML包图表示法跟踪需求。”(参见下图) * * 第十六章 收集系统需求 前面两章处理的是领域中的概念问题，产生了业务过程模型和类图。后面要进行的是研究实际的系统。任本章中，将学习： ● 系统展望。 ● 联合应用开发会议(JAD session)。 ● 组织系统的需求。 ● 使用用例。 现在到了开发组开发未来餐馆的技术骨架的时候了。开发组现在已经得到了业务过程模型和系统的类图。下面就可以开始编码了吗?这种想法是错误的，他们甚至离编写程序还有一大段的距离。首先，他们必须要开发出—个系统的视图。 大部分项目都以“构造一个顾客信息数据库系统并使它具有对用户友好的界面，以便于可以花费最短的时间对用户培训”或者“构造一个尽量在最短时间内解决问题的基于计算机的辅助桌面软件”。而现在，开发组只能从一个不太明确的任务“使用技术建立未来的餐馆”开始。开发组必须事先设想出这个餐馆是 什么样了，这样才能估计出餐馆中的各类人员怎样在其中工作。他们现在处在一般的开发组所没遇到过的情况。 开发组将使用他们所了解到的业务过程知识和新获取的领域知识，为的是看看外出就餐的哪些地方可以使用技术来改善。让我们来旁听一个开发组的会议。会议的成员有一名系统分析员、一名建模设计师、一名餐馆老板、一名服务员、一名厨师和一名系统工程师。另有一名主持会议的协调员。 16.1 开发系统的映像 协调员：“请看我们的业务过程模型图，我认为大家都看得出有好几处可以引进计算机技术加以改进。我在一块白板上做记录，哪位先发言?” 协调员给每位与会者散发一份下图的拷贝。 分析员：“很明显，与大部分其他企业一样，餐馆的业务运做也要依赖信息的流动。如果我们能够加速信息的流动(这也是技术所擅长的)，就能够达到我们的目的。” 餐馆老板：“我还不敢肯定已经理解了你的意思。你所说的“信息流动”指的是什么?我认为我的餐馆里一直在流动的是食物。” 系统工程师：“我可以帮你说明什么是信息流动。当顾客下一份定单后，他就在给服务员传递信息，并且，当服务员将这个定单转交给厨师时，他就在使信息继续流动。” 协调员：“还有什么地方有信息流动?” 服务员：“我想我已经有些明白了，当一名顾客叫我去问厨师定单完成情况时，也有信息流动，对不对?” 分析员：“完全正确。” 厨师：“但是服务员来问我饭菜做的如何时，我并不能真正做什么，一切还得照旧进行，在烹饪时我不希望被打扰。” 协调员：“或许我们能找出一种使这种打扰降至最低程度的方法。对信息流动诸位还有什么看法?” 这时，协调员试图缓和厨师的情绪，以使他集中注意力开会。 餐馆老板：“当服务员为顾客背诵每日特色菜点，或者回答顾客就菜单提出的问题时，这是不是信息流动?” 协调员：“肯定也是。”