信息系统分析与设计-实验二.docxVIP

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