信息系统分析与设计

1、实验二书面表达能力训练一、实验目的1. 了解UML中的事物、关系和图。2了解需求分析的目的：给客户带来价值。3. 训练书面表达能力。二、实验内容(一) 绘图基本练习，绘制 UML中的事物1. 掌握绘制类(class)的绘制方法。P42-3.3.1 (1 )类class2. 掌握接口( In terface)的绘制方法。P43-3.3.1 (2)接口 In terface3. 掌握用例(Use Case)的绘制方法。 P44-3.3.1 (3)用例 Use case4. 掌握协作(Collaboration )的绘制方法。 P45-3.3.1 (4)协作 Collaboration5. 掌握组件

2、(Component)的绘制方法。 P45-3.3.1 (6)组件 Component6. 掌握节点(Node)的绘制方法。P46-3.3.1 (7)节点Note(二) 书面表达能力训练请根据以下“需求分析中的麻烦事？ ”的十三回答，总结以下内容：1. 需求分析有哪些麻烦事？2. 针对这些麻烦事的简单解决方法？3. 你从这些回答中学习到哪些非需求分析方面的内容？“需求分析中的麻烦事？ ”的十三回答回答一1. 沟通问题2反复更改3.寻找潜在问题回答二1调研时人员配合不积极，实际系统与期望有差别2需求不确定，经常需要改动3对需要开发的系统流程不是很了解，需求分析时不能抓住重点回答三1. 需求变化的

3、太快。这说明客户的想法不断在进化，这是好事，早变不如迟变！ 不过客户经常推翻自己想法的话，这就需要我们好好引导了。2. 相关人员讨论不到重点。越是基层员工，越容易纠缠细节而忘记根本。需要选择有价值的员工以及这些基层员工的领 导，问他们的根本想法。3. 各个人的意见总是不统一。一些解决方案：找出意见不同者的共同利益，“设计”出各方都满意的需求。以及让意见不同者的领导来发挥主导作用。不过以上问题的根本原因就是客户对需求的认识还不够深，解决问题的根本办法就是项目组提升需求分析的能力，给客户提出有价值的需求方案并得到客户的认可。回答四 1行业知识的把握和学习。如果是老行业，需要经常总结提炼。如果面对新

4、行业，要具有快速学习接受新行业的经 验和能力。2对访问客户的定位。客户有很多种，有的是领导级别的， 有的是具体做事的， 有的是行业专家等等。我们经 常没有权利选择自己想要访问客户，所以面对你一无所知的客户， 要先直接或者间接问一些跟客户相关的信息，然后给你面对的客户一个准确的定位。面对不同类型的客户， 有不同的调研重点和调研方向。3挖掘潜在和本质的需求。这个难免与第一点有关系一一与需求人员对业务知识的掌握程度有关。不过除此之外， 也有需求人员的分析经验有关。这里的经验特指那些不与具体业务知识相关的经验。比如当你听到两个有关联的对象时，一定要搞清楚他们的00关系和数量关系。4把握常变需求，做相应

5、的扩展需要或者和客户交待清楚。 5熟练运用多种建模方式。比如我调研的时候经常是当场制作uml图的。如果没有一定得建模功底，很难当场用uml图来引导客户和自己的需求分析思路。6最后说一个抽象点的问题。那就是00思想。我们知道UML指引的需求分析也是面向对象的，即面向对象分析方法。在与客户沟通 过程中，为了更好的展开面向对象分析方法，除了分析人员要有很好的 00思想之外，还要指引客户走向面向对象的思维。这样很有利于你和客户达成共识，促成和谐、深度探讨、共同理解的调研环境。回答五1需求很空洞，很笼统。经常是领导说：我要上某某系统，或者我要一个某某功能。他 说不出上这个系统要达到的具体目标，也说不出具

6、体需要什么功能，涉及哪些使用部门等。 通常这个时侯领导的手下们也并不清楚领导的想法。当我们按照自己的思路和想象分析完 后，把想到的东西罗列给领导看，他只会说，这些功能全部都要，所有方面都要涉及等。而 这样的结果是系统很复杂，但可能很多流程和实际并不相符，还有很多功能永远都不会使用到。2需求提出者并没有想清楚，所以提出的需求经常变化。有时自己提出的要求过一段被 自已否定，甚至不承认是自已提出的，然后又提出一个不同的要求，反反复复。3提出需求的人没有多少耐心，软件设计者对需求者的业务流程并不熟悉，所以在理解 需求时会有偏差，但提出需求的人不愿花时间做深入的交流，只是把自已的想法点到为止。4很少会有

