• / 46
  • 下载费用:16 金币  

16收集系统需求

关 键 词:
16收集系统需求 16系统需求
资源描述:
第十六章 收集系统需求 前面两章处理的是领域中的概念问题,产生了 业务过程模型和类图。后面要进行的是研究实际的 系统。任本章中,将学习: ● 系统展望。 ● 联合应用开发会议(JAD session)。 ● 组织系统的需求。 ● 使用用例。 现在到了开发组开发未来餐馆的技术骨架的时 候了。开发组现在已经得到了业务过程模型和系统 的类图。下面就可以开始编码了吗?这种想法是错误 的,他们甚至离编写程序还有一大段的距离。首先 ,他们必须要开发出—个系统的视图。 大部分项目都以“构造一个顾客信息数据库系统 并使它具有对用户友好的界面,以便于可以花费最 短的时间对用户培训”或者“构造一个尽量在最短时间 内解决问题的基于计算机的辅助桌面软件”。而现在 ,开发组只能从一个不太明确的任务“使用技术建立 未来的餐馆”开始。开发组必须事先设想出这个餐馆 是 什么样了,这样才能估计出餐馆中的各类人员怎样 在其中工作。他们现在处在一般的开发组所没遇到 过的情况。 开发组将使用他们所了解到的业务过程知识和 新获取的领域知识,为的是看看外出就餐的哪些地 方可以使用技术来改善。让我们来旁听一个开发组 的会议。会议的成员有一名系统分析员、一名建模 设计师、一名餐馆老板、一名服务员、一名厨师和 一名系统工程师。另有一名主持会议的协调员。 16.1 开发系统的映像 协调员:“请看我们的业务过程模型图,我认为 大家都看得出有好几处可以引进计算机技术加以改 进。我在一块白板上做记录,哪位先发言?” 协调员给每位与会者散发一份下图的拷贝。 分析员:“很明显,与大部分其他企业一样,餐 馆的业务运做也要依赖信息的流动。如果我们能够 加速信息的流动(这也是技术所擅长的),就能够达到 我们的目的。” 餐馆老板:“我还不敢肯定已经理解了你的意思 。你所说的“信息流动”指的是什么?我认为我的餐馆 里一直在流动的是食物。” 系统工程师:“我可以帮你说明什么是信息流动 。当顾客下一份定单后,他就在给服务员传递信息 ,并且,当服务员将这个定单转交给厨师时,他就 在使信息继续流动。” 协调员:“还有什么地方有信息流动?” 服务员:“我想我已经有些明白了,当一名顾客 叫我去问厨师定单完成情况时,也有信息流动,对不 对?” 分析员:“完全正确。” 厨师:“但是服务员来问我饭菜做的如何时,我 并不能真正做什么,一切还得照旧进行,在烹饪时我 不希望被打扰。” 协调员:“或许我们能找出一种使这种打扰降至 最低程度的方法。对信息流动诸位还有什么看法?” 这时,协调员试图缓和厨师的情绪,以使他集 中注意力开会。 餐馆老板:“当服务员为顾客背诵每日特色菜点 ,或者回答顾客就菜单提出的问题时,这是不是信 息流动?” 协调员:“肯定也是。” 厨师:“有时我也回答顾客提出的问题。顾客让 服务员到厨房来问我某个菜做的怎么样时,我或者 告诉服务员,由服务员转达给顾客,或者我不太忙 时,会亲自出去解答顾客的问题。顾客喜欢我这么 做。” 服务员:“我要告诉你我最不喜欢的一种信息流 动。顾客下了一份定单,我将定单送到厨房,结果 听到厨师说我们缺某个菜。这时我必须让顾客再点 其他的菜。这通常会使顾客不高兴——也让我不高 兴,因为我的小费会受影响的。” 分析员:“是不是应该把这个过程作为一个单独 的业务过程另外讨论?” 协调员:“也许。我认为各位会同意再为此单独 开一个会。” 协调员要尽量使与会者注意力集中到会议的主 要议题上。注意协调员避免使用“是的,但……”等 字眼。 协调员:“让我们总结一下会议到目前为止的成 果,根据我的记录,信息流动出现在以下几处: ● 顾客下一份定单(点菜)。 ● 服务员将定单转交给厨师。 ● 顾客要求服务员到厨房探察定单的完成情况 。 ● 服务员为顾客背诵每日特色菜点。 ● 服务员回答顾客就菜单提出的问题。 ● 厨师回答顾客关于某样菜烹饪方面的问题。 与业务过程会谈时的情形一样,协调员在适当 的时候暂停会议,做个总结将大有好处。 分析员:“我知道还有一处没有出现在业务过程 模型图中。就是顾客如果对帐单有些疑问当服务员回 答这些问题时,这也需要信息流动。” 协调员:“对了,确实如此,业务过程中还有需 要信息流动的地方吗?” 系统工程师:“我发现了一处。在厨师与服务员 之间进行协调时是不是也需要信息流动?他们不是要 确保在顾客吃完小菜时给顾客同时上热的主菜吗?这 时需要大量信息流动。” 分析员:“我同意。这时的信息要以几种不同的 方式流动。” 餐馆老板:“你只拿出了两幅业务过程模型图。我记 得还有一幅。” 协调员:“对了。还有一幅‘清理餐桌’业务过程 模型图。” 分析员:“看上去这幅图中只有一处信息流动的 地方,但我敢打赌,这一处的信息流动十分重要:服 务员召唤清洁师,通知清洁师立即清理餐桌。” 餐馆老板:“是的,这是十分重要的。只有餐桌 清理好了才能让新来的顾客就坐。清理餐桌必须进行 的尽可能快,否则我们餐馆的休息室和候餐区里就坐 满了又饿又气的顾客。” 建模设计师:“在听到你们发言时,我同时在修 改我的类图。我可以问个问题吗?让我们的系统具有 评估招待顾客的工作效率的功能,这是不是个好主意 ?” 餐馆老板:“好主意。有了这项功能我们就知道 是不是要改进我们的工作以及如何改进。你是怎么认 为的?” 建模设计师:“在我们的Customer类中设置两个 属性arrivalTime和serveTime。我还准备再增加一个导 出属性waitDuration.它是serveTime和arrivalTime之 差。对此你有什么看法?” 餐馆老板:“好主意。这样我们就知道我们是怎 样招待顾客的了。” 分析员:“是的。还可以得到许多有用的数据— —例如每天所有顾客候餐的总时间每名服务员招待的 所有顾客的平均侯餐时间,等等。” 建模设计师:“还有另一种可能。假设在 Customer类中再增加一个叫做depatureTime的属性和 一个导出属性mealDuration,它是depatureTime和 serveTime之差,这样做如何?” 协调员:“应该不错。还有其他好的想法吗?” 建模设计师:“既然我们使用了基于时间的属性 ,不妨也为Server、Chef类中也添加一些这样的属性 ,用来告诉经理每个雇员的工作时间?” 餐馆老板:“哦…不,这种监视别人工作表现的 做法不适合施加给员工——我也不能这么做。并不是 他们工作偷懒(他们不会的),仅仅是他们不愿意有一 双眼睛始终盯着他们。如果能让每个人工作心情愉快 ,那么我们的餐馆就是一家好餐馆,顾客也能体会到 。” 厨师:“我同意。我前面讲过,做菜的时候不能 被打扰,该需要多长时间就得需要多长时间。我不希 望在我手里拿着一捆菜时,突然听到经理对我说必须 在4分钟之内把这个菜做好。” 服务员:“我也不想听到顾客在吃完主菜后说我 迟迟才将甜点菜单拿来。” 建模设计师:“好,我收回刚才的建议。既然你 们刚才提了这么多合理的反对意见,我就应当删掉 Manager类中的“monitor(监视)”操作。同时, Customer类也做相应的修改。” 建模设计师的想法表明他总是不断地修改类图 。 建模设计师、餐馆老板和服务员之间的谈话说 明了一个重要结论:让业务领域中的人也参与系统 开发是绝对必要的。如果没有餐馆老板和服务员提 供的反馈信息,开发组很可能就花费了不必要的时 间和金钱去实施一些工作监视方面的需求特征,最 后反而会自受其害。这样的想法一提出就遭到餐馆 中的工作人员的反对,这样可以让开发组重新思考 ,并最终做出有利于餐馆工作人员的决定。 协调员:“根据我所听到的,似乎我们可以将改 进分为两方面,一方面是加速信息的传递速度, 另一方面是加快某项个人任务的完成速度。开发组 的意见认为第二种不太受欢迎,而第一种却大有必 要。我说的对不对?” (全体同意) 分析员:“既然我们已经做了上述决定,下面是 不是应该继续讨论系统具体的需求?” 协调员:“当然。大家还有其他意见吗?” 服务员:“为了传递这些倍息,我一晚上要来回 走很多路。有的时候我还必须到离工作区很远的厨 房去。携带东西和往返的路程非常花费时间,更别 说还要穿着皮鞋来回走。” 分析员:“看样子我们的系统必须提供一些功能来消 除,至少是减轻往返路程和携带物品。这样才能加 快信息的流动。” 协调员:“往返路程和携带物品?” 分析员:“是的。我们的系统必须设法减少服务 员的来回走动。很显然他们要到厨房去取回定单并 把定单带回到餐桌旁,并且必须及时。” 系统工程师:“我认为我们要决定某件事情。使 用一个局域网来连接服务员和厨房以及服务员与清 洁师如何?这样信息的流动速度就可以加快很多。” 分析员:“我不想过分地强调对系统的分析,但 是局域网要在各个终端之间布线。这样的话,服务 员虽然不用直接跑到厨房去,但也还得必须跑到终 端面前。似乎有为了技术而使用技术的嫌疑,能带 来什么好处呢?” 系统工程师:“如果按照你说的方式来建立系统 ,那么我承认没带来什么好处。实际情况可能还会 更糟糕。但是我的主意不是这样的。假设每名服务 员和清洁师都携带一台终端——一台手提式电脑。 进一步假设找们在这些计算机之间建立一个无线网 络。厨房和经理办公室里可以分别放一台桌面电脑 终端。另一种可选的方案是让服务员和清洁师使用 掌上 电脑。但手提式电脑一般带有显示器和键盘,这种 特征可以为以后的设计增加灵活性。” 分析员:“哦…我喜欢你的这种方案。这样的系 统可以解决不少问题。例如,当一组顾客决定了定 单后,服务员可以将用户定单上的菜点输入到手提 式个人计算机中,然后传到厨房的桌面电脑。这样 可以省去服务员在服务区和厨房之间的往返。” 服务员:“我喜欢这种方案。当顾客吃完小菜时 ,我就可以通过敲击我的手提式电脑上的键盘通知 厨师顾客已经吃太小菜了,这样可以省去我亲自到 厨房去告诉厨师准备上主菜。” 厨师:“这样我在厨房就可以获得服务员传来的 信息。事实上,我所有的助手都可以同时收到消息 ,这可以通过把消息显示在几个大屏幕上做到。这 样我可以有效地跟踪我的每个助手在做什么菜,并 告知他们何时菜应该做好。让每个助手各负其责。” 系统工程师:“当完成了定单上的菜点后,你可 以通过厨房的桌面电脑向服务员的手提式电脑发送 消息,告知服务员。服务员可以不必来回往返,校 对某个菜是否已经做好。顺便提一句,我们可以将 手提式电脑(handleld PC)简称为手提机。” 服务员:“太好了。我也可以给清洁师发信号让 他过来清理餐桌,不用到处去找他们了。这样可以大 大提高工作效率。” 餐馆老板:“怎么具体实现这些呢?” 系统工程师:“现在暂时可以不必关心这个问题 。” 协调员:“我们都同意这种方案了吧?我们的系统 采用一个无线局域网,服务员和清洁师使用手提式个 人计算机,经理办公室和厨房使用桌面电脑。现在只 差一件事情了。” 分析员:“差什么事情?” 协调员:“为这个系统起个很酷的名字。” 分析员:不妨叫Wireless Interactive Network for Restaurant(餐馆无线交互式网络)?它的简写是 WINNER,代表胜利者的意思。” 协调员:“最后两个字有点多余。” 系统工程师:“干脆就来个简洁明快的名字: Wireless Interactive Network——WIN。” 厨师:“我喜欢这个名字。” 分析员:“我也是。WIN(胜利)这个名字无可挑剔 。” 协调员:“大家都同意采用WIN这个名字了吗?好 ,我认为我们的会议已经圆满成功。” 16.2 收集系统需求 既然开发组已经开发出实际系统的一个映像, 是不是程序员就可以编码了,系统工程师可以开始 部署系统了?绝对不是。开发组必须集中考虑用户的 需求,而不能只以技术观点来开发系统。尽管会议 中确定了某些方案,但是还必须将WIN系统中的概 念提交给餐馆中的工作人员和经理,以从这些可能 的用户那里获得反馈意见。 GRAPPLE开发过程的下一个动作要做的就是这 件事。在一个联合应用开发会议(JAD Session)中,开 发组收集用户的需求,将需求编制成文档,有了 需求文档在手,就可以对项目耗费的时间和金钱做 出估算。 联合应用开发会议在一间正式的会议室举行, 由一名协调员主持。将它称为“联合”会议是因为会议 的成员不仅包括开发组成员,还要包括系统可能的 最终用户和领域专家。参加这次会议的开发组成员 有两名分析员,兼做会议记录员,还有一名建模设 计师,两名程序员和一个系统工程师。可能的用户 是三名服务员,两名厨师、两个餐馆老板和两名清 洁师。 这次会议的目标是产生能反映系统功能的包图 ,每个包代表系统的一个功能模块,其中包含了详 细 说明该功能模块的若干个用例。 16.3 需求联合应用开发会议 协调员:“首先,感谢各位光临本次会议。这次 会议的时间可能很长,但也会很有趣。我们要做的 是收集一个被称为WIN的系统的需求。WIN系统中 的基本模念很容易理解,它的大致情况是这样的: 服务员使用手提式个人计算机与厨师和清洁师通信 。清洁师也使用手提式计算机通信。厨房中安装一 台桌面电脑和一个或多个显示屏幕。经理办公室中 也安装一台桌面电脑。我所说的可以参见图上所示 。 “我们希望将WIN系统安装在LNG餐馆中,并 期望能够改进现有的业务,提高工作效率。为了 达到这一目标,需要各位告诉我们你需要系统为你 做什么。换句话说,如果系统已经就位的话,那么 你将怎样使用系统? 这个问题在本次会议中将会反 复被提出。会议结束时,我们将得到每个人都满意 的一组系统需求。我们将使用它做为程序员构造实 际系统所依据的系统蓝图的基础。我希望大家时刻 记住:我们需要你们每个人对系统提出各种需求, 不论你们的职位是什么。” 分析员1:“我们能不能从系统的功能模块划分 开始?” 协调员:“理所当然。那么如何开始呢?” 餐馆老板2:“上一次讨论我没参加,但我认为 这是一个好主意。我们可以按照餐馆中的空间区域 组织系统的功能模块吗?大家知道,服务区需要一组 功能,厨房需要另一组功能,候餐区也有一组功能 ,等等。” 协调员:“这么做是一种可能性。” 分析员2:“我看了业务过程图后,觉得它已经 为我们提供了组织功能模块的方法了。” 程序员1:“怎么组织?” 分析员2:“按照角色。厨师必须做某些事情, 服务员也必须做自己的一些事情,等等。” 协调员:“听起来很不错,大家同意这种组织方 式吗?” (全体同意) 协调员:“好!根据业务过程图和类图,人员角 色有Server、Chef、Busser、Assistant和Manager。” 餐馆老板2:“你是不是遗漏了两个?还应该有 Coat-check clerk和Bartender吧?” 协调员:“我将他们补充进角色列表,还将使用 UML包图表示法跟踪需求。”(参见下图) 建模设计师:“我赞成这样做。我会在类图中补 充一些信息。CoatCheckClerk类早已经存在了。我将 细化这个类并添加Bartender类。” 协调员:“现在已经有了功能包,应该从哪个功 能包开始进一步分析?” 服务员1:“从Server包开始如何?” 协调员:“好。你需要这个包中为你提供哪些功 能?各位别忘了,尽管这个包所代表的角色可能与你 的职位不一致,但还是请大家从各方面提出你的看法 。每个人的建议我们都欢迎。” 服务员2:“我希望能在我的电脑中输入定单信息 ,并将这些信息传递到厨房。” 协调员:“好。还有别的吗?” 服务员1:“我能跟踪定单的状态吗?” 厨师2:“我能在定单完成后通知服务员吗?” 协调员:“对,对。你们应该已经注意到了我 已经把你们要求的功能写到了椭圆形的图标里。这 些图标被称为‘用例’。我将重新请你们中的部分人讨 论和分析这些用例,但这是下一次会议要做的事。” 16.4 结果 联合应用开发会议持续了好几天。当会议结束 后,产生了一组需求,这些需求通过用例来表达, 若干个相关用例被组织进一个包中。 Server包中的用例有: Chef包中的用例有: Busser包中的用例有: Assistant包中的用例有: Bartender包中的用例有: CoatCheckClerk包中的用例有: 下图是用UML表示法表示的这些包和用例,以 及建模设计师增加了两个类和必要的关联后所得到 的类图。 16.5 小结 在开发组的会议中,开发组开发了一个未来餐馆 中信息系统的映像。开发组成员认为能否加快信息的 流动速度是系统成败的关键,并且为此提出了一些技 术方案。 在一次联合应用开发会议中,开发组与系统可能 的用户以及领域专家一同收集系统需求。需求收集的 结果是一个包图,这个包图中的每个包代表了系统的 一个主要功能模块。每个包中的用例详细说明这个包 代表的功能。 开发组提交给客户的文档很多。包括业务过程 图、类图和一组功能包。下面开发组就要编码了吗? 还没有,他们还要分析功能包中包含的内容,这就 是下一个动作的目标。 联合应用开发会议的成员中有一部分可以是前 期的开发组会议的成员,事实上这也是被推荐的。 这部分成员可能会记住一些没在会议记录中记录下 的关键细节。 关于系统的功能模块划分,并不总是如本章所 述的那样,按照角色来组织系统的功能模块。只是 在餐馆这个特定领域按照角色组织功能模块比较 方便。其他类型的系统可能需要不同的功能划分。 例如,一个帮助系统可能需要问题输入、问题解决 和结果输出3个功能包,每个包中部包含若干个用例 。
展开阅读全文
  麦档网所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
0条评论

还可以输入200字符

暂无评论,赶快抢占沙发吧。

关于本文
本文标题:16收集系统需求
链接地址:https://www.maidoc.com/p-15679655.html
关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

[email protected] 2018-2020 maidoc.com版权所有  文库上传用户QQ群:3303921 

麦档网为“文档C2C模式”,即用户上传的文档所得金币直接给(下载)用户,本站只是中间服务平台,本站所有文档下载所得的金币归上传人(含作者)所有。
备案号:蜀ICP备17040478号-3  
川公网安备:51019002001290号 


收起
展开