1. 可行性研究
1.1. 可行性研究的目的
可行性研究实质上是要进行一次简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。这个过程通常结合了初步的需求分析，不做需求分析，就无法对需求进行可行性分析。它所需要的时间长短取决于工程的规模。一般说来，可行性研究的成本只是预期的工程总成本的5%到10%。
因此，可行性研究的目的不是解决问题，而是确定问题是否能够并且值得去解决。
并非任何问题都有简单明显的解决办法，事实上，许多问题不可能在预定的系统规模或时间期限之内解决。如果问题没有可行的解，那么花费在这项工程上的任何时间、人力、软硬件资源和经费，都是无谓的浪费。可行性研究的目的，就是用最小的代价在尽可能短的时间内确定问题是否能够解决。
如果问题没有可行的解，分析员应该建议停止这项开发工程，以避免时间、资源、人力和金钱的浪费；如果问题值得解，分析员应该推荐一个较好的解决方案，并且为工程制定一个初步的计划。
1.2. 可行性研究过程
首先需要进一步分析和澄清问题定义。
在澄清了问题定义之后，分析员应该导出系统的逻辑模型。
然后从系统逻辑模型出发，探索若干种可供选择的主要解法(即系统实现方案)。对每种解法都应该仔细研究它的可行性，一般说来，至少应该从下述三方面研究每种解法的可行性：
(1)技术可行性：工使用现有的技术能实现这个系统吗?
(2)经济可行性：这个系统的经济效益能超过它的开发成本吗?
(3)操作可行性：系统的操作方式在这个用户组织内行得通吗?
必要时还应该从法律、社会效益等更广泛的方面研究每种解法的可行性。
展开来说，典型的可行性研究过程有下述一些步骤
复查系统规模和目标
分析员对问题定义阶段书写的关于规模种目标的报告书进一步复查确认，改正含糊或不确切的叙述，清晰地描述对目标系统的一切限制和约束
研究目前正在使用的系统
现有的系统是信息的重要来源，新的目标系统必须也能完成它的基本功能；另一方面，现有的系统必然有某些缺点，新系统必须能解决旧系统中存在的问题。此外，运行使用旧系统所需要的费用是一个重要的经济指标，如果新系统不能增加收入或减少使用费用，那么从经济角度看新系统就不如旧系统
导出新系统的高层逻辑模型
优秀的设计过程通常总是从现有的物理系统出发，导出现有系统的逻辑模型，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统；
通过上一步的工作，分析员能够使用数据流图，描绘数据在系统中流动和处理的情况，从而概括地表达出他对新系统的设想。为了把新系统描绘得更清晰准确，还应该有一个初步的数据字典，定义系统中使用的数据中。
进一步定义问题
新系统的逻辑模型实质上表达了分析员对新系统必须做什么的看法。分析员应该和用户一起再次复查问题定义、工程规模和目标，这次复查应该把数据流图和数据字典作为讨论的基础。可行性研究的前4个步骤实质上构成一 个循环。
分析员定义问题，分析这个问题，导出一个试探性的解。在此基础上再次定义问题，再一次分析这个问题，修改这个解。继续这个循环过程中直到提出的逻辑模型完全符合系统目标。
导出和评价供选择的解法
分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的(较抽象的)物理解法，供比较和选择。导出供选择的解法的最简单的途径，是从技术角度出发考虑解决问题的不同方案。
首先，根据技术可行性的考虑初步排除一些不现实的系统方案。
其次，考虑操作方面的可行性。分析员应该根据使用部门处理事务的原则和习惯检查技术上可行的那些方案。
最后考虑经济方面的可行性。分析员应该估计余下的每个可能的系统的开发成本和运行费用，并且估计相对于现有的系统而言这个系统可以节省的开支或可以增加的收入。
推荐行动方针
根据可行性研究结果应该做出的一个关键性决定是，是否继续进行这项开发工程。如果分析员认为值得继续进行这项开发工程，那么他应该选择一种最好的解法，并且说明选择这个解决方案的理由。
通常使用部门的负责人主要根据经济上是否划算决定是否投资于一项开发工程，因此分析员对于所推荐的系统必须进行比较仔细的成本/效益分析。
草拟开发计划
分析员应该为所推荐的方案草拟一份开发计划，除了制定工程进度表之外还应该估计对各类开发人员和各种资源的需要情况，应该指明什么时候使用以及使用多长时间。此外还应该估计系统生命周期每个阶段的成本，最后应给出下一个阶段(需求分析)的详细进度表和成本估计。
书写文档提交审查
应该把上述可行性研究各个步骤的工作结果写成清晰的文档，请用户、客户组织的负责人及评审组审查，以决定是否继续这项工程及是否接受分析员推荐的方案
2. 系统流程图
2.1. 系统流程图概述
系统流程图是概括地描绘物理系统的传统工具。它的基本思想是用图形符号以黑盒子形式描绘组成系统的每个部件(程序，文档，数据库，人工过程等)。
系统流程图表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程，因此尽管系统流程图的某些符号和程序流程图的符号形式相同，但是它却是物理数据流图而不是程序流程图。
2.2. 系统流程图的图符
利用符号可以把一个广义的输入输出操作具体化为读写存储在特殊设备上的文件(或数据库)，把抽象处理具体化为特定的程序或手工操作等。
2.3. 系统流程图的例子
以一个简单的例子进行讲解
某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的存量临界值等数据，记录在库存清单主文件中。当仓库中零件数量有变化时，应该及时修改库存清单主文件，如果那种零件的库存量少于它的库存量临界值，则应该报告给采购部门以便订货，规定每天向采购部门送一次订货报告。
该装配厂使用一台小型计算机处理更新库存清单主文件和产生订货报告的任务，流程如下：
零件库存量的每一次变化称为一个事务，由放在仓库中的CRT终端输入到计算机中；
系统中的库存清单程序对事务进行处理，更新存储在磁盘上的库存清单主文件，并且把必要的订货信息写在磁带上；
最后，每天由报告生成程序读一次磁带，并且打印出订货报告。如下图所示。
2.4. 系统流程图的分层
面对复杂的系统时，一个比较好的方法是分层次地描绘这个系统。
首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能。然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。这种分层次的描绘方法便于阅读者按从抽象到具体的过程逐步深入地了解一个复杂的系统。
3. 数据流图 Data Flow Diagram,DFD
3.1. 数据流图的概念
数据流图(DFD)是一种图形化的交流工具和分析设计工具，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。
在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程，是系统逻辑功能的图形表示，即使不是专业的计算机技术人员也容易理解它，因此是分析员与用户之间极好的通信工具。
此外，设计数据流图时只需考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样具体地实现这些功能。
下面的顶级DFD高度概括了数据流图的处理过程，数据从外部实体流入目标系统进行加工，然后又流出到外部实体。
3.2. 数据流图的基本图符
数据流图有四种基本符号:
正方形(或立方体)，表示数据的源点或终点；
圆角矩形(或圆形)，代表数据的加工处理；
开口矩形(或两条平行横线)，代表数据存储；
箭头表示数据流，即特定数据的流动方向。
如下图所示：
除了4个基本符号以外，数据流图还有一个附加符号，如下图所示：
3.3. 绘制数据流图
3.3.1. 绘制数据流图的步骤
概括地说：自外向内，自顶向下，逐层细化，完善求精。
首先确定系统的输入和输出，以反映系统与外界环境的接口；
顶层数据流图将软件系统描述为一个加工，以反映最主要业务处理流程，它代表系统本身。但它并未明确表达数据加工的要求；
从输入端开始，根据系统业务工作流程，画出数据流流经的各加工框，以反映数据的实际处理过程，逐步画到输出端，得到第一层数据流图。对图中的加工分别加以编号；
细化每一个加工框。如果加工框内还有数据流，可将这个加工框再细分成几个“子加工框”，并在各子加工框之间画出数据流；
一次细化一个加工。
数据流图的细化可以连续进行，直到每一个加工只执行一个简单操作为止。就是说，直到每一个加工执行一个可以用程序实现的功能为止。
