系统分析师之系统分析基础知识及应用

系统分析师之系统分析基础知识及应用
狭义地说，系统分析就是需求分析。

系统分析是传统软件工程生命周期里的一个环节，亦即：分析-->设计-->开发-->测试，当然，整个过程会有迭代和变更，但仍遵循着这样的顺序。

系统分析要解决的是“软件做什么”的问题。

至于“软件怎么做”的问题，则应该交给软件设计师和程序员。

当系统分析把软件功能确定无误时，整个软件过程才有良好的开端。

系统分析的成果是需求分析说明书，该文档必须正确、详细、完整地对软件要实现的需求进行说明。

系统设计人员将根据该文档进行下一步的工作。

因此，系统分析要研究的主要课题应该是：如何获得需求；如果进行需求分析，以及如何定义和描述需求。

根据这些探讨可以看到，我们常说的系统分析，是指软件项目启动以后所进行的需求获取、分析和描述等方面工作。

广义地说，系统分析是对整个系统应用的分析和研究。

纵观软件整个生命周期，在项目立项建议、招投标、商务方案制作、可行性分析和项目计划中，实际上都包含了系统分析的成分。

这里我们必须面对很多不同的前提，所以采取举例说明的方式。

例如：
企业内部门如果想建立某个应用系统，他们首先得思考、编写和整理自己的需求，或者由IT部门人员进行整理。

他们所做的可以说是初步的系统分析。

同样，某院所立项做一些软件开发，并申报863拨款，在软件可行性分析研究时也要考虑，项目的远景是什么，系统的目标是什么，通过开发软件可解决什么问题，要实现的功能范围是哪些，据此才可以提出建议书，并通过论证。

这
些高层次的论证，实际上也是系统分析。

当软件公司参与竞标时，必然要估测开发的周期和成本，这也直接取决于系统要实现怎样的功能，要明确掌握系统要提供的功能，而客户虽然会有几页需求方面的说明，往往需要先行作好调研。

甚至需要做出一些原型来和未来客户进行交流。

咨询顾问在项目评估，或者产品实施中针对企业问题提供咨询建议时，他实际上也做了部分的系统分析工作。

商务销售人员在与客户讨论时，客户必然会提出他们的情况，这时，商务人员也将在尽可能短的时间里进行分析，并为用户勾划出一个基本的方案。

这样的方案制作，也可看做是系统分析。

等到做项目计划的时候，系统的目标是什么，解决什么问题，要实现的功能范围是哪些，这些往往已经被确定下来。

项目过程中的需求跟踪和调整，以及后期的需求验证，用户级测试和验收报告方面，也和系统分析有一些关系。

另外，系统分析也包含对业务模型进行学习和研究。

系统分析师要经常通过学习和思考，对应用领域的问题，即客户业务规则方面的问题进行研究，以建立一个特定应用领域的业务模型，这将有助于实现更具广泛适应性的解决方案。

从以上表述中可以看到，系统分析从项目前期酝酿阶段就已经开始，并且在反复地思考，要做一个怎样的软件。

而通过建立业务模型，可以更好地提供解决方案。

系统分析可以是广义的。

9年前，我们开发一个商业连锁公司的业务管理系统，开发组兴致勃勃地第一次使用了UML建模语言进行系统的分析和设计。

开发组花了大概2个月的时
间完成了对业务系统的分析，并使用Use Cases描述用户需求和软件功能------尽管对这两个元素的区分那时还经常混为一谈，最后形成了一个几十页的需求文档。

装订成册后，一天下午由项目经理和一个博士分析师两人去甲方哪里沟通，并期望对需求达成一致，并获得甲方的签字。

大家认为，使用这样清晰和结构化的表达方式，需求真的已经比较清楚了。

可是，意想不到的事情发生了。

甲方看了文档后，说“我看不懂！……我不能签字！”后来，无论我们的项目经理和博士怎么一一就需求讲给他听，他都无法，或者不愿意把听到的和需求文档里的那些陌生的符号（小人和椭圆）关联起来------他不相信他看不懂的东西，他无法对他看不懂的东西承担责任、签字画押。

生气的自然是我们的项目经理，可是甲方错了吗？
其实，这是一个典型的甲乙方沟通问题。

而问题的关键是，双方没有约定彼此认可的、相同的沟通语言。

就好像你说中文，他说西文；就好像RAS非对称密钥，你用一种密钥加密，而要求他用另一种密钥解密。

这在人与人的沟通世界里，简直就是痛苦----双方的痛苦！那时候，有人笑侃，“这是加密了的需求，要用UML这把钥匙才能把它打开，才能翻译成自然语言文本。

”人类在语言上不断地进步，最终出现了非常好用、沟通自由、表达准备的“自然语言”。

可是，在计算机世界里，自然语言却失去了它的价值。

我们似乎需要反达尔文进化，把自然语言再符号化、结构化。

另外，当我们对复杂现实世界（如：专业业务系统等）进行描述的时候，由于我们自然语言的过于灵活，使得我们沟通的双方出现了理解偏差，而且随着复杂性的增大，偏差越大。

直到现在，关于复杂业务系统的沟通，在软件工程师和客户之间，还依然存在着理解的偏差。

这是需求工程中的一个全球性疑难问题。

那么，既然如此，UML可以作为一个面向专业业务系统的描述语言，来表达实际业务吗？我想，UML之父Ivar Jacobson 、Booch 和James Rumbaugh 已经帮助我们回答了这个问题。

但是，接下来，你能强迫你的客户去懂得UML吗？有人说，在过去20年来，软件工程师是最辛苦的职业，因为他们不仅要懂计算机，还要懂甲方的业务，更重要的是，还要让甲方相信你懂他的业务。

而甲方，也许什么不懂都没有什么大不了的。

这种交易中的不对等，沟通中的不对等严重地束缚了软件产业的发展，返工、重开发等等几乎在每个软件企业里发生过；也因此造成了甲方许多投资失败。

想想吧，所有的产业链中，没有那个产业象软件业一样，把它和它的客户如此紧密的联系在一起。

所以，在一个共同的“生存链条里”，我们需要一起成长，一起进步。

当需求的问题日日夜夜纠缠着我们彼此的大脑的时候，我们需要共同的努力，需求结构化我们的需求，需要在沟通上创造新的方式，那就是：共同使用UML来确认需求。

当然，除过UML之外，还有IDEF0、Workflow等辅助技术。

因此，甲方的项目人，如果你还停留在初级的需求表达上，请进入UML的世界吧，请试用用例的利器吧。

它帮助你分解需求，关联需求，结构化需求，和快速理解需求。

如需了解更多系统分析师资讯，请看希赛软考学院！。