软件工程-第3章：需求分析

第3章需求分析,为什么要进行需求分析？,需求阶段修复一个缺陷的代价是编码阶段的1/51/10，是维护阶段的1/100/200。,（1）掌握具体的步骤和方法（2）提高分析问题和解决问题的能力（3）熟练运用一些图形工具,2,开发过程的两大阶段（1）正确地确定问题需求分析（2）为问题寻找合适的解答设计需求分析的目的：澄清用户的各种需求需求分析的任务：用户和开发人员一起理解用户的要求，并转化为书面文档。软件需求规格说明书,3,如何准确有效地得到用户的需求,需求工程基本任务,需求工程,需求管理,需求开发,需求获取,需求分析,需求规格说明,需求验证,变更管理,软件需求各组成部分之间的关系,总结需求分析流程,需求分析通信途径,3.1需求分析的任务3.2需求的获取方法3.3分析建模与规格说明3.4实体-联系图3.5数据规范化3.6状态转换图3.7其他图形工具,1,1.确定系统的综合要求,（1）功能要求（2）性能要求（3）运行要求（4）扩充要求,3.1需求分析的任务,建立数据模型（层次方框图、Warnier图）导出系统的逻辑模型,修正系统开发计划,2.分析系统的数据要求,3.需求分析的过程,7,需求分析阶段的四个步骤调查研究分析与综合书写需求分析文档需求分析文档评审,目的：通过各种途径获取用户需求信息产生用户需求说明书,7,（1）调查研究,（2）分析与综合,软件需求说明书数据要求说明书初步的用户手册修改、完善与确定软件开发实施计划,8,（3）书写需求分析文档,系统定义的目标否一致文档资料是否齐全文档描述是否完整、清晰、准确与其它系统的重要接口是否都已经描述,9,（4）需求分析的评审,3.2需求的获取,需求获取的困难：分析员与领域专家交流的过程中，易产生误解大型系统的多个用户群的需求相互矛盾，分析员寻求让满意的答案比较困难需求永远不会稳定,1.访谈面向数据流自顶向下求精简易的应用规格说明快速软件原型,1.访谈,正式访谈：系统分析员提出事先准备好的问题。非正式访谈：提出一些用户可以自由回答的开放性问题，鼓励被访者说出自己的想法。需要访问大量人员时，利用调查表访问较佳。,场景开始的系统状态描述标准事件流的描述错误出现的位置及处理方法可能在同一时间进行的活动场景完成后系统状态的描述,13,场景（情景）内容,某出版社系统调查表,组织结构与功能分析,组织结构图是一张反映组织内部之间隶属关系的树状结构图。组织业务关系图,2.面向数据流自顶向下求精,分析追踪数据流图,用户复查,细化数据流图,需求分析基本过程,借助数据流图、数据字典、IPO图等，细化、完善数据流图。,分析销售趋势,统计功能,结构化分析方法（SA）+结构化设计方法（SD）适用于大型的数据处理系统（MIS）的分析,14,无论系统多么复杂，分解技术能保证分析工作有计划、按步骤、有条不紊地来进行，避免面对复杂系统的茫然无措。,复杂性控制的基本手段分解、抽象,3.简易的应用规格说明,面向团队的需求收集法（用户与开发者配合）初步访谈开发者和用户分别写出“产品需求”开会讨论，各自展示需求列表得出一致意见，为需求列表制定小型规格说明根据会议成果，起草完整的软件需求规格说明,4.快速软件原型,快速建立演示主要功能的原型（1）第四代技术（2）可重用的软件构件（3）形式化规格说明和原型环境,短时间内建立原型,用户满意,修改完善原型,否,是,完成原型,3.3分析建模与规格说明,为了开发复杂的系统，应从不同角度（模型）抽象出目标系统的特性。,数据模型功能模型行为模型,实体联系图数据流图状态转换图,1.分析建模,2.需求规格说明,SRS,SoftwareRequirementSpecification阐述系统必须提供的功能和性能及限制条件,SRS作用:,理解与交流（用户、分析人员、设计人员）支持系统测试规划和控制开发过程,功能外部接口性能：运行速度、可用性、响应时间、恢复时间特性：可移植性、可维护性、安全性设计约束：是否存在必要的标准、开发语言、数据库、资源限制、运行环境等因素的影响和策略？,28,（1）SRS中的内容,（2）编写需求规格说明的原则,只描述“做什么”而无须描述“怎么做”必须说明运行环境形式化和自然语言间恰当选择（理解最重要）不存在十全十美的规格说明书需求描述详略适度编写可测试需求文档,将可测试的需求作为衡量软件规模的因素文档段落不宜太长避免使用模糊的、主观的术语如：和/或、等等、用户友好、容易、简单、迅速、有效、许多、最新技术、优越的、可接受的、最大化、最小化、提高等不可验证的语言建议：采用一种标准的SRS模板,1.引言1.1目的1.2文档约定1.3预期的读者和阅读建议1.4产品范围1.5参考文献2.综合描述2.1产品的前景2.2产品的功能2.3用户类和特征2.4运行环境2.5设计和实现上的设计2.6假设和依赖3外部接口需求3.1用户界面,3.2硬件接口3.3软件接口3.4通信接口4.系统特性4.1说明和优先级4.2激励/响应序列4.3功能需求5.非功能需求5.1性能需求5.2安全设施需求5.3安全性需求5.4软件质量属性5.5业务规划5.6用户文档6.其他需求附录,SRS模板,（3）需求验证,需求验证：检验需求能否满足客户的意愿,需求验证的技术需求评审：分析员、客户、设计人员、测试人员原型评价：用户提出真正的需求测试需求：通过测试，发现需求中的存在的问题,（4）需求规格说明的质量特性,正确性,功能、行为、性能的描述与用户期望吻合,是否准确地反映了用户的需要？是否已经认真考虑了每一项描述？需求可以追溯来源吗？用户参与需求过程的程度如何？,无二义性,对所有人都只能有一种明确的统一的解释。,是否有术语词汇表？具有多重含义或未知含义的术语是否已经定义？是否可量化和可验证？每项需求都有测试准则吗？,举例：如果用户试图透支，系统将采取适当的行动。,完整性,应包括软件要完成的全部任务，不能遗漏。,是否存在遗漏的功能或业务过程？每个定义的功能之间是否有接口？是否有信息在功能之间传递？是否定义了功能的使用者？是否已经定义了用户与功能之间的交互？是否定义了与外部过程和系统之间的接口？,所描述的功能是否可以映射到业务过程中？文档中是否存在待确定的需求引用？文档中是否存在未定义的术语和引用？文档的各个部分都完整吗？需求包括非功能属性的说明吗？是否考虑了软件性能？是否考虑了安全性要求？是否考虑了可靠性？是否考虑了系统容量问题？,可验证性,可以运用一些可行的手段对需求进行验证和确认。,是否存在不可验证的陈述如：界面友好、容易、简单、快速、健壮、新技术所有描述都是具体的和可测量的吗？,举例：下面的两个需求描述中哪一个难以验证？系统将在20秒内响应所有有效的请求。如果用户试图透支，系统将采取适当的行动。,一致性,需求的描述不能存在矛盾，如：术语冲突、功能和行为特性方面的矛盾以及时序上的不一致等。,文档的组织形式是否易于一致？不同功能的描述之间是否存在矛盾？是否存在有矛盾的需求描述或术语？文档中是否存在时序上的不一致？,系统允许立即使用所存的资金。只有在手工验证所存资金后，系统才能允许使用。,可修改性,格式和组织方式可方便后续的修改和协调。,是否存在明显的需求交叉引用？是否有内容列表和索引？是否存在冗余的需求？它们是交叉引用吗？,可跟踪性,每项需求都有来源且与设计、源代码和测试用例关联,每项需求都能在早期文档中追溯来源，例如：备忘录、法规、会议记录等；每一项需求都有唯一的名称或索引号，且与后期实现对应,举例：系统将在20秒内响应所有有效的请求。来自与用户的面谈，备忘录编号#1234,（5）需求管理,需求管理,变更控制,版本控制,需求跟踪,需求状态跟踪,建议变更分析影响作出决策交流合并测量需求的稳定性,确定需求文档的版本确定单个需求文档的版本,定义对其它需求的连接链定义对其它系统元素的连接链,定义需求状态跟踪需求的每一个状态,活动2：需求用于计划、产品和活动,目标1：形成需求基线,活动1：需求的开发前的评审,活动3：需求变更评审,目标2：计划、产品和活动与需求保持一致,变更申请,需求基线,需求跟踪性,需求跟踪性是维护需求与软件制品之间的映射（例如设计对象、用例、测试用例、已实现的软件组件等），以满足整个开发生命周期的需要。,建立需求跟踪的过程,识别并唯一地标识SRS中的每一个需求建立和更新SRS中的跟踪矩阵,需求跟踪矩阵示例,用例功能需求设计元素代码测试实例,UC1,Catalog.query.sort,Classcatalog,Catalog.sort(),test2,test3,UC2,Catalog.update,Classcatalog,Catalog.update(),test10,test11,需求管理需要CASE工具的支持,test12,需求描述示例,例1：产品必须在固定的时间间隔内提供状态信息，并且每次时间间隔不得小于60秒。,?,?,?,?,后台任务管理器在用户界面的指定区域显示状态信息。（1）在后台任务进程启动之后，消息必须每隔6010秒更新一次，并保持连续的可见性。（2）如果正在正常处理后台任务进程，那么后台任务管理器必须显示后台任务进程已完成的百分比。（3）当完成后台任务时，后台任务管理器必须显示一个“已完成”的信息。（4）如果后台任务中止执行，那么后台任务管理器必须显示一个出错信息。,需求描述示例,例2：如果可能的话，应当根据图书编号的列表在线确认所输入的图书编号。,系统必须根据在线的图书编号列表确认所输入的图书编号。如果在图书编号列表中查不到该图书的编号，或者当进行图书编号确认时图书编号列表不可访问，系统必须显示一个出错信息并且拒绝预订。,数据对象可以是外部实体、事物、行为、事件、角色、单位、地点、结构等。,1.数据对象,3.4实体联系图,2.属性属性定义了数据对象的性质。,属性,3.联系（1）一对一联系（1：1）（2）一对多联系（1：N）（3）多对多联系（M：N）在ER图中，用菱形框表示联系。,联系,例子：,通常用范式定义消除数据冗余的程度。1）第一范式2）第二范式3）第三范式,3.5数据规范化,3.6状态转换图,描述系统对事件响应的行为模型描述系统状态、事件及事件引发状态间的转换提供了行为建模机制,41,状态图：状态、变迁、事件,状态初始有效锁定售出,例：火车票（对象）的状态图,放票：初始状态有效状态票被预订：有效锁定预定后付款：锁定售出预定解除：锁定有效,付款,预定过期：锁定有效直接购买：有效售出换票：售出有效,预定,3.7其它图形工具,层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。,1.层次方框图,树形结构,手段比层次方框图更丰富,2.Warnier图,IPO图是输入/处理/输出图。,3.IPO图,结构化分析步骤,问题描述分层的数据流图决定哪些部分需要计算机化和怎样计算机化数据细节描述定义处理逻辑定义物理资源确定输入/输出规格说明，确定有关数值确定硬件需求根据结构化分析模型，建立系统规格说明文档,【问题描述】图书馆藏书：图书、期刊杂志，每种可以有多册；可以维护（注册、更新和删除）图书资料；管理员负责与借书者打交道；借书者可以预约目前借不到的图书或杂志；所有人都可以浏览图书馆的图书信息和各种告示。,51,例：用结构化分析方法分析图书馆系统,【功能分析】浏览功能：所有人都可以浏览图书馆的图书信息。借还功能：借书者可以借/续借、还、预约图书。图书管理功能：管理人员录入、更新和销毁等。借书者管理：系统管理人员注册、更改、注销借书者信息等维护工作。,52,【建立数据流图】,分析角色：一般浏览者、借书者、一般管理员和系统管理员四类外部用户。,【借/还功能数据流图】,借/还功能,54,【维护功能数据流图】,维护功能（第一步）DFD维护功能（修改）DFD,【借书功能细化的数据流图】,【建立E-R图】,图书馆系统有“图书”和“借书者”两个实体。“图书”实体，没有区别借书和预约关系。外部实体除了“借书者”，还有“系统管理员”。因此，必须考虑