软件工程——共同演进的方法与实践 教学课件 ppt 作者 田文洪 第三章需求分析

上传人:E**** 文档编号:89363602 上传时间:2019-05-24 格式:PPT 页数:32 大小:2.15MB
返回 下载 相关 举报
软件工程——共同演进的方法与实践 教学课件 ppt 作者 田文洪 第三章需求分析_第1页
第1页 / 共32页
软件工程——共同演进的方法与实践 教学课件 ppt 作者 田文洪 第三章需求分析_第2页
第2页 / 共32页
软件工程——共同演进的方法与实践 教学课件 ppt 作者 田文洪 第三章需求分析_第3页
第3页 / 共32页
软件工程——共同演进的方法与实践 教学课件 ppt 作者 田文洪 第三章需求分析_第4页
第4页 / 共32页
软件工程——共同演进的方法与实践 教学课件 ppt 作者 田文洪 第三章需求分析_第5页
第5页 / 共32页
点击查看更多>>
资源描述

《软件工程——共同演进的方法与实践 教学课件 ppt 作者 田文洪 第三章需求分析》由会员分享,可在线阅读,更多相关《软件工程——共同演进的方法与实践 教学课件 ppt 作者 田文洪 第三章需求分析(32页珍藏版)》请在金锄头文库上搜索。

1、第三章 需求分析,本章学习目标,2,3,知道如何根据需求分析来完成文档。,理解需求分析的主要步骤。,理解需求分析的过程。,软件需求管理的过程,需求分析,需求描述,需求验证,需求获取,需求变更,需求确认,需求变更,需求分析的定义,需求分析的任务和步骤,需求分析的任务 建立分析模型 编写需求说明 需求分析的步骤 需求获取 需求提炼 需求描述(撰写需求规格说明书) 需求验证,需求分析的任务和步骤,需求分析的任务 建立分析模型 编写需求说明,准确地定义未来系统的目标,确定为了满足用户的需求系统必须做什么。,需求分析的任务和步骤,需求分析的任务 建立分析模型 编写需求说明,用 规范的形式准确地表达用户的

2、需求。,为什么需要需求分析?,需求分析的错误和变更导致的软件开发失败占软件失败因素的1/3以上-Standish Group 缺少用户的输入:占软件失败因素的13% 不完整的需求和规格说明书:占软件失败因素的12% 需求和规格说明书的变更:占软件失败因素的12% 希望对开发进行指导 希望开发人员对用户的要求理解 希望用户理解开发人员 测试部门有理可依,修正需求错误的代价,第一步:需求获取,需求的类型,(1) 功能性需求:描述系统应该做什么,即为用户和其它系统完成的功能、提供的服务。 (2)非功能需求:必须遵循的标准,外部界面的细节,实现的约束条件,质量属性等等。 非功能需求限定了选择解决问题方

3、案的范围,如运行平台、实现技术、编程语言和工具等。,将飞机订票系统中的以下方面做如下的划分,F代表“功能性”,NF代表“非功能性”,X代表“不应当是需求”。简要的说明功能性或非功能性需求的种类。对于不应当是需求的方面,说明其原因。 如何输入有关航班、乘客及订票信息。F:输入。 什么信息要出现在机票和报告中。F:输出。 如何计算乘机费用。 F:计算。 什么信息必须存储在旅行社和其他人访问的数据库中。 F:数据存储。,例,举, 这个系统应该设计成可以处理旅行常客计划。 NF:增强的容限。 这个系统在任何时候都必须是可用的。一周中只允许有2分钟宕机时间。 NF:有效性。 必须使用排序算法根据离开时间

4、对航班排序。 X:这是一个设计问题。,需求来源,目标,领域知识,投资者,组织环境,运行环境,需求获取技术,向系统相关者进行问卷调查 主持与用户的面谈和讨论 需求专题讨论会 复查现有的报表、表格和过程描述 观察商业过程和工作流 应用用例 建立原型,某出版社系统调查表,某出版社系统调查表,需求获取面临的挑战,客户说不清楚需求 需求易变性 问题的复杂性和对问题空间理解的不完备性与 不一致性,第二步:需求提炼(需求分析),需求分析的核心在于建立分析模型。 需求分析采用多种形式描述需求,通过建立需求的多种视图,揭示出一些更深的问题。 需求分析还包括与客户的交流以澄清某些易混淆的问题,并明确哪些需求更为重

