系统分析方法
一、系统分析员基本功
2006-08-22, 15.43, sachina | 1957 x 阅读
好的系统分析员都是从优秀的程序员中产生的，坚实的编程功底、丰富的经验是今后做系统分析的基础。
没有对系统本身进行过透彻剖析过，很难领会到其中一些难以言述的精华。但并不等于好的程序员就能够成为好的系统分析员。
合理的知识结构。语言能力、文字表达能力、技术的全面性等是对系统分析员的基本要求。比如说c/s 和3 层开发，如果仅仅对netscape 公司的产品熟悉还不够，还需要了解比如微软等产品，并且要了解他们中产生历史，发展思路，技术优劣，以应付各种穷追猛打的提问。但更重要的是，这是你为应用定制技术要求的前提。
系统分析员思想
1. 全局观念是系统分析员必须具备的观念。
如果系统分析员设计时太注重细节，往往会陷入在某个问题上纠缠不清的泥潭。（93年，我论文指导老师的一席话影响了我随后几年对软件开发的理解——今后计算机会越来越快，多写几行代码少写代码无关紧要，最重要的是整体；一开始就错了，某个部份编得再好，也是没有用的） 系统分析员要有面向用户的思想。系统分析员应当有能力将自己扮演成用户，来了解要交付的项目看起来想什么样式，感觉想什么，从而了解用户的想法并挑选出合理部份去开发。从这个意义上说，系统分析员才能获得有意义的见解去引导他的开发组成员。系统分析员头脑中要对项目结局有一个清楚的认识，并保证项目不偏离方向。系统分析员要有根植于技术，高于技术思考问题的
思想。纯粹的程序员通常对最终结果考虑的不是很多，当一种新的技术在市场上出现时，他们对能否按时交付的考虑就比较少，而强烈希望他们的计划能够建立在新的技术之上。因此，系统分析员的想法和行动要象一个用户，又要能够站在技术的高度，成为真正的用户、程序员之间的代言人。
2. 任务难度的预测能力
系统分析员要具备快速的任务难度预测能力以及具备快速确定开发小组人员构成和任务划分的能力。（我将这条归为思想，而不是能力）昆虫自然会长出翅膀，而思想却需要长期的浸润。要做到这点，需要大量的思考、学习。设计远比编程重要。当今软件业的发展，各种开发工具的出现，编程已经不是什么问题，程序员的工作某种程度上讲是将别人现成的东西拼凑堆砌起来。系统分析员要清楚的认识到，现在大多数程序员没有学会怎么去整体的了解一个系统，有些甚至不了解编程（这不是说他们不会写代码）。可视化的开发工具加五花八门的控件，程序员可以偷点懒了。（这可不是夸大，我好几年的管理工作，接触过大量的程序员）基于技术，跳出框架。基于现有技术结合用户需求思考问题，设计时跳出
框架。
3. 系统分析员的关键
获得信任。系统分析员最重要的素质是获得信任，这是成为优秀系统分析员的关键。成熟最为关键。成熟可以为整个项目组提供正确的支持，能够理解技术怎样才能解决用户的需求。
系统分析员的准备工作
统一的各种文档模式，这其中包括今后软件变量、字段命名规则。我推荐用pb 制定的规则做基础，通过改造成为适合自身实用的标准。统一的文档管理。统一的分析软件。比如说rose （uml 太规范，国内的软件管理水平根本用不上，只不过尽量应用，你自己对系统分析的理解有好处）方法是思想的放映，在具体方法上就不多说了。我托人从u$a 弄到几本书，用于面向对象系统开发的使用》、《面向对象的分析》、《项目管理》等都是很不错的，推荐大家看看。
我在拙作" 在中国没有人懂计算机" 里发了点牢骚，听说挨了部份人（习惯性的）骂。其实，bbs 本来就是发泄的地方，在这里从来就罕有有内容的文章。
自从" 维纳斯" 登陆深圳后，大家更着眼于从宏观看中国的it 业了。中国it 这棵小树，说实在的，长到今天实在是不容易。一些人提出了" 反对微软霸权" 的口号，不少人呼唤中国" 硅谷" 的出现。微软的成功不是技术的成功，更多的是商业运作的成功。中国it 这棵树能长多高，取决于他所植根于的土壤。而现在
的事实是，这片土壤实在是太贫瘠了！如果按我们现在的思路和搞法，是长不成大树，更别指望能结？quot ；微软" ，" 硅谷" 这样丰硕的果实。如果说，我们的软件技术落后美国十年，我们的硬件制造技术则落后美国二十年，我们的管理水平落后美国至少三十年。而最终决定发展速率的恰恰是我们的死穴──低劣的管理水平。低劣的管理水平的形成的原因有着深厚的背景和多方面的原因。
系统分析工作是解决一个问题的工作，目标是将一个对计算机应用系统的需求转化成实际的物理实现，其中复杂就复杂在实际的面太多。在系统分析过程之中注意问以下的问题，可能会所进行的系统分析设计工作有帮助
1 ）您所完成的系统目的是什么？注意不是功能要求，而是目的。也就是为什么要建设、为什么要现代建设。在考虑系统目的时，我更多的侧重于系统的最终目标考虑，因为一个系统不可能一下子完美，为系统留些余地。
2 ）您所完成的系统有哪些方面参与，各方面的初衷是什么？那些人可能在系统建设中起重要作用，他们会采取什么样的态度？你对他们有多少影响力？中国it 行业的失败之一就是人" 太年轻" ，一定要有领导的支持，否则完蛋。不要认为自己对他们会有多少影响力，即便有，也要尽可能的认为是决策者再影响他们。在中国，一个技术员，你算老几？说到这里我很悲哀。哪些人在系统中起重要作用并弄清楚他们的态度，这点十分关键。
3 ）您的系统是否有一个明确的评价标准？最好从参与的各方面都进行考虑。
不知道这样说对不对，在系统建设之前，对你的程序员、对你的领导要有至少不同的两种评价。
4 ）你的系统设计思想是什么？是否能够得到各方面的认可。如果高明，对领导、对程序员都采用引导，
得到认可的最好办法，就是让他们认可他们自己的想法。（我力图这样做，但做得不好，系统分析员有一点要学会韬光养晦，忍）
5 ）你对参与系统设计开发的人员了解吗？他们的特长在哪里，是否愿意与你合作，为什么？你对他们有足够的影响力吗？软件发展到一定的程度，不是编程，不是数学，而是管理。
6 ）你的系统开发计划是否完善？你的计划表有明确的阶段吗？任何一阶段都应该怎样完成？如何对这一阶段完成的情况进行评价？
7 ）你对所采用的系统开发方法以及工具是否熟悉？你的夥伴是否熟悉？事实上，不是每种好的工具都要使用，也并不一定都要他们熟练掌握。提醒诸位一句，当你将方案做得可以不依赖某个程序员，你在程序员面前就无信任可言，因为从此程序员将受到更大的生存压力。我坚决不在公司使用rose.
8 ）你所完成的系统是否有原型？计算机的或者物理的。
系统分析员基本功
以上的几个问题都是在系统分析以及系统规划时涉及到的，供各位参考。
这文章很好，我的话是：" 需求分析实际应该是问题分析". 含义是系统要解决的是问题。而不是用户提出的需求。经常发现系统完成后，客户说" 我的问题还没有解决". 可是，需求分析稿上的目标都搞定了。
既然是问题分析，所以，熟悉目标系统的知识就是必要的。甚至，可以说，一个好的系统分析员也应该是好的业务专家。
我很高兴在这里遇到许多分析高手，可以交流分析中的问题。我赞同从来的观点。在中国作分析重要的是人气，因为中国的企业级信息系统的建设在很大程度上可以说并非确有需求，而是迫于某种压力。用户在很多时候考虑的不是系统的长远发展，而只是短期的成果，要求开发单位在很短的时间内完成一个很大的系统的开发，没有时间对系统进行周密的分析，在这种情况下，很多开发商就会粗分析，粗设计，尽快进入编码阶段，这样的系统的生命周期肯定不会很长。说了这么多，只是想说，系统分析员确实应是业务和管理专家，并且需要有很好的语言组织能力，他需要根据问题域中存在的问题去尽力说服用户，引导用户需求，毕竟，我们是专家，如果让用户牵着鼻子走，系统不会是成功的系统。（当然了，这要建立在用户是可引导的前提下）本人拙见。
在理解和分析用户的需求时，应说服用户明白：建立计算机应用系统并不是简单地用计算机代替手工劳作，它更应该是管理思想的一次革命，是现用户模式的一次升华和提高。如果系统不能高于现实，开发的系统将长期陷入需求的反复修改，其软件的生命周期也短了。
二、如何进行系统分析
2005-04-20, 08.56, sachina | 2994 x 阅读
出处：www.microsharp.cn
作者：一箭无邪
摘要：
教学目的，如何进行系统分析
正文：
一、什么是系统分析
在具体的研究需求分析之前，我们先了解一下软件工程这个概念。软件工程分为三个层次，过程层、方法层、工具层。在最基础的过程层，最重要的就是一组被称为关键过程区域（KPAs ）的框架（KPA 的概念在讨论CMM 的书中有详细的概念说明）。关键过程区域构成了软件项目的管理控制的基础，并且确立了上下文各区域的关系，其中规定了技术方法的采用、工程产品的，模型、文档、数据、报告、表格等，等的产生、里程碑的建立、质量的保证及变化的适当管理。方法层主要是过程在技术上的实现。它解决的问题是如何做。软件工程方法涵盖了一系列的任务：需求分析、设计、编程、测试、维护。同时他还包括了一组基本原则，控制了每一个的关键过程区域。工具层就很好理解了，他对过程层和方法层提供了自动和半自动的支持。这些辅助工具就称为CASE 。事实上需求分析是跨越了软件工程的三个层次的。这一点是和其他的过程是一样的。
可以看到需求分析的位置，它是我们软件开发的第一步。是对用户需求的定义，对软件系统的描述。系统分析的任务：将用户的业务逻辑转化为程序逻辑，计算时间和成本。根据开发人员的理论知识和实际的经验，人们会采用各种满足实际情况的系统分析、开发方法、步骤以及文档等等。一般情况下，在系统分析书中应该有以下内容（视项目而定）：
1、 系统需求说明 说明系统是一个什么样的系统，用市场上现有的系统来类比， 用客户（或是我们自己）需要一个什么样的系统进行说明，力求完整。并对系统的发展、可扩充性进行描述（现在没有哪个系统是一次OK 的）。说明与现有的系统有什么相同什么不同，说明未来系统的发展方面以及可移值性等能预见的事情。
2、 系统资源说明 对系统所需要的软件、硬件资源进行说明。描述系统所需要的 所有的TCO 成本。包括人员、时间、设备、系统、一次性投入资金、持续性投入资金这样 的所有资源。
3、 系统可行性分析 对系统的实施中的资源进行分析，说明投入的合理性和必然性，对其中的所有不可预见性的投入进行合理的量化说明，来说明系统的实施的可行性 。
二、系统分析员与程序员
大家应该对这两个词很熟悉了, 但是对词里包含的意义可能并不是特别清楚。首先必须说明的是, 程序员和系统分析员不存在谁高级谁低级的分别，他们是两种职业，对职业
技能的要求完全不同。所以厉害的程序员就是系统分析员的说法是不对的。当然，系统分析员的技能要求他必须要懂得如何写程序，但是他的重心在于如何把一个很大的项目切割成适合个人的小块，然后将这些小块组织起来。程序员的职责就是如何更好更快的实现这些小块。
三、系统分析的方法和工具
UML 全称：Unified Modeling Language，统一建模语言，是面向对象的建模语言，主要用于软件系统的面向对象建模。
UML 是以面向对象图的方式来描述任何类型的系统，具有很广泛的应用领域。特别是在建立软件系统模型中，它支持从系统需求、系统分析到系统设计的整个建模过程。由于UML 建模是一门专门的科学，而我们这门课程的任务是数据库系统开发，所以对于UML 我们将有限的注意力集中在认识UML 各种图示上。
可以使用Rational Rose 2003来建立UML 模型
1） 建立角色
2） 创建用例
3） 创建角色用例关系图
4） 创建时序图
5） 创建协作图
四、QQ 文本图形留言器系统分析的实现举例
1）需求分析总体图
2）各模块细分分析图
显示模块需求分析图
查询模块需求分析图
添加数据模块需求分析图
安全设置模块分析图
系统设置模块分析图
3）基本功能模块流程图(举例)
在这样的分析基础上，再进行编程，我们就可以有规律可依，做到有条不紊了。
三、Use Story方法
2005-04-20, 09.00, sachina | 1338 x 阅读
胡乱说说，里面肯定存在着不少的错误，还请高手指正。
Use Stories就是系统要实现的功能。它表述起来非常的简单，一个Use Stories只需要几句话就可以写完。之所以这样是因为用户需求的细节是非常易变的，而其高层描述却是相对稳定的。所以我们可以通过使用Use Stories的方法来从高层确定需要开发的内容，这些单纯的Use Story相当于系统中可能的点，而由我们通过与用户交流所得到的所有Use Stories则构成了一个面，它就是整个系统所需要实现的功能。
深入思考上面这段话的含义就会发现Use Stories在整个项目的初始分析阶段起的作用只是一个占位附。他告诉我们这样功能在实作的时候应该要实现，但是具体需要实现什么，怎么实现则是在迭代过程中的分析阶段所需要的事情。所以在写Use Stories的时候请切记，一定要简单概括，不可明确描述实现细节方面的问题。
说到这里就不能不说一下Use Story与Use Case的关系，我个人认为Use Story是一个更高层的分析阶段，它的抽象层次非常的高，如前面所说，它是一个占位符，而在具体对一个Use Story进行分析的时候则可以使用Use Case分析技术，将一个Use Story分解成为若干个Use Case。当然上面这段描述的前提是需要开发的系统足够的大Use Story对相对较大，一个Use Story可以折分一系列Use Case。但是如果项目的规则相对较小，那么可以直接使用Use Case来取代Use Story，这个在开发的时候需要灵活的掌握，不可死板追求到底用Use Story还是Use Case。
Use Story中除了包含对功能的简单描述之外，还可以酌情加入对异常情况的描述。虽然在具体分析一个Use Story 的时候还需要将其异常情况进行详细的列出，但是在撰写Use Story的时候还是有必要的尽可能的将它们列出，其原因在于，对异常情况的描述可以帮助我们发现一些在正常情况下无法体现出来的Use Story之间的关系。这对我们撰写Use Story的描述部分是有一定的帮助的，另外也可以在这个初始阶段提出一些问题，然后等待进入具体迭代的分析阶段时再进行解答。
Use Story内的描述只是开发者系统的一个最初步认识，所以以后开发者在实际开发时参考这些Use Story时一定要持着一种怀疑态度，再重复一次Use Story只是对高层系统一部分的抽象度非常高的描述。用户在具体开发的时候应该维护一份Use Story列表，如果在实际开发一个Use Story（或者这个Use Story所对应的某一个Use Case）的时候，遇到了对其它Use Story有影响的问题应该在这份Use Story列表当中标出。以便我们在这些受影响功能进行分析的时候可以尽量多的认识到这些影响它的问题。
用户在对Use Stories进行优先级的排序后，这个顺序虽然不是在未来完成整个系统的过程中实现Use Story的顺序（因为需求是易变的），然而一般情况下这个Use Stories的优先级排序，却决定了第一次 迭代的开发内容。优先级高的Use Story应该先完成，这是直面风险的一种方式，按照XP 的描述来看， 用户认为优先级越高的Use Story所存在商业价值就越大，当然其风险和不确定性也就越大，所以我们应该先实现它。 在用户确定了第一次迭代过程中所需要开发的Use Stories后，那么我们就可以将这些Use Stories分解成相应的任务了，注意，用户虽然为第一次迭代选择了相应的Use Sotries，但是这些Use Stories却未必会在第一次迭代当中完成，因为正如前面所说Use Stories的作用只是一个占位符，我们通过Use Stories所了解的
系统功能只是极为抽象的内容，单凭这些内容我们是无法估算出完成一个认识所需要的具体时间的，所以在决定开发一个Use Story的时候需要对这个Use Story进行进一步的分析，将这个Use Story拆解成若干个任务。折解的目的是Use Story所被折解成的任务将都是可以进行开发时间评估的（大小基本可知），只有这样的任务开发人员实际工作起来才会感觉到心里有数，一个Use Story所表示的抽象范围比较广，可以先将这个Use Story折解成若干个Use Case或者更小的Use Story（再强调一次，Use Case要比Use Story的抽象极别低），然后再将具体的Use Case折解成具体可以进行评估的任务。而如果我们对一个任务无法进行评估的话，那么可能就说明我们任务还有细分的余地，我们可以将它拆解成更小的任务（当然这里有一种情况是由于团队内的开发人员都不清楚任务所涉及到的专业知识，所以造成无法对任务的工作时间进行评估，在这种情况下，可能就需要一个此领域的专家帮忙了，或者如果没有这样条件的话，那么开发团队在经过对这种专业知识的短时间学习后再对任务进行评估？，或者重新评估使用此技术所付出的代价是否可以在一定的成本范围之内）。
在对Use Story进行拆解的过程当中经常会遇到的一个问题就是可以从进一步的分析过程当中得到一些浅在的Use Story或者Use Case。可以将这些Use Story或者Use Case加入到列表，然后评估其是否有必要被加入到本次迭代，如果有的话，那么一并进行分析，如果没有的话，那么将其安排到其它的迭代中来完成。 在拆解任务的过程中，我们应该保持对核心问题的注意力，举个例子来说，比如说我们要处理一个发送信息到指定用户的Use Case，这个Use Case核心的问题就是将信息成功的发送到指定用户处，而在拆解这个Use Case的时候我们发现校验收件人用户是否有效的操作也是一个相对比较复杂且工作量比较大的工作，因为它涉及到与帐号系统的配合工作。在这个时候我们所采取的策略就应该是将用户校验操作视为完成整个发送信息过程操作当中的非核心步骤，不需要对这个问题太过纠缠。在分析的时候只需要把它当做一步操作，而在实做的时候也只需要定义一个用户校验的接口，然后使用Mock 对象的技术来满足发送邮件时对用户校验系统的需求即可。
另外在拆解任务的过程当中还应该注意的一点是，不应该让我们所能够承受的复杂度和负载度超标，比如说当我们发现从一个Use Story分解出来的Use Case复杂的足以让我们不能够一次对付他们的时候就应该明智的将对Use Story的分析改成对某一个或者某几个特定Use Case的分析。只有使用客中化整为零，各个击破的策略才能够使我们在面对大型软件的时候保持我们的控制力。
Archie 的评价 2004.10.07
虽然不能准确的对故事进行估算，但是还是要进行估算的，而且团队的速度也是用故事的度量单位来衡量，而不是任务。
要进行估算就要对故事进行比较详细的了解，要和客户进行大量的沟通，了解到什么程度呢？能进行估算了为止。
四、面向对象开发中的本质用例及其职责
2005-04-20, 09.04, sachina | 2041 x 阅读
出处：UMLChina
作者：Robert Biddle
Robert Biddle 著，zhangxxin 译
本质用例（Essential Use Cases）是一种轻量级的方法，它简单明了，不受技术约束，用于沟通用户意图和系统职责，能够有效地捕捉用户界面的设计需求。在设计过程中，使用本质用例从系统职责中提取的关键词汇可以直接作为对象来使用，具有显著的优点。本文描述如何使用本质用例直接驱动面向对象开发过程，并实现与用户界面进行并行开发的方法。 在面向对象软件开发的过程中，用例在捕获需求过程中得到了广泛应用，并受到业界标准建模语言UML 和建模过程RUP 的广泛支持。Constantine 和Lockwood 在《以使用为中心的设计》
（Usage-Centered Design）中写道：“本质用例为支持用户界面设计而编写，简单明了，不受技术约束”。在一般过程中，本质用例用来产生用户界面设计，设计完成以后，又分解成几个更具体的一般用例，其中包括更详尽的细节和进一步的界面设计。但是，采用这种方法在用户界面设计完成以后才能进行实质的面向对象开发工作，费时费力，难以取得良好的效果。
在本文中，我们讨论在面向对象的软件开发过程中尝试直接使用本质用例的方法。与一般用例类似，本质用例可以作为面向对象设计的起点，但是，使用本质用例的方法进行沟通更加简洁，且无需指定太多的设计细节，便于需求搜集。
在过去两年中，我们使用本质用例方法作为主要需求搜集工具做了好几个系统的开发。我们发现，本质用例方法非常适用于面向对象软件开发，并且比一般用例具有更加显著的优点。
有三个结果需要介绍：第一，与我们推测的一样，本质用例可以直接驱动面向对象设计；其它的两个是意料之外的结果：一是本质用例提供了从需求转换到面向对象设计的指导，再有，就是保证了本质用例和对象之间的可追溯性。进一步研究发现，因为本质用例反映了用例的基本需求，从而可以由此确定用例的模式，更有效地进行需求搜集。
在后文中，我们将详细描述该方法。
本文组织如下：首先介绍本质用例提出的过程，并与一般用例方法进行比较；在第三章中，介绍本质用例的提取方法，以及使用角色扮演的方法检验其正确性和一致性；第四章通过一小段例子介绍如何在设计面向对象系统时使用本质用例；第五章以应用为中心讨论在无人参与的系统中使用本质用例的方法、开发过程以及业务过程设计等主题；最后，在第六章，进行相关工作的讨论，并得出结论。
背景
1. 用例
Jacobson 在他1992年的著作中写道：“用例是与系统进行对话时行为相关的事务系列的描述。”在最近的RUP 中，对用例的描述没有实质性的改变，它认为用例是“一系列带变量的动作描述，系统由此对特定用户产生有价值的可见结果”。
从某种程度上说，利用用例思想描述系统与外界的交互过程是行之有效的。
在软件开发的早期，用例着眼于系统交互，有助于提取系统行为，从而捕捉系统需求，确定系统规范。用格式化的语言和图形对系统的交互过程进行描述比较容易，而且易于理解，所以，由此产生的用例技术非常有效，特别适用于在大范围内进行需求搜集和分析工作。
在后续的开发阶段中，用例描述系统的交互过程。而交互过程是系统规约的具体化。在设计和实现过程中，系统规约通过结构来体现。在复审和测试过程中，用例描述测试等系统行为。在设计、实现和复审过程中，它们由同一角色引出，因此，整个开发过程具有可追溯性。
用例建立在一系列交互的基础上，一般来说，一个期望的交互过程总伴随与其目标（或子目标）一致的结构，因此，采用用例可以对需求进行有效的划分，通过组合、过滤、设定优先次序等方式进行组织，协助管理整个开发过程。
关于用例的优点以及用例到底是什么的讨论一直没有停止过。其基本概念已经有所发展和变化，尤其对软件开发方面的支持，例如职责描述和本质用例。我们选择本质用例作为工作的重点。
2. 本质用例
本质用例是以使用为中心设计的一部分，由Larry Constantine和 Lucy Lockwood 提出。用例具有显著的优点，但也有其局限性：“特别是一般的测试用例，它包括太多难以说明的，甚至是隐含的内建假设，而且用户界面设计的内容也包括在内”，这导致很早就必须进行设计决策，因为其内容成为需求的一部分，难于变更来适应以后的变化。
本质用例克服了上述问题。术语“本质”来源于：本质模型是“通过与技术无关的、理想化的、简单明了的描述来捕捉问题的实质”。Constantine 和Lockwood 对“本质用例”的定义如下：
“本质用例是使用应用领域或用户语言描述的结构化叙述，由职责的描述或交互过程组成。是一种轻量级的方法，对职责的描述简明扼要、技术无关、可独立实现，从反映系统交互的根本意图和目的角色的用户视角出发来描述交互过程，具有完整、针对性强、定义明确的特点。
本质用例用一种格式化的文本来记录用户和系统的交流过程。这个文本与Wirfs-Brock 使用的两列表的格式类似。虽然在Wirfs-Brock 的格式中用“动作”和“响应”两列来讨论用例抽象的级别框架，但它也适用于用户和系统的交互。
在本质用例中相应地采用“用户意图”和“系统职责”作为两列的标识。这样，即便使用用户界面细节描述也能抽象地描述交互的过程。需要注意的是，这个抽象过程并非作为一个整体与用例相关，而是与用例的各个阶段相关。用这种方法得到的本质用例是一系列交互过程，而不是抽象的步骤。
Constantine 和Lockwood 的例子如图1和图2所示。图1采用一般用例，用“用户动作”和“系统响应”进行描述，图2采用本质用例，用“用户意图”和“系统职责”进行描述。可以看到，采用本质用例的描述更抽象，更易于适应具体实现的变化，它更简短而且易于理解。
Jacobson 使用用例支持面向对象的软件设计； Constantine 和Lockwood 提出了本质用例和更广泛的基本模型框架，以支持界面设计和开发。我们注意到除了面向对象的软件开发外，本质用例实际上是毫无用处的。换句话说，本质用例的优点只有在面向对象的软件开发领域才能得到体现。
自动取款系统的一般用例描述（Constantine 和Lockwood ）
用户动作 系统响应
插入卡 读取磁卡
提示输入PIN
输入PIN 校验PIN
显示交易菜单
按键 显示总额菜单
按键 提示总额
输入总额 显示总额
按键 退卡
取卡 吐钞
取钞
自动取款系统本质用例描述（Constantine 和Lockwood ）
用户意图 系统职责
身份识别 验证身份
提供选择
选择 吐钞
取钞
本质用例和需求
在设计过程中，CRC 技术可以在团队活动中提高对设计的理解和设计的有效性，而在用例分析和评估过程中却缺乏这样的技术。我们希望开发这样一种技术。本质用例有许多适应这种技术的特性，因此，我们开始在面向对象软件开发过程中使用本质用例。
与CRC 技术类似，该技术包括索引卡和角色扮演。经过大家讨论确定用例以后，给每个用例分配一张卡片，在顶部写上用例的名称。将卡片纵向分成两部分，左侧描述用户，右侧描述系统，如图3所示。然后，团队中每两人一组来研究人机对话过程，一个扮演用户，一个扮演系统，并记录对话的经过，把结果提交给用例的审查小组进行复审。
本质用例描述系统的人机对话过程，是角色扮演的脚本，可以通过一部分人扮演系统，一部分人扮演用户的方式来模拟系统的人机对话过程。与纯文本的描述不同，这个过程是可视化的，不易引起歧义。Wirfs-Brock 指出，用例可以看做用户和系统的“交谈”过程，有助于系统建模。另外，用例和角色扮演还可以帮助确定系统边界，划清系统内部和外部的界限。
我们在应用领域和学校的开发小组中展开进一步的工作，获得了使用的实际经验。我们发现，抽象的本质用例有很多好处，简短的卡片式描述可以加速分析过程，更多地考虑交互细节，无需早期就在系统交互的具体问题上纠缠不清，被系统的具体实现所困扰而花费大量时间，从而可以集中精力确定系统的本质用例。
本质用例的抽象过程实际上是指导角色扮演的过程，并不是一个真正可实现的对话过程。但是，开发早期的角色扮演实际上是轻量级的，不能判断能否实现。如果需要对抽象元素的具体例子加以明确，那么，把它作为一个可操作的本质用例，可以由此讨论产生一个具体的脚本，描述可能的实现细节。
1. 用例
本质用例的对话并不是指简单的用户动作，而是用户意图。
在角色扮演中，要从角色的视角考虑问题，深入理解其动机和类型，考虑其所处的环境，了解其背景。这样才能准确表现其意图。
从这个意义上说，角色扮演对团队其它成员和听众变得更加重要。对用户意图的充分考虑赋予角色扮演更丰富的内容。更重要的是，复审人员需要更深入详细地考虑用例，评估其一致性，验证是否提取对话中的所有元素。
除此之外，用例着眼于系统与外部世界的交互过程和使用细节。而在大多数系统的开发过程中，系统使用的不确定导致用例实现完全依靠理解能力和创造能力的发挥。本质用例通过对用户意图的理解来确认系统用途，但并不否认用途也可以基于对用户本身的理解进行提取。在这种方式下，用户意图成为用例设计的原动力。
在RUP 等软件开发过程中，用户界面原型包括对用户本身和用户需求的理解，因此很早就需要进行开发。采用本质用例方法，在理解用户意图的前提下，为用户建立一个清晰的流程设想，同样可以作为系统后期设计的输入。但是，这种方法是轻量级的，不需要产生具体的用户界面，可以支持更快速的开发过程。
2. 系统职责
在本质用例中，采用系统职责代替系统响应进行描述是因为系统职责包括了更多与用户意图相关的内容，并在系统后期设计中产生其它影响。
在角色扮演中，用户角色扮演特定的人，意图可以通过多种方式表达，而系统扮演的未知实体则很难进行发挥。但是必须达到验证、确认人机交互过程的目的。
要深入理解人机对话中的任何一个元素，都需要在目标基础上加以引申。因此，本质用例对用户的描述采纳用户意图而不是用户目的。用户意图中除了可以理解的内容外，有一部分我们可以适当地加以引申。
对系统的描述应增加一些针对内部的说明，用以指导下一步的设计。系统职责是描述系统需要做什么，而不是系统实现的细节。这与用户意图的产生动机略有不同，但有助于确定用例和角色扮演。引入用户意图是为了描述系统实现的目标，而引入系统职责是为了描述系统实现的责任。
在本质用例中，某些用户界面与大系统的开发有千丝万缕的联系。在使用本质用例开发用户界面的例子中，系统职责作为人机对话的参与者，主要关心提供给用户的信息内容。但是，在大系统中，系统职责必须包括更广泛的内容。例如，在图2所示的银行系统取款的本质用例中，清楚地描述了与用户界面相关的内容，却缺乏与银行财会业务相关内容的描述。
当然，一般用例也有这样的缺点。如果用例只用于描述系统和用户之间的对
话，必然难以准确地体现各系统（子系统）之间的联系，比如图1的用例也有这样的缺点。
从这个意义上说，着眼于系统职责的本质用例更加实用，因为它并不直接、简单地描述系统与用户的交流过程。在图4的本质用例中，我们补充了对系统职责的描述，虽然这些描述不会在具体的对话过程中体现，但是交流过程的完整性和场景的一致性能够指导系统的开发。
补充后的自动取款系统的本质用例描述
用户意图 系统职责
身份识别 验证身份
启动交易服务
提供选择
选择 吐钞
结余
取钞; 终止交易服务
本质用例及其设计
面向对象的设计中，“职责”扮演了非常重要的角色，确切地说，它不仅是CRC 技术的关键概念，同样也是职责驱动设计中的关键概念。
在CRC 技术中，职责与对象相关联，标识需要解决的问题。在完成职责的过程中，互相协作的对象之间彼此通信，通过不断的优化、迭代，形成一个满意的结构。这样，将职责分配到类，并进行细化，作为一种工具，指导实际系统的开发。
在职责驱动的设计中，职责的内容更广泛更完整。与职责相关联的对象不仅描述了对象维护的知识，还需要描述对象需要完成的动作。在这个意义上，职责强调的是对行为的抽象，而不是具体可能的执行结构的提取。但是，对象可以通过协作对象之间的消息传递完成职责，也可以由此产生更高层次的抽象类。总的来说，在这种设计方法中，职责是在较高层次上进行抽象的分配，而不考虑对象执行的细节。
在CRC 技术和职责驱动的设计中，关于职责的概念和使用方法看起来非常
类似。它们都认为每一个对象都有一组明确的职责，都包括了进行职责分配，指导设计决策的概念。其实，两者之间本来就有一定的继承关系。面向对象设计的基本原理就是：对象是行为和数据的统一体。职责观点沿袭了这一说法，“职责”本身就包括了职责的内容和可以使用的资源。职责还允许进行授权和管理，通过对一系列子职责的调度和管理完成职责，包括了抽象和封装的概念，正象
Wrifs-Brock 等人解释的那样：“职责驱动强调对结构和对象行为的封装，关注类所完成的职责，而到实现阶段再考虑类实现的具体细节。”
本质用例的职责描述系统要做什么，而不是做的具体细节。这与对象封装的观点类似，同样也具有类似的优点。
用例中的职责与设计中的职责一样，都描述行为本身，而不是执行的细节，这就可以将需求和设计连结成一个整体来进行描述。
1. 确定系统边界
在实际工作中，需求主要是区分系统做什么不做什么。然而，这个边界非常难以确定，也非常难以与涉及的所有人（包括分析员和投资方等）进行沟通，达成共识。我们发现设计中使用的逼近技术非常适用于这种情况。我们把系统当成一个有明显边界的“黑盒子”，用本质用例的系统职责对系统的行为进行描述。
我们把系统看成由一系列职责组成尚未考虑执行细节的独立系统对象。Jacobson 等人在不同的方向上提出过类似的观点。采用本质用例、系统职责有助于确定系统边界。如果系统类似一个独立对象，那么用例就采用类似的方法描述，只能从系统的内部访问系统的行为，而交互的过程就类似于一系列能有序管理的参数和返回值。
在UML 和RUP 中，通用的用例图可以把这些想法固化下来，如图5所示，在图中，我们增加了一个方框，将用户意图和系统职责分离开来，从而明确了系统边界。
银行取款系统的用例表示样例
Jacobson 认可这种用法，UML 同样认可这种用法，它指出：“用例可以用一个随意封闭的矩形代表系统的边界或分界”。这种用法与系统对象的提法非常一致，便于讨论和确定系统边界。
2. 用例的职责和设计
对任何系统来说，本质用例的职责与系统对象内部的职责联系紧密。本质用例的职责反映了整个系统的行为，对象的职责协同工作也应该反映相同的行为。
这种方法将系统的需求和设计联系起来。本质用例的职责可以作为系统设计的起点，指导系统的行为设计，保证设计和用例的可追溯性。
从一系列本质用例开始设计，引出系统对象，通常通过一系列对象的协作完成职责。另外，在设计中，两者可以通过采用相同语言的方法巩固其一致性。
首先，尽可能采用一致的语言，对一系列描述系统对象职责的本质用例进行设计，然后再确定完成相同职责的协作类。
在严格的设计过程中，将根据上面的结果产生具体的类。这个过程是一个重新分配职责的过程，将直接影响最终设计方案的确定，要求非常细致。这个阶段的工作属于设计的基本流程，不可省略。需要一定的设计技巧和技术进行职责再分解。现在有一些成熟的技术可以直接使用，例如，在设计早期就可以使用类析取（Extract Class）技术。
但是，我们不提倡这种做法，主要有三个原因：其一，没用利用任何领域模型，使领域模型和设计脱节，造成理解和维护的困难；其二，一个完整系统有很多用例和职责，难以严格地分解；其三，难以兼顾其它地方产生的设计结构。
在CRC 和职责驱动的设计中，基于基本模型和应用领域模型，产生一组关键对象和类，根据领域知识和设计要求进行初步职责分配，然后着眼于少量的关键用例进行交互和迭代，产生初步设计方案。
在CRC 和职责驱动的设计中，本质用例没有引起任何流程的改变，但是，它扮演了使用快速原型法进行开发过程中非常有用的角色，为检验设计与需求的一致性提供了有效的方法。
这种方法要从设计初期抓起，从早期用例的职责分配抓起。换句话说，初始的设计职责应该从领域知识中产生。这样，可以与本质用例进行比较，得到早期的反馈，避免以后产生歧义。这样可以更好地指导关键职责设计者的开发工作。
设计一般都会有结果，有许多设计方案可以在新的设计中作为一部分进行继承和重用，例如组件、组件库、框架、设计模式等等，有的甚至本身已经是可执行的，它们对系统设计影响很大。而本质用例则提供最终设计与需求是否一致的有效检验方法。
与CRC 和职责驱动的设计不同，其它设计方法与职责本身可以无关，因此，设计和需求的检验显得更加复杂，更加重要，需要对组件和其它结构进行仔细检
查。但是，对可执行重用资源的检查并不是对其执行的正确性进行验证，更多的是对其行为模式的认可，也可以说是对其适用性的认可。这样确实对提高重用度具有深远的意义。
用例和设计的职责划分明确以后，问题就迎刃而解了。无论是无意的还是设计活动中的折衷，设计的不完善性都可能存在。无论采用哪种方式，都需要提升设计。另一方面，设计又可以从某种程度上弥补需求的不足。例如，设计必须基于现有系统的处理活动，哪怕仅是需求中的片言只语，这时就可以重新考察用例，看能否有所改变，能否使用现成的设计资源。
综上所述，引入需求和设计职责的概念提高了两者之间的可追溯性，保证需求和设计的一致性。
3. 举例说明
在本节中，我们将通过一个小例子来描述我们的工作。为了说明问题，例子非常简单，但是所用的方法同样适用于更复杂的系统，可以用于顶层设计，也可以用于详细设计，并且也有可用的支撑工具。
这个例子是图书馆系统中的一小部分。领域模型由两个对象类组成：书籍和借阅者。分析的过程如图6所示。在顶层，我们只关注于两个本质用例：借书和还书。
通过对这两个本质用例的进一步分析，我们可以得到迭代1中产生的CRC 卡片。在这个步骤中，我们不一定能够分析得到所有的系统对象。例如，要知道可借阅的图书，就必须登记已借阅的图书，必须对作为协作对象的职责进行分配。
系统对象应该明确，能够与用例对应，如果用例太多，产生的对象太大，就会难以执行。从领域模型出发，我们建立了三个类：单独的图书馆系统Library System 类、书籍Book 类（每本书一个实例）和借阅者Borrower 类（每个借阅者一个实例），然后考虑它们的职责分配。
迭代2显示了这个设计过程。在设计中，书籍借阅标志的设定在书籍Book 类中完成，但是，依然可以通过图书馆系统Library System类进行初始化、查询和更新操作。
图书馆系统Library System类还有一项职责，就是不但需要“知道有哪些图书”，而且还要能够查询。也就是说，图书馆系统Library System类必须对书籍Book 类进行管理，同时对借阅者Borrower 类也应有相应的管理功能。
在迭代3中，书籍Book 类和借阅者Borrower 类没有改变，增加了一个独立的分类Catalogue 类，完成“知道有哪些图书”的职责，可以用一个标准的collection 对象来实现。
需要说明的是，我们在这里基本上只列举在用例中明确描述的职责，实际上，在领域分析的过程中，还会分析产生一些职责，并且对整个过程发生影响。例如，检查书籍是否被借阅的职责就是通过类似领域分析的过程产生的。
如图所示，从需求中提取职责进行设计并不只是一个单向的过程，它可以进行调整和变化。但是，这个过程的描述非常有利于与投资方进行交流，特别是复审阶段的双方沟通。
讨论
在本章中，将讨论几个与本质用例相关的面向对象设计主题，包括：
· 无界面系统（实时系统）设计；
· 定制界面系统的设计；
· 迭代和增量开发过程；
· 界面和应用的并行开发；
· 基于业务过程的面向对象设计。
1. 无界面系统（实时系统）设计
在实时系统和软件引擎中，系统只与系统主角交互，并且没有传统的人机界面，那么，能否采用本质用例呢？答案是肯定的。本质用例同样适用于这类系统。
在这类系统中，有一个重要概念就是“外部世界（outside world）”。在任何系统中，都需要对系统的内部和外部进行明确的划分，从而确定系统的边界；确定系统交互的原则（无论是人还是机器）；设计交互方式。我们发现，在这样的系统中，本质用例同样有许多优点。在适当的抽象层次上，本质用例摆脱了表达和实现的具体细节的束缚，能够更准确的捕捉用户意图和系统职责的本质，它不受具体系统类型限制，简洁明了，易于理解，便于编辑，方便复审，可以实现分析和设计的无缝连接和平滑过渡。
系统常常有一些附加的非功能性约束，例如响应时间、交换速率、信息容量、可靠性等。因为用例着眼于交互的过程，所以不是发现和确定这类需求的理想工具。但是，它可以帮助记录和管理这类需求。在常规用例方法中，通常采用文字描述的方法，并与用例同步管理，且其管理过程与用例结构无关。本质用例也可以采用类似的方法。在以用为中心的设计中，这类指标往往与本质用例相关，因为它们对高性能的用户界面设计至关重要。
本质用例的系统职责、系统对象的职责以及中间对象的职责之间的可追溯性弥补了系统设计的不足，保证系统满足这类非功能性指标的要求。例如，用例级
的系统约束可以分解到对象中，对象的性能又直接影响到用例职责。采用公共任务标签的办法可以调整最终设计，确保满足非功能性指标要求。
2. 定制界面系统
本质用例同样适用于已经定义好界面的情形。在这种情况下，我们先对界面进行分析，然后描述交互过程的本质用例，并在此基础上进行面向对象的设计。这样，从系统交互和职责的本质着眼进行设计的中间系统更稳定，更能够适应界面细节的变化，同样具有本质用例方法的主要优点。
3. 设计业务流程
长期以来，常规用例被认为是业务流程建模的好方法，它主要描述的是业务单元（人）之间的交互，而不是计算机系统和人之间的交互过程。
本质用例与技术无关，它描述用例之中抽象的意图和任务，因此，无论采用何种界面技术，都可以实现用例。例如，采用相同的一个呼叫中心的用例，既可以支持用桌面应用的方法实现，也可以支持用Web 的方式实现。还可以支持采用交互的语音提示的方法实现。这就是说，本质用例与采用何种技术途径无关，需要的仅仅是最基本的计算支持。
使用本质用例的成功经验告诉我们：本质用例既适用于软件设计，也适用于业务流程设计，它们在抽象、对话和任务中具有相同的优点。
4. 开发过程
本节主要描述我们建立的软件设计模型，并为模型构建的过程提供参考。非常重要的是，从本质用例到系统对象，然后到面向对象的中间设计描述是开发的抽象过程，而不是构建模型的具体步骤，并不是类似于瀑布的过程，先对本质用例进行“分析”，接着确认其“完整性”和“正确性”，然后进行设计等等。
我们希望这个过程是一个增量的、可迭代的过程：先有一个备选用例表和一个初步的领域模型；其中的关键用例首先被细化，按用户意图和系统任务编写到用例卡片中；然后进行初步的设计，划分对象任务，并对用例的措词进一步细化和调整。再细化其它的用例，获得更多的对象模型，这些工作可根据后续工作中情况进行必要的复查和调整。
本质用例有助于软件开发的迭代过程，其抽象层次、用例与模型间的通用词汇决定了迭代开发的过程更易于跟踪，具有更好的一致性，对象和用例之间具有更良好的可追溯性。当设计完成时，所有的用例和对象都使用相同的词汇表，所有的系统任务被设计划分成适当的中间对象，所有的用例都可以被对象模型执行，能够更方便地检验设计和系统任务的一致性。
5. 并行开发
在以用为中心的设计中，使用本质用例同样可以产生用户界面。在这种情况下，基于本质用例采用面向对象设计方法进行中间设计具有更加显著的优点。它可以避免重复工作：它设计的用户界面可以直接在软件设计中重用，无须重新捕捉和进一步细化，使软件设计和界面设计可以同步进行，只要二者同时支持本质用例就可以保证良好的一致性。
这和其它的过程方法（特别是RUP 过程）略有不同，不需要在早期就完成界面设计，可以在软件设计阶段进行，支持软件设计和界面设计的同步进行，不会因为界面设计没有完成而延宕工期，可以有效地缩短项目周期，特别是在用户界面设计要求高、数量多的项目中，可以为整个项目节约好几个月的时间。
并行设计特别适合于Web 系统的开发，前端界面和后台服务软件可以独立设计，并有专门的技术支撑其实现。在这样的并行开发过程中，要求对迭代过程进行有效地管理，协调设计过程中用例的变更和实现，使二者保持良好的一致性和可追溯性。
与其它方法的比较
软件开发技术在不断地向前发展，也提出了许多其它的手段和方法。在此，我们着重介绍它们处理需求和设计之间关系的不同方法。
面向对象的软件工程（OOSE ）对建立对象模型中对象和用例之间的关系提出了许多有用的建议。Jacobson 等人用系统边界、控制和实体对象实现用例的方法来建立分析模型，但是在分配系统行为和产生类（class ）的过程，要求有一个附加的翻译过程。与这种方法相比，我们使用的本质用例方法具有更好的可操作性。
还有一些更简单和直接的方法来组织需求和进行面向对象设计。例如，在第二章中提到，Jacobson 等人介绍用例概念，以及Lockwood 提出在用例界面设计中使用本质用例方法就是基于这样的思想。还有许多指导用例写作及其在软件开发中具体应用的书籍。例如，Cockburn 最近就出版了一本详细介绍用例写作方法的书籍，并对各种风格的用例进行了介绍。Amour 和Miller 还讨论作了为需求搜集工作的一部分，如何发现和管理用例。但是，这些工作很少提及用例如何在分析和设计阶段的工作中反映，讨论用例和设计关系的工作在领域模型的开发中完成，把领域模型作为设计和开发的第一步。领域模型固然非常重要，但是，从需求到发现领域模型、领域模型满足需求之间还应该有大量的工作需要完成。
大量的文献都提到可追溯性的重要性。Pfleeger 指出，可追溯性包括横向和纵向的可追溯性。纵向的可追溯性是指开发过程中模型内部的关系，横向的可追溯性是指模型与模型之间的关系。加强系统的可追溯性可以有效地提高开发过程的质量和降低维护成本。
我们致力于需求与设计横向可追溯性的工作，将二者的关系直接反映到任务的分配中，成为设计工作的一部分。
任何软件开发方法都伴随相应的过程。最近经常提到的过程是Rational （瑞理公司）统一过程，即RUP 。RUP 是用例驱动的软件开发过程，用例连接开发过程的各个阶段。在我们使用的本质用例方法中，本质用例在开发过程中具有同等重要的地位，只是在用例格式的选择上有所差异。事实上，本质用例方法与RUP 方法中用例的描述没有任何矛盾，甚至可以认为本质用例是基于前文中指出的OOSE 方法中分析和设计工作流的细化。
还有一种开放式的软件开发过程，准确地说，它是一种软件开发方法的框架，而我们只关注其过程部分。特别值得关注的是它的开放式工具技术，为不同职责的软件开发需求提供完整的技术支持。它提供从原始需求到设计模型的技术，包括：协作分析技术、CRC 卡片建模技术、委托分析技术、领域分析技术、泛化和继承技术以及对象模型转换技术等。上述所有技术都可以和我们的研究联系起来，而我们的工作在指导操作和提供可追溯性方面做出了贡献。
最近，轻量级方法XP 等大行其道。基于XP 方法的设计要求功能需求尽量简化，在真正需要以前，不轻易增加别的功能。XP 是带有独立“用户故事”的增量开发过程（与用例类似但完全固化），通过再分解现存的程序实现用例，达到增量的目的。我们的方法与XP 的方法也有所类似，所有的设计都可以再生。但在XP 的方法中，当需要扩展支持新的用例时就需要重新设计，而在我们的方法中，设计从完整的系统目标出发，以实现整个系统为目的，所有的再分解都维持了对象的任务，都可以在中间组件之间重新进行分配。
结论
用例适用于各种软件的开发，本质用例起源于用户界面设计的细化和描述。我们尝试在面向对象的系统开发中使用本质用例，并在本文中进行了总结。
本质用例能够简单快速地发现需求，支持通过角色扮演进行沟通，有助于发现系统边界。它简明扼要，易于学习，避开了繁琐的实现细节，支持快速开发。使用这种方法易于确定用例模式。它还同时支持界面和系统设计，可以实现二者的并行开发。
本质用例标识系统任务，将需求和面向对象的设计联系起来。在设计中，其职责启发分配协作对象之间的抽象行为。使用本质用例描述需求，采用职责驱动的方法进行设计，可以更好地为设计提供指导，使设计和需求具有良好的可追溯性。
五、如何分析问题和需求
2005-04-20, 09.09, sachina | 2871 x 阅读
（梦郎个人观点）
万事开头难，需求没有完全分析清楚，系统设计很难满意。面对项目，我们如何提出问题，如何界定问题主次，哪些问题必须定义，哪些问题可暂时不理...... 。
一、提出问题
１. 树状遍历式寻找问题
每个问题都不是单一存在的，它都有相关问题，犹如一棵树一样，主问题就是主树杆，主问题伴随的其他问题，就是支树杆，以次类推。首先不要怕麻烦，每当一个问题提出，必须提出尽量多的相关新问题。提出问题的方法：顺藤摸瓜。
比如：写一个通用编辑器程序，此程序为自己或别人开发其他专业编辑器打下可靠稳定的基础。
１）问题：什么是通用编辑器。编辑器面向的对象应该是不确定的。
２）如果数据类型不确定，我们如何确定程序编写的对象。可以举出一些可能的假设。假设我们将此通用编辑器用作程序源代码编辑，那么就应该有中断、单步执行等设置，这导致数据不能封装在编辑器内部，应该由后期开发指定数据结构。
３）如果是程序编辑器，关键字的特显必不可少，所以显示的属性应该给出接口。
４）诸如关键字此类的是否还有其他需要特显的，那么，应该注意到特显类不仅仅是一种，程序设计时，最好抽象出特显的方法与数据结构（不管以后有多少不可预知的特显内容）。可以深入考虑特显接口应该如何给出，才能支持任意特显方式，它还需要哪些信息。
５）抽象特显类时，应该举出尽量多的可能性，综合考虑。
６）问题：哪些内容需要特显。编辑器很难知道，数据类应该自己了解。所以，特显内容的定义必须有一个机制让后期开发时使用。
７）问题：源代码编辑器有自动缩排、词法、语法分析，这些操作如何在编辑器中体现。考虑语法类接口。是否有收缩与展开操作，接口又如何。
８）又假设：后期要扩展成字处理程序。数据有文本、图象、特殊公式编辑、段落概念、表格等。
９）送进编辑器的数据可能是一组含有控制字的数据，问题：如何获得让编辑器知道不同数据的不同显示操作。编辑器肯定无法全知，所以，干脆交给后期开发需求处理。
１０）未知数据应该有：显示方法、光标定位处理等
１１）光标定位需要当前坐标，所以，必须有接口让编辑器知道数据宽高。
１２）综合结论：应该有一个接口机制。凡特殊操作的内容，交给后期处理，但通用编辑器应该做好数据管理和传送的工作，而这些工作，不管哪种编辑器都需要。
首先任其深入提问，虽然问题可能多得十分复杂或凌乱，但它对即将做的系统设计绝对有帮助，最好把每个问题都有一个清楚的了解，千万不要急于设计系统。通过这些提问和假设，就可清楚地分析我们所作的软件应该实现哪些内容，哪些内容实现有难度，实现这些内容的大体方法，通用编辑器能作什么。通过上列系列提问和解答，我们可以认为，通用编辑器仅仅是一个以行为基本编辑单位的编辑器摸板。编辑器不仅自己有编辑操作，同时允许外部提供特殊数据对象的编辑操作，最终实现文本编辑、图形编辑、表格编辑、公式编辑一体化。数据外部实现，将允许后期确定内容属性。
上述方法基本上确保了软件有好的可靠性、扩展能力、性能、重用性和系统化。想高效率生产系列软件，确实应该考虑的更多。
２. 直接切入目标问题
直接提出软件要完成的系列任务，通过考虑任务的实现，罗列问题，在问题的解答过程中反思任务的需求。这样的方法可以快速设计出软件开发方案。
仍然以通用编辑器为例：
１）编辑对象有：文本、图形、图象、表格等。
２）操作有：焦点移动、增加、删除、存取盘、选择块、粘贴拷贝、缩进、展开收缩、书签、中断设置、单步执行标记等。操作有分文本、图形图象、表格等的操作编辑。
３）显示：文本的不同字体风格显示、图形的显示、图象的显示、表格等的显示。
４）状态设置：改写插入、段落格式设置、标题控制、编辑器专业化的设置等
５）考虑各项功能的实现方案，发现问题。
６）如果有没有考虑到的，增加进去。
７）经过许多的方案设计，综合考虑和优化方案，提出最后的设计方案
８）综合结论：程序考虑了诸多功能，通用编辑器是众多功能的集合体，内部详细规划了各种类型数据的操作、显示和排版分析。
经过一系列的方案定义，将问题逐步减少，最后获得一个规模较大的系统设计早期方案。我们可以较早地进入系统设计，并且提前进入程序代码级开发工作，同时逐步实现各项内容。
此方法分析需求，有助于我们尽早实现想法，同时较好地控制住程序开发方向和基本功能完成的进度。但遗憾的是提高开发速度的代价是降低程序的可靠性、扩展性和重用性。过去，我们往往觉得所作的程序基本上不能再次使用，原因就在于没有抽象问题，寻找问题的根本解决方案。就问题实现问题的方法，忽略了深入分析问题的过程。对于针对开发某专业的应用软件采用此方法分析需求比较合适，但对系统性强的软件，最好采用树状遍历式寻找问题的方法。
二、分析问题和需求
在没有分析清楚问题和需求的来由就匆匆下定论是非常危险的。忽略问题和需求就可能埋下了潜在的程序或系统设计问题。我们也常常犯这样的错误：由于没有分析清楚问题和需求，结果到头来更改系统设计。能够提出的问题和需求，就一定要扎扎实实分析它，否则后果难料。
分析问题和需求的能力大小与思路和经验有关。好的思路来源于严谨、逻辑和跳跃的思考习惯。严谨要求不要放过任何一个小问题，逻辑要求思考的过程应该是一种符合规则的推导过程，跳跃思维要求思考的路子不是一走到底而是多条路子并行着走。经验来自于编写调试大量程序和善于总结，要求程序员不断地开发新程序和创造新思路，并且敢于尝试和接受失败，当然还有一条重要的方面：跟踪最新技术。
如何正确分析问题，有以下几个要素值得注意：
１. 所有问题和需求都有发生的根源。
问题和需求的表面现象总是与开发者思路切入点相关，如果切入点是狭隘的，那么围绕着问题和需求的分析往往局限于自身的思路范围，问题和需求产生的原因就很难发觉。所以当不能理解分析问题和需求时，不妨先找一找为什么存在这样的问题和需求，它的存在是否合理，然后再分析理解它就不难了。思路一定要跳出惯例。
２. 交替反复分析多个问题和需求，寻找问题间的共性和特性
看似问题和需求间没有联系，而且分析不清各自意义，那么建议交替反复分析考虑这些问题。勤能补拙，不要担心它将花费开发者多少时间，只有开发者仔细分析问题需求，以后的工作越来越简单明了。
３. 复杂化问题，
问题复杂化，是一个抽象问题或需求的逆过程，提出问题需求的许多可能的假设，丰富了问题需求的形式。能够复杂化问题，本身就体现了分析问题和需求的能力。比如：做一个加法程序，两个数相加，返回结果。简单的问题，但，我们一般都按两整数加法，有时考虑了浮点加法。为什么不是两个复数相加，或者是两个字符串相加等。这是一个使用操作符重载或类模板解决的简单例子，在这里我的意图是许多问题应该从更多的方面去验证问题是否同样存在。
４. 问一问自己：问题是否能够抽象化，继而简化问题。
众多的问题和需求变成程序代码的过程，就是公式化问题和需求。如果象上例加法一样，不管三七二十一，什么样的数据就写一段什么的代码，不同类型数据间的加法同样又要写一段代码，这样下去就写不完了。抽象问题，简化问题，类模板就是一个抽象问题很好的例子。在分析问题和需求的过程中，同样采用面向对象的思维方式去求解，会获得一个非常满意的需求报告。
５. 问题和需求分类分主次考虑
１）软件产品的性能指标：可靠、功能全、速度、易扩展。
易扩展：一种是产品升级换代快、系列化产品丰富。另一种是用户的二次开发扩展产品的再生功能。
速度：表示软件执行速度不仅要快，同时操作中的速度要均衡。
功能全：大而全不一定是不好，有能力和实力，最好做到功能尽量全。功能全直接体现软件开发商的实力。
可靠：这是最为重要的一点，软件首要考虑的应该是可靠。测试时，极限、异常操作都应该考虑进去。
２）问题和需求根据软件产品的性能指标和实现难度分类：核心需求，基本功能需求，高级功能需求、组合功能需求。
核心需求：直接影响速度、可靠、易扩展指标的好坏。比如：ＣＡＤ刷屏要求速度、ＣＡＤ命令行机制提高了易扩展性能、ＣＡＤ内部数据结构的管理机制直接影响软件的可靠性。核心需求将定义出软件的本质内容，它主要以程序设计原理为基础，结合软件任务需求定义数据结构和管理机制。核心需求是首先要确定下来的，是最主要的工作。
基本功能需求：完成任务的最基本的操作功能集合，这些基本功能是软件产品的底层处理功能，是众多问题和需求中抽象出的共性部分，它是其他功能的基础。基本功能需求也是非常重要的，它的好坏直接影响到后面高级功能的质量和能力。
高级功能：是众多问题和需求中的特性部分，这些功能对某个应用是非常有用，但在另一个应用中可能没有用。比如：ＣＡＤ中的图形计算：求面积或体积，在建筑施工图设计中没有使用，但在计算路基方面则非常有用。高级功能的需求应该放在较次要的位置，
组合功能：通过基本功能和高级功能组合操作后的功能。例如：ＣＡＤ中的ＬＩＳＰ语言，ＣＡＤ的批命令输入，ＣＡＤ的图块功能等。这些借助于基本功能和高级功能的组合功能是一种后期行为，没有这些功能，软件一样可以使用，所以，这些需求开发并不需要急于实现，但一定要在核心中考虑组合机制。
总之，需求分析是导致软件产品好坏的关键工作，导致软件开发难易程度大小的绝对因数。宁可将需求分析的时间给充足一些，也不愿以后在编程阶段补充修改需求（虽然修改需求是不可避免的事实）。
六、如何做好项目软件的分析
2005-04-20, 09.19, sachina | 1408 x 阅读
相红利（转载自中国系统分析员）
2003年02月01日
[摘要]
本文结合自己的经验，从实践的角度，对项目软件的分析工作从7个方面进行了阐述，并指出一些容易失误的做法。希望能对从事分析工作的同仁有所参考。
软件从使用范围的角度，可分为项目软件和产品软件。
项目软件：即针对特定某个客户的要求，并仅为其使用的软件。又称工程软件，特点是有明确的合同，严格的工期，约定的维护期等。如"XXX 公司XXX 系统" 。
产品软件：即针对某一领域客户的共有需求而开发的软件。特点是通用、功能丰富而冗余，通过一次性的购买行为获得等。如操作系统软件、数据库软件、CAD 软件等。
本文就项目软件的需求分析，结合自身的体会，提出一些看法和建议。
1、 依据分析阶段确定合适的客户方配合人员
这一点对于获取真正的用户要求非常重要。通常，客户方会组织专工以上层次的人或在单位小有名气的计算机能手来和开发方分析人员配合，共同整理需求。
应该对客户方配合人员进行分类，层次化，使之和分析的各阶段相对应。
分析的初期，即总体分析阶段，需要得到整体意义上的轮廓需求，此时，应与客户方总工以上层次的人员进行交流，这一层次的人，对未来的系统会有完整的描绘，可以划分出子系统，及其之间的关系，这也是高级管理层对系统的期望。可以以此作为纲领性的文档指导进一步的分析，并约束后续的分析过程，
避免需求范围漫无边际的扩大；
专业系统分析阶段，通常，客户单位都会有专业分工，彼此之间既相互独立，又会在某些点上发生联系。此阶段应与客户方专工层次的人员进行深入的讨论。这一层次的人，对自己的专业相当熟悉，对专业内的需求会非常到位，大都年富力强，有相当的阅历和理解能力，甚至自己都可以绘制业务流图，总结业务功能点。对他们应充分鼓励，尽量调动其积极性；
系统关联分析阶段，在各专业系统得到充分分析的基础上，紧接着就要理清它们之间的关系，这是提升需求档次的关键阶段，也是高级领导层和专工都关心的阶段。通常，客户单位都会有一些零散的软件，如财务软件，部颁软件等，这些专业软件都发挥着重要的作用，但都是些信息孤岛，客户会很自然的希望能把这些信息融合到整个系统中来，为更多的人所共享。同时，也希望数据能够在各专业系统间顺畅的流动，从而减少重复劳动，提高工作效率。此阶段应把总工层和专工层召集到一起，共同理清系统间的接口。
经过这三个阶段，对需求的描述将比较准确和完整。
2、 多方位描述同一需求
有一些需求贯穿了从基层人员到高层领导，对此需求应该从各个角度、各个方位给以描述，总结之后才能得到完整的表达，否则可能会漏掉一些信息。这也为后续的设计工作打好了基础。
比如，在设备管理类软件中，有一个概念叫" 缺陷" ，指由于材料老化或外力作用，使得设备处于不正常的运行状态，但还没有到立刻就酿成" 事故" 的程度，但如不及时检修，就可能出事。对于设备缺陷业务，就涉及到从班组人员到领导，上上下下对此都非常关心，但各层次的人关心的侧重点却不尽相同：领导关心" 消缺率" （即缺陷消除率）、" 消缺及时率" ；专工关心缺陷类型和处理方法；班组人员关心消缺工作的人员安排及时间地点。缺陷的业务处理流程依赖于" 设备缺陷单" （用于记录缺陷及消除情况），如果仅仅局限于从由基层得到的设备缺陷单上的数据结构（设备名称、缺陷发现人、发现时间、二级单位确认时间、缺陷性质、安排消缺时间、消缺人员、消除日期、处理方法），无法满足专工层的分析要求：对设备的缺陷情况按类型、零部件、型号、生产厂家等分类统计，为设备采购时作为选型参考、调整设备及其零部件的检修周期以减少缺陷发生的频率等，因此需要在原来的设备缺陷单上增加一些相关信息。
3、 清晰化每一数据项
由于需求将作为设计的基础，弄清所有的数据项的来龙去脉对于设计是必不可少的。不能有模糊不清的地方，同时通过对数据项来源的分析，可以让分析人员更清楚的看到数据的流动情况，也会发现一些新的需求点。
4、 充分挖掘潜在需求
由于分析人员对软件技术非常熟悉，一些由于技术所带来的潜在需求对于客户来说，一般很难被发现。不实现这些需求，对整个系统也没什么实质性的影响；实现这些需求，则会锦上添花。
对这些潜在需求，会有两种处理方式：告诉客户，客户会得到启发，可能进一步提出新的需求，会有一些更大胆的想法，从而扩大了需求范围，增加了工作量，甚至会影响到工期；不告诉客户，等客户想到了再说。
这些需求如果对于产品软件，可能会是一个卖点，要尽可能的去挖掘。但对项目软件，考虑各种风险，有时候可能会回避，或对客户隐瞒。
我觉得，不管是否告诉客户，分析人员还是应该去挖掘，最起码可以作为自己的知识积累。
5、 采用科学的分析报告模板
分析完成后，需要形成《需求分析报告》，应采用规范科学的报告模板，通过ISO 或CMM 的企业，其模板大都非常详尽，不仅仅作为报告模板，还可以指导分析过程。
比如，我所在的企业除了有规范的需求分析报告编写指南、报告模板，还有" 需求分析矩阵" 和" 需求变更报告" 用于管理需求和控制变更。
6、 积累领域知识
领域知识对于分析人员很重要，这些知识的广度和深度影响分析结果的准确性和分析进度。分析人员应该通过各种途径去获取这些，不断积累，并进行比较和总结。
7、 抱着学习与指导并存的态度
面对一个新的客户时，分析人员首先必须抱着谦逊的学习的态度，把这看成是丰富领域知识的机会。但并非客户单位的任何层次的人都有值得学习的东西，随着分析人员接触的领域客户不断增多，分析人员对该领域的理解也会越来越深，逐渐会成长为领域专家，会有很多地方超过客户对领域的理解，此时，要以自己的深入理解去指导客户，说服客户，甚至纠正客户的一些错误的认识，得到客户的信任与尊敬，这对迅速顺利的完成需求分析会很有帮助。
8、 误区
在进行需求分析的时候，容易陷入一些误区，导致分析结果不理想。
分析结果越复杂越好
这是技术型分析人员经常碰到的情况，认为分析出错综复杂的关系，花哨的图表才能显示出分析水平高，其实，分析经常要经历" 简单-复杂-简单" 的过程，前一个简单表现为分析人员" 认为简单" ；随着分析的深入，原以为简单的问题会越来越复杂；最后，经过概括、消化、分解，使得需求简单明了。
必须一次到位
由于项目工期紧，或者客户单位地理位置偏远，不想反复去现场，希望通过一次需求分析就能得到完整的不再改变的结果。有这种情况时，表现为分析人员对客户方配合人员穷追猛问，或坚持要求配合人员做出保证，承诺需求范围不再扩大等等。结果往往是双方关系紧张，配合人员怕担责任，提出过多的灵活的、可配置的一些要求，无端增加了后续设计和编码的工作量。一次到位的想法是不现实的，随着开发工作的进行，用户经常会提出以前没想到的需求，或者更改已有的需求。需求必然有一个迭代的过程，变是不可避免的，关键是对于变化的控制，比如通过正规而繁复的流程提高需求变化时客户付出的代价：告知客户如此变化将会使工期延长，或需要追加资金等等，尽管对于" 软件属于买方市场" 的现状来说，开发方往往叫不起这个板，但这样的控制还是有一定的效果的。
客户的需求必须全部满足
陷入这一误区的分析人员，往往自己的领域知识欠缺，对客户的需求是否合理，缺乏分辨能力，只能由客户牵者走，这样会带来很大的风险：造成需求冗余，项目返工，更有对需求变化失去控制的危险，随着项目的开展，整个开发团队会越来越痛苦。所以必须加深自己的领域知识，变被动接受为主动引导，进而拒绝客户的不合理需求。
以上所述仅为个人体会，都是些做分析时的基本要求，要做好需求分析工作，还有赖于其他很多因素，如分析方法及辅助分析工具的掌握程度、个人交际能力的高低、语言沟通能力的高低等等，欢迎同行广泛交流，共同进步。
系统分析方法
一、系统分析员基本功
2006-08-22, 15.43, sachina | 1957 x 阅读
好的系统分析员都是从优秀的程序员中产生的，坚实的编程功底、丰富的经验是今后做系统分析的基础。
没有对系统本身进行过透彻剖析过，很难领会到其中一些难以言述的精华。但并不等于好的程序员就能够成为好的系统分析员。
合理的知识结构。语言能力、文字表达能力、技术的全面性等是对系统分析员的基本要求。比如说c/s 和3 层开发，如果仅仅对netscape 公司的产品熟悉还不够，还需要了解比如微软等产品，并且要了解他们中产生历史，发展思路，技术优劣，以应付各种穷追猛打的提问。但更重要的是，这是你为应用定制技术要求的前提。
系统分析员思想
1. 全局观念是系统分析员必须具备的观念。
如果系统分析员设计时太注重细节，往往会陷入在某个问题上纠缠不清的泥潭。（93年，我论文指导老师的一席话影响了我随后几年对软件开发的理解——今后计算机会越来越快，多写几行代码少写代码无关紧要，最重要的是整体；一开始就错了，某个部份编得再好，也是没有用的） 系统分析员要有面向用户的思想。系统分析员应当有能力将自己扮演成用户，来了解要交付的项目看起来想什么样式，感觉想什么，从而了解用户的想法并挑选出合理部份去开发。从这个意义上说，系统分析员才能获得有意义的见解去引导他的开发组成员。系统分析员头脑中要对项目结局有一个清楚的认识，并保证项目不偏离方向。系统分析员要有根植于技术，高于技术思考问题的
思想。纯粹的程序员通常对最终结果考虑的不是很多，当一种新的技术在市场上出现时，他们对能否按时交付的考虑就比较少，而强烈希望他们的计划能够建立在新的技术之上。因此，系统分析员的想法和行动要象一个用户，又要能够站在技术的高度，成为真正的用户、程序员之间的代言人。
2. 任务难度的预测能力
系统分析员要具备快速的任务难度预测能力以及具备快速确定开发小组人员构成和任务划分的能力。（我将这条归为思想，而不是能力）昆虫自然会长出翅膀，而思想却需要长期的浸润。要做到这点，需要大量的思考、学习。设计远比编程重要。当今软件业的发展，各种开发工具的出现，编程已经不是什么问题，程序员的工作某种程度上讲是将别人现成的东西拼凑堆砌起来。系统分析员要清楚的认识到，现在大多数程序员没有学会怎么去整体的了解一个系统，有些甚至不了解编程（这不是说他们不会写代码）。可视化的开发工具加五花八门的控件，程序员可以偷点懒了。（这可不是夸大，我好几年的管理工作，接触过大量的程序员）基于技术，跳出框架。基于现有技术结合用户需求思考问题，设计时跳出
框架。
3. 系统分析员的关键
获得信任。系统分析员最重要的素质是获得信任，这是成为优秀系统分析员的关键。成熟最为关键。成熟可以为整个项目组提供正确的支持，能够理解技术怎样才能解决用户的需求。
系统分析员的准备工作
统一的各种文档模式，这其中包括今后软件变量、字段命名规则。我推荐用pb 制定的规则做基础，通过改造成为适合自身实用的标准。统一的文档管理。统一的分析软件。比如说rose （uml 太规范，国内的软件管理水平根本用不上，只不过尽量应用，你自己对系统分析的理解有好处）方法是思想的放映，在具体方法上就不多说了。我托人从u$a 弄到几本书，用于面向对象系统开发的使用》、《面向对象的分析》、《项目管理》等都是很不错的，推荐大家看看。
我在拙作" 在中国没有人懂计算机" 里发了点牢骚，听说挨了部份人（习惯性的）骂。其实，bbs 本来就是发泄的地方，在这里从来就罕有有内容的文章。
自从" 维纳斯" 登陆深圳后，大家更着眼于从宏观看中国的it 业了。中国it 这棵小树，说实在的，长到今天实在是不容易。一些人提出了" 反对微软霸权" 的口号，不少人呼唤中国" 硅谷" 的出现。微软的成功不是技术的成功，更多的是商业运作的成功。中国it 这棵树能长多高，取决于他所植根于的土壤。而现在
的事实是，这片土壤实在是太贫瘠了！如果按我们现在的思路和搞法，是长不成大树，更别指望能结？quot ；微软" ，" 硅谷" 这样丰硕的果实。如果说，我们的软件技术落后美国十年，我们的硬件制造技术则落后美国二十年，我们的管理水平落后美国至少三十年。而最终决定发展速率的恰恰是我们的死穴──低劣的管理水平。低劣的管理水平的形成的原因有着深厚的背景和多方面的原因。
系统分析工作是解决一个问题的工作，目标是将一个对计算机应用系统的需求转化成实际的物理实现，其中复杂就复杂在实际的面太多。在系统分析过程之中注意问以下的问题，可能会所进行的系统分析设计工作有帮助
1 ）您所完成的系统目的是什么？注意不是功能要求，而是目的。也就是为什么要建设、为什么要现代建设。在考虑系统目的时，我更多的侧重于系统的最终目标考虑，因为一个系统不可能一下子完美，为系统留些余地。
2 ）您所完成的系统有哪些方面参与，各方面的初衷是什么？那些人可能在系统建设中起重要作用，他们会采取什么样的态度？你对他们有多少影响力？中国it 行业的失败之一就是人" 太年轻" ，一定要有领导的支持，否则完蛋。不要认为自己对他们会有多少影响力，即便有，也要尽可能的认为是决策者再影响他们。在中国，一个技术员，你算老几？说到这里我很悲哀。哪些人在系统中起重要作用并弄清楚他们的态度，这点十分关键。
3 ）您的系统是否有一个明确的评价标准？最好从参与的各方面都进行考虑。
不知道这样说对不对，在系统建设之前，对你的程序员、对你的领导要有至少不同的两种评价。
4 ）你的系统设计思想是什么？是否能够得到各方面的认可。如果高明，对领导、对程序员都采用引导，
得到认可的最好办法，就是让他们认可他们自己的想法。（我力图这样做，但做得不好，系统分析员有一点要学会韬光养晦，忍）
5 ）你对参与系统设计开发的人员了解吗？他们的特长在哪里，是否愿意与你合作，为什么？你对他们有足够的影响力吗？软件发展到一定的程度，不是编程，不是数学，而是管理。
6 ）你的系统开发计划是否完善？你的计划表有明确的阶段吗？任何一阶段都应该怎样完成？如何对这一阶段完成的情况进行评价？
7 ）你对所采用的系统开发方法以及工具是否熟悉？你的夥伴是否熟悉？事实上，不是每种好的工具都要使用，也并不一定都要他们熟练掌握。提醒诸位一句，当你将方案做得可以不依赖某个程序员，你在程序员面前就无信任可言，因为从此程序员将受到更大的生存压力。我坚决不在公司使用rose.
8 ）你所完成的系统是否有原型？计算机的或者物理的。
系统分析员基本功
以上的几个问题都是在系统分析以及系统规划时涉及到的，供各位参考。
这文章很好，我的话是：" 需求分析实际应该是问题分析". 含义是系统要解决的是问题。而不是用户提出的需求。经常发现系统完成后，客户说" 我的问题还没有解决". 可是，需求分析稿上的目标都搞定了。
既然是问题分析，所以，熟悉目标系统的知识就是必要的。甚至，可以说，一个好的系统分析员也应该是好的业务专家。
我很高兴在这里遇到许多分析高手，可以交流分析中的问题。我赞同从来的观点。在中国作分析重要的是人气，因为中国的企业级信息系统的建设在很大程度上可以说并非确有需求，而是迫于某种压力。用户在很多时候考虑的不是系统的长远发展，而只是短期的成果，要求开发单位在很短的时间内完成一个很大的系统的开发，没有时间对系统进行周密的分析，在这种情况下，很多开发商就会粗分析，粗设计，尽快进入编码阶段，这样的系统的生命周期肯定不会很长。说了这么多，只是想说，系统分析员确实应是业务和管理专家，并且需要有很好的语言组织能力，他需要根据问题域中存在的问题去尽力说服用户，引导用户需求，毕竟，我们是专家，如果让用户牵着鼻子走，系统不会是成功的系统。（当然了，这要建立在用户是可引导的前提下）本人拙见。
在理解和分析用户的需求时，应说服用户明白：建立计算机应用系统并不是简单地用计算机代替手工劳作，它更应该是管理思想的一次革命，是现用户模式的一次升华和提高。如果系统不能高于现实，开发的系统将长期陷入需求的反复修改，其软件的生命周期也短了。
二、如何进行系统分析
2005-04-20, 08.56, sachina | 2994 x 阅读
出处：www.microsharp.cn
作者：一箭无邪
摘要：
教学目的，如何进行系统分析
正文：
一、什么是系统分析
在具体的研究需求分析之前，我们先了解一下软件工程这个概念。软件工程分为三个层次，过程层、方法层、工具层。在最基础的过程层，最重要的就是一组被称为关键过程区域（KPAs ）的框架（KPA 的概念在讨论CMM 的书中有详细的概念说明）。关键过程区域构成了软件项目的管理控制的基础，并且确立了上下文各区域的关系，其中规定了技术方法的采用、工程产品的，模型、文档、数据、报告、表格等，等的产生、里程碑的建立、质量的保证及变化的适当管理。方法层主要是过程在技术上的实现。它解决的问题是如何做。软件工程方法涵盖了一系列的任务：需求分析、设计、编程、测试、维护。同时他还包括了一组基本原则，控制了每一个的关键过程区域。工具层就很好理解了，他对过程层和方法层提供了自动和半自动的支持。这些辅助工具就称为CASE 。事实上需求分析是跨越了软件工程的三个层次的。这一点是和其他的过程是一样的。
可以看到需求分析的位置，它是我们软件开发的第一步。是对用户需求的定义，对软件系统的描述。系统分析的任务：将用户的业务逻辑转化为程序逻辑，计算时间和成本。根据开发人员的理论知识和实际的经验，人们会采用各种满足实际情况的系统分析、开发方法、步骤以及文档等等。一般情况下，在系统分析书中应该有以下内容（视项目而定）：
1、 系统需求说明 说明系统是一个什么样的系统，用市场上现有的系统来类比， 用客户（或是我们自己）需要一个什么样的系统进行说明，力求完整。并对系统的发展、可扩充性进行描述（现在没有哪个系统是一次OK 的）。说明与现有的系统有什么相同什么不同，说明未来系统的发展方面以及可移值性等能预见的事情。
2、 系统资源说明 对系统所需要的软件、硬件资源进行说明。描述系统所需要的 所有的TCO 成本。包括人员、时间、设备、系统、一次性投入资金、持续性投入资金这样 的所有资源。
3、 系统可行性分析 对系统的实施中的资源进行分析，说明投入的合理性和必然性，对其中的所有不可预见性的投入进行合理的量化说明，来说明系统的实施的可行性 。
二、系统分析员与程序员
大家应该对这两个词很熟悉了, 但是对词里包含的意义可能并不是特别清楚。首先必须说明的是, 程序员和系统分析员不存在谁高级谁低级的分别，他们是两种职业，对职业
技能的要求完全不同。所以厉害的程序员就是系统分析员的说法是不对的。当然，系统分析员的技能要求他必须要懂得如何写程序，但是他的重心在于如何把一个很大的项目切割成适合个人的小块，然后将这些小块组织起来。程序员的职责就是如何更好更快的实现这些小块。
三、系统分析的方法和工具
UML 全称：Unified Modeling Language，统一建模语言，是面向对象的建模语言，主要用于软件系统的面向对象建模。
UML 是以面向对象图的方式来描述任何类型的系统，具有很广泛的应用领域。特别是在建立软件系统模型中，它支持从系统需求、系统分析到系统设计的整个建模过程。由于UML 建模是一门专门的科学，而我们这门课程的任务是数据库系统开发，所以对于UML 我们将有限的注意力集中在认识UML 各种图示上。
可以使用Rational Rose 2003来建立UML 模型
1） 建立角色
2） 创建用例
3） 创建角色用例关系图
4） 创建时序图
5） 创建协作图
四、QQ 文本图形留言器系统分析的实现举例
1）需求分析总体图
2）各模块细分分析图
显示模块需求分析图
查询模块需求分析图
添加数据模块需求分析图
安全设置模块分析图
系统设置模块分析图
3）基本功能模块流程图(举例)
在这样的分析基础上，再进行编程，我们就可以有规律可依，做到有条不紊了。
三、Use Story方法
2005-04-20, 09.00, sachina | 1338 x 阅读
胡乱说说，里面肯定存在着不少的错误，还请高手指正。
Use Stories就是系统要实现的功能。它表述起来非常的简单，一个Use Stories只需要几句话就可以写完。之所以这样是因为用户需求的细节是非常易变的，而其高层描述却是相对稳定的。所以我们可以通过使用Use Stories的方法来从高层确定需要开发的内容，这些单纯的Use Story相当于系统中可能的点，而由我们通过与用户交流所得到的所有Use Stories则构成了一个面，它就是整个系统所需要实现的功能。
深入思考上面这段话的含义就会发现Use Stories在整个项目的初始分析阶段起的作用只是一个占位附。他告诉我们这样功能在实作的时候应该要实现，但是具体需要实现什么，怎么实现则是在迭代过程中的分析阶段所需要的事情。所以在写Use Stories的时候请切记，一定要简单概括，不可明确描述实现细节方面的问题。
说到这里就不能不说一下Use Story与Use Case的关系，我个人认为Use Story是一个更高层的分析阶段，它的抽象层次非常的高，如前面所说，它是一个占位符，而在具体对一个Use Story进行分析的时候则可以使用Use Case分析技术，将一个Use Story分解成为若干个Use Case。当然上面这段描述的前提是需要开发的系统足够的大Use Story对相对较大，一个Use Story可以折分一系列Use Case。但是如果项目的规则相对较小，那么可以直接使用Use Case来取代Use Story，这个在开发的时候需要灵活的掌握，不可死板追求到底用Use Story还是Use Case。
Use Story中除了包含对功能的简单描述之外，还可以酌情加入对异常情况的描述。虽然在具体分析一个Use Story 的时候还需要将其异常情况进行详细的列出，但是在撰写Use Story的时候还是有必要的尽可能的将它们列出，其原因在于，对异常情况的描述可以帮助我们发现一些在正常情况下无法体现出来的Use Story之间的关系。这对我们撰写Use Story的描述部分是有一定的帮助的，另外也可以在这个初始阶段提出一些问题，然后等待进入具体迭代的分析阶段时再进行解答。
Use Story内的描述只是开发者系统的一个最初步认识，所以以后开发者在实际开发时参考这些Use Story时一定要持着一种怀疑态度，再重复一次Use Story只是对高层系统一部分的抽象度非常高的描述。用户在具体开发的时候应该维护一份Use Story列表，如果在实际开发一个Use Story（或者这个Use Story所对应的某一个Use Case）的时候，遇到了对其它Use Story有影响的问题应该在这份Use Story列表当中标出。以便我们在这些受影响功能进行分析的时候可以尽量多的认识到这些影响它的问题。
用户在对Use Stories进行优先级的排序后，这个顺序虽然不是在未来完成整个系统的过程中实现Use Story的顺序（因为需求是易变的），然而一般情况下这个Use Stories的优先级排序，却决定了第一次 迭代的开发内容。优先级高的Use Story应该先完成，这是直面风险的一种方式，按照XP 的描述来看， 用户认为优先级越高的Use Story所存在商业价值就越大，当然其风险和不确定性也就越大，所以我们应该先实现它。 在用户确定了第一次迭代过程中所需要开发的Use Stories后，那么我们就可以将这些Use Stories分解成相应的任务了，注意，用户虽然为第一次迭代选择了相应的Use Sotries，但是这些Use Stories却未必会在第一次迭代当中完成，因为正如前面所说Use Stories的作用只是一个占位符，我们通过Use Stories所了解的
系统功能只是极为抽象的内容，单凭这些内容我们是无法估算出完成一个认识所需要的具体时间的，所以在决定开发一个Use Story的时候需要对这个Use Story进行进一步的分析，将这个Use Story拆解成若干个任务。折解的目的是Use Story所被折解成的任务将都是可以进行开发时间评估的（大小基本可知），只有这样的任务开发人员实际工作起来才会感觉到心里有数，一个Use Story所表示的抽象范围比较广，可以先将这个Use Story折解成若干个Use Case或者更小的Use Story（再强调一次，Use Case要比Use Story的抽象极别低），然后再将具体的Use Case折解成具体可以进行评估的任务。而如果我们对一个任务无法进行评估的话，那么可能就说明我们任务还有细分的余地，我们可以将它拆解成更小的任务（当然这里有一种情况是由于团队内的开发人员都不清楚任务所涉及到的专业知识，所以造成无法对任务的工作时间进行评估，在这种情况下，可能就需要一个此领域的专家帮忙了，或者如果没有这样条件的话，那么开发团队在经过对这种专业知识的短时间学习后再对任务进行评估？，或者重新评估使用此技术所付出的代价是否可以在一定的成本范围之内）。
在对Use Story进行拆解的过程当中经常会遇到的一个问题就是可以从进一步的分析过程当中得到一些浅在的Use Story或者Use Case。可以将这些Use Story或者Use Case加入到列表，然后评估其是否有必要被加入到本次迭代，如果有的话，那么一并进行分析，如果没有的话，那么将其安排到其它的迭代中来完成。 在拆解任务的过程中，我们应该保持对核心问题的注意力，举个例子来说，比如说我们要处理一个发送信息到指定用户的Use Case，这个Use Case核心的问题就是将信息成功的发送到指定用户处，而在拆解这个Use Case的时候我们发现校验收件人用户是否有效的操作也是一个相对比较复杂且工作量比较大的工作，因为它涉及到与帐号系统的配合工作。在这个时候我们所采取的策略就应该是将用户校验操作视为完成整个发送信息过程操作当中的非核心步骤，不需要对这个问题太过纠缠。在分析的时候只需要把它当做一步操作，而在实做的时候也只需要定义一个用户校验的接口，然后使用Mock 对象的技术来满足发送邮件时对用户校验系统的需求即可。
另外在拆解任务的过程当中还应该注意的一点是，不应该让我们所能够承受的复杂度和负载度超标，比如说当我们发现从一个Use Story分解出来的Use Case复杂的足以让我们不能够一次对付他们的时候就应该明智的将对Use Story的分析改成对某一个或者某几个特定Use Case的分析。只有使用客中化整为零，各个击破的策略才能够使我们在面对大型软件的时候保持我们的控制力。
Archie 的评价 2004.10.07
虽然不能准确的对故事进行估算，但是还是要进行估算的，而且团队的速度也是用故事的度量单位来衡量，而不是任务。
要进行估算就要对故事进行比较详细的了解，要和客户进行大量的沟通，了解到什么程度呢？能进行估算了为止。
四、面向对象开发中的本质用例及其职责
2005-04-20, 09.04, sachina | 2041 x 阅读
出处：UMLChina
作者：Robert Biddle
Robert Biddle 著，zhangxxin 译
本质用例（Essential Use Cases）是一种轻量级的方法，它简单明了，不受技术约束，用于沟通用户意图和系统职责，能够有效地捕捉用户界面的设计需求。在设计过程中，使用本质用例从系统职责中提取的关键词汇可以直接作为对象来使用，具有显著的优点。本文描述如何使用本质用例直接驱动面向对象开发过程，并实现与用户界面进行并行开发的方法。 在面向对象软件开发的过程中，用例在捕获需求过程中得到了广泛应用，并受到业界标准建模语言UML 和建模过程RUP 的广泛支持。Constantine 和Lockwood 在《以使用为中心的设计》
（Usage-Centered Design）中写道：“本质用例为支持用户界面设计而编写，简单明了，不受技术约束”。在一般过程中，本质用例用来产生用户界面设计，设计完成以后，又分解成几个更具体的一般用例，其中包括更详尽的细节和进一步的界面设计。但是，采用这种方法在用户界面设计完成以后才能进行实质的面向对象开发工作，费时费力，难以取得良好的效果。
在本文中，我们讨论在面向对象的软件开发过程中尝试直接使用本质用例的方法。与一般用例类似，本质用例可以作为面向对象设计的起点，但是，使用本质用例的方法进行沟通更加简洁，且无需指定太多的设计细节，便于需求搜集。
在过去两年中，我们使用本质用例方法作为主要需求搜集工具做了好几个系统的开发。我们发现，本质用例方法非常适用于面向对象软件开发，并且比一般用例具有更加显著的优点。
有三个结果需要介绍：第一，与我们推测的一样，本质用例可以直接驱动面向对象设计；其它的两个是意料之外的结果：一是本质用例提供了从需求转换到面向对象设计的指导，再有，就是保证了本质用例和对象之间的可追溯性。进一步研究发现，因为本质用例反映了用例的基本需求，从而可以由此确定用例的模式，更有效地进行需求搜集。
在后文中，我们将详细描述该方法。
本文组织如下：首先介绍本质用例提出的过程，并与一般用例方法进行比较；在第三章中，介绍本质用例的提取方法，以及使用角色扮演的方法检验其正确性和一致性；第四章通过一小段例子介绍如何在设计面向对象系统时使用本质用例；第五章以应用为中心讨论在无人参与的系统中使用本质用例的方法、开发过程以及业务过程设计等主题；最后，在第六章，进行相关工作的讨论，并得出结论。
背景
1. 用例
Jacobson 在他1992年的著作中写道：“用例是与系统进行对话时行为相关的事务系列的描述。”在最近的RUP 中，对用例的描述没有实质性的改变，它认为用例是“一系列带变量的动作描述，系统由此对特定用户产生有价值的可见结果”。
从某种程度上说，利用用例思想描述系统与外界的交互过程是行之有效的。
在软件开发的早期，用例着眼于系统交互，有助于提取系统行为，从而捕捉系统需求，确定系统规范。用格式化的语言和图形对系统的交互过程进行描述比较容易，而且易于理解，所以，由此产生的用例技术非常有效，特别适用于在大范围内进行需求搜集和分析工作。
在后续的开发阶段中，用例描述系统的交互过程。而交互过程是系统规约的具体化。在设计和实现过程中，系统规约通过结构来体现。在复审和测试过程中，用例描述测试等系统行为。在设计、实现和复审过程中，它们由同一角色引出，因此，整个开发过程具有可追溯性。
用例建立在一系列交互的基础上，一般来说，一个期望的交互过程总伴随与其目标（或子目标）一致的结构，因此，采用用例可以对需求进行有效的划分，通过组合、过滤、设定优先次序等方式进行组织，协助管理整个开发过程。
关于用例的优点以及用例到底是什么的讨论一直没有停止过。其基本概念已经有所发展和变化，尤其对软件开发方面的支持，例如职责描述和本质用例。我们选择本质用例作为工作的重点。
2. 本质用例
本质用例是以使用为中心设计的一部分，由Larry Constantine和 Lucy Lockwood 提出。用例具有显著的优点，但也有其局限性：“特别是一般的测试用例，它包括太多难以说明的，甚至是隐含的内建假设，而且用户界面设计的内容也包括在内”，这导致很早就必须进行设计决策，因为其内容成为需求的一部分，难于变更来适应以后的变化。
本质用例克服了上述问题。术语“本质”来源于：本质模型是“通过与技术无关的、理想化的、简单明了的描述来捕捉问题的实质”。Constantine 和Lockwood 对“本质用例”的定义如下：
“本质用例是使用应用领域或用户语言描述的结构化叙述，由职责的描述或交互过程组成。是一种轻量级的方法，对职责的描述简明扼要、技术无关、可独立实现，从反映系统交互的根本意图和目的角色的用户视角出发来描述交互过程，具有完整、针对性强、定义明确的特点。
本质用例用一种格式化的文本来记录用户和系统的交流过程。这个文本与Wirfs-Brock 使用的两列表的格式类似。虽然在Wirfs-Brock 的格式中用“动作”和“响应”两列来讨论用例抽象的级别框架，但它也适用于用户和系统的交互。
在本质用例中相应地采用“用户意图”和“系统职责”作为两列的标识。这样，即便使用用户界面细节描述也能抽象地描述交互的过程。需要注意的是，这个抽象过程并非作为一个整体与用例相关，而是与用例的各个阶段相关。用这种方法得到的本质用例是一系列交互过程，而不是抽象的步骤。
Constantine 和Lockwood 的例子如图1和图2所示。图1采用一般用例，用“用户动作”和“系统响应”进行描述，图2采用本质用例，用“用户意图”和“系统职责”进行描述。可以看到，采用本质用例的描述更抽象，更易于适应具体实现的变化，它更简短而且易于理解。
Jacobson 使用用例支持面向对象的软件设计； Constantine 和Lockwood 提出了本质用例和更广泛的基本模型框架，以支持界面设计和开发。我们注意到除了面向对象的软件开发外，本质用例实际上是毫无用处的。换句话说，本质用例的优点只有在面向对象的软件开发领域才能得到体现。
自动取款系统的一般用例描述（Constantine 和Lockwood ）
用户动作 系统响应
插入卡 读取磁卡
提示输入PIN
输入PIN 校验PIN
显示交易菜单
按键 显示总额菜单
按键 提示总额
输入总额 显示总额
按键 退卡
取卡 吐钞
取钞
自动取款系统本质用例描述（Constantine 和Lockwood ）
用户意图 系统职责
身份识别 验证身份
提供选择
选择 吐钞
取钞
本质用例和需求
在设计过程中，CRC 技术可以在团队活动中提高对设计的理解和设计的有效性，而在用例分析和评估过程中却缺乏这样的技术。我们希望开发这样一种技术。本质用例有许多适应这种技术的特性，因此，我们开始在面向对象软件开发过程中使用本质用例。
与CRC 技术类似，该技术包括索引卡和角色扮演。经过大家讨论确定用例以后，给每个用例分配一张卡片，在顶部写上用例的名称。将卡片纵向分成两部分，左侧描述用户，右侧描述系统，如图3所示。然后，团队中每两人一组来研究人机对话过程，一个扮演用户，一个扮演系统，并记录对话的经过，把结果提交给用例的审查小组进行复审。
本质用例描述系统的人机对话过程，是角色扮演的脚本，可以通过一部分人扮演系统，一部分人扮演用户的方式来模拟系统的人机对话过程。与纯文本的描述不同，这个过程是可视化的，不易引起歧义。Wirfs-Brock 指出，用例可以看做用户和系统的“交谈”过程，有助于系统建模。另外，用例和角色扮演还可以帮助确定系统边界，划清系统内部和外部的界限。
我们在应用领域和学校的开发小组中展开进一步的工作，获得了使用的实际经验。我们发现，抽象的本质用例有很多好处，简短的卡片式描述可以加速分析过程，更多地考虑交互细节，无需早期就在系统交互的具体问题上纠缠不清，被系统的具体实现所困扰而花费大量时间，从而可以集中精力确定系统的本质用例。
本质用例的抽象过程实际上是指导角色扮演的过程，并不是一个真正可实现的对话过程。但是，开发早期的角色扮演实际上是轻量级的，不能判断能否实现。如果需要对抽象元素的具体例子加以明确，那么，把它作为一个可操作的本质用例，可以由此讨论产生一个具体的脚本，描述可能的实现细节。
1. 用例
本质用例的对话并不是指简单的用户动作，而是用户意图。
在角色扮演中，要从角色的视角考虑问题，深入理解其动机和类型，考虑其所处的环境，了解其背景。这样才能准确表现其意图。
从这个意义上说，角色扮演对团队其它成员和听众变得更加重要。对用户意图的充分考虑赋予角色扮演更丰富的内容。更重要的是，复审人员需要更深入详细地考虑用例，评估其一致性，验证是否提取对话中的所有元素。
除此之外，用例着眼于系统与外部世界的交互过程和使用细节。而在大多数系统的开发过程中，系统使用的不确定导致用例实现完全依靠理解能力和创造能力的发挥。本质用例通过对用户意图的理解来确认系统用途，但并不否认用途也可以基于对用户本身的理解进行提取。在这种方式下，用户意图成为用例设计的原动力。
在RUP 等软件开发过程中，用户界面原型包括对用户本身和用户需求的理解，因此很早就需要进行开发。采用本质用例方法，在理解用户意图的前提下，为用户建立一个清晰的流程设想，同样可以作为系统后期设计的输入。但是，这种方法是轻量级的，不需要产生具体的用户界面，可以支持更快速的开发过程。
2. 系统职责
在本质用例中，采用系统职责代替系统响应进行描述是因为系统职责包括了更多与用户意图相关的内容，并在系统后期设计中产生其它影响。
在角色扮演中，用户角色扮演特定的人，意图可以通过多种方式表达，而系统扮演的未知实体则很难进行发挥。但是必须达到验证、确认人机交互过程的目的。
要深入理解人机对话中的任何一个元素，都需要在目标基础上加以引申。因此，本质用例对用户的描述采纳用户意图而不是用户目的。用户意图中除了可以理解的内容外，有一部分我们可以适当地加以引申。
对系统的描述应增加一些针对内部的说明，用以指导下一步的设计。系统职责是描述系统需要做什么，而不是系统实现的细节。这与用户意图的产生动机略有不同，但有助于确定用例和角色扮演。引入用户意图是为了描述系统实现的目标，而引入系统职责是为了描述系统实现的责任。
在本质用例中，某些用户界面与大系统的开发有千丝万缕的联系。在使用本质用例开发用户界面的例子中，系统职责作为人机对话的参与者，主要关心提供给用户的信息内容。但是，在大系统中，系统职责必须包括更广泛的内容。例如，在图2所示的银行系统取款的本质用例中，清楚地描述了与用户界面相关的内容，却缺乏与银行财会业务相关内容的描述。
当然，一般用例也有这样的缺点。如果用例只用于描述系统和用户之间的对
话，必然难以准确地体现各系统（子系统）之间的联系，比如图1的用例也有这样的缺点。
从这个意义上说，着眼于系统职责的本质用例更加实用，因为它并不直接、简单地描述系统与用户的交流过程。在图4的本质用例中，我们补充了对系统职责的描述，虽然这些描述不会在具体的对话过程中体现，但是交流过程的完整性和场景的一致性能够指导系统的开发。
补充后的自动取款系统的本质用例描述
用户意图 系统职责
身份识别 验证身份
启动交易服务
提供选择
选择 吐钞
结余
取钞; 终止交易服务
本质用例及其设计
面向对象的设计中，“职责”扮演了非常重要的角色，确切地说，它不仅是CRC 技术的关键概念，同样也是职责驱动设计中的关键概念。
在CRC 技术中，职责与对象相关联，标识需要解决的问题。在完成职责的过程中，互相协作的对象之间彼此通信，通过不断的优化、迭代，形成一个满意的结构。这样，将职责分配到类，并进行细化，作为一种工具，指导实际系统的开发。
在职责驱动的设计中，职责的内容更广泛更完整。与职责相关联的对象不仅描述了对象维护的知识，还需要描述对象需要完成的动作。在这个意义上，职责强调的是对行为的抽象，而不是具体可能的执行结构的提取。但是，对象可以通过协作对象之间的消息传递完成职责，也可以由此产生更高层次的抽象类。总的来说，在这种设计方法中，职责是在较高层次上进行抽象的分配，而不考虑对象执行的细节。
在CRC 技术和职责驱动的设计中，关于职责的概念和使用方法看起来非常
类似。它们都认为每一个对象都有一组明确的职责，都包括了进行职责分配，指导设计决策的概念。其实，两者之间本来就有一定的继承关系。面向对象设计的基本原理就是：对象是行为和数据的统一体。职责观点沿袭了这一说法，“职责”本身就包括了职责的内容和可以使用的资源。职责还允许进行授权和管理，通过对一系列子职责的调度和管理完成职责，包括了抽象和封装的概念，正象
Wrifs-Brock 等人解释的那样：“职责驱动强调对结构和对象行为的封装，关注类所完成的职责，而到实现阶段再考虑类实现的具体细节。”
本质用例的职责描述系统要做什么，而不是做的具体细节。这与对象封装的观点类似，同样也具有类似的优点。
用例中的职责与设计中的职责一样，都描述行为本身，而不是执行的细节，这就可以将需求和设计连结成一个整体来进行描述。
1. 确定系统边界
在实际工作中，需求主要是区分系统做什么不做什么。然而，这个边界非常难以确定，也非常难以与涉及的所有人（包括分析员和投资方等）进行沟通，达成共识。我们发现设计中使用的逼近技术非常适用于这种情况。我们把系统当成一个有明显边界的“黑盒子”，用本质用例的系统职责对系统的行为进行描述。
我们把系统看成由一系列职责组成尚未考虑执行细节的独立系统对象。Jacobson 等人在不同的方向上提出过类似的观点。采用本质用例、系统职责有助于确定系统边界。如果系统类似一个独立对象，那么用例就采用类似的方法描述，只能从系统的内部访问系统的行为，而交互的过程就类似于一系列能有序管理的参数和返回值。
在UML 和RUP 中，通用的用例图可以把这些想法固化下来，如图5所示，在图中，我们增加了一个方框，将用户意图和系统职责分离开来，从而明确了系统边界。
银行取款系统的用例表示样例
Jacobson 认可这种用法，UML 同样认可这种用法，它指出：“用例可以用一个随意封闭的矩形代表系统的边界或分界”。这种用法与系统对象的提法非常一致，便于讨论和确定系统边界。
2. 用例的职责和设计
对任何系统来说，本质用例的职责与系统对象内部的职责联系紧密。本质用例的职责反映了整个系统的行为，对象的职责协同工作也应该反映相同的行为。
这种方法将系统的需求和设计联系起来。本质用例的职责可以作为系统设计的起点，指导系统的行为设计，保证设计和用例的可追溯性。
从一系列本质用例开始设计，引出系统对象，通常通过一系列对象的协作完成职责。另外，在设计中，两者可以通过采用相同语言的方法巩固其一致性。
首先，尽可能采用一致的语言，对一系列描述系统对象职责的本质用例进行设计，然后再确定完成相同职责的协作类。
在严格的设计过程中，将根据上面的结果产生具体的类。这个过程是一个重新分配职责的过程，将直接影响最终设计方案的确定，要求非常细致。这个阶段的工作属于设计的基本流程，不可省略。需要一定的设计技巧和技术进行职责再分解。现在有一些成熟的技术可以直接使用，例如，在设计早期就可以使用类析取（Extract Class）技术。
但是，我们不提倡这种做法，主要有三个原因：其一，没用利用任何领域模型，使领域模型和设计脱节，造成理解和维护的困难；其二，一个完整系统有很多用例和职责，难以严格地分解；其三，难以兼顾其它地方产生的设计结构。
在CRC 和职责驱动的设计中，基于基本模型和应用领域模型，产生一组关键对象和类，根据领域知识和设计要求进行初步职责分配，然后着眼于少量的关键用例进行交互和迭代，产生初步设计方案。
在CRC 和职责驱动的设计中，本质用例没有引起任何流程的改变，但是，它扮演了使用快速原型法进行开发过程中非常有用的角色，为检验设计与需求的一致性提供了有效的方法。
这种方法要从设计初期抓起，从早期用例的职责分配抓起。换句话说，初始的设计职责应该从领域知识中产生。这样，可以与本质用例进行比较，得到早期的反馈，避免以后产生歧义。这样可以更好地指导关键职责设计者的开发工作。
设计一般都会有结果，有许多设计方案可以在新的设计中作为一部分进行继承和重用，例如组件、组件库、框架、设计模式等等，有的甚至本身已经是可执行的，它们对系统设计影响很大。而本质用例则提供最终设计与需求是否一致的有效检验方法。
与CRC 和职责驱动的设计不同，其它设计方法与职责本身可以无关，因此，设计和需求的检验显得更加复杂，更加重要，需要对组件和其它结构进行仔细检
查。但是，对可执行重用资源的检查并不是对其执行的正确性进行验证，更多的是对其行为模式的认可，也可以说是对其适用性的认可。这样确实对提高重用度具有深远的意义。
用例和设计的职责划分明确以后，问题就迎刃而解了。无论是无意的还是设计活动中的折衷，设计的不完善性都可能存在。无论采用哪种方式，都需要提升设计。另一方面，设计又可以从某种程度上弥补需求的不足。例如，设计必须基于现有系统的处理活动，哪怕仅是需求中的片言只语，这时就可以重新考察用例，看能否有所改变，能否使用现成的设计资源。
综上所述，引入需求和设计职责的概念提高了两者之间的可追溯性，保证需求和设计的一致性。
3. 举例说明
在本节中，我们将通过一个小例子来描述我们的工作。为了说明问题，例子非常简单，但是所用的方法同样适用于更复杂的系统，可以用于顶层设计，也可以用于详细设计，并且也有可用的支撑工具。
这个例子是图书馆系统中的一小部分。领域模型由两个对象类组成：书籍和借阅者。分析的过程如图6所示。在顶层，我们只关注于两个本质用例：借书和还书。
通过对这两个本质用例的进一步分析，我们可以得到迭代1中产生的CRC 卡片。在这个步骤中，我们不一定能够分析得到所有的系统对象。例如，要知道可借阅的图书，就必须登记已借阅的图书，必须对作为协作对象的职责进行分配。
系统对象应该明确，能够与用例对应，如果用例太多，产生的对象太大，就会难以执行。从领域模型出发，我们建立了三个类：单独的图书馆系统Library System 类、书籍Book 类（每本书一个实例）和借阅者Borrower 类（每个借阅者一个实例），然后考虑它们的职责分配。
迭代2显示了这个设计过程。在设计中，书籍借阅标志的设定在书籍Book 类中完成，但是，依然可以通过图书馆系统Library System类进行初始化、查询和更新操作。
图书馆系统Library System类还有一项职责，就是不但需要“知道有哪些图书”，而且还要能够查询。也就是说，图书馆系统Library System类必须对书籍Book 类进行管理，同时对借阅者Borrower 类也应有相应的管理功能。
在迭代3中，书籍Book 类和借阅者Borrower 类没有改变，增加了一个独立的分类Catalogue 类，完成“知道有哪些图书”的职责，可以用一个标准的collection 对象来实现。
需要说明的是，我们在这里基本上只列举在用例中明确描述的职责，实际上，在领域分析的过程中，还会分析产生一些职责，并且对整个过程发生影响。例如，检查书籍是否被借阅的职责就是通过类似领域分析的过程产生的。
如图所示，从需求中提取职责进行设计并不只是一个单向的过程，它可以进行调整和变化。但是，这个过程的描述非常有利于与投资方进行交流，特别是复审阶段的双方沟通。
讨论
在本章中，将讨论几个与本质用例相关的面向对象设计主题，包括：
· 无界面系统（实时系统）设计；
· 定制界面系统的设计；
· 迭代和增量开发过程；
· 界面和应用的并行开发；
· 基于业务过程的面向对象设计。
1. 无界面系统（实时系统）设计
在实时系统和软件引擎中，系统只与系统主角交互，并且没有传统的人机界面，那么，能否采用本质用例呢？答案是肯定的。本质用例同样适用于这类系统。
在这类系统中，有一个重要概念就是“外部世界（outside world）”。在任何系统中，都需要对系统的内部和外部进行明确的划分，从而确定系统的边界；确定系统交互的原则（无论是人还是机器）；设计交互方式。我们发现，在这样的系统中，本质用例同样有许多优点。在适当的抽象层次上，本质用例摆脱了表达和实现的具体细节的束缚，能够更准确的捕捉用户意图和系统职责的本质，它不受具体系统类型限制，简洁明了，易于理解，便于编辑，方便复审，可以实现分析和设计的无缝连接和平滑过渡。
系统常常有一些附加的非功能性约束，例如响应时间、交换速率、信息容量、可靠性等。因为用例着眼于交互的过程，所以不是发现和确定这类需求的理想工具。但是，它可以帮助记录和管理这类需求。在常规用例方法中，通常采用文字描述的方法，并与用例同步管理，且其管理过程与用例结构无关。本质用例也可以采用类似的方法。在以用为中心的设计中，这类指标往往与本质用例相关，因为它们对高性能的用户界面设计至关重要。
本质用例的系统职责、系统对象的职责以及中间对象的职责之间的可追溯性弥补了系统设计的不足，保证系统满足这类非功能性指标的要求。例如，用例级
的系统约束可以分解到对象中，对象的性能又直接影响到用例职责。采用公共任务标签的办法可以调整最终设计，确保满足非功能性指标要求。
2. 定制界面系统
本质用例同样适用于已经定义好界面的情形。在这种情况下，我们先对界面进行分析，然后描述交互过程的本质用例，并在此基础上进行面向对象的设计。这样，从系统交互和职责的本质着眼进行设计的中间系统更稳定，更能够适应界面细节的变化，同样具有本质用例方法的主要优点。
3. 设计业务流程
长期以来，常规用例被认为是业务流程建模的好方法，它主要描述的是业务单元（人）之间的交互，而不是计算机系统和人之间的交互过程。
本质用例与技术无关，它描述用例之中抽象的意图和任务，因此，无论采用何种界面技术，都可以实现用例。例如，采用相同的一个呼叫中心的用例，既可以支持用桌面应用的方法实现，也可以支持用Web 的方式实现。还可以支持采用交互的语音提示的方法实现。这就是说，本质用例与采用何种技术途径无关，需要的仅仅是最基本的计算支持。
使用本质用例的成功经验告诉我们：本质用例既适用于软件设计，也适用于业务流程设计，它们在抽象、对话和任务中具有相同的优点。
4. 开发过程
本节主要描述我们建立的软件设计模型，并为模型构建的过程提供参考。非常重要的是，从本质用例到系统对象，然后到面向对象的中间设计描述是开发的抽象过程，而不是构建模型的具体步骤，并不是类似于瀑布的过程，先对本质用例进行“分析”，接着确认其“完整性”和“正确性”，然后进行设计等等。
我们希望这个过程是一个增量的、可迭代的过程：先有一个备选用例表和一个初步的领域模型；其中的关键用例首先被细化，按用户意图和系统任务编写到用例卡片中；然后进行初步的设计，划分对象任务，并对用例的措词进一步细化和调整。再细化其它的用例，获得更多的对象模型，这些工作可根据后续工作中情况进行必要的复查和调整。
本质用例有助于软件开发的迭代过程，其抽象层次、用例与模型间的通用词汇决定了迭代开发的过程更易于跟踪，具有更好的一致性，对象和用例之间具有更良好的可追溯性。当设计完成时，所有的用例和对象都使用相同的词汇表，所有的系统任务被设计划分成适当的中间对象，所有的用例都可以被对象模型执行，能够更方便地检验设计和系统任务的一致性。
5. 并行开发
在以用为中心的设计中，使用本质用例同样可以产生用户界面。在这种情况下，基于本质用例采用面向对象设计方法进行中间设计具有更加显著的优点。它可以避免重复工作：它设计的用户界面可以直接在软件设计中重用，无须重新捕捉和进一步细化，使软件设计和界面设计可以同步进行，只要二者同时支持本质用例就可以保证良好的一致性。
这和其它的过程方法（特别是RUP 过程）略有不同，不需要在早期就完成界面设计，可以在软件设计阶段进行，支持软件设计和界面设计的同步进行，不会因为界面设计没有完成而延宕工期，可以有效地缩短项目周期，特别是在用户界面设计要求高、数量多的项目中，可以为整个项目节约好几个月的时间。
并行设计特别适合于Web 系统的开发，前端界面和后台服务软件可以独立设计，并有专门的技术支撑其实现。在这样的并行开发过程中，要求对迭代过程进行有效地管理，协调设计过程中用例的变更和实现，使二者保持良好的一致性和可追溯性。
与其它方法的比较
软件开发技术在不断地向前发展，也提出了许多其它的手段和方法。在此，我们着重介绍它们处理需求和设计之间关系的不同方法。
面向对象的软件工程（OOSE ）对建立对象模型中对象和用例之间的关系提出了许多有用的建议。Jacobson 等人用系统边界、控制和实体对象实现用例的方法来建立分析模型，但是在分配系统行为和产生类（class ）的过程，要求有一个附加的翻译过程。与这种方法相比，我们使用的本质用例方法具有更好的可操作性。
还有一些更简单和直接的方法来组织需求和进行面向对象设计。例如，在第二章中提到，Jacobson 等人介绍用例概念，以及Lockwood 提出在用例界面设计中使用本质用例方法就是基于这样的思想。还有许多指导用例写作及其在软件开发中具体应用的书籍。例如，Cockburn 最近就出版了一本详细介绍用例写作方法的书籍，并对各种风格的用例进行了介绍。Amour 和Miller 还讨论作了为需求搜集工作的一部分，如何发现和管理用例。但是，这些工作很少提及用例如何在分析和设计阶段的工作中反映，讨论用例和设计关系的工作在领域模型的开发中完成，把领域模型作为设计和开发的第一步。领域模型固然非常重要，但是，从需求到发现领域模型、领域模型满足需求之间还应该有大量的工作需要完成。
大量的文献都提到可追溯性的重要性。Pfleeger 指出，可追溯性包括横向和纵向的可追溯性。纵向的可追溯性是指开发过程中模型内部的关系，横向的可追溯性是指模型与模型之间的关系。加强系统的可追溯性可以有效地提高开发过程的质量和降低维护成本。
我们致力于需求与设计横向可追溯性的工作，将二者的关系直接反映到任务的分配中，成为设计工作的一部分。
任何软件开发方法都伴随相应的过程。最近经常提到的过程是Rational （瑞理公司）统一过程，即RUP 。RUP 是用例驱动的软件开发过程，用例连接开发过程的各个阶段。在我们使用的本质用例方法中，本质用例在开发过程中具有同等重要的地位，只是在用例格式的选择上有所差异。事实上，本质用例方法与RUP 方法中用例的描述没有任何矛盾，甚至可以认为本质用例是基于前文中指出的OOSE 方法中分析和设计工作流的细化。
还有一种开放式的软件开发过程，准确地说，它是一种软件开发方法的框架，而我们只关注其过程部分。特别值得关注的是它的开放式工具技术，为不同职责的软件开发需求提供完整的技术支持。它提供从原始需求到设计模型的技术，包括：协作分析技术、CRC 卡片建模技术、委托分析技术、领域分析技术、泛化和继承技术以及对象模型转换技术等。上述所有技术都可以和我们的研究联系起来，而我们的工作在指导操作和提供可追溯性方面做出了贡献。
最近，轻量级方法XP 等大行其道。基于XP 方法的设计要求功能需求尽量简化，在真正需要以前，不轻易增加别的功能。XP 是带有独立“用户故事”的增量开发过程（与用例类似但完全固化），通过再分解现存的程序实现用例，达到增量的目的。我们的方法与XP 的方法也有所类似，所有的设计都可以再生。但在XP 的方法中，当需要扩展支持新的用例时就需要重新设计，而在我们的方法中，设计从完整的系统目标出发，以实现整个系统为目的，所有的再分解都维持了对象的任务，都可以在中间组件之间重新进行分配。
结论
用例适用于各种软件的开发，本质用例起源于用户界面设计的细化和描述。我们尝试在面向对象的系统开发中使用本质用例，并在本文中进行了总结。
本质用例能够简单快速地发现需求，支持通过角色扮演进行沟通，有助于发现系统边界。它简明扼要，易于学习，避开了繁琐的实现细节，支持快速开发。使用这种方法易于确定用例模式。它还同时支持界面和系统设计，可以实现二者的并行开发。
本质用例标识系统任务，将需求和面向对象的设计联系起来。在设计中，其职责启发分配协作对象之间的抽象行为。使用本质用例描述需求，采用职责驱动的方法进行设计，可以更好地为设计提供指导，使设计和需求具有良好的可追溯性。
五、如何分析问题和需求
2005-04-20, 09.09, sachina | 2871 x 阅读
（梦郎个人观点）
万事开头难，需求没有完全分析清楚，系统设计很难满意。面对项目，我们如何提出问题，如何界定问题主次，哪些问题必须定义，哪些问题可暂时不理...... 。
一、提出问题
１. 树状遍历式寻找问题
每个问题都不是单一存在的，它都有相关问题，犹如一棵树一样，主问题就是主树杆，主问题伴随的其他问题，就是支树杆，以次类推。首先不要怕麻烦，每当一个问题提出，必须提出尽量多的相关新问题。提出问题的方法：顺藤摸瓜。
比如：写一个通用编辑器程序，此程序为自己或别人开发其他专业编辑器打下可靠稳定的基础。
１）问题：什么是通用编辑器。编辑器面向的对象应该是不确定的。
２）如果数据类型不确定，我们如何确定程序编写的对象。可以举出一些可能的假设。假设我们将此通用编辑器用作程序源代码编辑，那么就应该有中断、单步执行等设置，这导致数据不能封装在编辑器内部，应该由后期开发指定数据结构。
３）如果是程序编辑器，关键字的特显必不可少，所以显示的属性应该给出接口。
４）诸如关键字此类的是否还有其他需要特显的，那么，应该注意到特显类不仅仅是一种，程序设计时，最好抽象出特显的方法与数据结构（不管以后有多少不可预知的特显内容）。可以深入考虑特显接口应该如何给出，才能支持任意特显方式，它还需要哪些信息。
５）抽象特显类时，应该举出尽量多的可能性，综合考虑。
６）问题：哪些内容需要特显。编辑器很难知道，数据类应该自己了解。所以，特显内容的定义必须有一个机制让后期开发时使用。
７）问题：源代码编辑器有自动缩排、词法、语法分析，这些操作如何在编辑器中体现。考虑语法类接口。是否有收缩与展开操作，接口又如何。
８）又假设：后期要扩展成字处理程序。数据有文本、图象、特殊公式编辑、段落概念、表格等。
９）送进编辑器的数据可能是一组含有控制字的数据，问题：如何获得让编辑器知道不同数据的不同显示操作。编辑器肯定无法全知，所以，干脆交给后期开发需求处理。
１０）未知数据应该有：显示方法、光标定位处理等
１１）光标定位需要当前坐标，所以，必须有接口让编辑器知道数据宽高。
１２）综合结论：应该有一个接口机制。凡特殊操作的内容，交给后期处理，但通用编辑器应该做好数据管理和传送的工作，而这些工作，不管哪种编辑器都需要。
首先任其深入提问，虽然问题可能多得十分复杂或凌乱，但它对即将做的系统设计绝对有帮助，最好把每个问题都有一个清楚的了解，千万不要急于设计系统。通过这些提问和假设，就可清楚地分析我们所作的软件应该实现哪些内容，哪些内容实现有难度，实现这些内容的大体方法，通用编辑器能作什么。通过上列系列提问和解答，我们可以认为，通用编辑器仅仅是一个以行为基本编辑单位的编辑器摸板。编辑器不仅自己有编辑操作，同时允许外部提供特殊数据对象的编辑操作，最终实现文本编辑、图形编辑、表格编辑、公式编辑一体化。数据外部实现，将允许后期确定内容属性。
上述方法基本上确保了软件有好的可靠性、扩展能力、性能、重用性和系统化。想高效率生产系列软件，确实应该考虑的更多。
２. 直接切入目标问题
直接提出软件要完成的系列任务，通过考虑任务的实现，罗列问题，在问题的解答过程中反思任务的需求。这样的方法可以快速设计出软件开发方案。
仍然以通用编辑器为例：
１）编辑对象有：文本、图形、图象、表格等。
２）操作有：焦点移动、增加、删除、存取盘、选择块、粘贴拷贝、缩进、展开收缩、书签、中断设置、单步执行标记等。操作有分文本、图形图象、表格等的操作编辑。
３）显示：文本的不同字体风格显示、图形的显示、图象的显示、表格等的显示。
４）状态设置：改写插入、段落格式设置、标题控制、编辑器专业化的设置等
５）考虑各项功能的实现方案，发现问题。
６）如果有没有考虑到的，增加进去。
７）经过许多的方案设计，综合考虑和优化方案，提出最后的设计方案
８）综合结论：程序考虑了诸多功能，通用编辑器是众多功能的集合体，内部详细规划了各种类型数据的操作、显示和排版分析。
经过一系列的方案定义，将问题逐步减少，最后获得一个规模较大的系统设计早期方案。我们可以较早地进入系统设计，并且提前进入程序代码级开发工作，同时逐步实现各项内容。
此方法分析需求，有助于我们尽早实现想法，同时较好地控制住程序开发方向和基本功能完成的进度。但遗憾的是提高开发速度的代价是降低程序的可靠性、扩展性和重用性。过去，我们往往觉得所作的程序基本上不能再次使用，原因就在于没有抽象问题，寻找问题的根本解决方案。就问题实现问题的方法，忽略了深入分析问题的过程。对于针对开发某专业的应用软件采用此方法分析需求比较合适，但对系统性强的软件，最好采用树状遍历式寻找问题的方法。
二、分析问题和需求
在没有分析清楚问题和需求的来由就匆匆下定论是非常危险的。忽略问题和需求就可能埋下了潜在的程序或系统设计问题。我们也常常犯这样的错误：由于没有分析清楚问题和需求，结果到头来更改系统设计。能够提出的问题和需求，就一定要扎扎实实分析它，否则后果难料。
分析问题和需求的能力大小与思路和经验有关。好的思路来源于严谨、逻辑和跳跃的思考习惯。严谨要求不要放过任何一个小问题，逻辑要求思考的过程应该是一种符合规则的推导过程，跳跃思维要求思考的路子不是一走到底而是多条路子并行着走。经验来自于编写调试大量程序和善于总结，要求程序员不断地开发新程序和创造新思路，并且敢于尝试和接受失败，当然还有一条重要的方面：跟踪最新技术。
如何正确分析问题，有以下几个要素值得注意：
１. 所有问题和需求都有发生的根源。
问题和需求的表面现象总是与开发者思路切入点相关，如果切入点是狭隘的，那么围绕着问题和需求的分析往往局限于自身的思路范围，问题和需求产生的原因就很难发觉。所以当不能理解分析问题和需求时，不妨先找一找为什么存在这样的问题和需求，它的存在是否合理，然后再分析理解它就不难了。思路一定要跳出惯例。
２. 交替反复分析多个问题和需求，寻找问题间的共性和特性
看似问题和需求间没有联系，而且分析不清各自意义，那么建议交替反复分析考虑这些问题。勤能补拙，不要担心它将花费开发者多少时间，只有开发者仔细分析问题需求，以后的工作越来越简单明了。
３. 复杂化问题，
问题复杂化，是一个抽象问题或需求的逆过程，提出问题需求的许多可能的假设，丰富了问题需求的形式。能够复杂化问题，本身就体现了分析问题和需求的能力。比如：做一个加法程序，两个数相加，返回结果。简单的问题，但，我们一般都按两整数加法，有时考虑了浮点加法。为什么不是两个复数相加，或者是两个字符串相加等。这是一个使用操作符重载或类模板解决的简单例子，在这里我的意图是许多问题应该从更多的方面去验证问题是否同样存在。
４. 问一问自己：问题是否能够抽象化，继而简化问题。
众多的问题和需求变成程序代码的过程，就是公式化问题和需求。如果象上例加法一样，不管三七二十一，什么样的数据就写一段什么的代码，不同类型数据间的加法同样又要写一段代码，这样下去就写不完了。抽象问题，简化问题，类模板就是一个抽象问题很好的例子。在分析问题和需求的过程中，同样采用面向对象的思维方式去求解，会获得一个非常满意的需求报告。
５. 问题和需求分类分主次考虑
１）软件产品的性能指标：可靠、功能全、速度、易扩展。
易扩展：一种是产品升级换代快、系列化产品丰富。另一种是用户的二次开发扩展产品的再生功能。
速度：表示软件执行速度不仅要快，同时操作中的速度要均衡。
功能全：大而全不一定是不好，有能力和实力，最好做到功能尽量全。功能全直接体现软件开发商的实力。
可靠：这是最为重要的一点，软件首要考虑的应该是可靠。测试时，极限、异常操作都应该考虑进去。
２）问题和需求根据软件产品的性能指标和实现难度分类：核心需求，基本功能需求，高级功能需求、组合功能需求。
核心需求：直接影响速度、可靠、易扩展指标的好坏。比如：ＣＡＤ刷屏要求速度、ＣＡＤ命令行机制提高了易扩展性能、ＣＡＤ内部数据结构的管理机制直接影响软件的可靠性。核心需求将定义出软件的本质内容，它主要以程序设计原理为基础，结合软件任务需求定义数据结构和管理机制。核心需求是首先要确定下来的，是最主要的工作。
基本功能需求：完成任务的最基本的操作功能集合，这些基本功能是软件产品的底层处理功能，是众多问题和需求中抽象出的共性部分，它是其他功能的基础。基本功能需求也是非常重要的，它的好坏直接影响到后面高级功能的质量和能力。
高级功能：是众多问题和需求中的特性部分，这些功能对某个应用是非常有用，但在另一个应用中可能没有用。比如：ＣＡＤ中的图形计算：求面积或体积，在建筑施工图设计中没有使用，但在计算路基方面则非常有用。高级功能的需求应该放在较次要的位置，
组合功能：通过基本功能和高级功能组合操作后的功能。例如：ＣＡＤ中的ＬＩＳＰ语言，ＣＡＤ的批命令输入，ＣＡＤ的图块功能等。这些借助于基本功能和高级功能的组合功能是一种后期行为，没有这些功能，软件一样可以使用，所以，这些需求开发并不需要急于实现，但一定要在核心中考虑组合机制。
总之，需求分析是导致软件产品好坏的关键工作，导致软件开发难易程度大小的绝对因数。宁可将需求分析的时间给充足一些，也不愿以后在编程阶段补充修改需求（虽然修改需求是不可避免的事实）。
六、如何做好项目软件的分析
2005-04-20, 09.19, sachina | 1408 x 阅读
相红利（转载自中国系统分析员）
2003年02月01日
[摘要]
本文结合自己的经验，从实践的角度，对项目软件的分析工作从7个方面进行了阐述，并指出一些容易失误的做法。希望能对从事分析工作的同仁有所参考。
软件从使用范围的角度，可分为项目软件和产品软件。
项目软件：即针对特定某个客户的要求，并仅为其使用的软件。又称工程软件，特点是有明确的合同，严格的工期，约定的维护期等。如"XXX 公司XXX 系统" 。
产品软件：即针对某一领域客户的共有需求而开发的软件。特点是通用、功能丰富而冗余，通过一次性的购买行为获得等。如操作系统软件、数据库软件、CAD 软件等。
本文就项目软件的需求分析，结合自身的体会，提出一些看法和建议。
1、 依据分析阶段确定合适的客户方配合人员
这一点对于获取真正的用户要求非常重要。通常，客户方会组织专工以上层次的人或在单位小有名气的计算机能手来和开发方分析人员配合，共同整理需求。
应该对客户方配合人员进行分类，层次化，使之和分析的各阶段相对应。
分析的初期，即总体分析阶段，需要得到整体意义上的轮廓需求，此时，应与客户方总工以上层次的人员进行交流，这一层次的人，对未来的系统会有完整的描绘，可以划分出子系统，及其之间的关系，这也是高级管理层对系统的期望。可以以此作为纲领性的文档指导进一步的分析，并约束后续的分析过程，
避免需求范围漫无边际的扩大；
专业系统分析阶段，通常，客户单位都会有专业分工，彼此之间既相互独立，又会在某些点上发生联系。此阶段应与客户方专工层次的人员进行深入的讨论。这一层次的人，对自己的专业相当熟悉，对专业内的需求会非常到位，大都年富力强，有相当的阅历和理解能力，甚至自己都可以绘制业务流图，总结业务功能点。对他们应充分鼓励，尽量调动其积极性；
系统关联分析阶段，在各专业系统得到充分分析的基础上，紧接着就要理清它们之间的关系，这是提升需求档次的关键阶段，也是高级领导层和专工都关心的阶段。通常，客户单位都会有一些零散的软件，如财务软件，部颁软件等，这些专业软件都发挥着重要的作用，但都是些信息孤岛，客户会很自然的希望能把这些信息融合到整个系统中来，为更多的人所共享。同时，也希望数据能够在各专业系统间顺畅的流动，从而减少重复劳动，提高工作效率。此阶段应把总工层和专工层召集到一起，共同理清系统间的接口。
经过这三个阶段，对需求的描述将比较准确和完整。
2、 多方位描述同一需求
有一些需求贯穿了从基层人员到高层领导，对此需求应该从各个角度、各个方位给以描述，总结之后才能得到完整的表达，否则可能会漏掉一些信息。这也为后续的设计工作打好了基础。
比如，在设备管理类软件中，有一个概念叫" 缺陷" ，指由于材料老化或外力作用，使得设备处于不正常的运行状态，但还没有到立刻就酿成" 事故" 的程度，但如不及时检修，就可能出事。对于设备缺陷业务，就涉及到从班组人员到领导，上上下下对此都非常关心，但各层次的人关心的侧重点却不尽相同：领导关心" 消缺率" （即缺陷消除率）、" 消缺及时率" ；专工关心缺陷类型和处理方法；班组人员关心消缺工作的人员安排及时间地点。缺陷的业务处理流程依赖于" 设备缺陷单" （用于记录缺陷及消除情况），如果仅仅局限于从由基层得到的设备缺陷单上的数据结构（设备名称、缺陷发现人、发现时间、二级单位确认时间、缺陷性质、安排消缺时间、消缺人员、消除日期、处理方法），无法满足专工层的分析要求：对设备的缺陷情况按类型、零部件、型号、生产厂家等分类统计，为设备采购时作为选型参考、调整设备及其零部件的检修周期以减少缺陷发生的频率等，因此需要在原来的设备缺陷单上增加一些相关信息。
3、 清晰化每一数据项
由于需求将作为设计的基础，弄清所有的数据项的来龙去脉对于设计是必不可少的。不能有模糊不清的地方，同时通过对数据项来源的分析，可以让分析人员更清楚的看到数据的流动情况，也会发现一些新的需求点。
4、 充分挖掘潜在需求
由于分析人员对软件技术非常熟悉，一些由于技术所带来的潜在需求对于客户来说，一般很难被发现。不实现这些需求，对整个系统也没什么实质性的影响；实现这些需求，则会锦上添花。
对这些潜在需求，会有两种处理方式：告诉客户，客户会得到启发，可能进一步提出新的需求，会有一些更大胆的想法，从而扩大了需求范围，增加了工作量，甚至会影响到工期；不告诉客户，等客户想到了再说。
这些需求如果对于产品软件，可能会是一个卖点，要尽可能的去挖掘。但对项目软件，考虑各种风险，有时候可能会回避，或对客户隐瞒。
我觉得，不管是否告诉客户，分析人员还是应该去挖掘，最起码可以作为自己的知识积累。
5、 采用科学的分析报告模板
分析完成后，需要形成《需求分析报告》，应采用规范科学的报告模板，通过ISO 或CMM 的企业，其模板大都非常详尽，不仅仅作为报告模板，还可以指导分析过程。
比如，我所在的企业除了有规范的需求分析报告编写指南、报告模板，还有" 需求分析矩阵" 和" 需求变更报告" 用于管理需求和控制变更。
6、 积累领域知识
领域知识对于分析人员很重要，这些知识的广度和深度影响分析结果的准确性和分析进度。分析人员应该通过各种途径去获取这些，不断积累，并进行比较和总结。
7、 抱着学习与指导并存的态度
面对一个新的客户时，分析人员首先必须抱着谦逊的学习的态度，把这看成是丰富领域知识的机会。但并非客户单位的任何层次的人都有值得学习的东西，随着分析人员接触的领域客户不断增多，分析人员对该领域的理解也会越来越深，逐渐会成长为领域专家，会有很多地方超过客户对领域的理解，此时，要以自己的深入理解去指导客户，说服客户，甚至纠正客户的一些错误的认识，得到客户的信任与尊敬，这对迅速顺利的完成需求分析会很有帮助。
8、 误区
在进行需求分析的时候，容易陷入一些误区，导致分析结果不理想。
分析结果越复杂越好
这是技术型分析人员经常碰到的情况，认为分析出错综复杂的关系，花哨的图表才能显示出分析水平高，其实，分析经常要经历" 简单-复杂-简单" 的过程，前一个简单表现为分析人员" 认为简单" ；随着分析的深入，原以为简单的问题会越来越复杂；最后，经过概括、消化、分解，使得需求简单明了。
必须一次到位
由于项目工期紧，或者客户单位地理位置偏远，不想反复去现场，希望通过一次需求分析就能得到完整的不再改变的结果。有这种情况时，表现为分析人员对客户方配合人员穷追猛问，或坚持要求配合人员做出保证，承诺需求范围不再扩大等等。结果往往是双方关系紧张，配合人员怕担责任，提出过多的灵活的、可配置的一些要求，无端增加了后续设计和编码的工作量。一次到位的想法是不现实的，随着开发工作的进行，用户经常会提出以前没想到的需求，或者更改已有的需求。需求必然有一个迭代的过程，变是不可避免的，关键是对于变化的控制，比如通过正规而繁复的流程提高需求变化时客户付出的代价：告知客户如此变化将会使工期延长，或需要追加资金等等，尽管对于" 软件属于买方市场" 的现状来说，开发方往往叫不起这个板，但这样的控制还是有一定的效果的。
客户的需求必须全部满足
陷入这一误区的分析人员，往往自己的领域知识欠缺，对客户的需求是否合理，缺乏分辨能力，只能由客户牵者走，这样会带来很大的风险：造成需求冗余，项目返工，更有对需求变化失去控制的危险，随着项目的开展，整个开发团队会越来越痛苦。所以必须加深自己的领域知识，变被动接受为主动引导，进而拒绝客户的不合理需求。
以上所述仅为个人体会，都是些做分析时的基本要求，要做好需求分析工作，还有赖于其他很多因素，如分析方法及辅助分析工具的掌握程度、个人交际能力的高低、语言沟通能力的高低等等，欢迎同行广泛交流，共同进步。