软件技术基础第3章.ppt

《软件技术基础第3章.ppt》由会员分享，可在线阅读，更多相关《软件技术基础第3章.ppt（36页珍藏版）》请在三一办公上搜索。

1、3.1 问题定义和可行性研究3.2 需求分析3.3 结构化分析(SA方法)概述3.4 数据流图3.5 数据词典3.6 需求分析阶段的其他工作,第3章 需求分析,返回主目录,第3章 需 求 分 析,3.1 问题定义和可行性研究 软件开发一般涉及用户和开发人员，即先由用户提出问题，然后由软件开发人员给出问题的解答。但用户和开发人员往往缺乏共同的语言，用户熟悉本身的业务(如飞机订票)但不熟悉计算机技术，软件开发人员熟悉计算机技术但不了解用户的业务，软件开发人员习惯用数据结构、程序结构、编程语言等方式来讨论问题，而用户不能确切地理解这些概念，所以双方交流时存在着隔阂。更有甚者，用户本身也不知道他究竟要

2、计算机做些什么。如果开发人员急于求成，在未明确软件系统应该“做什么”的情况下就开始进行设计、编程，直至系统完成交付给用户之后，才发现它不符合要求，但这时已太迟了。,由此人们认识到，为了开发出满意的软件系统，开发过程应该分为两大阶段进行。第一阶段是正确地确定问题，即明确地确定用户所要解决的问题是什么，并形成关于目标系统的规模和报告；第二阶段才是为问题寻找合适的解答。作为软件开发组织，其开发软件的目的是为了利益，因此，必须对该软件项目进行可行性研究。可行性研究主要从两方面进行：从技术角度对目标系统进行可行性分析，以确定目标系统是否有可行的解；另一方面，从成本/效益角度对目标系统进行可行性分析，以确

3、定目标系统是否值得去解，并形成有关目标系统的高层逻辑模型的报告。该模型是用某种描述方法，对问题进行逻辑上的描述，抽象出问题的实际模型，并对项目的可行性给出明确说明。,3.2 需 求 分 析,在可行性研究的基础上，就必须明确软件系统必须“做什么”，并形成有关目标系统的需求说明书，这就是需求分析Requirement Analysis)，又称需求分析阶段，其目的是澄清用户的需求。这个阶段的基本任务是：用户和软件人员双方一起来充分地理解用户的要求，并把双方共同的理解明确地表达成一份书面文档需求说明书(Requirement Specification)。所以分析阶段的两大任务就是“理解”和“表达”，

4、“分析”就是理解问题，“规格说明”就是按某种标准的方式把问题表达出来。在软件生命期的各个阶段中，分析阶段是面向“问题”的，它主要是对用户的业务活动(如飞机订票)进行分析，明确在用户的业务环境中，软件系统应该“做什么”。,后面的设计、编程阶段则是面向“解答”的，这时考虑的是如何构造一个满足用户要求的系统。所以，在分析阶段，我们应集中考虑软件系统“做什么”，而尽可能少考虑系统将怎样具体实现的问题，实现问题应尽量推迟到以后的阶段去解决。那么什么是“用户要求”(Requirements)呢？在软件工程中，所谓“用户要求”(或称“需求”)是指软件系统必须满足的所有性质和限制。用户要求通常包括功能要求、性

5、能要求、可靠性要求、安全保密要求、开发费用、开发周期以及可使用的资源等方面的限制，其中功能要求是最基本的，它又包括数据要求和加工要求两方面。用户和软件人员充分地理解了用户的要求之后，要将共同的理解明确地写成一份文档需求说明书，所以需求说明书就是“用户要求”的明确表达。,需求说明书主要有以下三个作用：(1)作为用户和软件人员之间的合同，为双方相互了解提供基础。(2)反映出问题的结构，可以作为软件人员进行设计和编程的基础。(3)作为验收的依据，即作为选取测试用例（如进行形式验证）的依据。这三种作用对需求说明书提出了不同的、有些矛盾的要求。作为设计的基础和验收的依据，需求说明书应该是精确而无二义的，

