需求分析建模方法

‘壹’ 需求建模是什么阶段采用的主要手段

需求建模是设计需求阶段采用的主要手段。

建立完善的数据库结构管理设备的基本参数、运行状态和各种工作计划。数据库的框架和结构必须根据设备和运行状态而设计，方便提供强大的录入、查询、统计、分析和报表等各种功能操作，较好的反映平台业务的基本情况和运行状况，满足平台的基本要求。

建模过程

建立DFD图的目的是描述系统的功能需求。DFD方法利用应用问题域中数据及信息的提供者与使用者、信息的流向、处理、存储四种元素描述系统需求，建立应用系统的功能模型。

首先要明确目标系统的功能需求，并将用户对目标系统的功能需求完整、准确、一致地描述出来，然后确定模型要描述的问题域。虽然在建模过程中这些内容是逐步细化的，但必须自始自终保持一致、清晰和准确。

‘贰’ 需求分析的建模分析方法有哪两种

数据库设计需求
1. 需求概述
建立完善的数据库结构管理设备的基本参数、运行状态和各种工作计划。

数据库的框架和结构必须根据设备和运行状态而设计，方便提供强大的录入、查询、统计、分析和报表等各种功能操作，较好的反映平台业务的基本情况和运行状况，满足平台的基本要求。

2. 外部设计需求
2.1 标识符和状态

数据库表前缀：根据模块名定义（如用户模块：sys_）

用户名：root

密码：待定

权限：全部

有效时间：开发阶段

说明：系统正式发布后，可能更改数据库用户/密码。

2.2 使用它的程序

本系统主要利用java作为后端的应用开发工具，使用MySQL作为后台的数据库， Linux或Windows均可作为系统平台。

2.3 约定

所有命名一定要具有描述性，杜绝一切拼音、或拼音英文混杂的命名方式。
字符集采用 UTF-8，请注意字符的转换。
所有数据表第一个字段都是系统内部使用主键列，自增字段，不可空，名称为：id，确保不把此字段暴露给最终用户。
除特别说明外，所有日期格式都采用date格式。
除特别说明外，所有字段默认都设置不充许为空， 需要设置默认值。
所有普通缩影的命名都是表名加设置缩影的字段名组合，例如用户表User中name字段设置普通所以，则缩影名称命名方式为user_name_index。
2.4 专门指导

对本系统的开发者、使用这、测试员和维护人员，提出以下参考意见：

在使用数据库时，首先要参考上面的约定内容，做好软件的安装以及表格的建立。
数据库的输入统一采用键盘。对于数据库的使用权限，请参考本系统其他相关文档。
数据库的后台管理员没用等级差异，可根据实际情况添加删除管理员。
2.5 支持软件

操作系统： Linux / Windows

数据库系统：MySQL

查询浏览工具：Navicat Premium

命令行工具：mysql

注意：mysql 命令行环境下对中文支持不好，可能无法书写带有中文的 SQL 语句。

3. 结构设计需求
3.1 概念结构设计需求

概念数据库的设计是进行具体数据库设计的第一步，概念数据库设计的好坏直接影响到逻辑数据库的设计，影响到整个数据库的好坏。

我们已经得到了系统的数据流程图和数据字典，现在就是要结合数据规范化的理论，用一种模型将用户的数据要求明确地表示出来。

概念数据库的设计应该极易于转换为逻辑数据库模式，又容易被用户所理解。概念数据库设计中最主要的就是采用“实体-关系数据”模型来确定数据库的结构。

数据是表达信息的一种重要的量化符号，是信息存在的一种重要形式。数据模型则是数据特征的一种抽象。它描述的是数据的共性，而不是描述个别的数据。一般来说，数据模型包含两方面内容：

数据的静态特性：主要包括数据的基本结构、数据间的关系和数据之间的相互约束等特性。
数据的动态特性：主要包括对数据进行操作的方法。
在数据库系统设计中，建立反映客观信息的数据模型，是设计中最为重要的，也最基本的步骤之一。

数据模型是连接客观信息世界和数据库系统数据逻辑组织的桥梁，也是数据库设计人员与用户之间进行交流的共同基础。概念数据库中采用的实体-关系模型，与传统的数据模型有所不同。“实体-关系”模型是面向现实世界，而不是面向实现方法的，它主要是用使用方便，因而在数据库系统应用的设计中，得到了广泛应用。“实体-关系”模型可以用来说明数据库中实体的等级和属性。

以下是实体-关系模型中的重要标识：

在数据库中存在的实体；
实体的属性；
实体之间的关系；
3.2 逻辑结构设计需求
物理结构设计需求

1）定义数据库、表及字段的命名规范：

数据库、表及字段的命名要遵守可读性原则。
数据库、表及字段的命名要遵守表意性原则。
数据库、表及字段的命名要遵守长名原则。
2）选择合适的存储引擎：
3）为表中的字段选择合适的数据类型。

4）建立数据库结构

4. 运用设计需求
4.1 表名的命名规范

