系统分析与设计方法 · 问题分析五步与需求定义

欢迎来到第 8 章，系统分析与设计方法。这一章开篇先给架构师定了位，原文说：对于架构设计师而言，如何进行系统设计是其看家本领，而设计是在对系统进行分析的基础上进行的，否则，设计就是无米之炊。

原文有原话：从软件开发项目中的角色分配来看，系统架构设计师应该在信息系统项目管理师的协调下，与系统分析师协同工作。谁协调、跟谁协同，这两个位置别摆错。

8.1 节，定义问题与归结模型。软件系统的目的是为了解决问题，因此在建模之初最重要的步骤是对问题的分析与定义。问题分析的目标，就是在开发之前对要解决的问题有一个更透彻的理解。要达到这个目标，通常需要五个步骤：在问题定义上达成共识、理解问题的本质、确定项目干系人和用户、定义系统的边界、确定系统实现的约束。简记：共识、本质、干系人、边界、约束。

原文给了个朴素办法：最简单的方法就是把问题写出来，看看是否能够获得大家的认可。要更有效，就按标准化格式写。根据 UP 的建议包括四个要素：问题概述，用简短的几句话将所理解的问题本质描述出来；影响，说明该问题将会对哪些项目干系人产生影响，干系人就是 Stakeholder，也叫风险承担者；结果，确定问题对项目干系人和商业活动会产生什么样的影响；优点，概要性地提出解决方案，并列举出该解决方案的主要优点。

但有个关键判断：每一句描述都会夹杂着叙述者的个人理解和判断，因此透过表面深入本质，理解问题背后的问题，是问题分析阶段一个十分关键的任务。其中一种技术叫根本原因分析，是一种提示问题或其表象的根本原因的系统化方法，在实际应用中常使用因果鱼骨图和帕累托图两种方法。

答案帕累托图。拆一下干扰项：甘特图管进度、思维导图做发散，都不在原文的方法里；用例图确实是本书的大明星，但它描述系统功能、用来划边界，跟找根因无关——出题人就是赌你看见眼熟的词就勾上去。

先说因果鱼骨图，它是一种有效的探寻问题根源的技术，通过直观的图形找出问题或现象的所有潜在原因，从而追踪出问题的根源，提供了一种运用集体智慧解决问题的方法。使用步骤三条：将问题简明扼要地写在右边的方框里；确定问题潜在原因的主要类别，将它们连到鱼的脊骨上；用头脑风暴法寻找原因并归类。

再说帕累托图，它采用直方图的形式，根据问题的相对频率或大小从高往低降序排列，帮助设计师将精力集中在重要的问题上。原文金句：它为 80% 的问题找到关键的 20% 的原因。使用步骤要会复述：明确问题，也就是前面达成共识的问题定义；找出问题的各种可能原因，通常利用头脑风暴来收集意见；选择评价标准和考察期限，最常用的评价标准包括频率，即占总原因的百分比，和费用，即产生的影响，而考察的期限应具有相应问题的代表性，并不是越长越好；然后收集各种原因发生的频率及费用数据；将原因按频率或费用从大到小排列；最后原因排在横轴上，频率或费用排在纵轴上。

项目干系人是指任何将从新系统或应用的实现中受到实质性影响的人。原文点出个识别的难易规律：许多项目干系人就是系统的用户，这一部分通常易于识别；但还有一部分是系统的间接用户，甚至只是受系统影响的商业结果，这一部分不易识别，但十分重要。注意这后半句，问「哪部分干系人不易识别但十分重要」，答案就是间接用户和受系统影响的商业结果。

寻找干系人时可以问一组问题：系统的用户是谁？系统的客户，也就是购买者，是谁？还有哪些人会受到系统输出的影响？系统完成并投入使用后，有谁会对它进行评估？还有没有其他系统内部或外部的客户？系统将来由谁来维护？这里有个小辨析——用户和客户不是一回事，用户是用的人，客户是掏钱买的人，选择题爱拿这对词做文章。

系统的边界是指解决方案系统和现实世界之间的边界。在系统边界中，信息以输入和输出的形式流入系统并由系统流向系统外的用户，所有和系统的交互都是通过系统和外界的接口进行的。定义边界时把世界分成两部分：系统，以及与系统进行交互的事物。描述边界有两种方法：一种是结构化分析中的上下文范围图，另一种是面向对象分析中的用例模型。这个「两种方法」的对仗本身就是考题。

