软件技术基础第3章节[8).ppt

3.1 问题定义和可行性研究 3.2 需求分析 3.3 结构化分析(SA方法)概述 3.4 数据流图 3.5 数据词典 3.6 需求分析阶段的其他工作 ?;第3章 需 求 分 析; 由此人们认识到，为了开发出满意的软件系统，开发过程应该分为两大阶段进行。第一阶段是正确地确定问题，即明确地确定用户所要解决的问题是什么，并形成关于目标系统的规模和报告；第二阶段才是为问题寻找合适的解答。 作为软件开发组织，其开发软件的目的是为了利益，因此，必须对该软件项目进行可行性研究。可行性研究主要从两方面进行：从技术角度对目标系统进行可行性分析，以确定目标系统是否有可行的解；另一方面，从成本/效益角度对目标系统进行可行性分析，以确定目标系统是否值得去解，并形成有关目标系统的高层逻辑模型的报告。该模型是用某种描述方法，对问题进行逻辑上的描述，抽象出问题的实际模型，并对项目的可行性给出明确说明。;3.2 需 求 分 析; 后面的设计、编程阶段则是面向“解答”的，这时考虑的是如何构造一个满足用户要求的系统。所以，在分析阶段，我们应集中考虑软件系统“做什么”，而尽可能少考虑系统将怎样具体实现的问题，实现问题应尽量推迟到以后的阶段去解决。 那么什么是“用户要求”(Requirements)呢？在软件工程中，所谓“用户要求”(或称“需求”)是指软件系统必须满足的所有性质和限制。用户要求通常包括功能要求、性能要求、可靠性要求、安全保密要求、开发费用、开发周期以及可使用的资源等方面的限制，其中功能要求是最基本的，它又包括数据要求和加工要求两方面。 用户和软件人员充分地理解了用户的要求之后，要将共同的理解明确地写成一份文档──需求说明书，所以需求说明书就是“用户要求”的明确表达。; 需求说明书主要有以下三个作用： (1) 作为用户和软件人员之间的合同，为双方相互了解提供基础。 (2) 反映出问题的结构，可以作为软件人员进行设计和编程的基础。 (3) 作为验收的依据，即作为选取测试用例（如进行形式验证）的依据。 这三种作用对需求说明书提出了不同的、有些矛盾的要求。 作为设计的基础和验收的依据，需求说明书应该是精确而无二义的，这样才不致被人误解。需求说明书越精确，以后出现错误、混淆、反复的可能性就越少。; 例如“本系统应能令人满意地处理所有的输入信息”是一种含糊不清的描述，验收时无法检查这一要求是否满足。又如“响应时间足够快”也是不明确的，而“响应时间小于3秒”则是精确的描述，在测试时可以检查系统“满足”还是“不满足”这个要求。 用户能看懂需求说明书，并能发现和指出其中的错误是保证软件系统质量的关键，所以需求说明书必须简明易懂，尽量不包含计算机技术中的概念和术语，使用户和软件人员双方都能接受它。 由于用户往往不是一个人，而是企业组织中各个部门的好几个工作人员，他们可能提出相互冲突的要求，分析阶段必须协调和解决这些冲突，最后在需求说明书中表达的应该是一致的、无矛盾的用户要求。; 由于用户的要求时时会发生变化，需求说明书也就需作相应的修改，所以需求说明书的表达方式又必须是易于修改和维护的。 总之，需求说明书应该既完整、一致、精确、无二义，又要简明易懂并易于修改和维护。显然，要达到这样的目标并不容易。 分析阶段是保证软件质量的第一步，如何分析用户要求，需求说明书用什么形式表示等都需要有一定的技术来指导。由于分析阶段是同用户进行讨论，因此这个阶段的方法、模型、语言和工具都必须考虑到用户的特点。20世纪70年代以来，逐步出现了多种适用于分析阶段的技术，但是至今还没有出现既能完整精确地描述大型系统的用户要求，又能简单易懂地被广大用户接受的形式语言，目前大多数软件系统的需求说明书还是用非形式化的方式(例如用图形或自然语言等)表示的。;3.3 结构化分析(SA方法)概述; 图3.1中系统S很复杂，为了理解它，可以将它分解成S1和S2两个子系统；如果子系统S1仍然很复杂，可以将它们再分解成S1.1和S1.2 等子系统，如此继续下去，直到子系统足够简单，能够清楚地被理解和表达为止。 对系统作了合理的逐层分解后，我们就可分别理解系统的每一个细节(图3.1中的S1.1、S1.2、S2.1、S2.2等)，并为每个细节写下说明(称为“小说明”)，再将所有这些“小说明”组织起来，就获得了整个系统S的系统说明书。 “逐层分解”体现了分解和抽象的原则，它使人们不至于一下子陷入细节，而是