表名以英文单词、单词缩写、简写、下划线构成，总长度要求小于30位。

4.2 表字段的命名规范

字段名以英文单词、单词缩写、简写、下划线构成，总长度要求不超过30位。
字段名以名词或名词短语，字段采用单数形式。若表名由多个单词组成，则取各个单词的缩写组成，单词缩写间使用下划线作为分隔。
若某个字段是引用某个表的外键，则字段名应尽量与源表的字段名保持一致，一面混淆。
5. 安全保密设计需求
5.1 防止用户直接操作数据库的方法

通过把关键应用服务器和数据库服务器进行分离，防止用户对数据库服务器的直接操作，保证数据库安全。

5.2 应用系统的用户口令进行加密

在软件系统中，对于数据的保护、业务操作的许可是通过识别用户身份和权限来完成的。用户口令相比较，相同的话系统将该用户的操作权限分配给用户，用户再根据所分配的权限对系统进行操作。

由以上过程可知，用户口令在传输过程中容易被窃取泄漏，另外如果数据库被非法进入则其中保存的口令能够被非法查看。因此，在传输过程中和数据库中的口令记录字段不应使用明文传递和保存，应该在口令被传递前对其明文口令使用有效的主流技术，对传输数据进行加密部分描述的加密算法进行加密，在加密后传输到系统。系统将用户提交的经过加密的口令数据保存的加密口令进行比较，相一致则进行后续操作。

‘叁’ 如何进行软件需求的建模

软件需求建模的方法目前比较流行一般有三种：面向对象、结构化、面向问题域。传统上一般采用结构化的方法，也就是面向过程、面向数据的方法，可以采用数据流图、与ER图的建模方法对流程和数据分别建模。而现在大家也在使用面向对象的需求分析方法，也就是采用USE CASE的方式描述需求，采用对象关系图描述数据。比较新的方法是面向问题域的方法。

‘肆’ 需求分析的主要方法是

目前，软件需求的分析与设计方法较多，一些大同小异，而有的则基本思路相差很大。从开发过程及特点出发，软件开发一般采用软件生存周期的开发方法，有时采用开发原型以帮助了解用户需求。在软件分析与设计时，自上而下由全局出发全面规划分析，然后逐步设计实现。
从系统分析出发，可将需求分析方法大致分为功能分解方法、结构化分析方法、信息建模法和面向对象的分析方法。
(1)功能分解方法。
将新系统作为多功能模块的组合。各功能义可分解为若干子功能及接口，子功能再继续分解。便可得到系统的雏形，即功能分解——功能、子功能、功能接口。
(2)结构化分析方法。
结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。此分析法又称为数据流法。其基本策略是跟踪数据流，即研究问题域中数据流动方式及在各个环节上所进行的处理，从而发现数据流和加工。结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。
(3)信息建模方法。
它从数据角度对现实世界建立模型。大型软件较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是E—R图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。
信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。
(4)面向对象的分析方法。
面向对象的分析方法的关键是识别问题域内的对象，分析它们之间的关系，并建立三类模型，即对象模型、动态模型和功能模型。面向对象主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象的分析中几项最重要特征。类的对象是对问题域中事物的完整映射，包括事物的数据特征(即属性)和行为特征(即服务)

‘伍’ 需求分析时应该建立哪些模型，如何建立

需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档 (System Requirement Specification); 2.DRM 文档；3.Acceptance Plan.

从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

狭义上理解：需求分析指需求的分析、定义过程。

一、为什么要需求分析

需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.

需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计.

二、需求分析的任务

简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.

三、需求分析的过程

需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.

问题识别
就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.

分析与综合
逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).

制订规格说明书
即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.

评审
对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。

四、需求分析的方法

需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.

原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.

原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.

原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。

在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。

追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.

五、需求分析的20条法则

客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。

1、 分析人员要使用符合客户语言习惯的表达
需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。

2、分析人员要了解客户的业务及目标
只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。

3、 分析人员必须编写软件需求报告
分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

4、 要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

5、 开发人员要尊重客户的意见
如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

6、 开发人员要对需求及产品实施提出建议和解决方案
通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

7、 描述产品使用特性
客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要 “界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

8、 允许重用已有的软件组件
需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。

9、 要求对变更的代价提供真实可靠的评估
有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。

10、 获得满足客户功能和质量要求的系统
每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。

11、 给分析人员讲解您的业务
分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。

12、 抽出时间清楚地说明并完善需求
客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。

13、 准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。

在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。

14、 及时作出决定
分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。

15、 尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。

16、 划分需求的优先级
绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。 在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。

17、 评审需求文档和原型
客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。

18、 需求变更要立即联系
不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。

19、 遵照开发小组处理需求变更的过程
为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。

20、 尊重开发人员采用的需求分析过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。

“需求确认”意味着什么

在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”

这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”

同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”

这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。

对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。 需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。

六、点评需求分析误区

要想说什么是好的需求分析，不如说什么是不好的需求分析，知道什么是不好的，自然也就知道了什么是好的。以下就是一些不好的情况：

