系统分析处于从项目触发到形成项目章程，从项目章程扩展到项目需求，再到需求的逻辑过程分析，最后到可行性方案的确定。整个系统分析在项目管理周期过程中处于项目整体管理的制定项目章程环节，分析的是业务需求。虽然讲解的内容是以过程的形式进行介绍的，但是具体的每个操作基本都是以系统操作为基础的。
- 什么是系统分析
- 系统分析方法
- 范围定义阶段
- 问题分析阶段
- 需求分析阶段
- 逻辑设计阶段
- 决策分析阶段
- 系统分析的未来
1.什么是系统分析
没有什么标准或者是完整的定义，但是一般意义上来说，系统分析主要集中在业务层面上，不是技术或实现方面的。
2.系统分析方法
系统分析方法有很多种，每种都有作用，相互竞争也相互完善，要根据合适的场景去选择，混搭也是可以的，但是要以解决问题为标准。
模型驱动法包括结构分析、信息工程和面向对象分析等。模型驱动分析是以图形交流业务问题、需求和方案。结构化分析是最广泛应用的分析，它强调以过程为中心，关注数据通过业务和软件过程的流程。信息工程关注系统中存储的数据结构，而不是过程，以数据为中心，强调知识或数据需求的分析。面向对象分析是解决数据模型和过程模型的同步问题，现在成为主流。
加速系统分析法包含获取原型、快速架构开发。加速系统分析法强调构造原乡以更快地位一个新系统确定业务需求和用户需求。获取原型使用快速开发工具辅助用户获取业务需求。当然原型是很简陋，特别是UI和外观，但是请引导业务人员关注需求，不要关注外观。还有很重要的一点是，你必须有足够多的原始素材可以支撑你能使用原型，假如你是第一次做系统分析，请放弃它。快速架构系统是一种构建系统模型的加速分析法，采用逆向工程从已有系统生成原型。但是这两种加速系统分析法都缺少一个正式的设计下进行，所以工程师难以一边原型化，一边保持加速系统分析阶段的优点。
前两种都依赖于需求的确定和管理，下面是两种常用的需求获取方法。调查研究技术，一门系统研究必备的技能，调查内容包括：文档、文献或实地考察、观察当前系统的运行环境、调查和资源管理人员及用户群体、同一些有经验的人面谈，只要能有助于获取需求，都可以着手调查看看。调查是非常消耗时间的，联合需求计划技术可以加速需求的获取和管理。
业务过程重构法改进业务流程，避免保留低效率的自动化过程。
FAST系统分析策略不强制使用某种单一方法，集成前面几套方法称为一套比较流行的敏捷方法。
Note：上面的方法介绍的像蜜糖一样甜美，不过这些只是简介性质类的，能够根据灵活场景使用需要更多的细节和思考，以及行动。
3.范围定义阶段
范围定义极端是典型系统开发的第一阶段。在其他资料中，这个阶段可能叫做初始研究阶段、开始研究阶段、概述阶段、计划阶段。范围定义阶段回答“这个项目看起来是否值得？”。为了回答这个问题，我们必须定义项目的范围以及触发该项目的可见问题、机会、指示。这个阶段主要关心现有系统的系统所有者视图，以及触发项目的问题或机会。范围定义阶段的交付成果是项目章程，它的内容有：1.列出问题和机会；2.协商项目的初步分为；3.评估项目的价值；4.计划项目进度表和预算；5.汇报项目计划。
列出问题和机会，确定触发该项目的问题、机会、指示，并对每个问题、机会、指示都按照紧急程度、可见性、好处、优先权进行评估。通常是由高级系统分析员和项目经理领导完成这个任务，大部分的参与者可以粗略的归为系统所有者，包括主要的负责人等。可见性是一个方案或系统在多大程度上对客户、执行管理层是可见的，通常用评级标准鉴别。
协商项目的初步范围，由高级系统分析员和项目经理领导，参与者大部分是系统所有者，包括主要负责人，主要工作内容是基于前一个阶段产生的初始问题陈述形成定义项目范围的基础。项目范围包括使用什么样的数据描述系统、包括什么样的业务过程、系统用户怎么连接系统。当前阶段的主要技术有调查研究和会议。
评估项目价值，由高级系统分析员和项目经理领导，但系统所有者应作出决策，主要任务是基于有限的资料猜测项目收益是否可以冲抵项目成本，然后决策是否继续。
计划项目进度表和预算，主要由项目经理的责任，由上一个阶段决定是否启动。前提是项目启动的一致性得到认可。当然进度表和预算作为资源的一种，需要存档。
汇报项目计划是用于向指导部门汇报获得批准的过程。任何指导部门都应主要由非信息系统专家或管理人员构成。这也表示项目有效的沟通技巧需要很熟练的。
4.问题分析阶段
问题分析阶段通常无法跳过，几乎总是需要对当前系统的某种理解，可以想一些办法进行加速问题分析阶段。首先，如果项目是由一个战略或战术规划触发，那么项目的价值是毫无疑义的，问题分析阶段可以缩减到仅仅只是理解当前系统；其次，一个 项目由一个只是引发的，例如法律等，这也会加速问题分析阶段；最后使用某些方法学和住址有意地合并问题分析阶段和需求分析阶段，也可以加速系统分析的过程。问题分析阶段的目标是充分研究和理解问题领域，并全面分析其中存在的问题、机会和约束条件。问题分析阶段的主要关心的是现有系统的系统所有者视图和系统用户视图，仍然需要使用虽少的系统建模。问题分析阶段的任务有：1.研究问题领域；2.分析问题和机会；3、分析业务过程；4.制定系统改进目标；5.修改项目计划；6.汇报调查结果和建议。
研究问题领域，业务问题、机会、指示和约束条件都存在与这个领域。这个任务由项目经理领导，资深系统分析员主持，身兼两职也是正常的。为了可以覆盖问题领域，足够的系统用户是必需的，但是只能抽调部分系统用户（因为系统用户也要维持正常业务运转），很少出现有限的系统用户可以代表全部系统用户的利益。在这种情况下，能够保证系统用户和系统分析人员之间有效的沟通是非常重要的。在当前阶段产生的文档，不仅要检查是否存在，还要检查时效性问题。所有的对业务问题、机会、指示的理解应该文档化（1.当时的理解是这样的；2.后来随着信息的补充或过一段时间，理解会发生变化；3.可以更好的存档和传播），可以采用模型的模式，也可以采用知识-过程-通信的构件方式。上下文图是一种用于分析系统在系统用户层面的输入输出模型，将系统记为黑盒模型，系统用户的每个服务过程的输入输出通过图形表示，极好的解决了系统用户和系统的交互上的分析。
分析问题和机会，必须说这个需要深厚的基础，不要一开始就视图用“我们想...”或者“我们需要...”等方式描述问题，更多要从原因和结果层面进行分析。
分析业务过程只适用于业务重构项目，基于现有业务进行分析，整个业务流程降低费用提升效率。
制定系统改进目标，主要是建立成功的准则，对系统的任何改进都应该参照此规则。它同时确定任何可能限制系统改进灵活性的约束条件。系统改进目标也代表对新系统预期的首次尝试，约束条件是针对实现目标的限制或界限。系统改进目标应该是可以度量的，非常明确的；约束条件可以是进度、成本、技术、政策等。
修改项目计划是针对项目范围变动做的整体性变更，由系统分析员推动。首先评估范围变动，然后将变动的修改合并进项目范围，接着变更项目计划，最后排列项目任务的优先级。
汇报调查结果和建议，将前面几个小过程的交付物整理出来，如果有过程文档更佳，进行汇报和后续评审，是否项目继续下去。
5.需求分析阶段
需求分析阶段回答一个问题“用户需要什么？想从一个新系统中得到什么？”这是任何一个信息系统成功的关键。需求分析阶段的活动有：1.定义需求；2.排列需求的优先次序；3.修改项目计划；4.交流需求陈述，这些活动可能是并行执行的，最终的交付物是需求陈述。
定义需求， 将项目目标转换成功能需求和非功能需求，主要交付物就是功能需求和非功能需求的草稿，这些草稿形式各异。需求清单和每个目标的子清单组成了需求，每个子清单都包括输入、输出、过程、存储的数据。当然也可以采用用例来建模。
排列需求的优先次序，在需求验证之后，系统所有者和用户应该排列系统需求的优先次序。强制需求是最小的系统实现需求，理想的需求是相对强制需求来说非基本的需求。在排列过程中可以使用时间盒技术，分段式排列。
修改项目计划，这个修改主要是更详细的需求对项目计划的反馈，带来进度、成本、范围上的变化。
交流需求陈述，这是一个持续性的任务，在这个过程中用户会不断的宣扬他们对需求的优先级考虑，需要项目经理和主管来主持优先级变更。人际关系、交流、协商技巧是该项任务需要的基本技术。
整个需求分析其实一直贯穿在生命周期中，需要持续的管理项目需求，最好有专门的流程来管理。
6.逻辑设计阶段
逻辑设计阶段是使用系统建模进一步记录业务需求，这些系统模型表示了数据结构、业务过程、数据流和用户接口。某种意义上讲，逻辑设计阶段验证了前面阶段建立的需求。当前阶段的最终交付物是生成一个业务需求陈述，它将实现前面阶段中确定的系统改进目标。在当前阶段的任务图中任务开始变得不像前几个阶段那么有先后顺序。逻辑设计阶段的任务有：1.结构化功能需求；2.建立功能需求的原型（可选）；3.验证功能需求；4.定义验收测试用例。
结构化功能需求是逻辑设计的一种方法，有系统分析员支持任务记录结果，该任务由每个功能需求出发，输出的是实际系统模型和详细规格说明。如何做到系统模型和详细规格说明给到恰好足够是需要根据实际需要决定。
建立功能需求的原型（可选），是系统建模的替代方法，有系统构造人员推动任务，系统分析员记录和分析结构，通常系统用户是任务的主要数据输入者，依赖于用户已经确定的一个或多个功能需求。原型一般用在需求分析阶段构造输入和输出的示例，可以非常便于构造数据库和数据信息，前提假设条件是用户看到原型时能够知道他们的需求。这个假设满足起来看上去很容易，实际上并不容易，这要求用户有一定的技术功底，当然在中国就更不容易了。
验证功能需求，由系统分析员支持该任务，验证需求的完整性和正确性，协调用户找出需求中的错误、忽略并进行澄清。
定义验收测试用例，这个任务不是必需但是此时开始并不算早，因为当前阶段已经可以获得系统的业务过程、数据规则、业务规则，包括执行顺序等等，有系统分析员和系统构造人员执行该任务。
7.决策分析阶段
决策分析阶段确定候选方案，分析那些候选方案并推荐一个将被设计、构造和实现的目标系统。评估过程中不仅要考虑业务层面的信息，还要考虑现有的技术架构和环境，从技术层面考量，做出一个比较妥当的决策。决策分析阶段的任务有：1.确定候选方案；2.分析候选方案；3.比较候选方案；4.修改项目计划；5.推荐一种系统方案。
确定候选方案，由系统分析员推动这个任务，这些候选方案的设计思想和观点来源于系统所有者、系统用户、系统构造人员等。调查研究技术、小组会议技术是用于研究候选系统方案的主要技术。
分析候选方案，有系统分析员推动，不要比较候选方案，只需要对每个候选方案在技术可行性、运行可行性、经济可行性、进度可行性四个维度进行分析，记录分析过程和结构。
比较候选方案，由系统分析员推动，系统设计人员和系统构造人员参与回答技术可行性问题，最终授权由系统所有者和系统用户执行最后的分析和推荐工作，在比较过程中直接排除掉不可行的方案。如果被推荐的方案不止一个，应该设置方案的优先权。
修改项目计划，由项目经理、项目所有者和整个项目团队一起推动，系统分析员和系统所有者是关键人物，主要内容是不断的修正项目计划，保证项目信息在各个方面的一致性。
推荐一种系统方案，有项目经理和主要负责人联合推动，向业务团队推荐一种系统方案。系统分析员需要编写正式的业务报告，做出不涉及技术的演示汇报。
8.系统分析的未来
面向对象分析最终代替结构化分析和信息工程，成为系统分析员的首选。CASE技术会继续改进，RAD技术也会快速发展，但是知道从根本上研究和分析业务问题并定义作为系统设计前提的逻辑业务需求的系统分析员仍然是最前沿的。