7、这样一个人，他懂得所有部门所有岗位的需求，能站在一个更高的层次，以 放眼全局的眼光来描述需求。作为需求分析人员， 通常面对的是零散的、只考虑自已部门方便的、不全面的需求，在不熟悉业务流程的情况下，想整理清楚几乎象登天。5提出需求的人没有前詹性，只考虑眼前，做出来的系统用不了多久又要更改回答六1、找不到真正的干系人尤其是业务提出者， 系统决策者等上层用户。 与此类用户无法有效沟通，不能明白领导的真实意图，潜在需求，只是围绕在中间和下面人员，纠缠于业务细节，很容易走偏，带来 反复、拖期。2、太想把需求一次性搞完。例如在2个周内 或者 在*时间内，按照瀑布流程或里程碑要求，完成该项目的需求分析工作，

8、公司流程这样规定的，公司领导很多也是这样要求的，都想来个“一次搞完万事大吉”做完需求就可以指导项目后面各个阶段的运行了，岂不知需求的获取 和 客户的交流，是贯穿项目始终的， 项目组和客户对需求，尤其是潜在需求的认识、达成共识，是需要一个 循序渐进的过程的。3、我们不是业务专家。现在的软件项目，很多都是针对某个行业做深度开发的或者 在已有的多个系统基础上做集成，然后再开发新应用的。这种情况下，对该行业的知识、背景、趋势、专业等不到一 定程度的了解，很难与用户有效的沟通起来，仅仅是用户讲你来记的听课方式，用户也不会有很多交流兴趣的。至少我们自己像个专家或者带个类似角色的人充当专家或者先找行业专家做

9、好课前辅导。以上仅仅是对工程类项目需求分析遇到的问题。做产品开发，涉及的内容可能会更多。回答七1、需求分析需要针对重点，找到最终用户；但是现实却是参与者都在发言，不知道该听谁 的，不该听谁的，并且可能没有一个真正用户。2、由于参与者多，导致的需求变更问题，反复存在。3、需求文案、文档等说明不能完全渗透至开发或者最终用户，导致开发结果令用户不满， 耽误时间，浪费成本。应对建议：分析各种用户的关系、各自的利益关注点等，能帮助我们识别出真正的需求，解决各种用户之间的利益矛盾点。深入理解客户的业务，站在比客户更高的高度，这样才能做到“给客户带来价值”。要做到以上的要求，难度是超高的，希望本课程能给大家

10、带来帮助！回答八1、客户和用户不重视需求分析，在进行需求调研时，不能积极配合，往往是有各种事情， 打断调研工作。有时客户（信息中心的人）重视了，但用户不重视。当然，也有自身原因， 由于对用户业务不够了解，常常造成双方沟通存在偏差，影响效率，又因项目进度等要求， 造成需求分析工作草草结束。2、用户不能准确表达其需求，计算机技术人员理解的和用户说的不一致。3、业务较复杂时，需要对业务进行优化，但用户常有抵触。而按现有业务做的软件，常常感觉并不能带来多少便利。 如果仅仅是简单将现有业务从手工变为信息化，一般并不能带来多大的生产力提升，需要我们在需求分析的时候能吃透业务，提出更好的、更有价值的需求解决

11、方案。回答九 我遇到的情况是已经有产品了，新的项目多半是在既有产品之上开发1如何减少需求对既有设计的影响？有时客户很强势，提出一些对既有产品结构有很大影响但有不得不答应的要求。2界面需求不好明确，经常是后期作出来了，客户看到了让改。功能需求还有具体化的可能， 那纯界面的需求如何设计？3市场部提出的功能需求文档不明确，往往都是一句话。回答十我也来说说 最近遇到的情况。1, 甲方需求接口人，为假设甲方知道某些领域术语或者知识。2, 甲方在1中基于假设的条件下，会一股脑儿的把他知道的告诉你。3，甲方需求接口人告诉你的时候，你不可能快速理解。并且他也可能并不知道你不理解。应对建议：1, 不打断甲方需求