（1）创意和求实
毋庸质疑的，每个人都会为自己的一个新的Idea而激动万分，特别是当这个Idea受到一些根本不知道你原本要干嘛的人的惊赞时。但是请注意，当你激动得意的时候，你可能已经忘了你原本是在描述一个需求，而不是在策划一个创意、创造一个概念。很多刚开始做需求分析的人员都或多或少的会犯这样的错误，陶醉在自己的新想法和新思路中，却违背了需求的原始客观性和真实性原则。

永远别忘了：需求不是空中楼阁，是实实在在的一砖一瓦。

（2）解剖的快感
几乎所有搞软件的人，做需求分析的时候，一上来就会把用户告诉你的要求，完完整整的作个解剖，切开分成几个块，再细分成几个子块，然后再条分缕析。可是当用户迷惑的看着你辛辛苦苦做出来的分析结果问你：我想作一个数据备份的任务，怎么做？这时，你会发现，需要先后打开三个窗口才能完成这个任务。

永远别忘了：分解是必需的，但最终的目的是为了更好的组合，而不是为了分解。

（3）角度和思维
经常听到这样的抱怨：“用户怎么可以提出这样苛刻的要求呢？”。细细一了解，你会发现，用户只不过是要求把一个需要两次点击的功能，改成只有一次点击。这样会导致需要改变需求、改变编码、甚至重新测试，增加工作量。可是，如果换个角度来想想，这个功能，开发的时候只用了几次、几十次，可是用户每天都要用几百次甚 至几千次几万次，改动一下就减少了一半的工作量，对他来说，这样的需求难道会苛刻吗？

永远别忘了：没有任何需求是不对的，不对的只是你的需求分析。试着站在用户的思维角度想想，你的需求分析就会更加的贴近用户，更加的合理。软件应该是以人为本的。

（4）程序员逻辑
从程序员成长为系统分析员是一个普遍的轨迹，但并不是一个好的程序员就必然能成为一个好的系统分析员。一些程序员的固化逻辑，使得他们在做需求分析的时候往往钻进了一些牛角里面。比如说1／0逻辑（或者是说黑白逻辑），认为不是这样就是那样，没有第三种情况。可实际情况往往是，在一定的时候是这样，其它时候是那样。又比如穷举逻辑，喜欢上来就把所有一二三可能的情况列举出来，然后一个一个分别处理，每个占用三分之一的时间；可是实际的情况往往是，三分之一的情况占了99％的比例，其它两种情况一年都不会遇到一次。实际中还有很多这样的例子，不一一列举了。

永远别忘了：需求分析和程序设计不尽相同，合理、可行是才是重要的。跳出程序设计的圈子，站在系统的角度上来看问题，你的结论会截然不同。

‘陆’ 需求分析怎么做

10月22日 10:37 尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。Gause 和Weinberg（1989）提出使用“上下文无关问题”—这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？”这些回答可以更直接地认识问题，而这是封闭（close-end）问题所不能做到的。

需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理的特性。一个研究表明：比起不成功的项目，一个成功的项目在开发者和客户之间采用了更多的交流方式（Kiel and Carmel 1995）。与单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统（MIS）的应用来说是一种传统的需求来源。直接聘请用户进行获取需求的过程是为项目获得支持和买入（buy-in）的一种方式。

尽量理解用户用于表述他们需求的思维过程。充分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。

在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获取过程将会拖延。如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外的需求。当前的范围太小，以致不能提供一个令人满意的产品。需求的获取将导致修改项目的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。

正如经常所说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。这样说虽然很简洁，但似乎过于简单化。需求的获取应该把重点放在“做什么”上，但在分析和设计之间还是存在一定的距离。你可以使用假设“怎么做”来分类并改善你对用户需求的理解。在需求的获取过程中，分析模型、屏幕图形和原型可以使概念表达得更加清楚，然后提供一个寻找错误和遗漏的办法。把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。

需求获取讨论会中如果参与者过多，就会减慢进度。人数大致控制在5到7人是最好的。这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。相反地，从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。这将导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。最好的权衡在于选择一些授权为他们的用户类发言的产品代表者，他们也被同组用户类的其它代表所支持。

没有一个简单、清楚的信号暗示你什么时候已完成需求获取。当客户和开发者与他们的同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时，他们都将对潜在产品产生新的构思。你不可能全面收集需求，但是下列的提示将会暗示你在需求获取的过程中的返回点。

1. 如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。用户总是按其重要性的顺序来确定使用实例的。

2. 如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些新的使用实例，这时也许你就完成了收集需求的工作。这些新的使用实例可能是你已获取的其它使用实例的可选过程。

3. 如果用户开始重复原先讨论过的问题，此时，也许你就完成了收集需求的工作。

4. 如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求的工作。

5. 如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收集需求的工作。

