信息系统分析和设计实验二.docVIP

实验二书面表达能力训练 一、 实验目的 了解UML中的事物、关系和图。 了解需求分析的冃的：给客户带來价值。 训练书面表达能力。 二、实验内容 (一)绘图基本练习，绘制UML屮的事物 掌握绘制类(class)的绘制方法。P42-3.3.1 (1)类class 掌握接口 (Interface)的绘制方法。P43-3.3.1 (2)接口 Interface 掌握用例(Use Case)的绘制方法。P44-3.3.1 (3)用例Use case 掌握协作(Collaboration)的绘制方法。P45-3.3.1 (4)协作 Collaboration 掌握组件(Component)的绘制方法。P45-3.3.1 (6)组件 Component 掌握节点(Node)的绘制方法。P46-3.3.1 (7)节点Note (二)书面表达能力训练 请根据以下“需求分析中的麻烦事？ ”的十三回答，总结以下内容: 需求分析有哪些麻烦事？ 针对这些麻烦事的简单解决方法？ 你从这些回答中学习到哪些非需求分析方面的内容？ “需求分析中的麻烦事？ ”的十三回答 回答一 沟通问题 反复更改 寻找潜在问题 回答二 1调研时人员配合不积极，实际系统与期望有差别 2需求不确定，经常需要改动 3对需要开发的系统流程不是很了解，需求分析时不能抓住重点 回答三 1?需求变化的太快。 这说明客户的想法不断在进化，这是好事，早变不如迟变！ 不过客户经常推翻自己想法的话，这就需要我们好好引导了。 相关人员讨论不到重点。 越是基层员工，越容易纠缠细节而忘记根本。需要选择有价值的员工以及这些基层员工的领 导，问他们的根本想法。 各个人的意见总是不统一。 一些解决方案： 找11!意见不同者的共同利益，“设计”出各方都满意的需求。 以及让意见不同者的领导来发挥主导作用。 不过以上问题的根本原因就是客户对需求的认识还不够深，解决问题的根本办法就是项目组 提升需求分析的能力，给客户提出有价值的需求方案并得到客户的认可。 回答四 行业知识的把握和学习。 如果是老行业，需要经常总结提炼。如果面对新行业，要具有快速学习接受新行业的经 验和能力。 对访问客户的定位。 客户有很多种，有的是领导级别的，有的是具体做事的，有的是行业专家等等。我们经 常没有权利选择自己想要访问客户，所以面对你一无所知的客户，要先直接或者间接问一些 跟客户相关的信息，然后给你面对的客户一个准确的定位。面对不同类型的客户，有不同的 调研重点和调研方向。 挖掘潜在和本质的需求。 这个难免与第一点有关系一一与需求人员对业务知识的掌握程度有关。不过除此之外， 也有需求人员的分析经验有关。这里的经验特指那些不与具体业务知识相关的经验。比如当 你听到两个有关联的对彖时，一定要搞清楚他们的00关系和数量关系。 把握常变需求，做相应的扩展需要或者和客户交待清楚。 熟练运用多种建模方式。 比如我调研的时候经常是当场制作uml图的。如果没有一定得建模功底，很难当场用 uml图来引导客户和自己的需求分析思路。 最后说一个抽彖点的问题。那就是00思想。 我们知道UML指引的需求分析也是血向对象的，即面向对象分析方法。在与客户沟通 过程中，为了更好的展开面向对象分析方法，除了分析人员要有很好的00思想之外，还要 指引客户走向面向对象的思维。这样很有利于你和客户达成共识，促成和谐、深度探讨、共 同理解的调研环境。 回答五 需求很空洞，很笼统。经常是领导说：我要上某某系统，或者我要一个某某功能。他 说不出上这个系统要达到的具体目标，也说不出具体需要什么功能，涉及哪些使用部门等。 通常这个时侯领导的手下们也并不清楚领导的想法。当我们按照自己的思路和想象分析完后, 把想到的东西罗列给领导看，他只会说，这些功能全部都要，所有方面都要涉及等。而这样 的结果是系统很复杂，但可能很多流程和实际并不相符，还有很多功能永远都不会使用到。 需求提出者并没有想清楚，所以提出的需求经常变化。有时自己提出的要求过一段被 自己否定，甚至不承认是自己提出的，然后又提出一个不同的要求，反反复复。 提出需求的人没有多少耐心，软件设计者对需求者的业务流程并不熟悉，所以在理解 需求时会有偏差，但提出需求的人不愿花时间做深入的交流，只是把自已的想法点到为止。 很少会有这样一个人，他懂得所有部门所有岗位的需求，能站在一个更高的层次，以 放眼全局的眼光來描述需求。作为需求分析人员，通常面对的是零散的、只考虑自已部门方 便的、不全面的需求，在不熟悉业务流程的情况下，想整理清楚几乎象登天。 提出需求的人没有前詹性，只考虑眼前，做出来的系统用不了多久又要更改 回答六 1、找不到真正的干系人 尤其是业务提出者，系统决策者等上层用户。与此类用户无法有效沟通，不能明白领导 的真实意图，潜在需求，只是