12、接口人，让他总体上概述一下。2, 根据总体概述用 UC图 描述粗粒度的系统概貌， 不明白立马问甲方。 一定要再总体上用 UC描述出系统的功能点。3, 根据某个UC图里面的功能点，再细分，可以用静态或者动态方法细分。在分析的时候要一定有一张领域知识的术语表，不懂地方随时沟通并记录， 在开始的时候先让甲方总体介绍。然后自己用UC画出轮廓，然后细分，千万别让客户一股脑的没逻辑或逻辑很少的把业务知 识倒给你。回答十一1、客户对业务认知度不够，无决策权，反复确认需求过程时导致客户不满。2、客户对分析需求时提出的技术性难题置之不理，认为这不是作为甲方的自己应该关心的 问题。3、项目经理盲目的遵从客户要求，

13、导致项目组开发进度一再修改，拖延到最后无法交差。回答十二做了几年开发，现在才转做软件设计， 其实说是软件设计但是我觉得我最需要做的就是需求 分析。目前我工作的城市对需求分析不是很重视，大部分软件公司都是接到项目就开始着手开发了，即使有需求分析环节也是要求一两天就出来结果。而且，很多需求都是由客户部的人转述给我们，我们没有机会真正接触到客户甚至用户。我感觉需求分析最麻烦的事情是：1、项目负责人不重视需求分析的重要性，长期以来的软件开发习惯让大家更重视开发。2、需求分析人员接触不到真正的用户，大部分需求分析人员最多只能接触到客户，由客户来说明需要实现什么业务。 但是客户描述的角度是以他自身出发，不

14、能真正地反应用户的需求。3、客户至上的心理枷锁会让需求人员在分析的时候过多地在意客户提出来的具体细节，而忽视了软件的真正需求和目标，会陷入细节的纠结中无法自拔。4、客户需求变更频繁，其实潜在的问题应该是需求分析人员没有认识到我们设计软件到底 需要解决什么问题。根本原因就是需求分析人员的业务认知程度一直低于客户对业务的认知 程度，无法理解客户的真正需求。5、需求分析人员对业务的不熟悉，容易造成客户怎么提就怎么设计，思维被固化。6、需求分析的范围界定不清楚，经常在分析过程中为了某一功能而增加另一功能，造成范围越扩越大，到最后无法继续进行。7、需求分析人员也很想了解业务，但是不知道如何下手了解。 这

15、些是我做需求分析的一些困惑吧，希望在不久的一天自己能够想明白，不再困惑。回答十三简单说说我对需求分析和软件设计的感受：需求分析：易学难精，不懂软件设计不会写代码的话，也可以做好需求分析工作，但很难达到更高的境界，我见到的需求分析很牛的人，他们同时也是（或者是曾经是）程序的设计高手或者是骨灰级的程序员。软件设计：难学难精，优秀的软件设计师必须具备分析需求的能力，很多设计的问题其实是与需求分析密不可分的。三、实验要求1 绘图题：请用文字简单说明绘制过程，如需贴图请将绘制图片请黏贴到相应的位置。2文字题：请用最简洁明了的方式表达可以是文字、表格或图混合的方式。3. 实验二提交时间：3月23日。四、实

16、验报告1.实验报告内容（一）绘图基本练习，绘制UML中的事物1.掌握绘制类（class）的绘制方法。P42-3.3.1 （1 ）类class过程描述：在Rose中打开左侧树形浏览器的 Logical View 宀Mai n节点，双击 Ma in打开对应视 图。然后单击 Toolbox工具栏上的类按钮，并在Main视图编辑区单击，即可创建一个类。NewClass表示默认创建的类名，单击选中后再单击NewClass字符串可以修改类名。双击类图或者右键单击类图，在弹出菜单中选择Open Specification命令，系统会弹出类图属性设置对话框，可以对类进行进一步设置。贴图：好 Ratidnal

17、Rose - jritriedl* - pCleis Diagram:View /産 百 Edit Viwr Fchtat Ekows总 Report Queiy dc：e Add-Ins Window* Help匚刁bl盂笔氏忌睢二JI同PS冏間冃阪4 孤G女|IT-Cl r：4 Cut Tit*Q /I 宙CJggJ'ef） ciusir，一 /2. 掌握接口（ In terface）的绘制方法。 P43-3.3.1 （2）接口 In terface过程描述：在Rose中打开左侧树形浏览器的Logical View 宀Mai n节点，双击 Ma in打开对应视图。然后单击 Tool

