2．任务难度的预测能力

    系统分析员要具备快速的任务难度预测能力以及具备快速确定开发小组人员构成和任务划分的能力。（我将这条归为思想，而不是能力）昆虫自然会长出翅膀，而思想却需要长期的浸润。要做到这点，需要大量的思考、学习。设计远比编程重要。当今软件业的发展，各种开发工具的出现，编程已经不是什么问题，程序员的工作某种程度上讲是将别人现成的东西拼凑堆砌起来。系统分析员要清楚的认识到，现在大多数程序员没有学会怎么去整体的了解一个系统，有些甚至不了解编程（这不是说他们不会写代码）。可视化的开发工具加五花八门的控件，程序员可以偷点懒了。（这可不是夸大，我好几年的管理工作，接触过大量的程序员）基于技术，跳出框架。基于现有技术结合用户需求思考问题，设计时跳出
框架。

3. 系统分析员的关键是获得信任
    系统分析员最重要的素质是获得信任，这是成为优秀系统分析员的关键。成熟最为关键。成熟可以为整个项目组提供正确的支持，能够理解技术怎样才能解决用户的需求。

4. 系统分析员的准备工作

      统一的各种文档模式，这其中包括今后软件变量、字段命名规则。我推荐用pb制定的规则做基础，通过改造成为适合自身实用的标准。统一的文档管理。统一的分析软件。比如说rose（uml 太规范，国内的软件管理水平根本用不上，只不过尽量应用，你自己对系统分析的理解有好处）方法是思想的放映，在具体方法上就不多说了。我托人从u$a 弄到几本书，用于面向对象系统开发的使用》、《面向对象的分析》、《项目管理》等都是很不错的，推荐大家看看。
      我在拙作" 在中国没有人懂计算机" 里发了点牢骚，听说挨了部份人（习惯性的）骂。其实，bbs 本来就是发泄的地方，在这里从来就罕有有内容的文章。
      自从" 维纳斯" 登陆深圳后，大家更着眼于从宏观看中国的it业了。中国it这棵小树，说实在的，长到今天实在是不容易。一些人提出了" 反对微软霸权"的口号，不少人呼唤中国" 硅谷" 的出现。微软的成功不是技术的成功，更多的是商业运作的成功。中国it这棵树能长多高，取决于他所植根于的土壤。而现在的事实是，这片土壤实在是太贫瘠了！如果按我们现在的思路和搞法，是长不成大树，更别指望能结？quot；微软" ，" 硅谷" 这样丰硕的果实。如果说，我们的软件技术落后美国十年，我们的硬件制造技术则落后美国二十年，我们的管理水平落后美国至少三十年。而最终决定发展速率的恰恰是我们的死穴──低劣的管理水平。低劣的管理水平的形成的原因有着深厚的背景和多方面的原因。
      系统分析工作是解决一个问题的工作，目标是将一个对计算机应用系统的需求转化成实际的物理实现，其中复杂就复杂在实际的面太多。在系统分析过程之中注意问以下的问题，可能会所进行的系统分析设计工作有帮助。
    (1) 您所完成的系统目的是什么？注意不是功能要求，而是目的。也就是为什么要建设、为什么要现代建设。在考虑系统目的时，我更多的侧重于系统的最终目标考虑，因为一个系统不可能一下子完美，为系统留些余地。
    (2) 您所完成的系统有哪些方面参与，各方面的初衷是什么？那些人可能在系统建设中起重要作用，他们会采取什么样的态度？你对他们有多少影响力？中国it行业的失败之一就是人" 太年轻" ，一定要有领导的支持，否则完蛋。不要认为自己对他们会有多少影响力，即便有，也要尽可能的认为是决策者再影响他们。在中国，一个技术员，你算老几？说到这里我很悲哀。哪些人在系统中起重要作用并弄清楚他们的态度，这点十分关键。
    (3) 您的系统是否有一个明确的评价标准？最好从参与的各方面都进行考虑。不知道这样说对不对，在系统建设之前，对你的程序员、对你的领导要有至少不同的两种评价。
    (4) 你的系统设计思想是什么？是否能够得到各方面的认可。如果高明，对领导、对程序员都采用引导，得到认可的最好办法，就是让他们认可他们自己的想法。（我力图这样做，但做得不好，系统分析员有一点要学会韬光养晦，忍!）
    (5) 你对参与系统设计开发的人员了解吗？他们的特长在哪里，是否愿意与你合作，为什么？你对他们有足够的影响力吗？软件发展到一定的程度，不是编程，不是数学，而是管理。
    (6) 你的系统开发计划是否完善？你的计划表有明确的阶段吗？任何一阶段都应该怎样完成？如何对这一阶段完成的情况进行评价？
    (7) 你对所采用的系统开发方法以及工具是否熟悉？你的夥伴是否熟悉？事实上，不是每种好的工具都要使用，也并不一定都要他们熟练掌握。提醒诸位一句，当你将方案做得可以不依赖某个程序员，你在程序员面前就无信任可言，因为从此程序员将受到更大的生存压力。我坚决不在公司使用rose。
    (8) 你所完成的系统是否有原型？计算机的或者物理的。

5. 系统分析员的基本功

     以上的几个问题都是在系统分析以及系统规划时涉及到的，供各位参考。这文章很好，我的话是：" 需求分析实际应该是问题分析".含义是系统要解决的是问题。而不是用户提出的需求。经常发现系统完成后，客户说" 我的问题还没有解决".可是，需求分析稿上的目标都搞定了。既然是问题分析，所以，熟悉目标系统的知识就是必要的。甚至，可以说，一个好的系统分析员也应该是好的业务专家。
      我很高兴在这里遇到许多分析高手，可以交流分析中的问题。我赞同从来的观点。在中国作分析重要的是人气，因为中国的企业级信息系统的建设在很大程度上可以说并非确有需求，而是迫于某种压力。用户在很多时候考虑的不是系统的长远发展，而只是短期的成果，要求开发单位在很短的时间内完成一个很大的系统的开发，没有时间对系统进行周密的分析，在这种情况下，很多开发商就会粗分析，粗设计，尽快进入编码阶段，这样的系统的生命周期肯定不会很长。说了这么多，只是想说，系统分析员确实应是业务和管理专家，并且需要有很好的语言组织能力，他需要根据问题域中存在的问题去尽力说服用户，引导用户需求，毕竟，我们是专家，如果让用户牵着鼻子走，系统不会是成功的系统。（当然了，这要建立在用户是可引导的前提下）本人拙见。
     在理解和分析用户的需求时，应说服用户明白：建立计算机应用系统并不是简单地用计算机代替手工劳作，它更应该是管理思想的一次革命，是现用户模式的一次升华和提高。如果系统不能高于现实，开发的系统将长期陷入需求的反复修改，其软件的生命周期也短了。