电子科技大学软件工程需求分析改.ppt

电子科技大学软件工程需求分析改.ppt

《电子科技大学软件工程需求分析改.ppt》由会员分享，可在线阅读，更多相关《电子科技大学软件工程需求分析改.ppt（125页珍藏版）》请在冰豆网上搜索。

,授课教师：

蓝天联系电话：

13488929723电子邮箱：

第三章需求分析,本章学习目标,2,3,掌握用例图等面向对象分析方法,掌握数据流图等结构化分析方法,理解需求分析的过程和主要步骤,为什么需要需求分析？

需求分析的错误和变更导致的软件开发失败占软件失败因素的1/3以上-StandishGroup缺少用户的输入：

占软件失败因素的13%不完整的需求和规格说明书：

占软件失败因素的12%需求和规格说明书的变更：

占软件失败因素的12%希望对开发进行指导希望开发人员对用户的要求理解希望用户理解开发人员测试部门有理可依,美国专门从事跟踪IT项目成功或失败的权威机构,修正需求错误的代价,指数级增长,软件需求管理的过程,需求提炼,需求描述,需求验证,需求获取,需求变更,需求确认,需求变更,需求分析的定义,需求分析的任务和步骤,需求分析的任务建立分析模型编写需求说明需求分析的步骤需求获取需求提炼需求描述（撰写需求规格说明书）需求验证,需求分析的任务和步骤,需求分析的任务建立分析模型编写需求说明,准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。

需求分析的任务和步骤,需求分析的任务建立分析模型编写需求说明,用需求规格说明书规范的形式准确地表达用户的需求。

第一步：

需求获取,需求的类型,

（1）功能性需求：

描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务。

（2）非功能需求：

必须遵循的标准，外部界面的细节，实现的约束条件，质量属性等等。

非功能需求限定了选择解决问题方案的范围，如运行平台、实现技术、编程语言和工具等。

？

将飞机订票系统中的以下方面做如下的划分，F代表“功能性”，NF代表“非功能性”，X代表“不应当是需求”。

简要的说明功能性或非功能性需求的种类。

对于不应当是需求的方面，说明其原因。

如何输入有关航班、乘客及订票信息。

F：

输入什么信息要出现在机票和报告中。

F：

输出如何计算乘机费用。

F：

计算什么信息必须存储在旅行社和其他人访问的数据库中。

F：

数据存储,例,举,这个系统应该设计成可以处理常旅客计划。

NF：

可扩展性这个系统在任何时候都必须是可用的。

一周中只允许有2分钟宕机时间。

NF：

有效性必须使用某排序算法根据离开时间对航班排序。

X：

这是一个设计问题,需求来源,用户目标,领域知识,投资者,组织环境,运行环境,需求获取技术,采访设定情景（用例）原型会议观察商业过程和工作流,某出版社系统调查表,某出版社系统调查表,需求获取面临的挑战,客户说不清楚需求需求易变性问题的复杂性和对问题空间理解的不完备性与不一致性,需求诱导十原则,倾听,需求诱导十原则,2.有准备的沟通,需求诱导十原则,3.需要有人推动,需求诱导十原则,4.最好当面沟通,需求诱导十原则,5.记录所有决定,需求诱导十原则,6.保持通力协作,需求诱导十原则,7.聚焦并协调话题,需求诱导十原则,8.采用图形表示,需求诱导十原则,9.继续前进原则,一旦认可某件事情，继续前进；如果不认可某件事情，继续前进；如果某项特性或功能不清晰，当时无法澄清，继续前进,需求诱导十原则,10.谈判双赢原则,沟通活动通用任务集,识别主要客户和共利益者与主要客户会谈“上下文无关的问题”，以确定业务需要和商业价值最终用户的特性需要需要的用户可见输出业务约束写一页项目范围的说明评审范围说明，并应客户要求做出相应修改,业务操作管理人员、产品管理人员、市场营销人员、内部和外部客户、最终用户、顾问、产品工程师、软件工程师、支持和维护工程师,谁将使用该解决方案？