18、box工具栏上的接口按钮，并在Main视图编辑区单击，即可创建一个接口。New In terface表示默认接口的名称，选中后再单击Newl nterface字符串可以修改接口名称。右键单击接口并在弹出菜单中选择Options t stereotype Display命令，可以看到接口的四种显示方式，分别是None、Label、Decoration和Icon （Icon为默认的显示方式）。贴图:用例 Use case3.掌握用例(Use Case)的绘制方法。P44-3.3.1 (3) 过程描述：在Rose中打开左侧树形浏览器的User Case View 宀视图。然后单击 Toolbox工具

19、栏上的用例按钮，并在MainMain节点，双击 Main打开对应 视图编辑区单击，即可创建一个NewUseCase 修改Open Specification命令，在弹出的属性设置用例。NewUseCase表示默认接口的名称，用户可以选中用例再单击文字 名称，也可以右键单击图标在弹出菜单中选择 对话框中进行设置。贴图：4. 掌握协作(Collaboration )的绘制方法。P45-3.3.1 (4)协作 Collaboration过程描述：在Rose中并没有直接提供绘制协作的方法。用户可以首先绘制一个用例，打开属性设置对话框，然后在其属性设置对话框中的Stereotype下拉框中选择 use-

20、case realization即可。也可以将use-case realization类型的按钮添加到工具栏上面，在本实验中选用第一种做法。贴图：令 白松I- U疋匚MF DiBgriini: Uie 色讷* 丿 KAair<| 箕y. File- Edit Wew Fd-nnst Qfdwke ReficrtTook Add-Ins LWrtdcw Help_ r X宅殆净畔口 K H； ®* c暂（latabLiJJE ijllse C«t 鬥冲d!IbLDL1 7. . dl di*.;El a« a cs k1： i am糸rFs底 lla*L Vi

21、 #*礼/1* 厂气Mr CeJiabMr' -耳 *1 T T1 砸/Ht DI JtsLi.'. &E 2. FL|BiA£aAlLlAl辿5. 掌握组件(Component)的绘制方法。 P45-3.3.1 (6)组件 Component过程描述：在Rose中打开左侧树形浏览器的Comp onent View f Ma in节点，双击Mai n打开对应视图。然后单击 Toolbox工具栏上的组件按钮，并在Main视图编辑区单击，即可创建一个组件。组件的默认名称为 NewComponent，同理可以直接修改组件名或者打开属性对话框来 设置更多属性。贴图：电

22、t RdTiDH jil- turtitled) - CORlp&rigirt jUrarnrlLEiiinparN&fTtrMdiflj買kl Hie Edit 讷 cv Farm nt iBrcmsE Rqpcrt Quefy Task Add-Ins kWindow Help-呂 XH V Ri F S罟口曲苗也国世ESQ泛&幻B / 亡 C ffl二I|_|前* 杠业也 庄 iJllM C«t 巧 圧 OOil-口匚Mb虹:U邛4F . ''La(/Ifrui H.«L; pi h：让 FL6掌握节点（Node）的绘制方法。P

23、46-3.3.1 （7）节点Note过程描述:在Rose中双击Deployment View 打开对应视图。然后单击Toolbox工具栏上的处理器按钮或者设备按钮，并在右侧视图编辑区单击，即可创建一个节点。处理器默认名称为 NewProcessor，设备默认名称为 NewDevice 。贴图:（二）（三）书面表达能力训练1 需求分析有哪些麻烦事？2.3针对这些麻烦事的简单解决方法？4. 你从这些回答中学习到哪些非需求分析方面的内容？你的总结描述：1 需求分析有哪些麻烦事？答：简而言之需求分析中的麻烦之处分为三部分：重视度低、沟通问题和频繁改动。首先， 存在一部分的客户与从业人员对需求分析并不重视。对于客户而言，这样的不重视很可能演变为对于需求描述的空洞：例如只是简单地说要有什么系统或功能，却不进行具体的详细叙述与表达，甚至不能积极配合； 对于少部分从业尤其是项目负责人来说，对需求分析的不重视也会致使直接开始软件的开发过程，从而引发后续的问题。其次，客户与开发者之间、甚至开发者内部存在的沟通问题，也一直在各个方面对需求设计产生负面的影响。譬如“客户想法至上”、“各个人意见总是不统一”、“开发者想法与客户要求不同”等等都是这一方面的常见问题，欠于沟通与理解错误往往导致设计到后期再重新推倒重来。最后，客户方对要求频繁反复的改动更是深深困扰着从业者们。客户的需求