以上知识大致上讨论需求分析应该如何做，实际上对于需求分析的方法有很多很多，已经形成了一定的理论，当然这种理论比较偏向与方法学，而方法学的应用主要还是要靠个人。所以，大家在实际应用的时候，不妨结合自己的实际，有选择性的采用一些方法，那你就是成功的。
用例在需求分析中的使用

多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求（McGraw and Harbison 1997）。Ivar Jacobson（1992）把这种看法系统地阐述成用例（用例）的方法进行需求获取和建模。虽然用例来源于面向对象的开发环境，但是它也能应用在具有许多开发方法的项目中，因为用户并不关心你是怎样开发你的软件。而最重要的，用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。

用例的重要功能是用画用例图的功能来鉴别和划分系统功能。它把系统分成角色（actor）和用例（用例）。角色(actor)表示系统用户能扮演的角色（role）。这些用户可能是人，可能是其他的计算机一些硬件或者甚至是其它软件系统，唯一的标准是它们必须要在被划分进用例的系统部分以外。它们必须能刺激系统部分并接收返回。用例描述了当角色给系统特定的刺激时系统的活动。这些活动被文本描述。它描述了触发用例的刺激的本质，输入和输出到其他活动者，和转换输入到输出的活动。用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施。

这样说可能会非常复杂，其实一个用例描述了系统和一个角色（actor）的交互顺序。用例被定义成系统执行的一系列动作，动作执行的结果能被指定角色察觉到。用例可以:

· 用例捕获某些用户可见的需求，实现一个具体的用户目标。

· 用例由角色激活，并提供确切的值给角色。

· 用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。在UML中，用例表示为一个椭圆。

角色是指用户在系统中所扮演的角色。其图形化的表示是一个小人。在某些组织中很可能有许多角色实例（例如有很多个销售员），但就该系统而言，他们均起着同一种作用，扮演着相同的角色，所以用一个角色表示。一个用户也可以扮演多种角色。例如，一个高级营销人员既可以是贸易经理，也可以是普通的营销人员；一个营销人员也可以是售货员。在处理角色时，应考虑其作用，而不是人或工作名称，这一点是很重要的。

我们使用不带箭头的线段将角色与用例连接到一起，表示两者之间交换信息，称之为通信联系。角色触发用例，并与用例进行信息交换。单个角色可与多个用例联系；反过来，一个用例可与多个角色联系。对同一个用例而言，不同角色有着不同的作用：他们可以从用例中取值，也可以参与到用例中。需要注意的是角色在用例图中是用类似人的图形来表示，尽管执行的，但角色未必是人。例如，角色也可以是一个外界系统，该外界系统可能需要从当前系统中获取信息，与当前系统有进行交互。

一个用例可能包括完成某项任务的许多逻辑相关任务和交互顺序。因此，一个用例是相关的用法说明的集合，并且一个说明（scenario）是用例的实例。这种关系就像是类和对象的关系。在用例中，一个说明被视为事件的普通过程(normal course)，也叫作主过程，基本过程，普通流，或“满意之路” (happy path)。在描述普通过程时列出执行者和系统之间相互交互或对话的顺序。当这种交互结束时，执行者也达到了预期的目的。

在用例中的其它说明可以描述为可选过程(alternative coruse)。可选过程也可促进成功地完成任务，但它们代表了任务的细节或用于完成任务的途径的变化部分。在交互序列中，普通过程可以在一些决策点上分解成可选过程，然后再重新汇成一个普通过程。

角色类和角色实例

软件产品最终是给一些用户来使用的，而用户之间的差异是非常大的。造成差异的原因包括了对计算机的认知程度的不同，使用习惯的不同，在软件目标组织中所处的地位不同，地理位置不同，业务熟练程度不同。

不同的用户都有自己一系列的功能需求和非功能需求。对电脑熟练程度不同的人可能就会有不同的要求，熟练程度低的用户可能希望有一个友好的界面，熟练程度高的用户可能更希望有快捷键或宏的操作以提高工作效率。考虑到用户的差异性，将用户分类并研究用户类的行为特征是非常有必要的。所以在做具体的需求之前，先将用户分局行为和特点进行分类，对于研究、收集用户的需求是非常有帮助的。

可以利用一个简单的表格列出一些原始的分类，然后不断的完善这个表格。确认你的分类之间没有交集。并充分描述用户分类的行为，目的，要求等。在企业分析中，比较常见的分类可能包括，供应商，客户，部门等。

就像C++中的类和对象一样，我们把分析出的用户分类称为“角色类”，把实际的用户称为“角色实例”。在得到用户分类之后，最重要的就是要选出用户代表，用户代表不仅仅是在需求阶段中参与项目，还必须对项目的全过程负责。用户代表能够代表用户分类的需求。抓住用户代表的需求就大致把握住了用户类的需求。当然，需求分析还是需要在用户中做大规模的调查的，只是要把重点放在用户代表上。

确保和用户直接进行沟通！大家有没有玩过传话的游戏，可能看过。一群人排成一列，一句话从排头挨个向后传，到最后，那句话已经是面目全非了。所以，一定要保证项目组能够直接和用户接触。