存在别的解决方案吗？

能向我们展示（或描述）解决方案的使用环境吗？

我的提问和你想解决的问题相关吗？

还有我应该问的其他问题吗？

小规格说明：

控制面板是一个安装在墙上的单元，尺寸大概是9*5英寸；控制面板和传感器、计算机之间是无线连接；通过一个12键的键盘与用户交互，通过一个2*2的LCD显示器为用户提供反馈信息；软件将提供交互提示、回显以及类似的功能,沟通活动通用任务集,与客户/最终用户进行协作，确定：

采用标准格式记录客户可见的使用场景输入和输出重要的软件特性、功能和行为客户定义的商业风险描述场景、输入/输出、特性/功能以及风险与客户细化场景、输入/输出、特性/功能以及风险为每个用户场景、特性、功能和行为分配客户定义的优先级回顾搜集的所有信息并修订为计划活动做准备,用例：

初始化监测主要参与者：

房主目标：

设置系统在房主离开住宅或留在房间内时监测传感器前提条件：

系统已经输入密码并识别各种传感器触发器：

房主决定“设置”系统，即打开报警功能场景：

1.房主：

观察控制面板2.房主：

输入密码3.房主：

选择“stay”或“away”4.房主：

观察红色报警灯显示SafeHome已经被打开异常：

1.密码不正确：

房主重新输入正确的密码优先级：

必须的，必须被实现何时可用：

首次增量使用频率：

每天多次使用方式：

通过控制面板接口次要参与者：

技术支持人员，传感器次要参与者使用方式：

电话线（技术支持人员）；有线或无线接口（传感器）未解决的问题：

练习,为如下活动之一开发一个完整的用例：

在ATM上提款在餐厅使用饭卡付款使用在线书店搜索书,第二步：

需求提炼（需求分析）,需求分析的核心在于建立分析模型。

需求分析采用多种形式描述需求，通过建立需求的多种视图，揭示出一些更深的问题。

需求分析还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要，其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。

需求分析模型,柜台取款,客户-柜台-营业员-银行主机-,客户、银行、现金,客户、系统、现金,客户-ATM机-银行主机-,ATM取款,分析建模,结构化分析模型面向对象分析模型分析模型描述工具数据流图、数据字典和加工规约控制流图、控制规约和状态变迁图E-R图用例图，对象-关系图，对象-行为图,其基本思想是用系统工程的思想和工程化的方法，根据用户至上的原则，自始自终按照结构化、模块化，自顶向下地对系统进行分析与设计。

由5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。

需求建模图形工具,第三步：

需求规格说明书,需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。

需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。

软件需求规格说明的原则,从现实中分离功能，即描述要“做什么”而不是“怎样实现”要求使用面向处理的规格说明语言（或称系统定义语言）如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中规格说明必须包括系统运行环境规格说明必须是一个认识模型规格说明必须是可操作的规格说明必须容许不完备性并允许扩充规格说明必须局部化和松散耦合,软件需求规格说明的结构,IEEE标准为需求文档提出了以下结构，组织机构内部可以基于此标准扩展：

a.需求文档的目的b.文档约定c.预期的读者和阅读建议d.产品范围e.参考文献,a.产品前景b.产品功能与优先级c.用户特征d.运行环境e.设计与实现上的限制f.假设和依赖性,

（2）综合描述,

（1）引言,（3）需求描述,a.功能需求b.数据需求：

与功能有关的数据定义和数据关系c.性能需求：

响应时间、容量要求、用户数等d.外部接口：

用户界面、软硬件接口、通信接口e.设计约束：

软件支持环境、报表、数据命名等f.软件质量属性（可维护性、可靠性、可移植性、可用性、安全性等）g.其他需求这一节是文档中最实质性的部分，由于在机构组织的实践中存在极大的变数，对这一节定义的标准结构可以进行增删。

（4）附录（词汇表、分析模型、待定问题列表）,（5）索引,第四步：

