第3章 需求分析 计算机软件技术 知识基础教程 .ppt

3.1 问题定义和可行性研究 3.2 需求分析 3.3 结构化分析(SA方法)概述 3.4 数据流图 3.5 数据词典 3.6 需求分析阶段的其他工作 ? 第3章 需求分析 返回主目录 第3章 需 求 分 析 3.1 问题定义和可行性研究 软件开发一般涉及用户和开发人员，即先由用户提出问题，然后由软件开发人员给出问题的解答。但用户和开发人员往往缺乏共同的语言，用户熟悉本身的业务(如飞机订票)但不熟悉计算机技术，软件开发人员熟悉计算机技术但不了解用户的业务，软件开发人员习惯用数据结构、程序结构、编程语言等方式来讨论问题，而用户不能确切地理解这些概念，所以双方交流时存在着隔阂。更有甚者，用户本身也不知道他究竟要计算机做些什么。如果开发人员急于求成，在未明确软件系统应该“做什么”的情况下就开始进行设计、编程，直至系统完成交付给用户之后，才发现它不符合要求，但这时已太迟了。 由此人们认识到，为了开发出满意的软件系统，开发过程应该分为两大阶段进行。第一阶段是正确地确定问题，即明确地确定用户所要解决的问题是什么，并形成关于目标系统的规模和报告；第二阶段才是为问题寻找合适的解答。 作为软件开发组织，其开发软件的目的是为了利益，因此，必须对该软件项目进行可行性研究。可行性研究主要从两方面进行：从技术角度对目标系统进行可行性分析，以确定目标系统是否有可行的解；另一方面，从成本/效益角度对目标系统进行可行性分析，以确定目标系统是否值得去解，并形成有关目标系统的高层逻辑模型的报告。该模型是用某种描述方法，对问题进行逻辑上的描述，抽象出问题的实际模型，并对项目的可行性给出明确说明。 3.2 需 求 分 析 在可行性研究的基础上，就必须明确软件系统必须“做什么”，并形成有关目标系统的需求说明书，这就是需求分析Requirement Analysis )，又称需求分析阶段，其目的是澄清用户的需求。这个阶段的基本任务是：用户和软件人员双方一起来充分地理解用户的要求，并把双方共同的理解明确地表达成一份书面文档——需求说明书(Requirement Specification)。所以分析阶段的两大任务就是“理解”和“表达”，“分析”就是理解问题，“规格说明”就是按某种标准的方式把问题表达出来。 在软件生命期的各个阶段中，分析阶段是面向“问题”的，它主要是对用户的业务活动(如飞机订票)进行分析，明确在用户的业务环境中，软件系统应该“做什么”。 后面的设计、编程阶段则是面向“解答”的，这时考虑的是如何构造一个满足用户要求的系统。所以，在分析阶段，我们应集中考虑软件系统“做什么”，而尽可能少考虑系统将怎样具体实现的问题，实现问题应尽量推迟到以后的阶段去解决。 那么什么是“用户要求”(Requirements)呢？在软件工程中，所谓“用户要求”(或称“需求”)是指软件系统必须满足的所有性质和限制。用户要求通常包括功能要求、性能要求、可靠性要求、安全保密要求、开发费用、开发周期以及可使用的资源等方面的限制，其中功能要求是最基本的，它又包括数据要求和加工要求两方面。 用户和软件人员充分地理解了用户的要求之后，要将共同的理解明确地写成一份文档──需求说明书，所以需求说明书就是“用户要求”的明确表达。 由于用户的要求时时会发生变化，需求说明书也就需作相应的修改，所以需求说明书的表达方式又必须是易于修改和维护的。 总之，需求说明书应该既完整、一致、精确、无二义，又要简明易懂并易于修改和维护。显然，要达到这样的目标并不容易。 分析阶段是保证软件质量的第一步，如何分析用户要求，需求说明书用什么形式表示等都需要有一定的技术来指导。由于分析阶段是同用户进行讨论，因此这个阶段的方法、模型、语言和工具都必须考虑到用户的特点。20世纪70年代以来，逐步出现了多种适用于分析阶段的技术，但是至今还没有出现既能完整精确地描述大型系统的用户要求，又能简单易懂地被广大用户接受的形式语言，目前大多数软件系统的需求说明书还是用非形式化的方式(例如用图形或自然语言等)表示的。 3.3 结构化分析(SA方法)概述 3.3.1 由顶向下逐层分解 软件工程技术中，控制复杂性的两个基本手段是“分解”和“抽象”。对于一个复杂的问题，由于人的理解力、记忆力均有限，所以不可能触及到问题的所有方面以及全部的细节。为了将复杂性降低到人可以掌握的程度，可以把大问题分割成若干个小问题，然后分别解决，这就是“分解”。分解也可以分层进行，即先考虑问题最本质的属性。暂把细节略去，以后