软件工程导论之第3章 需求分析(第五版课件

第3章软件需求分析,教学目的与要求：深刻理解需求分析阶段的概念及任务，熟练掌握ER图，HIOP图的画法。教学重点：需求分析阶段的任务、方法、具体任务。教学难点：写出需求规格说明书,第3章需求分析,3.1需求分析的任务3.2与用户沟通获取需求的方法3.3分析建模与规格说明3.4实体-联系图3.5数据规范化,3.6状态转换图3.7其他图形工具3.8验证软件需求3.9小结习题,3.2与用户沟通获取需求的方法,需求获取的关键在于通过与用户的沟通和交流，收集和理解用户的各项要求。3.2.(1)访谈-访问用户和用户领域的专家(2)需求讨论会(3)问卷调查(4)现场考察3.2.(5)快速建立软件原型-原型化方法(6)基于用例的方法,1.用户面谈,用户面谈一种理解商业功能和商业规则的最有效方法面谈过程需要认真的计划和准备面谈之前确立面谈目的确定要包括的相关用户确定参加会议的项目小组成员建立要讨论的问题和要点列表复查有关文档和资料确立时间和地点通知所有参加者有关会议的目的、时间和地点,52,1.用户面谈,面谈过程需要认真的计划和准备（续）,进行面谈衣着得体，准时到达寻找异常和错误情况深入调查细节详细记录指出和记录下未回答条目和未解决问题面谈之后复查笔记的准确性、完整性和可理解性把所收集的信息转化为适当的模型和文档确定需要进一步澄清的问题域适当的时候向参加会议的每一个人发一封感谢信,53,2.需求专题讨论会,需求专题讨论会,-项目主要风险承担人在短暂而紧凑的时间段内集中在一起，一般为1至2天，与会者可以在应用需求上达成共识、对操作过程尽快取得统一意见。,优点,协助建立一支高效的团队，围绕项目成功的目标；-所有的风险承担人都畅所欲言；,促进风险承担人和开发团队之间达成共识；-揭露和解决那些妨碍项目成功的行政问题；-能够很快地产生初步的系统定义。,54,2.需求专题讨论会,专题讨论会准备,-参加会议人员：主持人、用户、技术人员、项目组人员-安排日程：通常在具有相应支持设备的专用房间进行,举行会议,-可能出现行政间的责备或冲突，主持人应掌握讨论气氛并控制会场。,-会议最重要的部分是自由讨论阶段，这种技术非常符合专题讨论会的气氛，并且营造一种创造性的和积极的氛围，同时可以获得所有相关者的意见。,-注意分配会议时间，记录所有言论。,55,2.需求专题讨论会,56,3.问卷调查,问卷调查,-可用于确认假设和收集统计倾向数据-问卷需要快速回答，允许匿名方式存在问题,-相关的问题不能事先决定,问题背后的假设对答案造成偏颇，如这符合你的期望吗？-难以探索一些新领域,-难以继续用户的模糊响应,在完成最初的面谈和分析后，可作为一项协作技术可以收到良好的效果。,57,4.现场考察,现场观察商业过程和工作流程,-掌握用户如何实际使用一个系统以及到底用户需要哪些信息，最好的办法是亲自观察用户是如何完成实际工作的。,一般方法,-对办公室进行快速浏览，了解布局、设备要求和使用、工作流总体情况。,-安排几个小时观察用户是如何实际完成他们的工作，理解用户实际使用计算机系统和处理事务的细节。,像用户一样接受训练和做实际工作，发现关键问题和瓶颈。注意：观察可能使用户紧张。,58,5.原型化方法,原型化方法,-一个软件原型是所提出的新产品的部分实现，帮助开发人员、用户以及客户更好地理解系统的需求，它比开发人员常用的技术术语更易于理解。,建立原型的原因,-解决在产品开发的早期阶段需求不确定的问题，用户、经理和其他非技术项目风险承担者发现在确定和开发产品时，原型可以使他们的想象更具体化。,基于WEB的应用系统原型,-使用HTML进行界面设计,59,6.基于用例的方法,用例建模是以任务和用户为中心的，开发和描述用户需要系统做什么。,用例建模的步骤,-确定系统的参与者-确定场景,-确定系统用例,-确定用例之间的关系-编写用例描述文档,60,3.3.1分析建模1、问题识别双方确定对问题的综合需求。基于项目有关的软件的功能、性能、环境、用户界面、可靠性、安全性、保密性、可移植性、可维护性、等方面的需求。,3.3分析建模与规格说明需求分析的步骤,2、分析和综合导出软件的逻辑模型,2、分析和综合导出软件的逻辑模型1）分析人员对获取的需求进行一致的分析检查，逐步细化软件功能，划分各子功能；2）对系统数据域进行分解，分配到各子功能上；3）用图文结合的形式，建立新系统的逻辑模型和物理视图。物理视图指系统数据输入输出使用什么设备或方式，例键盘输入、数据扫描、数据传送等方式。,3.3.2软件需求规格说明,3.3.2软件需求规格说明软件需求规格说明书，是需求分析阶段得出的最主要的文档。补充：需求分析阶段要编写文档：1）编写“需求规格说明书”2）编写初步用户手册3）编写“确认测试计划”(为系统完成后确认验收的依据).4）修改完善软件开发计划需求规格说明书写法见实验指导书,3.4实体-联系图（E-R图）,应该包括在SRS（需求规格说明）中的内容-功能：软件应该提供什么功能？外部接口：软件如何与人、系统硬件和其他系统等进行相互作用？-性能：软件系统在运行速度、可用性、响应时间、恢复时间等方面有什么要求？-特性：软件系统在可移植性、可维护性、安全性等方面有什么考虑？设计约束：是否存在必要的标准、开发语言、数据库、资源限制、运行环境等因素的影响和策略？不应该包括在SRS中的内容-项目开发计划:如成本、人员、进度、工具、方法等-产品保证计划:如配置管理、验证与测试、质量保证等-软件设计细节:需求通常用于表达“做什么”，而不描述“如何做”。,编写需求规格说明的原则,原则1：只描述“做什么”而无须描述“怎么做”原则2：必须说明运行环境原则3：考虑用户、分析员和实现者的交流-对形式化和自然语言之间作出恰当的选择-明确的理解最重要，不存在十全十美的软件规格说明书,编写需求规格说明的原则,原则4：力求寻找到恰如其分的需求详细程度-一个有益的原则就是编写单个的可测试需求文档-建议将可测试的需求作为衡量软件产品规模大小的尺度原则5：文档段落不宜太长简短-记住：不要在需求说明中使用“和/或”、“等等”之类的词原则6：避免使用模糊的、主观的术语-如用户友好、容易、简单、迅速、有效、许多、最新技术、优越的、可接受的、最大化、最小化、提高等-不可验证建议：采用一种标准的SRS模板,需求工程,需求工程是应用已证实有效的原理和方法，并通过合适的工具和符号，系统地描述出待开发系统及其行为特征和相关约束。,活动,持续进行的需求管理需求,需求获取,需求分析,需求验证,规格说明,工作产品,已确认的,需求规格,会议记录等,分析模型,需求规格,说明书,说明书,22,为了把用户的数据要求清楚、准确地描述出来，系统分析员通常建立一个概念性的数据模型(也称为信息模型)。数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。3.4.1数据对象3.4.2属性3.4.3联系3.4.4实体-联系图的符号通常，使用实体-联系图(entity-relationshipdiagram)来建立数据模型。可以把实体-联系图简称为ER图，相应地可把用ER图描绘的数据模型称为ER模型。,3.4实体-联系图（E-R图）,ER信息模型的设计,ER信息模型的设计ER方法是英文entityrelationshipapproach的简称，译作实体一联系方法。此法通过ER图形表示信息世界中的实体、属性、关系的模型。1）ER图约定：实体用方框表示，联系用菱形框表示。框内填入相应的实体名，联系名及属性名。下图举了三个例子，表示了二个实体间的联系，而三个例子由三种不同的联系方法。,三个例子,三个例子，表示了二个实体间的联系，而三个例子由三种不同的联系方法。,第一种情况,第一种情况：是一对一的关系，一个工厂只有一个正厂长。第二种情况：是一对多的联系，一个仓库存放多种和多个产品；第三种情况：是多对多的联系，一个学生要学习多门课程，而一门课程又有多名学生学习，所以是多对多的联系。同时从图中也可看出联系也可能有属性，如存放有属性数量，学习有属性成绩等。2）如何设计ER图先画出局部ER图，再对局部ER加以综合，产生一个总体ER图,先画出局部ER图，再对局部ER加以综合，产生一个总体ER图。,软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。下面给出第一、第二和第三范式的定义：(1)第一范式在同一表中没有重复项出现，如果有则应将重复项去掉。每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。,3.5数据规范化,(2)第二范式满足第一范式条件,(2)第二范式满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)。每个表必须有一个（而且仅一个）数据元素为主关键字，其它元素与主关键字一一对应。(3)第三范式符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)。表中的所有数据元素，不但要能够唯一地被主关键字所标识，而且它们之间还必须相互独立，不存在其它的函数关系。,3.6状态转换图,根据本章开头讲的结构化分析的第3条准则，在需求分析过程中应该建立起软件系统的行为模型。状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。因此，状态图提供了行为建模机制，可以满足第3条分析准则的要求。（面向对象模型中介绍）,3.6状态转换图（略）,3.7其他图形工具,3.7其他图形工具3.7.1层次方框图(H图）层次方框图是用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。,3.7.2Warnier图,图3.5层次方框图的一个例子,法国计算机科学家Warnier提出了表示信息层次结构的另外一种图形工具。和层次方框图类似，Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。,3.7.2Warnier图,HIPO图,图3.6Warnier图的一个例子,3.7.3HIPO图HIPO（HierarchyPlusInputProcessOutput）图，是IBM公司于70年代中期在层次结构图的基础上，做出的一种描述系统结构和模块内部处理功能的工具。HIPO图，有H图和IPO图两部分组成。H图描述整个系统的设计结构合格模块之间的关系，H图画n层，每层根据经验一般为310个模块，层次（n层）按具体情况定。IPO图描述某一特定模块内部的处理过程和输入输出关系。HIPO图一般有1张H图，多张IPO图组成,层次模块结构图,H图特点,层次模块结构图（H图）,1、H图基本做法：是将系统划分为若干子系统，子系统下再划分为若干的模块，大模块内再分子模块。2、H图特点：主要关心模块的外部属性，不关心模块的内部，即只关心它是什么能够作什么，不关心它怎么做。（怎么做IPO图解决）3、模块的定义(什么是模块)：具有输入输出、逻辑功能、运行程序和内部数据这四种属性的一个程序。IPO图IPO图是输入、处理、输出图的简称,图3.7IPO图的一个例子图,图3.7IPO图的一个例子图,c.5.4.4上组模块送入出入库单据,1核对纪录2核对价格3核对用户纪录4记录合格,将合格标志送回上一级模块c.5.4.4,模块编号:c.5.5.8,图3.8改进的IPO图的形式,图3.8改进的IPO图的形式,本书建议使用一种改进的IPO图(也称为IPO表)，,3.8验证软件需求,需求工程,需求工程是应用已证实有效的原理和方法，并通过合适的工具和符号，系统地描述出待开发系统及其行为特征和相关约束。,活动,持续进行的需求管理需求,需求获取,需求分析,需求验证,规格说明,工作产品,已确认的,需求规格,会议记录等,分析模型,需求规格,说明书,说明书,22,需求验证是检验需求能否满足客户的意愿。需求验证的技术需求评审：由不同代表（如分析员、客户、设计人员、测试人员）组成的评审小组以会议形式对需求进行系统性分析。原型评价：客户和用户在一个可运行的系统模型上实际检验系统是否符合他们的真正需要。-测试用例生成：通过设计具体的测试方法，发现需求中的许多问题。,3.8验证软件需求3.8.2验证软件需求的方法,3.8.1从哪些方面验证软件需求的正确性,33,需求验证主要围绕需求规格说明的质量特性展开。它主要是：正确性无二义性完整性可验证性一致性可修改性可跟踪性,需求规格说明的质量特性,正确性需求规格说明对系统功能、行为、性能等的描述必须与用户的期望相吻合，代表了用户的真正需求。审查需求的正确性应该考虑的问题用户参与需求过程的程度如何？-每一个需求描述是否准确地反映了用户的需要？-系统用户是否已经认真考虑了每一项描述？需求可以追溯到来源吗？举例：下面的需求描述正确吗？-在用户每次存钱的时候系统将进行信用检查。,34,需求规格说明的质量特性,无二义性-需求规格说明中的描述对于所有人都只能有一种明确统一的解释。审查需求的无二义性应该考虑的问题-需求规格说明是否有术语词汇表？-具有多重含义或未知含义的术语是否已经定义？-需求描述是否可量化和可验证？每一项需求都有测试准则吗？举例：下面的需求描述是无歧义的吗？-如果用户试图透支，系统将采取适当的行动。,35,需求规格说明的质量特性,完整性-需求规格说明应该包括软件要完成的全部任务，不能遗漏任何必要的需求信息。审查需求的完整性应该考虑的问题-是否存在遗漏的功能或业务过程？-在每个定义的功能之间是否有接口？-是否有信息或消息在所定义的功能之间传递？-是否定义了功能的使用者？-是否已经清楚地定义了用户与功能之间的交互？-是否定义了与外部过程和系统之间的接口？,36,需求规格说明的质量特性,审查需求的完整性应该考虑的问题（续）-所描述的功能是否可以映射到业务过程中？-文档中是否存在待确定的需求引用？-文档中是否存在未定义的术语和引用？-文档的各个部分都完整吗？-需求包括非功能属性的说明吗？是否考虑了软件性能？是否考虑了安全性要求？是否考虑了可靠性？是否考虑了系统容量问题？,37,需求规格说明的质量特性,可验证性,-需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认。,审查需求的可验证性应该考虑的问题,-在需求文档中是否存在不可验证的陈述，诸如“用户界面友好”、“容易”、“简单”、“快速”、“健壮”、“最新技术”等？-所有描述都是具体的和可测量的吗？,举例：下面的两个需求描述中哪一个难以验证？,-系统将在20秒内响应所有有效的请求。,-如果用户试图透支，系统将采取适当的行动。,38,需求规格说明的质量特性,一致性,-需求规格说明对各种需求的描述不能存在矛盾，如术语使用冲突、功能和行为特性方面的矛盾以及时序上的不一致等。,审查需求的一致性应该考虑的问题-文档的组织形式是否易于一致？-不同功能的描述之间是否存在矛盾？-是否存在有矛盾的需求描述或术语？-文档中是否存在时序上的不一致？,举例：下面的两个需求描述是否有矛盾？,-系统允许立即使用所存的资金。,-只有在手工验证所存资金后，系统才能允许使用。,39,需求规格说明的质量特性,可修改性,-需求规格说明的格式和组织方式应保证后续的修改能够比较容易和协调一致。,审查需求的可修改性应该考虑的问题,-是否存在明显的需求交叉引用？,-是否有内容列表和索引？,-是否存在冗余的需求，即同一个需求的描述出现在文档的不同地方？如果存在，它们是交叉引用吗？,40,需求规格说明的质量特性,可跟踪性,-每一项需求都能与其对应的来源、设计、源代码和测试用例联系起来。,可跟踪性的两种形式,-每一项需求都可以在早期的文档中追溯到其来源，例如备忘录、法规、会议记录等；,-每一项需求都有唯一的名称或索引号，与后期实现对应。举例：下面的需求描述记录了早期的文档来源。,-系统将在20秒内响应所有有效的请求。,来自与用户的面谈，备忘录编号#1234,41,需求管理,需求管理是分析变更影响并控制变更的过程，主要包括变更控制、版本控制和需求跟踪等活动。,需求管理,变更控制,版本控制,需求跟踪,需求状态跟踪,建议变更,确定需求文档,定义对其它需,定义需求状态,分析影响,的版本,求的连接链,跟踪需求的每,作出决策,确定单个需求,定义对其它系,一个状态,交流,文档的版本,统元素的连接,合并,链,测量需求的稳定性,42,需求描述示例,举例预订图书，如果可能的话，应当根据图书编号的列表在线确认所输入的图书编号。,需求描述示例,举例如果可能的话，应当根据图书编号的列表在线确认所输入的图书编号。问题“如果可能的话”意味着什么？“应当”是否精确？改正？系统必须根据在线的图书编号列表确认所输入的图书编号。如果在图书编号列表中查不到该图书的编号，或者当进行图书编号确认时图书编号列表不可访问，系统必须显示一个出错信息并且拒绝预订。,需求描述示例,举例1,产品必须在固定的时间间隔内提供状态信息，并且每次时间间隔不得小于60秒。,?,?,?,?,问题,-上述需求描述有什么缺陷？-如何改正？,46,需求描述示例与改正,改正,后台任务管理器应该在用户界面的指定区域显示状态信息。（1）在后台任务进程启动之后，消息必须每隔6010秒更新一次，并且保持连续的可见性。（2）如果正在正常处理后台任务进程，那么后台任务管理器必须显示后台任务进程已完成的百分比。（3）当完成后台任务时，后台任务管理器必须显示一个“已完成”的信息。（4）如果后台任务中止执行，那么后台任务管理器必须显示一个出错信息。,47,传统软件工程方法学使用结构化分析技术，完成分析用户需求的工作。需求分析是发现、求精、建模、规格说明和复审的过程。第一步是进一步了解用户当前所处的情况，发现用户所面临的问题和对目标系统的基本需求；接下来应该与用户深入交流，对用户的基本需求反复细化逐步求精，以得出对目标系统的完整、准确和具体的需求。具体地说，应该确定系统必须具有的功能、性能、可靠性和可用性，必须实现的出错处理需求、接口需求和逆向需求，必须满足的约束条件，并且预测系统的发展前景。,3.9小结,在需求分析阶段还应该写出软件需求规格说明书，经过严格评审并得到用户确认之后，作为这个阶段的最终成果。通常主要从一致性、完整性、现实性和有效性等4个方面复审软件需求规格说明书。多数人习惯于使用实体-联系图建立数据模型，使用数据流图建立功能模型，使用状态图建立行为模型。读者应该掌握这些图形的基本符号，并能正确地使用这些符号建立软件系统的模型。为了提高可理解性，还可以用层次方框图或Warnier图等图形工具辅助描绘系统中的数据结构。概括地说，任何一个计算机系统的基本功能都是把输入数据转变成输出信息，算法定义了转变的规则。因此，没有对算法的了解就不能确切知道系统的功能。IPO图是