假如眼光仅仅放在满足客户眼下的需求，当问题不断出现时再不断修补，头痛医头，脚痛医脚，甚至系统构架需要不断调整或重新设计，那么，很快就会陷入代码泥潭或坠入系统重复开发的无底深渊，当初项目完成时的成就感将被无止境的沮丧所代替。系统分析决定系统开发的成败，软件建模使系统开发走向成熟。
一、系统分析在网站项目治理中的地位
在进行了需求分析和业务流程分析并得到客户的认可之后，对项目进行系统分析是极其重要的。系统分析是能体现整个系统的灵魂的文档，将客户的需求从具体到抽象的一个过程，并制定编码人员可实施的规范和标准。
由于Web应用技术发展的历史相对与软件的历史短得多，在开发网络应用系统尤其是网站制作的系统设计中设计人员往往对系统分析重视的不够，非凡是设计一些初期比较简单的或交互及功能较少的网站时，主要原因通常为：
客户初期的需求比较简单，忽略了客户潜在的巨大需求；
项目实施周期短，初期阶段采用最快的而不是最合理的实现手段；
经费有限，难以支付高质量的人力费用；
Web编程技术手段多样，轻易上手，设计人员参差不齐；
从现实中来看，网站项目的开发与治理和实施远不如软件工程规范，在编程语言、数据库、通信协议、应用服务器等相关环境都在不断快速发展和完善的情况下，的确很难期望每一个设计师都能网站项目进行系统的合理的分析，从而制定一套跨平台、健壮的、易扩展和升级的系统方案。
但是，这并不能成为系统分析员逃避或懈怠的借口，假如把一个系统比做一部汽车，系统分析的工作相当于设计发动机，也许很轻易就想像的出用125cc的摩托车发动机去牵引10吨重载卡车会是一个什么样的后果。
在系统分析的过程中需要对需求分析进行进一步的深化和分析，通常客户及业务人员在需求分析和流程分析的过程中比较注重功能上的表现和定义，即使是做出正规的用户界面原型，对系统的需求也是不完整的，处于非技术人员的缘故，很难苛求能提出完整清楚专业的性能需求，但不意味着这需求不存在，而且这隐藏的需求对编码人员来说是极其重要的。
因此，客户的需求能否在系统中得到真正的体现和实施，系统分析是至关重要的。
二、系统分析所要做的工作
把系统分析和具体设计阶段分开，针对不同项目的具体情况再决定采用什么方式进行开发。
那么在系统分析过程中重点要做的是：对客户的需求分析进一步完善和补充，尤其是性能需求：让客户更加清楚这是一个什么样的系统，所要达到的功能和性能指标是什么，系统的扩展性和适应性如何，如何为客户今后的升级或维护提供最有效的方法。
系统运行所需要的的环境：系统能正常运行所需要的硬件、软件、网络环境；
系统的资源说明：系统所需要的各种成本。包括人员、时间、工作环境、一次性投入资金、持续性投入资金等所有资源。
系统可行性分析；对于系统分析员比较苦恼的是大多客户在系统的要求上提不出独立的或成熟的意见，而将烫山芋交给了系统分析员的手上，为了避免在系统论证方面难以把握的失控和无从下手，设计几种不同类型的方案供客户选择不失为一个好的方法：
“比如通常至少应该考虑下述几类可能的方案：1：低成本的解决方案系统只能完成最必要的工作，不能多做一点额外的工作。2：中等成本的解决方案这样的系统不仅能够很好地完成预定的任务，使用起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用户没有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的能力在实践中将证实是很有价值的。3：高成本的"十全十美"的系统这样的系统具有用户可能希望有的所有功能和特点。系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上，推荐一个较好的系统（最佳方案），并且制定实现所推荐的系统的具体计划。假如用户接受分析员推荐的系统，则可以着手完成本阶段的另一项主要工作。”（引用《如何写系统分析书》一文）
经过系统分析的阶段，我们就比较轻易和客户在系统如何部署、采用的数据库类型、设计模型和分析模型等方面达成一致的熟悉，假如能顺利地将客户的需求业务逻辑分析转化为程序逻辑，把原先用户可视化的界面原型和业务流程图映射成编码人员理解的模型和规范时，那么恭喜你，项目已经成功了一半。
三、系统分析的难点和技能要求
网络应用的开发技术在日新月异地进步，从而使网站应用系统的开发模式具有多种选择性，达到同样的目标可以采用很多不同的方式，现代的应用系统越来越成为一个庞大的集成方案，需要考虑不同的操作平台、不同的应用服务器、不同的数据库、不同的编程语言、不同的传输介质等等，无疑对系统分析员来说是个严重的考验，任何人都不可能精通甚至说把握全部的技术，简单例子：现在有Windows，Unix，Linux等各种服务器操作平台，有SQL Server，Oracle，DB2，Sybase，mysql等数据库，有Java，PHP，ASP，CGI，jsp，C++，VB，Delphi等等工具，谁能全部精通呢？假如不能，那么如何确定是Windows+SQL Server+ASP好还是Unix+Oracle+JAVA合适？况且各种软件和语言还在不断发展进步之中，超越窄带的互联网，今后还可以涉及到宽带所带来的变动，或者增加与无线移动的接口，因此系统分析员能否出色的胜任工作很大程度上决定了系统开发的成败。
系统分析的主要难点在于：
对客户隐藏的性能需求的分析：由于客户对尚未实施的系统无法预见，对今后的业务发展也无法预知，对性能需求的分析和定义更需要系统分析员协助客户去确定和挖掘；
确定项目设计方法：根据项目需求和资源的配置选择最合适的设计方式。
对系统模块的划分和代码复用的设计：模块最大化，代码复用度最高，是一个成熟的系统不断致力追求的，将大型复杂的应用系统分解成相对独立，具有高度复用的模块，各个模块之间采用规范的参数接口，将大大提高系统的开发效率和维护升级的方便性。即使在网站的模版设计或交互设计上，也尽可能采用嵌套可复用的模版或调用统一的样式表、JS文件等。
项目整体评估：系统分析员绝不应成为孤立的完美主义者，而需要根据项目的大局出发，比如公司的资源配置、人力状况、客户要求等因素评估项目整体和各个模块的工作量、进度和分配资源，制定出最合理的可行的实施方案。
系统分析员不但需要具备良好的沟通协调能力，更需要具备业务和技术领域两方面的专业技能，在项目小组中是非常要害的角色之一。
四、软件建模使系统开发迈向成熟
Web应用系统往往随着客户的需求增长，开发不断深入，最终变得非常复杂，而且以Web为核心的网站系统通常都具有高度的动态扩展和交互，要在不完整和不断改变的需求情况下，在有限的时间内完成一套轻易修改和维护的健壮的系统，在UML（统一建模语言）出现之前是极其困难的。
大多的Web设计师或程序开发员为了让客户尽快看到可运行的应用系统，经过界面设计或简单的系统分析后直接进入编码阶段，甚至各个模块分头开发，服务器段代码随意编写、数据库任意添加、参数定义没有规范，整个应用系统处于一种无序混乱的状态，当我们采用建模及按照软件工程的方式进行治理的时候，情况马上就会好的多。
什么是建模？
建模是使你逐层深入解决问题的办法；确认应用系统的功能需求并为事务处理原则建模；对抽象的对象映射需求，辨认和提供设计模版并创建惯用的模版；分辨和设计对象或划分三层模型的服务；对软件的组成部分映射成对象并设计组件在网络上如何分布；
UML（Unified Modeling Language，统一建模语言）是一种通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统的文档。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，同样，在网站设计或以网站为表现形式的各种网络应用项目中，UML也表现出强大的作用。UML能够描述系统的静态结构和动态行为：静态结构定义了系统中重要对象的属性和操作以及这些对象之间的相互关系；动态行为定义了对象的时间特性和对象为完成目标任务而相互进行通信的机制。UML不是一种程序设计语言，但我们可以用代码生成器将UML模型转换为多种程序设计语言代码，或使用反向生成器工具将程序源代码转换为UML模型。
我们可以看的出，建模并不等同于程序编码，利用同样的UML模型可以生成不同语言的框架代码，而且可以通过反向生成，在编写代码过程中及时更新UML模型，这对系统分析员和项目治理人员来说是梦寐以求的。只要能够仔细地把握客户的需求，不断改进UML模型，那么采用什么样的语言开发已经成了次要，大量的需求积累和分析工作能在客户需求变化时得到高度的复用，即使系统采用新的语言重新开发，需要的也仅仅是编码部分的工作。
虽然软件建模可以在开发的任何阶段进入，但是在设计初期，应该将精力更加集中在系统功能及性能分析、系统运行环境、选择编程语言等，而不是考虑考虑程序的细节，如在屏幕上的什么位置放置按钮等。在项目开发的中期引入建模是非常有意义的，通过建模把握程序开发的方向，准确完成需求分析中所要求的任务。
在高展先生的《全程建模》一文中阐述的“全程镜像一体化建模方式“，整个建模过程依靠业务驱动，在模型设计中利用盒子的上下两部分分别代表业务组织结构和软件逻辑结构，将客户可视的具体的需求与系统抽象的逻辑流程一一对应，这对缺乏技术背景的客户代表和经验不足的系统分析员之间的沟通具有明显有效的作用。
五、总结
系统分析是项目开发中最艰巨的工作，本阶段需要非凡注重的工作重点在于：
补充完善上一阶段可能欠缺的系统的性能需求；
系统分析员需要站在全局出发，设计合理可行的设计方案；
在需求不明的情况下设计多种解决方案供客户选择，
将系统分解模块，最大限度地设计代码复用；
使用UML建模方式，将客户变化的需求映射到模型中，大大提高系统的扩展性和开发效率