6、这样才不致被人误解。需求说明书越精确，以后出现错误、混淆、反复的可能性就越少。,例如“本系统应能令人满意地处理所有的输入信息”是一种含糊不清的描述，验收时无法检查这一要求是否满足。又如“响应时间足够快”也是不明确的，而“响应时间小于3秒”则是精确的描述，在测试时可以检查系统“满足”还是“不满足”这个要求。用户能看懂需求说明书，并能发现和指出其中的错误是保证软件系统质量的关键，所以需求说明书必须简明易懂，尽量不包含计算机技术中的概念和术语，使用户和软件人员双方都能接受它。由于用户往往不是一个人，而是企业组织中各个部门的好几个工作人员，他们可能提出相互冲突的要求，分析阶段必须协调和解决这些冲突，最

7、后在需求说明书中表达的应该是一致的、无矛盾的用户要求。,由于用户的要求时时会发生变化，需求说明书也就需作相应的修改，所以需求说明书的表达方式又必须是易于修改和维护的。总之，需求说明书应该既完整、一致、精确、无二义，又要简明易懂并易于修改和维护。显然，要达到这样的目标并不容易。分析阶段是保证软件质量的第一步，如何分析用户要求，需求说明书用什么形式表示等都需要有一定的技术来指导。由于分析阶段是同用户进行讨论，因此这个阶段的方法、模型、语言和工具都必须考虑到用户的特点。20世纪70年代以来，逐步出现了多种适用于分析阶段的技术，但是至今还没有出现既能完整精确地描述大型系统的用户要求，又能简单易懂地被广

8、大用户接受的形式语言，目前大多数软件系统的需求说明书还是用非形式化的方式(例如用图形或自然语言等)表示的。,3.3 结构化分析(SA方法)概述,3.3.1 由顶向下逐层分解 软件工程技术中，控制复杂性的两个基本手段是“分解”和“抽象”。对于一个复杂的问题，由于人的理解力、记忆力均有限，所以不可能触及到问题的所有方面以及全部的细节。为了将复杂性降低到人可以掌握的程度，可以把大问题分割成若干个小问题，然后分别解决，这就是“分解”。分解也可以分层进行，即先考虑问题最本质的属性。暂把细节略去，以后再逐层添加细节，直至涉及到最详细的内容，这就是“抽象”，SA方法也是采用了这两个基本手段。对于一个复杂的系

9、统(例如银行管理系统)，如何理解和表达它的功能呢?SA方法使用了“由顶向下逐层分解”的方式。,图3.1中系统S很复杂，为了理解它，可以将它分解成S1和S2两个子系统；如果子系统S1仍然很复杂，可以将它们再分解成S1.1和S1.2 等子系统，如此继续下去，直到子系统足够简单，能够清楚地被理解和表达为止。对系统作了合理的逐层分解后，我们就可分别理解系统的每一个细节(图3.1中的S1.1、S1.2、S2.1、S2.2等)，并为每个细节写下说明(称为“小说明”)，再将所有这些“小说明”组织起来，就获得了整个系统S的系统说明书。“逐层分解”体现了分解和抽象的原则，它使人们不至于一下子陷入细节，而是有控制

10、地逐步了解更多的细节，这是有助于理解问题的。,图3.1 由顶向下逐层分解示例,图3.1的顶层抽象地描述了整个系统，底层具体地画出了系统的每一个细节，而中间层则是从抽象到具体的逐步过渡。按照这样的方式，无论系统多么复杂，分析工作都可以有计划、有步骤并有条不紊地进行。系统规模再大，分析工作的复杂程度也不会随之增大，只是多分解几层而已，所以SA方法有效地控制了复杂性。,3.3.2 描述方式 由于目前还没有出现既能精确地描述大型系统的用户要求，又简明易懂的形式语言，因此SA方法采用了介于形式语言和自然语言之间的描述方式。它虽然不如形式语言精确，但是简明易懂，所表达的意义也比较明确。用SA方法获得的需求