对于和用户直接沟通这一点，一般的针对特定企业的应用系统当然是不成问题，可是如果是开发行业软件，和用户直接沟通就成为一件几乎是不可能的事情。在这种情况下，一般有几种解决的办法：

做大规模的市场调查，针对你的目标市场做市场调查，并根据统计学的理论建立你的数学模型。这部分的工作效果最好，其性质有些象一些游戏公司会发布一些Demo版的游戏。可是对于一般的企业来说，这项工作费时费力，高昂的成本往往使大家知难而退。我的意见是，方法是非常好的，但是可以采用折衷的办法，例如选取有代表性的企业，为特定企业制作一个较小的版本并收集反馈意见等。这涉及到很多市场营销的内容，并不是我的专业所长，这里就不多弄斧了。
聘请行业专家，一个行业专家往往可以在项目需求方面发挥极为重要的作用。一个行业专家往往都有大量的行业经验和行业的人际关系网络。在产品的设计方面，这个行业专家提供很多宝贵的意见。在目前很多的软件的开发过程中都采用了这种方式。行业专家有两种：一种是在这个行业中有很深的资历，但是对软件技术并不熟悉；第二种是开发过同类软件的软件专家，这种人在开发同类软件过程中已经积累了大量的项目经验，并且具有软件开发的知识。这种方式是获取需求的最好的方式。 分析对比同类软件，微软在开发Office、Visual Studio的时候，也是参照了Lotus和Borland的成熟产品。这种方式的特点在于成本很低，比较适合和其他的方式配合使用。但是，要注意自己有没有触犯专利法。

需求的冲突

有的时候，虽然已经将用户分类并选出了用户代表。但是需求的来源众多，往往会发生需求之间自相矛盾的事情。需求从四面八方收集来后，人们难以解决冲突，澄清模糊之处以及协调不一致之处。某些人还要对不可避免要发生的范围问题单独作出决定。在项目的早期阶段，你必须决定谁是需求问题的决策者。如果不清楚谁有权并且有责任来作出决策，或者授权的个人不愿意或不能作出决策，那么决策者的角色将自然而然地落在开发者身上。这是一个非常糟糕的选择，因为开发者通常没有足够多的信息和观点来作出业务上的决策。

在软件项目中，谁将对需求作出决策的问题并没有统一的正确答案。分析员有时听从呼声高的或来自最高层人物的最大的需求。即便使用用户代表这一手段，必须解决来自不同用户类的相冲突的需求。通常，应尽可能由处于公司底层的人作出决策，因为他们与问题密切相关，并能得到关于这些问题的广泛信息。

如果不同的用户类有不一致的需求，那么必须决策出满足哪一类用户的需求更为重要。了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关系如何，将有助于你决定哪一个用户类所占份额最大。

当开发者想象中的产品与客户需求冲突时，通常应该由客户作出决策。然而，不要陷到“客户总是对的”的陷阱中去，对他们百依百顺。现实中，客户并不总是对的。客户总是持有自己的观点，开发者必须理解并尊重这一观点。

用例

在具体的需求过程中，有大的用例（业务用例），也有小的用例。主要是由于用例的范围决定的。用例像是一个黑盒，它没有包括任何和实现有关或是内部的一些信息。它很容易就被用户（也包括开发者）所理解（简单的谓词短语）。如果用例不足以表达足够的信息来支持系统的开发，就有必要把用例黑盒打开，审视其内部的结构，找出黑盒内部的Actor和用例。就这样通过不断的打开黑盒，分析黑盒，再打开新的黑盒。直到整个系统可以被清晰的了解为止。

为什么要采用这种分析方法呢？计算机系统除了在与外界系统、人员有一系列的交互，在系统内部也往往存在着复杂的交互。因此，在系统建模时，除了描述系统与外界的交互，同时还要描述系统内部的交互。传统的MIS系统中，系统与外界的交互较多。典型的，如ATM取款机：存在着大量的用户与ATM，ATM与其它系统的交互。而电信领域的系统，与外界的交互较少。例如，系统的输入可能仅仅是从交换机上采集信息，然后由系统进行处理。系统的复杂逻辑包含在系统内部处理的流程上，而非与外部系统的交互。建模主要任务是表达系统内部的交互。

用例图适于表达交互，之所以上面使用了电信系统，是因为用例最早来自于Ericsson的交换机系统。当时，还是Ericsson雇员的Jacobson初步建立了用例图的概念，并于1994年提出了OOSE方法，其最大特点是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器，比较适合支持商业工程和需求分析。随着用例的发展，用例被大量的用于对功能进行描述。每个用例代表了系统与外部ACTOR的交互。可以采取顺序图来表达用例的具体操作程序。ACTOR用于确定系统的边界。

ACTOR、用例可以从不同的层次来描述信息。采用该原则的原因有：

1. 需求并不是在项目一开始就很明确，往往是随着项目的推进，逐渐细化。

2. 人的认知往往具有层次的特性。从粗到细、从一般到特殊。采用不同的层次来描述，适于认知的过程。

