如何写系统分析书
如何写系统分析书
By Cooljob, Chinacode,yu_jin, i.q.
想请大家一起来谈谈在软件工程中我们所做的第一步：系统分析。
系统分析，我个人认为这里应该出来系统的灵魂性的文档。这样的文档应该说出以下内容（视项目而定）：
1、系统需求说明
说明系统是一个什么样的系统，用市场上现有的系统来类比，用客户（或是我们自己） 需要一个什么样的系统进行说明，力求完整。并对系统的发展可扩充性进行描述（现在没有哪个系统是一次OK的）。说明与现有的系统有什么相同什么不同，说明未来系统的发展方面以及可移值性等能预见的事情。
2、系统资源说明
对系统所需要的软件、硬件资源进行说明。描述系统所需要的所有的TCO成本。包括人 员、时间、设备、系统、一次性投入资金、持续性投入资金这样的所有资源。
3、系统可行性分析
对系统的实施中的资源进行分析，说明投入的合理性和必然性，对其中的所有不可预见 性的投入进行合理的量化说明，来说明系统的实施的可行性。
作为开发前期的工作，我觉得还应该包括：总体设计和详细设计。
总体设计
这个阶段必须回答的关键问题是：“概括地说，应该如何解决这个问题？”
首先，应该考虑几种可能的解决方案。例如，目标系统的一些主要功能是用计算机自动完成还是用人工完成；如果使用计算机，那么是使用批处理方式还是人机交互方式；信息存储使用传统的文件系统还是数据库……。通常至少应该考虑下述几类可能的方案：
低成本的解决方案。
系统只能完成最必要的工作，不能多做一点额处的工作。
中等成本的解决方案。
这样的系统不仅能够很好地完成预定的任务，使用起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用户没有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的能力在实践中将证明是很有价值的。
高成本的“十全十美”的系统。
这样的系统具有用户可能希望有的所有功能和特点。
系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上，推荐一个较好的系统（最佳方案），并且制定实现所推荐的系统的详细计划。如果用户接受分析员推荐的系统，则可以着手完成本阶段的另一项主要工作。
上面的工作确定了解决问题的策略以及目标系统需要哪些程序，但是，怎样设计这些程序呢？结构设计的一条基本原理就是程序应该模块化，也就是一个大程序应该由许多规模适中的模块按合理的层次结构组织而成。总体设计阶段的第二项主要任务就是设计软件的结构，也就是确定程序由哪些模块组成以及模块间的关系。通常用层次图或结构图描绘软件的结构。
详细设计
总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化，也就是回答下面这个关键问题：“应该怎样具体地实现这个系统呢？”
这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该包含必要的细节，程序员可以根据它们写出实际的程序代码。通常用ＨＩＰＯ图（层次图加输入／处理／输出图）或ＰＤＬ语言（过程设计语言）描述详细设计的结果。
我想这样的文档系统的思路是一个慢慢积累的过程，如一些开发人员所说，我们现在有太多的形式上的东西，它并不是一个程序员真正需要的系统分析／设计书，对于系统的设计到实施到最后的代码以及验收有太多的改动和变化，我们正在一个极不规范的系统中生存，所以我们不可能有太多的选择，只能草草应付了事。所以需要探索得出一个真正适合我们的文档模式，这个模式或是说模板能为我们的代码工作减少负担，带来更多的动能。
1。现在的应用和以前大不一样
现在的应用是一种庞大的集成，包括跨平台， 网络，数据库等等，而且新技术的出现越来越快，任何人都无法精通甚至是掌握 全部技术。 简单例子：现在有windows,unix,linux等平台，有sql server,oracle,sybase等 数据库，有C++,vb,delphi等工具，谁能全部精通呢？如果不能，那么如何确定是 windows+sql server+delphi好还是unix+oracle+C++合适？
2。客户没有需求
我做过银行，电信等大客户，也做过各种小客户。他们无一例外的说“我要做一个OA系统”，“我要做一个企业网”，“我要做一个。。。”。可他们无法确定要实现什么，因为：很少有用户是真正由于业务的需求而做项目的；而且他们也不清楚能够实现什么(因为他们不懂notes,不懂企业网)。
3。需求与环境的变化
由于在项目开发前客户没有实质性的需求，加上软件开发人员不熟悉客户的业务，就导致在开发过程中需求的不断变化，严重时将导致分析与设计作废。
4。对象化的工具和过程化的程序
现在的开发工具已经很对象化了，而我们开发的程序却很过程化。也就是说你虽然努力的模块化，层次化，可只要运行环境有所变化，你还要不断地修改，再修改源码。这说明我们确实需要把实际中的做法修改一下。
一个项目如果做到了80%的时候才真正明确则个系统是什么样子的话，我认为是设计者 的失败。我认为在设计阶段不但应该做好传统做法的各种文档和论证，而且，应该做一些具体的设计工作了。比如，系统的整体运行设计及系统各功能模块的具体设计。而且这些设计应当都有详细的设计说明书。当这些说明书完成后，应当能做到，随便找个程序员他都能只通过看某功能模块的设计说明书就能够开始代码的开发而不用再重新思考该怎样去做了，程序员在这里就真的只是一个设计者的实现工具。
当然，现在的系统都越来越繁杂越来越庞大越来越向集成性质靠拢，似乎是没有多少人能掌握具体用什么做效果是否如何如何，但关键就是这里。莫非真的没有人能做到这点吗？非也！只不过是目前的显示情况是，设计人员的水平偏低，有些公司的设计人员根本就没有多少的开发经验，他又怎能了解太多的系统呢。系统设计在目前看来似乎是个拿钱多干活少的工作，但这是不正常的现象。培养一个程序员根本不用花多大的力气，一个人只要不太笨不太蠢，给他一个机会，相信就能掌握某门技术或方法。但要掌握若干种方法，就不是能够通过速成解决的了。
问题也在于此。目前似乎所有的系统设计人员都能够设计所有的东西。其实不然。很多人都有知识的局限性，这就决定他只能对某些方向的东西做出决策和设计。客户固然不知道他要做什么，但我们应该知道。如果在前期能够多接触用户多深入实际，把设计人员当成客户工作中的一员， 他就能够真正了解到客户的需求，当然也就能够为他做出合适的设计。
至于说到各种系统之间的好坏对比，我想，任何东西都没有绝对，有的只是某些方面的权衡。比如性能或空间的权衡或者价格和性能的权衡，或者就是功能侧重上的权衡等等等如此而已。计算机里的东西没有哪一样的存在不是包含了这种权衡在内的。虽然从商务上似乎总想说服用户什么东西好什么东西不好，其实从技术上讲无所谓好和不好，有的只是区别及该区别所针对的问题而已。
所以，不见得非要在用户决定之前由系统设计的人员事先来为各种方案做个排队，只需要了解用户的需求，然后从大方向上决定一个方向再做具体设计就可以了。
从过去的实践角度举例来说。首先，认同两个说法：
1。项目(或说工程)有三个主要方面：功能，时间，成本。
2。系统分析的任务：将用户的业务逻辑转化为程序逻辑，计算时间和成本。
让我们来做一个概要设计：
1。功能：简单的信息发布系统。
2。系统分析员根据项目的时间和成本，在充分权衡各种方案的利弊的基础上提出SQL SERVER+CORBA+DELPHI的方案。 。。。 用户很满意，OK，
开始详细设计：
1。为方便用户的安装使用三层结构。
2。客户端包含信息分布和查询两个模块。
3。使用各种图或语言描述各种函数，过程，模块，层次。 。。。
一切顺利，开始编码。 。。。 编码完成，用户试用，这时用户提出：在客户端要能实时跟踪信息的变化，而你却发现DELPHI的CORBA不支持回调！转用其它方案时间上不可能，补救措施也不灵(比如使用timer，但客户的网络环境不允许多个用户的频繁刷新)，怎么办？
现在来分析一下问题出在哪里：
1。有人会说系统分析员不真正了解客户的需求，可这不可能(项目时间的限制)也不现实(不可能让分析员到每个岗位都去操作一下)。
2。有人会说系统分析员的知识和经验不足，可现实却是分析员认为应该的，客户觉得没必要，而客户觉得必须的分析员又不可理解。这是不同的工作造成的，俗话说隔行如隔山。
3。有人会说系统分析员的水平不够，可问题绝大部分是出在细节而不是大方向上，掌握全部细节可能吗？ 这里就是一个长期困扰我的问题：细节(而不是方向)往往成为成功与失败的关键(注意，这里的成功是包含了时间和成本的)，而细节是不可能全部发现与分析清楚的。
如何在这种不完整的需求上构造完整的系统呢？或是根本不可能呢？我认为这个过程中不足的地方就是：把东西做死了，没有切实地为用户着想。很多人在做设计时，可能考虑的最多的是实现上的方便，而不是系统的扩展及更新。需知道，用户的需求是在不断变化的，如果总是在设计前就“善意”地替用户假设，是难以预料后事的结局的。
所以我想，在设计阶段就因该把可能出现的问题都摆到桌面上讨论，包括其特点及效果和后果，而不是自以为是地好心地替用户“假设”。 其实一个系统设计的优劣，其系统的扩展性能是一个很重要的指标，一个单纯就事论事地针对某件事情而做出的“专用”系统是没有任何远见的。