展开一点。上下文范围图就是数据流图中的顶层图，是反映领域信息的模型，能清晰显示系统的工作职责和相邻系统的职责起止之处。用例模型则通过引入参与者来描述和系统进行交互的事物，只要识别了参与者，自然而然系统的界限就确定下来了。找参与者时问：谁会对系统提供信息？谁会在系统中使用信息？谁会从系统中删除信息？谁将操作系统？系统将会在哪里被使用？系统从哪里得到信息？哪些外部系统要和系统进行交互？

由于各种因素的存在，会对解决方案的选择造成一定的限制，称这种限制为约束。每条约束都将影响到最后的解决方案的形成，甚至会影响是否能够提出解决方案。约束源很多，原文列举了：进度、投资收益、人员、设备预算、环境、操作系统、数据库、主机和客户机系统、技术问题、行政问题、已有软件、公司总体战略和程序、工具和语言的选择、人员及其他资源限制。题目问「以下哪项不属于约束源」时，就到这串里找不在其中的选项。

对，8.1.2 问题定义。通过对问题进行细致周密的分析，就可以对其进行综合的定义。对于一个问题的完整定义，通常应包括目标、功能需求和非功能需求三个方面。先说目标：目标是指构建系统的原因，它是最高层次的用户需求，是业务上的需要，而功能、性能需求则必须以某种形式对该目标做出贡献。

描述目标时要注意五个方面。优势：目标应该不仅仅是解决问题，还要提供业务上的优势；度量：不仅要说明业务的优势，而且还必须提供度量这种优势的标准；合理性：要确保完成解决方案所需的工作量少于所获得的业务优势，这才是合理的解决方案；可行性：要探寻能够满足度量标准的解决方案；可达成性：对于组织而言，是否具备获取该系统的技能，构建完成后是否能够操作它。优势、度量、合理性、可行性、可达成性，五条。

功能需求是用来指明系统必须做的事情，只有这些行为的存在，才有系统存在的价值。两句限定要背：功能需求应该源于业务需求，它只与问题域相关，与解决方案域无关。详细程度上要注意：这些需求是业务需求，因此应该由业务人员来验证。

描述功能需求还有个二义性问题，体现在两个方面：一是同名异义的词，自然语言中存在许多同名但异义的词语，应该谨慎地排除它们带来的影响；二是代词，代词经常会产生指代不明的现象，应该尽量避免使用，而是换成主语及宾语。希赛教育专家提示：检查二义性的有效方法是大声地朗读出来，大家一起边听边进行讨论。

对，而且是个高频考点。非功能需求是系统必须具备的属性，这些属性可以看作是一些使产品具有吸引力、易用、快速或可靠的特征或属性。非功能需求并不改变产品的功能，它是为工作赋予特征的。识别两者的思维模式原文一句话：功能需求是以动词为特征的，而非功能需求则是以副词为特征的。练习题第二题就考这句：正确选项是功能需求以动词为特征，非功能需求以副词为特征。凡是说「均以名词」「均以副词」「均以动词」的选项，一个「均」字就露馅了。

可以这么联想，但考试口径以原文为准。非功能需求包括八种：观感需求，产品外观的精神实质，与用户界面观感相关的一组属性；易用性需求，包括用户的接受率、因引入产品而提高的生产效率、错误率、特殊人群的可用性等指标；性能需求，关于功能实现要求有多快、多可靠、多少处理量及多精确的约束，例如速度、精度、安全性、容量、值范围、吞吐量、资源使用效率、可靠性也就是平均无故障时间、可用性也就是不停机时间、可扩展性；可操作性需求，衡量产品的操作环境；可维护性和可移植性需求；安全性需求，通常体现为保密性、完整性和可获得性；文化和政策需求；法律需求，哪些法律和标准适用于本产品。

对，性能需求里安全性、可靠性、可用性这几个词还会在别的章节反复出现，先混个脸熟。把本集必背过一遍：架构师在信息系统项目管理师协调下与系统分析师协同工作；问题分析五步是共识、本质、干系人、边界、约束；根本原因分析用因果鱼骨图和帕累托图，帕累托为 80% 的问题找到关键的 20% 的原因，评价标准是频率和费用；边界两种描述法是上下文范围图和用例模型；问题完整定义包括目标、功能需求、非功能需求，目标注意优势、度量、合理性、可行性、可达成性五条；功能需求以动词为特征、非功能需求以副词为特征；功能需求只与问题域相关、由业务人员验证，二义性来自同名异义词和代词。

下一集讲需求分析与软件设计的总纲：那组吓人的项目失败统计数字、需求分析四方面工作、需求的三层模型，还有系统设计到底是在设计还是在选择和妥协——那句「骑自行车到月球」的比喻值得记住。