11、说明书由以下几部分组成：(1)一套分层的数据流图；(2)一本数据词典；(3)一组小说明；(4)补充材料。,这套文档中，“数据流图”描述系统的分解，即描述系统由哪些部分组成、各部分之间有什么联系等；“数据词典”描述系统中的每一个数据；“小说明”则详细描述系统中的每一个加工所完成的操作。上述资料再加上视系统而定的各种补充材料就可明确而完整地描述一个系统的功能。SA方法在描述方式上的特点是尽量采用图形表示，因为图形比较形象、直观、易于理解，一张图的表达效果可能比几千字的叙述还要好。,3.4 数 据 流 图,数据流图主要用来描述目标系统的逻辑模型。下面分析数据流图的基本成分。SA方法采用“分解”的方式

12、来理解一个复杂的系统，“分解”需要有描述的手段，数据流图(Data Flow Diagram)就是作为描述“分解”的手段而引进的。对大多数数据处理系统来说，从数据流的角度来描述一个企事业组织的业务活动是比较合适的。数据流图描述了一个组织有哪几个组成部分，也描述了来往于各部分之间的数据流。下面先看一个例子。,假定要为某培训中心研制一个计算机管理系统。我们首先需分析这个系统应该做些什么，为此必须分析培训中心的业务活动。培训中心是一个功能很复杂的系统，它为在职人员开设许多门课程，有兴趣的人可以来电或来函报名选修某门课程，培训中心要收取一定的费用，学员通过支票付款，也可以来电或来函查询课程计划等有关事

13、宜。培训中心的日常业务是：将学员发来的电报、信件、电话收集分类后，按几种不同情况处理。如果是报名的，则将报名数据送给负责报名事务的职员，他们要查阅课程文件，检查某课程是否额满，然后在学生文件、课程文件上登记，并开出报名单交财务部门，财务人员再开出发票经复审后通知学员。,如果是付款的，则由财务人员在帐目文件上登记，再经复审后发给学员一张通知单。如果是查询的，则交查询部门查阅课程文件后给出答复。如果是想注销原来已选修的课程，则由注销人员在课程、学生、帐目文件上作相应修改，经复审后通知学员。对一些要求不合理的函电，培训中心将拒绝处理。我们可以用图3.2的数据流图描述这个系统的“分解”。这张图告诉我们

14、：系统分解成“收集”、“分类”、“报名”等八个部分，这些部分之间通过图中所示的数据流进行联系，要理解整个系统只需分别理解这八个部分就可以了。由于每个部分比整个系统小多了，所以分析工作就可以简化。从图3.2看出，数据流图有四种基本成分：,(1)数据流(用箭头表示)；(2)加工(用圆表示)；(3)文件(用直线段表示)；(4)数据流的源点或终点(用方框表示)。数据流图中的每个成分都有一个互不相同的名字来加以区分。下面分别讨论各种成分。1.数据流 数据流由一组固定成分的数据组成。在图3.2中，数据流“报名请求”由“姓名”、“年龄”、“性别”、“单位名”、“课程名”等成分组成，数据流“发票”由“姓名”、

15、“单位名”、“金额”组成，它们的组成成分都是确定的。,图3.2 数据流图,数据流可以从加工流向加工，也可以从加工流向文件或从文件流向加工，也可以从源点流向加工或从加工流向终点。一般来说，除了流向文件或从文件流出的数据流不必命名之外(在这种情况下，有文件名已足够了)，每个数据流都必须有一个合适的名字。名字一方面是为了区别，同时也是给人一个直观的印象，使人容易理解这个数据流的含义。应该注意的是：数据流图中描述的是数据流而不是控制流。图3.3 中“取下一张卡片”是一个控制流而不是数据流，因为并没有任何数据沿着这个箭头流动，所以这个箭头应该从图中删去。习惯使用框图(程序流程图)的软件人员特别应该注意不