需求验证,需求验证的重要性：

如果在后续的开发或当系统投入使用时才发现需求文档中的错误，就会导致更大代价的返工。

由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大的多。

假设需求阶段引入1个错误的需求，设计时对这个需求需要510条设计实现，1条设计需要510条程序，1条程序需要35种测试组合测试。

原始需求,正确的规格说明错误的规格说明,正确的设计错误的设计对错误需求的设计,正确的编码错误的编码对错误设计的编码对错误需求的编码,正确功能测试到的错误没有测试到的错误,一个错误的需求，纠正成本100元,10纠正成本1000元,10,5,$100$50000!

对需求文档需执行以下类型的检查：

（1）有效性检查检查不同用户使用不同功能的有效性。

（2）一致性检查在文档中，需求之间不应该冲突。

（3）完备性检查需求文档应该包括所有用户想要的功能和约束。

（4）现实性检查检查保证能利用现有技术实现需求。

需求验证技术,

（1）需求评审由分析员、设计员、测试员、用户参与的正式或非正式的会议评审。

正式会议要有严格的评审程序，要有会议记录，开发组根据缺陷建议修改需求说明并重审。

（2）利用原型检验系统是否符合用户的真正需要（3）对每个需求编写概念性的测试用例。

（4）编写用户手册。

用浅显易懂的语言描述用户可见的功能。

（5）自动的一致性分析。

可用CASE工具检验需求模型的一致性。

软件需求工具,RationalRequisitePro能够帮助项目团队改进项目目标的沟通，增强协作开发，降低项目风险，以及在部署前提高应用程序的质量。

TelelogicDOORS基于整个公司的需求管理系统，用来捕捉、链接、跟踪、分析及管理信息，以确保项目与特定的需求及标准保持一致。

BorlandCaliberRM基于Web和用于协作的需求定义和管理工具，可以帮助分布式的开发团队平滑协作，从而加速交付应用系统。

CaliberRM辅助团队成员沟通，减少错误和提升项目质量。

RationalRose可用于UML建模分析,需求总在变化,需求变更管理,变更管理是将个人、团队和组织从现有状态转移/过渡到期望状态的结构化方法。

它授权雇员接受并理解当前业务环境中的变更。

在项目管理中，变更管理是指项目变更被引入和接受后的项目管理过程。

管理和控制需求基线的过程需求变更控制系统一个正式的文档，说明如何控制需求变更建立变更审批系统,需求变更处理流程,面向过程的分析方法,结构化分析方法,面向数据流进行需求分析的方法结构化分析方法适合于数据处理类型软件的需求分析具体来说，结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止结构化分析方法使用工具：

数据流图，数据字典，实体联系图，状态变迁图,功能模型数据流图,数据流图,数据流图中的主要图形元素,例：

描述银行取款过程的数据流图,数据流与数据加工之间的关系,数据流图的层次结构,为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。

按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统,分层数据流图,在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。

它的输入流是该系统的输入数据，输出流是系统所输出数据,中间层流图则表示对其上层父图的细化。

它的每一加工可能继续细化，形成子图,底层流图是指其加工不需再做分解的数据流图，它处在最底层,顶层流图（商店业务处理系统）,这个数据流图只是一个高层的系统逻辑模型，它反映了目标系统要实现的功能,商店业务系统数据流图绘制步骤,首先确定系统的输入和输出根据商店业务，画出顶层数据流图，以反映最主要业务处理流程经过分析，商店业务处理的主要功能应当有销售、采购、会计三大项。

主要数据流输入的源点和输出终点是顾客和供应商。

然后从输入端开始，根据商店业务工作流程，画出数据流流经的各加工框，逐步画到输出端，得到第一层数据流图,第一层数据流图,第二层：

加细每一个加工框1.销售细化,2.采购细化,检查和修改数据流图的原则,数据流图上所有图形符号只限于前述四种基本图形元素数据流图的主图必须包括前述四种基本元素，缺一