使用用例开发系统的一般过程

在开发过程的初始阶段，可以根据具体的项目特点，制订开发各个视图之间的关联原则，指导规范。在开发的过程中，视图的组织原则应不断进行维护、更新。

识别ACTOR来识别系统与外界交互的实体。ACTOR具有特定领域的特征，例如：交换机（采集系统）、97信息系统等。在系统层次的ACTOR确定了系统的边界。

识别用例。同ACTOR一样，用例具有不同层次。对较为概括的USECASE，需要细化。注：系统开发需要一定的规则来确定，如何来分解用例；可能基于原有系统的经验，或是参考现有资料。

当用例细化到可以被理解的层次。需要基于用例进行下一步的开发。如前面提到的，用例主要用来描述交互。因此，存在交互的实体和交互的细节。交互的实体采用类图来描述；而交互的细节，采用顺序图来描述。

当系统复杂到一定层次时，类图和顺序图可能不能足以描述其复杂程度。在该情况下，需要使用状态图来辅助阐述。状态图和顺序图之间使用事件联结在一起。它们之间的一致性问题，目前UML和ROSE没有提供解决方案。相对折衷的方法是使用事件的命名规范强制一致性。

可以说，之前说的所有的东西都是为了能够导出用例在需求中的作用。用例是从用户的角度看待系统，而不是基于程序员的角度。这样的话，用例驱动的系统能够真正做到以用户为中心，用户的任何需求都能够在系统开发链中完整的体现。用户和程序员间通过用例沟通，避免了牛头马嘴的尴尬局面。 从前，系统开发者总是通过情节来获取需求，是问用户希望系统为他做什么。在Jacobson发明了用例的概念之后，需求获取就变成问用户要利用系统做什么。这是立场不同导致的结果。用户通常并不关心系统是如何实现的（也有少数可爱的技术狂是例外）。对他们来说，更重要的是要达到他的目的。相反的，大部分的程序员的工作习惯就是考虑计算机应该如何实现用户的要求。所幸的是，用例方法能够调和双方的矛盾，因为虽然用例是来源于用户，服务于用户，但是它同样可以用于开发的流程。当系统的开发过程都是基于用例的，用用例获取需求，用用例设计，用用例编码，用用例测试的时候。这个开发过程就是用例驱动的。 用例和用例文档

《软件需求》一书中提到了几种方法来确定用例：

· 首先明确执行者和他们的角色，然后确定业务过程，在这一过程中每一个参与者都在为确定用例而努力。

· 确定系统所能反映的外部事件，然后把这些事件与参与的执行者和特定的用例联系起来。

· 以特定的说明形式表达业务过程或日常行为，从这些说明中获得用例，并确定参与到用例中的执行者，有可能从现在的功能需求说明中获得用例。如果有些需求与用例不一致，就应考虑是否真的需要它们。

用例代表了用户的需求，在你的系统中，应该直接从不同用户类的代表或至少应从代理那里收集需求。用例为表达用户需求提供了一种方法，而这一方法必须与系统的业务需求相一致。分析者和用户必须检查每一个用例，在把它们纳入需求之前决定其是否在项目所定义的范围内。基于“用例”方法进行需求获取的目的在于：描述用户需要使用系统完成的所有任务。在理论上，用例的结果集将包括所有合理的系统功能。在现实中，你不可能获得完全包容，但是比起我所知道的其它获取方法，基于用例的方法可以为你带来更好的效果。

当使用用例进行需求获取时，应避免受不成熟的细节的影响。在对切合的客户任务取得共识之前，用户能很容易地在一个报表或对话框中列出每一项的精确设计。如果这些细节都作为需求记录下来，他们会给随后的设计过程带来不必要的限制。你可能要周期性地检查需求获取，以确保用户参与者将注意力集中在与今天所讨论的话题适合的抽象层上。向他们保证在开发过程中，将会详尽阐述他们的需求。在一个逐次详细描述过程中，重复地详述需求，以确定用户目标和任务，并作为用例。然后，把任务描述成功能需求，这些功能需求可以使用户完成其任务，也可以把它们描述成非功能需求，这些非功能需求描述了系统的限制和用户对质量的期望。虽然最初的屏幕构思有助于描述你对需求的理解，但是你必须细化用户界面设计。

建立用例文档。在每一次的需求获取之后，都会生成很多未整理的需求，你必须将它们组织成用例文档。使用诸如模板的技术能够提高你的速度和需求的复用性。一个用例文档可以使用表格来组织，主要的要素包括了用例标识号、用例名称、父用例标志号、创建者、创建时间、审核者、修订记录、角色、说明、先决条件、请求结果、优先级、普通过程、可选过程、例外、非功能需求、假设、注释和问题。

虽然列举出了这么多的属性，但是实际中使用的属性这要看你的团体而定，看项目的大小而定。把大量的时间花在用例的描述上是没有意义的。用户需要的是一个软件系统，并不是一大堆的用例说明。