16、要犯这种错误。,图3.3 数据流和控制流,2.加工 加工是对数据进行的操作。在图3.2中，“报名”、“产生发票”、“查询”等都是加工，加工的名字也应适当地反映这个加工的含义，使之容易理解。3.文件 文件是暂时存储的数据。图3.2中有“学生”、“课程”、“帐目”等文件。文件的名字也应适当地选择，以便理解。我们还应注意加工与文件之间数据流的方向，如果加工要读文件，则数据流是从文件流出的；如果加工要写文件或修改文件(虽然修改文件一般先要读文件，但其本质是写)，则数据流是流向文件的；如果加工既要读文件(除了修改文件之外)又要写文件，则数据流是双向的。在图3.4中，加工“检查拼写的正确性”对输入的词进行

17、检查。,图3.4 源点和终点,4.源点和终点 一个数据处理系统的内部用数据流、文件和加工三种成分表示一般已足够了，然而为了便于理解，有时还可以画出数据流的源点和终点来说明它的来龙去脉。源点和终点通常是存在于系统之外的人员或组织，如图3.2 中“学员”是数据流“函电”的源点，也是数据流“通知单”的终点。画出源点和终点只是起到注释作用和帮助理解而已，由于它们是系统之外的事物，我们对此是不大关心的，所以源点和终点的表达不必很严格。总之，数据流图从“数据”和“数据的加工”这两个相互补充的方面来表达一个数据处理系统。它从数据的角度描述它们作为输入进入系统，经过某个加工，再经过某个加工，或者合并，或者分解

18、，或者存储，最后成为输出离开系统。,经验证明，对数据处理系统来说，从数据角度观察问题一般能够较好地抓住问题的本质，并描述出系统的概貌。但是，数据流图只描述了系统的“分解”，它并没有表达出每个数据和加工的具体含义，这些信息需在“数据词典”和“小说明”中表达出来。数据流图的优点是直观、容易理解，容易被一组人同时进行审查。如果图中有错误，一般也比较显眼，容易被人们发现。实践证明，从事数据处理工作的人(包括用户和软件开发人员)都很容易接受这个描述方式。,3.5 数 据 词 典,3.5.1 数据词典与数据流图的联系 数据流图描述了系统的“分解”，即描述了系统由哪几部分组成，各部分之间有什么联系等，但是并

19、没有说明系统中各个成分是什么含义，因此仅仅一套数据流图并不能构成系统的需求说明书，只有为图中出现的每一个成分都给出明确定义之后，才较完整地描述了一个系统。数据流图中所有名字的定义就构成了一本词典，同日常使用的词典一样。SA方法所用的词典也是这样一个工具，当我们不知道某个名字的含义时，借助于它就可查出这个名字的含义。词典中所有条目应该按一定次序排列起来，这样才能供人们方便地查阅。,数据流图与词典是密切联系的，两者结合在一起才构成了“需求说明书”，单独一套数据流图或单独一本词典都是没有任何意义的。数据流图中出现的每一个数据流名、每一个文件名和每一个加工名在词典中都应有一个条目给出这个名字的定义。此

20、外，在定义数据流、文件和加工时，又要引用到它们的组成部分，所以每一个组成部分在词典中也应有一个条目给出其定义。,3.5.2 数据词典条目的各种类型 词典中包含以下四种类型的条目：(1)数据流；(2)文件；(3)数据项(指不能再分解的数据单位)；(4)加工。数据流、文件和数据项等数据型条目构成了数据词典(Data Dictionary)。1.数据流条目 数据流条目给出某个数据流的定义，它通常是列出该数据流的各组成数据项。,如图3.2中的数据流“报名单”由“姓名”、“单位名”、“年龄”、“性别”和“课程名”等数据项组成，词典中“报名单”这个条目就可写成 报名单姓名单位名年龄性别课程名 有些数据流的

21、组成很复杂，一下子列出它所有的数据项可能不易使人理解，此时同样可采用“由顶向下逐步分解”的方式来说明，例如某学校管理系统中，有个名为“课程”的数据流，它由“课程名”、“教员”、“教材”和“课程表”组成，而“课程表”又由“星期几”、“第几节”和“教室”组成，则词典中可以建立“课程”及“课程表”两个条目，它们分别是 课程课程名教员教材课程表 课程表星期几第几节教室,这样，只要依次查阅这两个条目，就可确切地理解“课程”这个名字的含义。给出数据流的定义时，需要使用一些简单的符号，如：表示“与”；：表示“或”，即选择括号中的某一项；：表示“重复”，即括号中的项要重复若干次，重复次数的上、下限也可在括号边