5、要,其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。,分析建模,结构化分析模型 面向对象分析模型 分析模型描述工具 数据流图、数据字典和加工规约 CFD、控制规约和状态变迁图 E-R图 用例图,对象-关系图,对象-行为图,第三步:需求规格说明书,需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。 需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解,使之成为整个开发工作的基础。,软件需求规格说明的原则,从现实中分离功能,即描述要“做什么”而不是“怎样实现” 要求使用面向处理的规格说明语言(或称系统定义语言)

6、如果被开发软件只是一个大系统中的一个元素,那么整个大系统也包括在规格说明的描述之中 规格说明必须包括系统运行环境 规格说明必须是一个认识模型 规格说明必须是可操作的 规格说明必须容许不完备性并允许扩充 规格说明必须局部化和松散耦合,IEEE标准为需求文档提出了以下结构,组织机构内部可以基于此标准扩展: (1)引言 a. 需求文档的目的 b. 文档约定 c. 预期的读者和阅读建议 d. 产品范围 e. 参考文献 (2)综合描述 a. 产品前景 b. 产品功能与优先级 c. 用户特征 d. 运行环境 e. 设计与实现上的限制 f. 假设和依赖性,软件需求规格说明的结构,软件需求规格模板,(3)需求

7、描述 a. 功能需求 b. 数据需求:与功能有关的数据定义和数据关系 c. 性能需求:响应时间、容量要求、用户数等 d. 外部接口:用户界面、软硬件接口、通信接口 e. 设计约束:软件支持环境、报表、数据命名等 f. 软件质量属性(可维护性、可靠性、可移植性、 可用性、安全性等等) g. 其他需求 这一节是文档中最实质性的部分,由于在机构组织的实践中存在极大的变数,对这一节定义的标准结构可以进行增删。 (4)附录(词汇表、分析模型、待定问题列表) (5)索引,需求验证的重要性:如果在后续的开发或当系统投入使用时才发现需求文档中的错误,就会导致更大代价的返工。由需求问题而对系统做变更的成本比修改

8、设计或代码错误的成本要大的多。假设需求阶段引入1个错误的需求,设计时对这个需求需要510条设计实现,1条设计需要 510条程序,1条程序需要35种测试组合测试。,原始需求,正确的规格说明 错误的规格说明,正确的设计 错误的设计 对错误需求的设计,正确的编码 错误的编码 对错误设计的编码 对错误需求的编码,正确功能 测试到的错误 没有测试到的错误,一个错误的需求,纠正成本100元,10 纠正成本1000元,10,5,第四步:需求验证,对需求文档需执行以下类型的检查: (1)有效性检查 检查不同用户使用不同功能的有效性。 (2)一致性检查 在文档中,需求不应该冲突。 (3)完备性检查 需求文档应该

9、包括所有用户想要的功能和约束。 (4)现实性检查 检查保证能利用现有技术实现需求。,(1)需求评审 由分析员、设计员、测试员、用户参与的正式或非正式的会议评审。正式会议要有严格的评审程序,要有会议记录,开发组根据缺陷建议修改需求说明并重审。 (2)利用原型检验系统是否符合用户的真正需要。 (3)对每个需求编写概念性的测试用例。 (4)编写用户手册。用浅显易懂的语言描述用户可见的功能。 (5)自动的一致性分析。可用CASE工具检验需求模型的一致性。,需求验证技术,需求总在变化,需求变更管理,管理和控制需求基线的过程 需求变更控制系统 一个正式的文档,说明如何控制需求变更 建立变更审批系统,案例分析,见word,小结,软件需求贯穿于软件工程的整个生命周期 软件需求:用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。 需求分析的任务建立需求分析模型和编写需求说明。,作业,1.描述需求分析中用例图的缺点。 2.需求分析主要的步骤是什么? 3.给出功能和非功能性需求的例子。 4.在产品需求和过程需求中的不同点是什么? 5.请举出一些需求分析的主要来源。,

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 高等教育 > 大学课件

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号