‘柒’ 如何进行结构化需求分析,其建模方法都有哪些

1. 基本型需求，这类需求是应该得到满足，有是应该的，没有是会引起用户不满；所以这类需求是比较重要也是需求挖掘和需求分析应当用心做好的，这是一个产品的基础。举例说明，聊天表情，几乎任何具备聊天场景的IM，都有发送表情的功能，输入法也开发了自己的默认表情，如果你设计一款新的APP，缺少了表情，可能会让用户不满。

2. 期望型需求，在做用户调研或则访谈的时候，用户反馈如果有某个功能，该多好，当你想深入了解的时候，用户或客户自己也说不明白为什么需要这个功能，就是觉得如果你有，就很好，如果没有其实也影响不大；还有种可能，用户使用了竞品友商的产品，进行相互对比的时候，告诉你某某产品有这个功能，我觉得你们也应该有，这类需求属于期望型需求同时也属于基本型需求，所以这类需求不满足，会引起用户的不满，得到满足，会给产品加分但是不会太多。对于期望型需求，我曾经也纠结过苦恼过，也设计过原型，一直迟迟没有提交开发，这类需求收集到了可以提前准备，等时机成熟（有很多用户或则客户都提到这个需求）或则有开发资源的时候，再做。举个例子，我现在在做的是ToB的产品，是专业的销售人员、外勤人员的行为管理软件，提需求的大部分是后勤人员，他们的工作就是使用后台进行监督、管理、汇总等，尤其是刚刚使用我们产品，对考勤管理特别用心，每天都会盯着考勤查看谁请假、出差、迟到早退、各种异常，然后每月工资也会按照考勤来制定，问题来了，用户提到如果考勤能这样排版、这样汇总、如果能够在一个页面看到所有信息等等。其实这些需求都是某些用户频繁使用产品，遇到的麻烦和想偷懒所提出的，他们期望软件帮他们完成所有的工作，然后自己每天就是坐在电脑前静静的等待结果。这类需求，需要慎重容易导致产品变得越来越臃肿，为了满足了任何人的需求，反而满足不了任何人的需求。所以很多文章都提到，产品经理面对需求，需要做减法。期望型需求，就是考验产品经理做加法还是做减法的判断力。

3. 兴奋型需求，让人出乎意料的产品属性，这类需求满足了会给产品增加不少魅力和好评。

1. 生理上的需要：食物 / 水 / 睡眠 / 生理平衡 / 分泌 / 性 / 呼吸；对应的移动互联网产品有美团外卖、陌陌等。

2. 安全上的需要：人身安全 / 健康保障 / 资源所有 / 财产安全 / 道德保障 / 工作保障 / 家庭安全；对应的移动互联网产品有支付宝、咕咚、乐运动、超级减肥王、动动记步、KEEP等。

3. 情感和归属的需要：爱情 / 友情 / 性亲密；对应的移动互联网产品有珍爱网、世纪佳缘、生日管家、她趣等等。

4. 尊重的需要：自我尊重 / 信心 / 成就 / 对他人尊重 / 被他人尊重；对应的移动互联网产品有新浪微博等。

5. 自我实现的需要：道德 / 创造力 / 自觉性 / 问题解决能力 / 公正度 / 接受现实能力；对应的移动互联网产品有在行。

‘捌’ 面向对象的需求分析中要建立什么模型

一、总述
面向对象分析的输入是用户的功能需求，输出是简单的、理性化的分析模型，此阶段的工作更多侧重于如何理解软件的功能需求；
面向对象设计的输入是面向对象分析的结果，蔬菜水果最终的、细化后的设计模型，此阶段的工作更多侧重于如何得到一个合适的、完整的解决方案。
二、主要区别
(1)
在侧重点上，面向对象分析侧重于理解问题，描述软件要做什么，而面向对象设计侧重于理解解决方案，描述软件要如何做。
(2)
面向对象分析一般只考虑理想饿设计，不关心技术和实现层面的细节，而面向对象设计需要得到更具体、更详尽，更接近于真实的代码的设计方案。
(3)
在设计结果的描方式上，面向对象分析阶段侧重于描述对象的行为，而面向对象设计阶段侧重于描述对象的属性和方法。
(4)
面向对象分析只关注功能性需求，而面向对象设计既关注功能性需求，也关注非功能性需求。
(5)
面向对象分析产生的系统模型通常规模较小，而面向对象设计产生的系统模型规模较大，内容也比较详尽、完整。
三、分析设计工具(rationalrose
+
uml)
1、需求分析阶段
常借助于“用例图”、“顺序图”对功能模型进行建模；
用例描述，一般包括：用例名称，系统范围，用户目标，前置条件，执行过程，扩展情况，后置条件。
顺序图着眼于整个系统。
2、面向对象分析阶段（包含需求分析阶段的用例建模）
常借助于“类图、对象图”，“顺序图、协作图”，“状态图”进行静态模型建模和动态模型建模。
这里的类图主要指通过用例分析得到的实体类、控制类和边界类。
顺序图也着眼于各个分析类对象间的协作。
3、面向对象设计阶段
常借助于“类图”，“顺序图、协作图”，“状态图”来细化各个类以及对象间的协作、关系的可见性；
这里的类图，要具体到属性、方法，类之间的关系依赖（继承、组合、聚合）
这里的顺序图要具体到各个类的实例之间的消息传递、函数调用。
面向对象设计阶段常借助一些设计模式达到软件的可扩展行，应对软件的可预测到的变化。