22、上标出；（）：表示“可选”，即括号中的项可能没有。分析员可根据自己的习惯，选择使用类似的符号。其中自定义的符号应说明其功能。下面再给出一个数据流条目的例子：,数据流“发票”由15个“发票行”组成，而每个“发票行”又由“货名”、“数量”、“单位”和“总价”组成，则词典中的“发票”条目是 发票货名数量单价总价 也可分别建立“发票”和“发票行”两个条目，它们是 发票发票行 发票行货名数量单价总价 2.文件条目 文件条目给出某个文件的定义，同数据流一样，文件的定义通常是列出其记录的组成数据项。此外，文件条目还可指出文件的组织方式，如“按帐号递增次序排列”等。,是一个例子：帐目帐号户名地址款额日期 组织

23、：按帐号递增次序排列。3.数据项条目 数据项条目给出某个数据项的定义，这通常是该数据项的值类型、允许值等，例如“帐号”这个数据项的值可以是0000099999之间的任意整数，则词典条目“帐号”可写成：帐号0000099999 又如，数据项“日期”可取1997/112/131等值，则词典条目“日期”可写成：日期1997/112/131,有了这样的词典，我们只要依次查阅“帐目”、“帐号”、“日期”等条目，就可了解文件“帐目”的精确含义了。有些数据项本身名字已足以说明其含义，如词典条目“学生”中：学生姓名年龄性别班级 这里“姓名”、“年龄”、“性别”等数据项的含义是不言而喻的，所以就不必再解释了，这

24、些名字称为是“自定义”的，自定义的词在词典中就不必再给出条目了。词典条目的具体格式往往因系统而异，它也同用户习惯使用的表达方式有关。,3.6 需求分析阶段的其他工作,除了前面讨论的工作之外，需求分析阶段还应完成下列工作：1)确定设计限制 软件的设计要受到系统以外许多因素的影响，如成本、进度、可用的软硬件资源等。因此分析还必须确定设计的限制，并试图说明每种限制都是合理的。2)确定验收准则 在同用户讨论时，分析员应该提出这样的问题：“如果明天就将系统交给你，你凭什么认为这个系统是成功的?”。这个问题和相应的回答便构成了一组验收准则。验收准则应该尽可能具体，用于确认每个主要功能的测试方法也应同时确定

25、下来。,用户往往会很一般地回答上述问题，而分析员必须寻求精确的答复，他应该认识到：如果不能精确地规定这些准则，则说明用户需求还是模糊的。验收准则是测试计划的基础，如果被忽视了，就是开发人员的失职。3)编写“初步用户手册”“初步用户手册”为系统的操作员描绘了软件系统的外貌，并能说明需求分析工作是否已确定了软件系统的所有主要输入和输出，该手册还可用来评价系统的人机界面。用户在审查“初步用户手册”时经常会这样说：“我想这不是我们启动这个功能的方式，这不行，因为”。这些评论最好在分析阶段就做出，到系统验收时才说就太迟了。,需求说明书写成之后，用户和分析员应该对它进行复查，争取系统还只在纸上时就发现其中的错误并及时纠正。开发人员应该检查是否正确地理解了问题的整个含义，仔细评价全部文档的完整性、一致性、正确性和清晰性。复查的结果几乎总是修改并重新定义某些需求，需求分析中的这些反复正是所期望的，甚至是值得提倡的。最后，一份能被用户和开发人员双方共同接受的需求说明书终于产生。需求说明书的篇幅可能较长，我们可将各种图形和文字材料适当装订起来，分成章节，再加上前言、目录等，编成一本易于阅读的手册。需求说明书将为软件系统的设计、实现和验收奠定良好的基础。获得用户和开发人员共同确认的需求说明书，就是分析阶段胜利完成的里程碑。,