第9章-面向对象需求分析

chapter_9*软件工程基础第九章面向对象方法学chapter_9chapter_9*本章要点传统方法学的局限性面向对象方法学概述面向对象建模统一建模语言UMLchapter_9chapter_9*软件工程追求的目标和要解决的主要问题软件危机反映出来的问题，主要包括：软件开发效率低、软件质量差、软件不可维护、软件项目成功率低等。chapter_9chapter_9*传统方法学的局限性结构化方法的核心是以用户的需求为基础，进行功能分解。分析阶段主要建立的模型：数据流图、数据字典、IPO、ER图、状态图设计阶段的主要建立的模型：软件模块结构图、IPO细化实现的主要结果是：源程序结构化程序设计方法主要特点是：自顶向下、逐步求精；先分解（功能分解并模块化）和再组装。chapter_9chapter_9*传统方法学的局限性－举例案例：设计并实现一个四则运算软件，输入两个数和运算符，输出运算结果。根据用户需求，设计三个功能：输入、计算、输出。设计一个录入界面，用于输入一个运算符和两个运算数；设计一个计算模块进行相应的计算；设计一个输出界面显示运算结果。chapter_9chapter_9*chapter_9chapter_9*chapter_9chapter_9*从例子看出？面向对象方法比结构化方法处理程序要复杂多了为什么还要推崇面向对象的方法呢？假设又增加一个求平方根的运算结构化方法：修改源程序，增加求平方根运算面向对象：源程序不变，增加一个求平方根运算的子类，对调用者来说没有任何影响。传统方法学的局限性chapter_9chapter_9*结论：结构化方法学存在的问题：软件重用性差软件可维护性差当问题比较简单的时候，结构化方法非常有效，简单易行；而当问题到一定的复杂程度时，面向对象的思想模式，更适合解决复杂问题；面向对象的方法提高软件开发效率和软件可维护性等问题，有利于解决软件危机chapter_9chapter_9*本章要点传统方法学的局限性面向对象方法学概述面向对象建模统一建模语言UMLchapter_9chapter_9*究竟什么是面向对象的方法?　　根据Coad和Yourdon的定义，按照以下4个概念设计和实现的系统，称为是面向对象的。面向对象方法=对象+类+继承+通信面向对象方法学概述chapter_9chapter_9*面向对象的软件工程面向对象分析（ObjectOrientedAnalysis，OOA）–分析和理解问题域，找出描述问题域和系统责任所需的类及对象，分析它们的内部构成和外部关系，建立OOA模型。面向对象设计（ObjectOrientedDesign，OOD）–将OOA模型直接变成OOD模型，并且补充与一些与实现有关的部分，如人机界面、数据存储等。面向对象编程（ObjectOrientedProgramming，OOP）–用一种面向对象的编程语言将OOD模型中的各个成分编写成程序，由于从OOA→OOD→OOP实现了无缝连接和平滑过渡，因此提高了开发工作的效率和质量。chapter_9chapter__10*面向对象需求分析概述不论采用哪种方法开发软件，分析的过程都是提取系统需求并建立分析模型的过程。面向对象分析的关键，识别出问题域内的对象，分析他们相互间的关系，建立起问题域的简洁、精确、可理解的正确模型。分析阶段主要建立的模型：功能模型(用例模型）：用例图和用例描述对象模型（类图是核心）动态模型（状态图、顺序图、活动图）chapter_9chapter__10*基于用例的面向对象分析过程面向对象分析过程并不是从考虑对象开始，而是从理解系统的使用方式开始。如果系统是人机交互的，则考虑被人使用的方式；如果系统是涉及过程控制的，则考虑被机器使用的方式；如果系统是协调和控制应用的，则考虑被其他程序使用的方式。chapter_9chapter__10*基于用例的面向对象分析过程一、建立功能模型（1）确立系统的使用者（2）确定用例（3）确定用例模型（4）用例模型说明chapter_9chapter__10*二、建立对象模型（1）识别分析类（2）描述类的职责（3）建立分析类的关系（4）描述每个类的属性基于用例的面向对象分析过程chapter_9chapter__10*三、建立动态模型根据用例图和类图，画顺序图四、评审分析模型基于用例的面向对象分析过程chapter_9chapter_9*本章要点传统方法学的局限性面向对象方法学概述面向对象建模统一建模语言UMLchapter_9chapter_9*用面向对象方法开发软件，通常需要建立三种形式的模型，它们分别是描述系统数据结构的对象模型，描述系统控制结构的动态模型描述系统功能的功能模型。面向对象建模chapter_9chapter_9*OO的三种基本模型功能模型：即用例模型对象模型：构建分析类，使用类图、对象图描述对象、对象属性、对象之间的关系，是系统静态模型。动态模型：利用活动图、状态图、时序图、等描述系统动态行为。每种模型描述的侧重点不同chapter_9chapter_9*本章要点传统方法学的局限性面向对象方法学概述面向对象建模统一建模语言UMLchapter_9chapter_9*UML中的5类图形UseCaseDiagramsUseCaseDiagrams用例图ScenarioDiagramsScenarioDiagrams协作图StateDiagramsStateDiagrams构件图ComponentDiagramsComponentDiagrams部署图StateDiagramsStateDiagrams包图ScenarioDiagramsScenarioDiagrams状态图UseCaseDiagramsUseCaseDiagrams时序图StateDiagramsStateDiagrams类图/对象图活动图模型库chapter_9chapter_9*用例图（UseCaseDiagram）用例图描述了系统的功能需求，从执行者的角度来理解系统，概要的反应系统提供的外部可见服务。用例图的元素有用例，执行者和连接。用例由执行者来激活，并提供确切的值给执行者，执行者是用户在系统中所扮演的角色。chapter_9chapter_9*用例图：执行者参与者（Actor）（角色）–参与者是与系统交互的外部实体。–参与者既可以是使用该系统的用户，也可以是与系统交互的其他外部系统、硬件设备或时间。时间图书催还，到书通知由时间触发chapter_9chapter_9*用例图：用例用例（UseCase）是指系统的参与者和系统交互所执行的动作序列。即参与者想要系统做的事情。在UML语言中，用例用一个椭圆来 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 示如图所示，并且在椭圆内或椭圆下方标明用例名称。用例可以促进与用户沟通，理解正确的需求，同时也可以用来划分系统与外部实体的界限。chapter_9chapter_9*用例图显示了主角、用例以及它们之间的关系。用例模型用例描述针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内容。chapter_9chapter_9*用例描述chapter_9chapter_9*图书信息删除功能用例描述举例执行者管理员前置条件管理员用户登录到管理员界面后置条件显示删除成功并返回管理员页面主成功场景（1）点击图书管理—>图书信息查询，显示信息查询界面。（2）点击图书信息列表右侧的“删除”按钮。（3）确定删除对话框选择“是”。（4）系统成功删除一条图书信息 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 。扩展1（3a）弹出确定删除对话框，选择“否”（3a1）不执行删除操作。chapter_9chapter_9*请完成系统登录用例描述，由首页—>登陆—>主页面执行者：前置条件：执行用例前系统必须要处于的状态；后置条件：执行用例后系统所处的状态。主成功场景：描述执行者和系统之间的交互过程（正常使用情况）扩展：描述执行者和系统之间的交互过程中异常情况的处理；用例描述练习chapter_9chapter_9*用例描述练习执行者个人用户前置条件进入系统首页后置条件显示登录成功并进入主页面主成功场景（1）用户访问系统首页（2）进入登陆页面（3）用户输入用户名和密码，然后单击“登录”按钮（4）系统验证用户名和密码（5）系统显示主界面扩展1（4a）用户名或密码为空（4a1）系统重新显示首页并在相应的输入域右侧提示错误信息“不能为空”（4a2）返回主成功场景步骤（3）扩展2（4b）用户名或密码错误（4b1）系统重新显示并提示错误信息“用户名/密码错误”（4b2）返回主成功场景步骤（3）chapter_9chapter_9*连接关系分为三种：用例与参与者之间的关系，参与者与参与者之间的关系，用例与用例之间的关系。（1）用例与参与者之间的关系，用实线表示。它实际上是UML关联记号，表明参与者和用例以某种方式通信。用例图：连接chapter_9chapter_9*（2）参与者与参与者之间的关系：由于参与者不是具体的人或物，而是类，所以参与者之间的关系就是类与类之间的关系，主要为一般参与者（超类）与特殊参与者（子类）之间泛化关系。用三角箭头表示，箭头从子类指向超类。出门者（超类）是出公差者（子类）和游客（子类）的泛化，如图所示：用例图：连接chapter_9chapter_9*（3）用例与用例之间的关系：用例图：连接chapter_9chapter_9*扩展关系是指一个用例被定义为基础用例的增量扩展，这样通过扩展关系，就可以把新的行为附加到已有用例中。在UML语言中，扩展关系用虚箭头加《extend》来表示，如图所示：还书可以扩展出交纳罚金用例。注意，箭头指向基础用例。用例图：连接chapter_9chapter_9*包含关系是指当存在若干用例共有的步骤序列，则可以将该序列抽取出来，形成一个子用例，以被基础用例调用。在UML语言中，包含关系用虚线箭头加《includ》表示，箭头所指向的是被包含的用例。如图所示：输入成绩和修改成绩时都要保存成绩。用例图：连接chapter_9chapter_9*chapter_9chapter_9*泛化关系是指一个用例也可以被特别细化为一个或多个子用例。任何子用例都可以用于其父用例能够应用的场合。在UML语言中，泛化关系用实线三角箭头表示，箭头从子用例指向父用例。如图所示：读者借书和借期刊可以泛化为借阅用例（父用例）。用例图：连接chapter_9chapter_9*设计用例图的步骤设计Use-case时，我们遵循下列步骤：第一步，识别出系统的“actor”并标识它们之间的关系。Actor可以是用户、外部系统。着重从系统外部执行者的角度来描述系统需要提供哪些功能，并指明这些功能的执行者(Actor)是谁。尽可能地确保所有Actor都被完全识别出来。第二步，描述主要的UseCase以及它们之间的关系。第三步，重新审视每个UseCase，为它们下个详尽的定义。chapter_9chapter_9*图书管理系统的用例建模在访谈中，我们得知：该系统只有一种使用者：图书馆工作人员，并且同一时刻只有一个工作人员使用该系统。图书馆工作人员，日常的业务主要有：图书管理，借阅管理和图书的借阅/归还。chapter_9chapter_9*参与者——图书馆工作人员用例——图书管理、借阅管理和图书的借阅/归还chapter_9chapter_9*从用户业务的视角出发，进行用例建模的。chapter_9chapter_9*课堂练习以图书借阅系统为例，画出用例图。（先确定角色，再确定每个角色的职责）读者：查询图书，预定图书，取消预定，缺书登记办公室人员：管理读者信息流通组人员：协助借书、还书和进行处罚。还可以查询图书信息和读者信息。请同学们画一下图书借阅系统的用例图chapter_9chapter_9*chapter_9chapter_9*课堂练习注意：还书用例可以被扩展。因为还书时，要看该书被人预定没有，若预定则到书通知，通知预定者前来借书。借书用例与取消用预定之间也存在扩展关系。当所借的图书为预定图书时，应取消预定记录。当所借的书全部借出时，可以转向“预定”用例。用户查询图书信息和流通组人员查询图书信息不同。chapter_9chapter_9*chapter_9chapter_9*总结你从用例图看出什么？参与者和用例分别描述了“谁来做？”和“做什么？”这两个问题。用例图：描述系统能做什么（功能），谁使用这些系统功能不能全部反应系统需求，要与用例说明、界面原型配合完成需求分析。chapter_9chapter_9*总结--用例之间的关系泛化：同一业务目的的不同技术实现，或指一个用例可以被特别细化为一个或多个子用例包含：提取公共交互，提高复用扩展：把新的行为附加到已有用例中chapter_9chapter_9*总结画用例图注意的问题：在初期不要考虑过多的细节。用例图是系统分析、设计和实现的基础图形。用例图只反应系统的总体功能，以及与这些功能相关的角色。一个用例内部的具体处理细节由其他图形工具描述。chapter_9chapter_9*常用的UML图用例图活动图类图顺序图状态图chapter_9chapter_9*用活动图描述系统中已知用例的业务过程还书的活动图活动图中的圆角矩形表示活动；箭头表示活动之间的迁移chapter_9chapter_9*活动图活动图（ActivityDiagram）：活动图也是一种动态图，它描述了系统从一种活动转换到另一种活动的整个过程。用于展示系统从一个活动流转到另一个活动的可能路径与判断条件。活动图的节点是活动，强调了系统中多个活动形成的控制流。chapter_9chapter_9*活动图活动图的目的和用途活动图是一种表述业务过程的技术,可以用来对业务过程建模，也可以对用例实现进行建模。活动图与流程图的最主要的区别在于，活动图能够标识活动的并行行为。chapter_9chapter_9*活动图订单处理活动图的组成元素？chapter_9chapter_9*活动图的组成元素：包括初始节点、终点、活动节点、转换、分支、分岔与汇合。活动图chapter_9chapter_9*活动图标识泳道的活动图为了有效地表示各个活动由谁负责，可以通过泳道(SwimLane)来实现。泳道借书记录chapter_9chapter_9*常用的UML图用例图活动图类图顺序图协作图状态图chapter_9chapter_9*　　类图(Classdiagram)是用类和类之间的关系描述系统，是从静态角度表示系统的，因此类图属于一种静态模型。　　　　定义系统中的类,表示类之间的联系如关联、依赖、聚合、继承等,也包括类的内部结构(类的属性和操作)。　　类图是构建其他图的基础，没有类图，就没有顺序图、协作图等其他图，也就无法表示系统的其他各个方面。类图(classdiagram)chapter_9chapter_9*chapter_9chapter_9*类的关系在面向对象的建模中，有5种最重要的关系是关联普通关联、限定关联聚集共享聚集（聚合）、组合聚集（组合）泛化依赖实现在图形上，把关系画成一条线，并用不同的线区别关系的种类。chapter_9chapter_9*一、关联关联是类之间的连结，分为：普通关联、限定关联、关联类等类。　类之间的关系—关联（1）普通关联　　关联中三角形的尖指向关联执行的方向。chapter_9重数（multiplicity）：表示该类有多少个对象与对方的一个对象连接。重数的表示方法通常有：0…1表示0到1个对象0…*或*表示0到多个对象1+或1…*表示1到多个对象1…15表示1到15个对象3表示3个对象如果图中未明确标出关联的重数，则默认重数是1。chapter_9（2）限定关联限定关联通常用在一对多或多对多的关联关系中，可以把模型中的重数从一对多变成一对一，或从多对多简化成多对一。在类图中把限定词放在关联关系末端的一个小方框内。例如，某操作系统中一个目录下有许多文件，一个文件仅属于一个目录，在一个目录内文件名确定了惟一一个文件。利用限定词把一对多关系简化成了一对一关系。chapter_9（3）关联类关联类：为了说明关联的性质增加的附加信息。关联中的每个连接与关联类的一个对象相联系。关联类可以通过一条虚线与关联连接。关联类与一般的类一样，也有属性、操作和关联。chapter_9chapter_9chapter_9*二、聚合聚合是一种特殊的关联，它指出类间的“整体-部分”关系。在UML中被表示为在整体的一端用一个空心菱形修饰的简单关联。类之间的关系—聚合chapter_9chapter_9*类之间的关系—组合(组合聚集)组合：组合是聚合的一种形式，它具有强的拥有关系，而且整体与部分的生命周期是一致的。部分与整体共存，整体不存在了部分也会随之消失（或失去存在价值了）在UML中，组合是一种特殊的关联，用整体端有实心菱形箭头的简单关联修饰它。chapter_9chapter_9*组合关系与聚合关系的区别：聚合关系表示整体与部分的关系比较弱，而组合关系比较强。举例：计算机与外设之间的关系聚合关系人和人的心脏的关系组合关系类之间的关系—组合与聚合chapter_9chapter_9*三、泛化（generalization）是一般事物（称为父类或超类）和较特殊事物（称为子类或孩子类）之间的关系。例如，你可能遇到一般类Client（用户类）和它的较特殊类Librarian(管理员类)。类之间的关系—泛化chapter_93.泛化泛化关系指出在类与类之间存在“一般-特殊”关系。抽象类：没有具体对象的类。常用作父类，用于描述其他类（子类）的公共属性和行为。抽象操作：抽象类通常都具有抽象操作，用来指定该类的所有子类应具有哪些行为。9.4.2表示关系的符号chapter_9图示抽象类：类名下方附加标记值{abstract}。折角矩形：说明子类操作drive的功能。图示抽象操作：与抽象类相似，在操作标记后面跟随一个性质串{abstract}。具体类：有自己的对象，并且该类的操作都有具体的实现方法。chapter_9图9.13复杂类图示例综合应用了许多概念和图示符号chapter_9chapter_9*四、依赖（dependency）描述两个类之间的语义连接关系：其中一个类是独立的，另一个类不是独立的，如果独立的类改变了，将影响依赖于它的类。用带箭头的虚线连接有依赖关系的两个类，箭头指向独立的类。比如：人和空气人空气类之间的关系--依赖chapter_9细化关系(一种依赖)假设两个模型元素A和B描述同一个事物，但抽象层次不同，B是在A的基础上的更详细的描述，则称B细化了A，或称A细化成了B。不同阶段模型之间存在依赖关系。设计类分析类chapter_9chapter_9*五、实现（realization）实现是类之间的语义关系，关系中的一个类描述了另一个类（接口）实现的契约。也就是说，一个类只具有行为的定义，而具体的结构和行为描述由另一个类来给出。例如类之间的关系—实现chapter_9chapter_9*UML图：类图Uml扩展出三种不同的类：实体类、控制类和边界类。实体类：业务级别的类。控制类：与业务过程有关，控制整个用例业务的流程和执行次序。边界类：在系统与外界之间，用于交换信息。控制类和边界类是面向技术的类，应属于设计阶段。chapter_9chapter_9*类的种类：界面类、控制类、实体类chapter_9登录实例http://blog.csdn.net/javaeeteacherchapter_9功能演示http://blog.csdn.net/javaeeteacherchapter_9类及调用关系http://blog.csdn.net/javaeeteacherchapter_9chapter_9*常用的UML图用例图类图顺序图活动图状态图chapter_9chapter_9*状态图状态图描述对象在整个生命周期内，在外部事件的作用下，从一种状态转换到另一种状态的关系图。这种图的节点是状态(包括初始状态和终止状态)，关系是转换。状态图适合于描述跨越多个用例的单个对象的行为。chapter_9chapter_9*状态图状态图与活动图的不同之处：（1）描述的重点不同。活动图描述的是从活动到活动的控制流；状态图描述的是对象的状态及状态之间的转移。（2）使用场合不同。在分析用例、理解业务流程时，一般使用活动图；在描述一个对象在其生命期内的状态变化，使用状态图。chapter_9chapter_9*根据“登录”用例描述，画出状态图退出chapter_9chapter__10*UML建模实例-----图书管理系统1.用户主要业务：图书管理，图书借阅\归还，借阅管理。其中，图书管理包括图书的入库和报废以及遗失；借阅管理包括学生借阅证的办理和补办。2.图书信息包括：图书登录号，书名，ISBN，图书类别，作者，出版社，出版日期，总页数，定价，图书分类3.学生信息包括：姓名，学号，班级，专业，性别4.借阅信息包括：借阅时间，归还时间5.系统只有一个角色使用：图书馆工作人员chapter_9chapter__10*可以加上必要的注释chapter_9chapter__10*chapter_9chapter__10*chapter_9chapter__10*任务2：用例建模-2—活动图为每个用例建立业务流程1.借书流程图书管理员得到学生出示的借书证图书管理员得到学生递给他的索书号进行借书信息登记chapter_9chapter__10*2.还书流程得到图书信息查阅借书信息表登记归还根据还书流程，画出还书的活动图chapter_9chapter__10*借阅管理chapter_9chapter__10*办理借阅证chapter_9chapter__10*借阅证遗失补办chapter_9chapter__10*图书管理chapter_9chapter__10*同样的，图书管理中的三个动作状态也需要进一步细化。图书报废处理图书入库图书遗失处理chapter_9chapter__10*何时使用活动图为每个用例画活动图，可能会导致分析停滞。建议：要保守地使用它。何时用？1、用例比较复杂2、需要分析用例包括哪些动作，以便扩展。3、并发步骤建模chapter_9chapter__10*任务3：用例建模-3：用例描述用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这时就需要写用例描述。对于用例描述的内容，没有硬性规定的格式，一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、后置（事后）条件等等。chapter_9chapter__10*图书管理系统的用例描述——新办借阅证用例名称：新办借阅证用例描述：图书馆工作人员输入学生信息进行借阅证办理。参与者：图书馆工作人员。前置条件：图书馆工作人员点击“新办借阅证”基本路径：输入学生信息（学号，姓名，专业，班级，性别）点击“提交”后置条件：显示添加的借阅证信息（借阅证编号，学号，姓名，专业，班级，性别）备选流程：点击“重新填写”，实现重填学生信息功能。chapter_9chapter__10*图书管理系统的用例描述——补办借阅证用例名称：补办借阅证用例描述：图书馆工作人员输入学生信息进行借阅证补办。参与者：图书馆工作人员。前置条件：图书馆工作人员点击“补办借阅证”基本路径：输入学号点击“查询”显示该学生遗失的借阅证信息（借阅证编号，学号，姓名，专业，班级，性别）点击“补办”后置条件：显示该学生新借阅证信息（借阅证编号，学号，姓名，专业，班级，性别）备选流程：A：1点击“重新填写”，实现重填学号。B：如果学生有借阅图书未归还，显示当前该学生借阅情况（书名,ISBN，借阅时间，应归还时间）chapter_9chapter__10*现在，请完成下列用例描述图书借阅chapter_9chapter__10*图书管理系统的用例描述——图书借阅用例名称：图书借阅用例描述：图书馆工作人员输入借阅证编号和图书登录号来完成图书借阅。参与者：图书馆工作人员。前置条件：图书馆工作人员点击“图书借阅”基本路径：输入借阅证编号。输入图书登录号。点击“借阅”后置条件：显示当前借阅信息（书名,ISBN，借阅时间，应归还时间）备选流程：点击“重填”实现借阅证和图书登录号重新填写chapter_9chapter__10*图书管理系统的用例描述——图书归还用例名称：图书归还用例描述：图书馆工作人员输入图书登录号进行图书归还。参与者：图书馆工作人员。前置条件：图书馆工作人员点击“图书归还”基本路径：输入图书登录号点击“查询”显示该书借阅证信息（书名,ISBN，借阅时间，应归还时间）点击“归还”后置条件：提示“归还成功”备选流程：点击重新填写，实现图书登录号重新填写chapter_9chapter__10*任务4：根据需求信息，进行领域分析，交付——图书管理系统领域类图所谓业务领域类图要描述一下三点：     1.系统中有哪些实体。     2.这些实体能做什么操作。     3.实体间的关系。chapter_9chapter__10*寻找类的方法语法分析是最简单寻找类的方法：找出用户描述中的名次或形容词+名词，这些词中有些是类，有些是类的属性。候选词是系统用户吗？是，则可作为一个领域分析类。这个候选词可以拥有或提供某些业务服务或功能吗？候选词拥有或管理数据结构吗？候选词和其它候选词之间有关系吗？如果回答不是，则这个候选词很可能不是分析类。chapter_9chapter__10*图书管理系统的数据建模——步骤1：对系统中关键词的抽象我们从与用户的访谈中间可以发现一些关键词汇：学生信息，图书信息，以及借阅信息。因此，可以在系统中抽象出3个类：学生，图书，借阅信息。chapter_9chapter__10*图书管理系统的数据建模——步骤2：为类添加属性学生信息表包含：姓名，学号，班级，专业，性别图书信息表包含：图书登录号，书名，ISBN，图书类别，作者，出版社，出版日期，总页数，定价，图书分类借阅信息表包含：借阅时间,归还时间。chapter_9chapter__10*chapter_9chapter__10*图书管理系统的数据建模——步骤3：分析和建立类之间的关系学生——借阅信息1：n图书——借阅信息1：nchapter_9chapter__10*chapter_9chapter__10*完成需求分析说明书chapter_9chapter__10*获取非功能需求可以用一个调查表的形式来获取非功能需求。调查表内容如下：非功能需求调查表可靠性安全性系统数据的敏感程度如何　系统运行于何种环境　客户组织中的信息保密程度　使用人员情况　事务性系统业务交叉程度如何　数据精确度要求如何　业务是在线的还是离线的　系统集成情况如何　是分布式系统还是集中式系统　稳定性系统的服务能力要求如何　用户的操作频率如何　业务的及时性要求如何　数据的重要程度如何　chapter_9chapter__10*获取非功能需求非功能需求调查表可用性　界面客户的行业性质如何　客户的企业文化如何　客户业务的复杂程度如何　使用人员的情况如何　操作习惯　客户之前使用过什么系统吗？　客户喜欢什么样的操作风格　文档要求　客户需要联机文档吗？　客户需求在线帮助吗？　客户的计算机操作水平如何？　chapter_9chapter__10*获取非功能需求非功能需求调查表有效性性能系统的平均访问量　系统的峰值访问量　系统的数据流量　系统的并发要求　硬件环境如何　可伸缩性客户业务预期的扩张速度　客户数据量的扩张速度　使用人数的扩张速度　可扩展性系统规模会持续扩大吗？　客户是否有长期系统建设计划？　客户有升级系统的长期计划吗？　chapter_9chapter__10*非功能需求调查表可移植性硬件环境客户当前的硬件环境如何　客户是否有长期的硬件厂商合作伙伴　客户的业务是否在快速增长　软件环境客户和系统运行环境如何　客户是否有长期的软件提供商　开发者自己是否有长期明确的技术路线　chapter_9chapter__10*与用户确定最后交付的内容在需求分析中，我们还需要与用户就最终交付的软件产品内容，以及产品交付形式达成一致。软件产品不仅是可以运行的程序，还包括在整个软件开发过程中产生的一系列文档以及必要的用户使用说明书。软件产品的交付可以采用光盘形式（CD，DVD），光盘介质存储比磁盘介质存储时间更持久一些。chapter_9chapter_9*作业P230：10chapter_9