1.5 系统分析与问题领域
系统分析是一种问题解决技术，它将一个系统分解成各个组成部分，目的是研究各个部分如何工作、如何交互，以实现其系统目标。系统分析讨论的问题域是指正在被研究的用户业务领域，指拟开发系统进行处理的业务范围。
系统分析是对系统项目开发的各个早期阶段的表述，事实上不存在一个被广泛接受的信息系统分析的定义，一般无法明确区分什么时候系统分析结束，或什么时候系统设计开始。传统的概念认为，信息系统分析主要涉及业务问题方面，而非技术或实现方面。
1.5.1 系统分析过程
在系统开发项目中，系统分析过程一般需经历：范围定义、问题分析、需求分析和决策分析4个阶段。其中前三个阶段合在一起称为系统分析，最后一个阶段涉及系统分析与系统设计之间的转换。
1. 范围定义阶段
范围定义阶段也称初始研究阶段或计划阶段。此阶段考虑的问题是：“系统项目是否存在开发的价值？”为此必须定义项目的范围及触发该项目的可能的问题、机会和指示。若该项目是可行的，此阶段将按照系统范围、开发策略、开发进度、资源需求和系统预算来制订项目计划。
范围定义阶段最后的交付成果是系统规划说明书。系统说明书定义了项目范围、计划、方法学、标准等内容，它的完成是项目的第一个里程碑。范围定义阶段一般包含下列4项具体任务。
任务1：确认系统项目开发的动机，说明触发该项目的问题、机会，并对每项内容按照紧急程度、可见性、收益和优先权进行评估。
任务2：协商系统项目的初步范围。系统范围定义了项目的边界，明确了将被包括进来或者不被包括进来的业务。系统范围在项目执行期间可能会发生变化，但是初始计划必须确定系统的初始范围。如果以后范围发生了明显变化，有关各方也将能很好地理解预算与进度的变化。
任务3：评估系统项目的价值，对系统项目从运行环境、技术、经济、社会因素等方面进行可行性分析。
任务4：制订系统项目计划，即设计项目进度表和预算表。初步的项目计划至少应包含两项内容。一是项目进度表和整个项目的资源分配表。这个计划也被称作基线计划，它将在项目的每个阶段结束时进行更新。二是用于完成项目下一个阶段（问题分析阶段）的一个详细计划和进度表。
2. 问题分析阶段
问题分析阶段也称详细研究阶段或可行性分析阶段，是对系统项目的开发动机、机会及目标进行全面、深入理解的阶段。此阶段考虑的问题是：“系统项目真的具有开发的价值吗？”
问题分析阶段的目标是充分地研究和理解问题领域，并全面分析其中存在的问题、机会和约束条件，归结起来有下列5项任务。
任务1：研究问题领域。此任务是分析问题领域中的业务问题、机会、指示和约束条件等。此任务的交付成果是对问题领域和业务术语的理解，一般以文档形式记录下来，以便验证或更好地理解系统。
任务2：分析问题和机会。此任务由系统分析员直接负责，但是所有的系统所有者和用户都应参与到因果分析中，因为他们是问题领域专家。这个任务的交付成果是修改的问题陈述及对每个问题和机会的因果分析，并将这些分析用文档记录。调查研究技术和JRP技术有助于此项任务的完成。
任务3：分析业务过程。这个任务只适用于业务过程重构（BPR）项目、建立在业务过程重构基础上的项目，或者需要重大的业务过程重构的开发项目。在这类项目中，要求项目团队十分详细地检查企业的业务过程，考量每个过程相对于整个系统增加或减少的价值。这个任务的交付成果是过程模型和过程分析。
任务4：制定系统改进目标。当完成对系统的范围、问题和机会的理解后，就可以制定系统改进目标了。这个任务的目的是建立成功的准则，对系统的任何改进都将按照该准则进行度量。同时也确定了任何可能限制系统改进的约束条件，如针对实现目标的限制或界线，最终期限、预算和所需的技术等。
任务5：修改项目计划与汇报。项目范围是不断变化的。以在范围定义阶段获得的初步理解和估计为基础，项目范围可能已经在规模上和复杂程度上进行了增加或缩减，此时应重新评估项目范围，并相应地修改项目计划。
3. 需求分析阶段
需求分析阶段主要为新系统定义业务需求，包含的基本任务有4项。此阶段最后交付成果是产生一个“业务需求陈述”，它将实现在前面阶段中确定的系统改进目标。
任务1：定义需求。将问题分析阶段中确定的系统改进目标，转换成满足系统的功能需求或非功能需求的框架。功能需求指满足系统改进目标所需的输入、输出、过程和存储的数据等。非功能需求如满足吞吐量、易学易用性、预算、开支和开支节省、时间表和最终期限、文档和培训需求、质量管理、安全和内部审核等。此任务的交付成果是功能需求和非功能需求的草稿描述。
任务2：排列需求的优先次序。一般来说，系统开发项目的成功总是按照业务需求被满足的程度来衡量的，但这并不意味着所有的需求要平等对待。如果一个项目落后于进度或者超出预算，此时若能判断出哪个需求相对更为重要是十分有用的。
任务3：修改项目计划。系统需求的优先次序确定后，分析人员将重新定义对项目范围的理解并相应地修改项目计划。项目团队必须考虑到新系统可能会比原先预期的规模更大。如果是这样，项目团队就必须相应地调整进度、预算和范围。
任务4：交流需求陈述。交流是需求分析阶段一个持续的任务，必须保证在整个阶段都同业务团体交流需求及其优先级信息。
4. 决策分析阶段
决策分析阶段确定候选方案、分析候选方案，并推荐其中之一成为设计、构造和实现的目标系统。决策分析阶段可以细化为4项任务。
任务1：确定候选方案。当系统业务需求确定后，接下来必须做的工作是确定候选方案。某些候选方案是由系统所有者和用户的设计思想和观点形成的，另一些则可能有各种来源：系统分析员、系统设计人员、技术顾问和其他信息系统专家。评估候选方案不是这个任务的目的，该任务仅仅需要定义要被考虑的可能的候选方案。
任务2：分析候选方案。每个候选方案必须进行可行性分析。系统分析员从技术可行性、运行可行性、经济可行性和进度可行性4个方面来评估各个方案。
任务3：比较候选方案。当完成对每个候选方案的可行性分析后，比较这些候选方案，从中选出一个或多个方案推荐给系统所有者和用户。
任务4：修改项目计划并推荐系统方案。随着分析人员对系统、问题、需求和方案的一步步深入了解，不断地修改项目计划并相应地调整项目范围是显然的。因此，根据推荐的方案，应该再一次重新评估项目范围，并相应地修改项目计划。
1.5.2 信息领域
目前，信息系统的开发与应用在各个行业越来越普遍，在应用系统分析方法对信息系统进行分析时，遇到的下面几个问题会显得比较突出。
1. 问题域与系统责任
问题域是指被开发系统的应用领域，即在现实世界由这个系统进行处理的业务范围。系统责任是所开发系统应具备的职能，两者具有很大的重合，但又不完全一致。对问题域和系统责任进行深入的调查研究，产生准确透彻的理解是运用系统分析方法成功开发一个系统的首要前提，也是分析工作的第一个难点。这项工作困难的主要原因是：软件专业出身的分析人员，他们多半不是问题专家，即使他们为某个领域开发过一两个系统，当他们面临新的领域时也仍然是外行。但是分析工作要求他们在不长时间内掌握问题域的基本情况和关键问题。问题域专家可以协助或参与分析工作，但是他们多半不是软件专家，他们的知识领域与系统开发的要求又有很大的距离。
当今信息系统所面临的问题域比以往更为广阔和复杂，信息系统比以往更为庞大。计算机硬件性能的提高和价格的下降使得人们把越来越多、越来越复杂的问题域交给计算机来解决。软件的发展也使编程效率在不断提高。相对而言，问题域和系统责任的复杂化对信息系统的压力也在与日俱增。
2. 交流问题
人与人之间的交流是分析工作面临的另一个重要问题。分析人员与其他人员的交流包括以下几个方面。
①与用户和领域专家的交流——为了了解用户的需求和理解问题域。
②分析人员之间的交流——为了分工、合作、问题切磋和系统衔接。
③与用户和领域专家的再交流——为了检验用户需求和问题域的理解是否正确；为了帮助用户更改或放弃某些需求，或改进现实系统的某些运作制度。
④与设计人员交流——工作交接，这种交流主要通过系统分析文档来表达，也不排除口头的说明和相互讨论。
⑤与管理人员的交流——工作的审核、认可、进度检查、计划调整等。
3. 需求的不断变化
需求变化是在大多数项目中司空见惯的事情。需求变化最常见的原因多半来自用户，客观原因是问题域本身在信息系统开发过程中发生了变化；主观原因是用户在立项的开始可能对需求的提法不完全或不适当，他们随着信息系统的开发而逐渐成熟，所以常常补充或者更改早期提出的需求；竞争因素也是引起变化的原因，为了利于竞争，可能需要为系统增加某些需求，也可能为了降低成本，加快开发而需削减某些需求。另外还有经费因素、技术因素等也会引起需求变化。
4. 复用的要求
软件复用是提高系统开发效率，改善软件质量的重要途径。分析结果复用是把已有分析模型中的成分组织成可复用的构件，以便在进行相同的或相似领域的新系统的分析时复用；此外，还可以在把一个旧信息系统改造为基于新的软硬件支持的新信息系统时尽量地复用旧的分析结果。
1.5.3 建模和模拟
模型是对所研究的系统、过程、事物或概念的一种表达形式，是对被研究对象的一种抽象。信息系统开发涉及的行业范围广、应用复杂，分析人员需要在这复杂的信息系统中澄清业务流程、提炼需求功能，并最后做出分析方案，建立各种层次或范围的模型是非常有必要的。
系统分析的基础是问题解决技术。由于解决问题的方法很多，所以系统分析方法也就有很多。从建模的角度来看，可以分为模型驱动分析法和模拟分析法。
模型驱动分析法强调绘制图形化系统模型来记录和验证现有的或建议的系统。系统模型最终将成为设计和构造一个改进系统的蓝图。结构化分析、信息工程和面向对象分析都是基于模型驱动的分析方法。
获取原型法首先模拟原型系统，原型是由用户提供响应需求的一个快速而粗略的实现，用以确定用户的业务需求。快速架构分析法考虑从现有系统或获取原型中导出系统模型，再进行编辑和改进得以实现新系统，可以看作是模型驱动和模拟分析的混合方式。
系统分析的不同阶段也有不同分析方法。需求获取方法是指包括系统分析员在内的，用来从用户团体那里提取系统问题和方案需求的技术，是系统进行模型驱动或模拟分析的基础。所有以上提及的这些方法都将在第2章中做详细介绍。