‘玖’ 软件需求的分析方法

软件需求分析方法大体分为如下四类：结构化方法、面向对象方法、面向控制方法和面向数据方法。限于篇幅，将主要从结构化方法和面向对象方法以及RUP三个方面进行简要的探讨。 面向对象（Object Oriented, OO）的方法把分析建立在系统对象以及对象间交互的基础之上，使得我们能以3个最基本的方法框架——对象及其属性、分类结构和集合结构来定义和沟通需求。面向对象的问题分析模型从3个侧面进行描述，即对象模型(对象的静态结构)、动态模型(对象相互作用的顺序)和功能模型(数据变换及功能依存关系)。需求工程的抽象原则、层次原则和分割原则同样适用于面向对象方法，即对象抽象与功能抽象原则是一样的，也是从高级到低级、从逻辑到物理，逐级细分．每一级抽象都重复对象建模(对象识别)一动态建模(事件识别)一功能建模(操作识别)的过程，直到每一个对象实例在物理(程序编码)上全部实现为止。
面向对象需求分析(OORA)利用一些基本概念来建立相应模型，以表达目标系统的不同侧面。尽管不同的方法所采用的具体模型不尽相同，但都无外乎用如下五个基本模型来描述软件需求：
整体—部分模型：该模型描述对象(类)是如何由简单的对象（类）构成的。将一个复杂对象(类)描述成一个由交互作用的若干对象(类)构成的结构的能力是OO途径的突出优点。该模型亦称聚合模型。
分类模型：分类模型描述类之间的继承关系。与聚合关系不同，它说明的是一个类可以继承另一个或另一些类的成分，以实现类中成分的复用。
类—对象模型：分析过程必须描述属于每个类的对象所具有的行为，这种行为描述的详细程度可以根据具体情况而定。既可以只说明行为的输入、输出和功能，也可以采用比较形式的途径来精确地描述其输入、输出及其相应的类型甚至使用伪码或小说明的形式来详细刻画。
对象交互模型：一个面向对象的系统模型必须描述其中对象的交互方法。如前所述，对象交互是通过消息传递来实现的。事实人对象交互也可看作是对象行为之间的引用关系。因此，对象交互模型就要刻画对象之间的消息流。对应于不同的详细程度，有不同的消息流描述分析，分析人员应根据具体馆况而选择。一般地，一个详细的对象交互模型能够说明对象之间的消息及其流向，并且同时说明该消息将激活的对象及行为。一个不太详细的对象交互模型可以只说明对象之间有消息，并指明其流向即可。还有一种状况就是介于此两者之间。
状态模型：在状态模型中，把一个对象看作是一个有限状态机，由一个状态到另一状态的转变称作状态转换。状态模型将对象的行为描述成其不同状态之间的通路。它也可以刻画动态系统中对象的创建和废除，并称由对象的创建到对象的废除状态之间的退路为对象的生存期。
状态模型既可以用状态转换因的图形化手段，又可用决策表或称决策矩阵的形式来表。 RUP（Rational Unified Process）是Rational公司开发和维护的过程产品。RUP是工程化的软件开发过程，它提供了在开发机构中分派任务和责任的纪律化方法。RUP不仅仅是一个简单的过程，而是一个通用的过程框架，可用于各种不同类型的软件系统、各种不同的应用领域、各种不同类型的组织、各种不同的功能级别以及各种不同的项目规模。RUP的突出特点可以由以下三个关键词来体现——用例驱动、以构架为中心、迭代和增量的。这些是RUP所特有的，也是同等重要的。构架提供了一种结构来指导迭代过程中的工作，而用例则确定了目标井驱动每次迭代的工作。
进行需求分析的基础是要获得用户的需要，为了完成这一工作，必须建立业务模型，通过描述业务规则、业务逻辑，明确业务过程并对其进行规范、优化。对于一个系统，在建立业务模型时，应从3个方面来描述其特性：功能、行为、数据，对应于这些特性。 基于上述分析可知，结构化分析方法与面向对象分析方法的区别主要体现在两个方面：
* 将系统分解成于系统的方式不同。前者将系统描述成一组交互作用的处理，后者则描述成一组交互作用的对象。
* 子系统之间的交互关系的描述方式不一样。前者加工之间的交互是通过不太精确的数据流来表示的，而后者对象之间通过消息传递交互关系。
因此，面向对象软件需求分析的结果能更好地刻画现实世界，处理复杂问题，对象比过程更具有稳定性，便于维护与复用。