第04章软件需求工程

整理文档很辛苦,赏杯茶钱您下走!

免费阅读已结束,点击下载阅读编辑剩下 ...

阅读已结束,您可以下载文档离线阅读编辑

资源描述

1第四章软件需求工程软件工程课件软件工程2第四章软件需求工程4.1软件需求工程基础4.2软件需求获取4.3传统的需求分析方法4.4面向对象的需求分析4.5快速原型化方法4.6软件需求规格说明4.7软件需求评审4.8软件需求管理软件工程34.1软件需求工程基础软件需求工程的基本任务是准确地回答“软件系统必须做什么?”这个问题。它在系统工程和软件设计之间起到桥梁的作用。软件需求工程是软件生存周期中重要的一步,也是决定性的一步。只有通过软件需求工程的活动才能把软件功能和性能的总体概念描述为具体的软件需求规格说明,从而奠定软件开发的基础。系统工程软件需求工程软件设计工程软件工程4软件需求的定义和层次1997年IEEE在《软件工程标准词汇表》对需求(requirement)所作出的定义为:a)用户为解决某一问题或为达到某个目标所需要的条件或能力。(需方)b)系统或系统部件为满足合同、标准、规格说明或其他正式的强制性文档所必须具有的条件或能力。(供方)c)对在a)和b)中所描述的条件或能力的文档化说明。软件工程5GB/T11457―2006《信息技术软件工程术语》等同采用了这个定义。它从两个方面阐述了需求的含义:从用户角度要求系统应具有的外部行为从开发者角度要求系统应具有的内部特性最后强调了需求一定要文档化。软件需求包括3个不同的层次:业务需求、用户需求、功能需求和非功能需求。不同层次是从不同角度与不同程度反映着细节问题。软件工程6业务需求(BusinessRequirement)业务需求反映了组织或客户高层次的目标要求。业务需求主要来自于项目的投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织的愿景,即为什么要开发一个系统;系统的业务范围、业务对象、客户、特性、价值和各种特性的优先级别等。软件工程7用户需求描述了要求系统必须完成的任务,即用户对系统的目标要求。用户需求通常只涉及系统的外部可见行为,不涉及系统的内部特性。用户需要是用户真正需要的东西,用户需求是用户对其需要的一种陈述,但这种陈述可能与它们的需要不一致。用户需求一般采用自然语言和直观图形相结合的方式描述,例如采用用例(UseCase)文档或场景(Scenario)等方式说明。用户需求(userRequirement)软件工程8功能需求和非功能需求功能需求定义了开发者应提供的软件功能或服务,但不涉及这些功能或服务的实现。非功能需求则是对功能需求的补充,包括了对系统的各种限制和用户对系统的质量要求。特性是指逻辑上相关的功能需求的集合以满足业务需求。功能需求记录在软件需求规格说明(SRS)中。非功能需求的描述如下:软件工程9产品需求性能实时性;其他时间限制,包括响应时间、处理时间、包传送时间等;资源配置需求,包括内存容量、磁盘容量、缓存容量、硬软件支持等;处理精度、单位时间处理量、网络流通量等。接口相关硬件接口、软件接口、人机接口可靠性可用性(系统无故障运行时间所占总运行时间的百分比)完整性(系统的行为遵从用户需求所期望行为的百分比)安全性系统一旦发生故障降低损失防止严重危害的能力保密性防止非法访问保证信息不泄露的能力软件工程10产品需求运行限制使用频度、运行期限;控制方式(如本地控制还是远程控制);对操作员的需求;物理限制对系统的规模等限制。过程需求开发类型(实用型开发还是试验型开发?是有机型、嵌入型还是半独立型项目?)开发工作量估计对资源、开发时间及交付的安排开发方法应遵循的规范和标准(如开发规范、文档规范、专业标准等)里程碑和评审(如对阶段制品设置检查点和评审内容)质量控制标准及验收标准(如质量检验指标)软件工程11系统需求来自于系统分析和结构设计。例如,有一个电信计费系统,它包括许多业务规则,这些业务规则与企业方针、政府条例、会计准则、计算方法有关,它们本身并非软件需求,因为它们不属于任何特定的软件系统的范围,它们属于系统需求。过程需求建立可理解性、可修改性、可移植性、可测试性、效率等质量需求并设置优先级可维护性系统需求软件工程12功能需求非功能需求系统需求软件需求规格说明质量属性外部接口约束业务需求愿景和范围文档用户需求用例文档功能需求业务需求软件工程13所有的用户需求必须与业务需求一致。功能需求必须从用户需求中提取,以满足用户对产品的要求从而完成其任务。开发人员应根据功能需求来设计软件以实现必须的功能。功能需求从外部(用户角度)描述了软件系统所应具有的行为。对一个复杂产品来说,软件功能需求也许只是系统需求的一个子集。各种需求的关系软件工程14非功能需求作为功能需求的补充,包括产品必须遵从的标准、规范和合约;外部接口的具体细节;性能要求;设计或实现的约束条件及质量属性。约束是指在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述,从而反映产品功能。多角度描述产品对用户和开发者都极为重要。软件工程15软件需求工程过程软件需求工程阶段研究的对象是软件项目的用户需要。需要注意的是,必须全面地理解用户的各种需求分析和澄清模糊的用户需求准确地表达被接受的用户需求只有经过确切描述的软件需求才能成为软件设计的基础。软件需求工程需要执行的活动包括:软件工程161)确定目标系统将要面对的各类用户;2)从各类用户的代表那里收集需求;3)了解用户的任务和目标,以及这些任务要实现的业务目标;4)分析从用户那里得到的信息,将用户的任务和目标与软件的功能需求、非功能需求、业务规则、解决方案建议及其他无关信息区分开来;5)将顶层的需求分配到软件系统构架内定义好的软件成分中;6)了解各个质量属性的相对重要性;软件工程178)协商需求的实现优先级;9)将收集的用户需求表述为书面的需求规格说明和模型;10)审阅需求文档,以确保在认识上与用户需求相一致。应在开发组接受需求之前解决所有分岐。软件开发的目标是实现目标系统的物理模型,即确定待开发系统的各种软件成分,并将功能和信息结构分配到这些软件成分中。但是目标系统的具体物理模型是由当前系统的具体物理模型经过一系列的转换得到的。软件工程18软件需求工程的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型,解决目标系统“做什么”的问题。目标系统当前系统物理模型逻辑模型模型化抽象化物理模型逻辑模型具体化实例化理解需求导出怎么做做什么软件工程19Abran和Moore的软件需求工程过程模型(未包括需求管理)用户需求和系统需求需求规格说明用户需求草稿分析模型可行性研究分析建模需求获取需求描述需求有效性验证软件工程201.需求获取1)定义需求开发过程2)定义项目愿景和范围3)确定用户群4)选择用户代理人5)确定用例6)确定系统事件和响应7)描述软件的功能和性能8)指明软件与其他系统元素的接口9)建立软件必须满足的约束软件工程212.分析建模1)分析可行性2)确定需求优先级3)为需求建模4)创建数据字典5)将需求分配至各子系统6)应用质量功能进行调整分析模型为日后软件设计提供了可被翻译成数据、体系结构、接口和处理过程设计的模型。软件工程223.需求描述需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。1)采用SRS模板2)确定需求来源3)唯一标识每项需求4)记录业务规范5)定义质量属性4.需求有效性验证审查需求文档,确定合格标准软件工程234.2软件需求获取需求获取的目标是确定用户“需要”什么样的软件产品,即新的软件必须能够做什么。没有专业的系统分析人员,用户很难了解到需要开发什么相关信息和功能;另一方面,没有与用户的交流,系统分析人员也很难弄清客户真正需要什么。发现用户需求的过程称为需求获取。一旦提出了最初的需求,进一步推敲、细化和扩充的过程称为分析建模。软件工程24需求获取过程需求获取包括以下活动:1)发现和分析问题发现问题症结,并分析问题的原因/结果关系。2)获取需求根据对问题的理解定义需求。a)使用调查研究方法收集信息;b)遵循需求获取框架,按照三个成分观察:即数据、过程和接口。3)需求归档以草稿形式归档调查结果。形式有用例、决策表、需求表等。软件工程25需求获取技术的基本特征好的需求获取技术,对于规范需求获取活动,高效准确地获取需求定义,是十分重要的。好的需求获取技术,应具有如下基本特征:提供便于沟通的工具,如易于理解的语言和直观的图表;提供定义系统边界(交互)的方法;提供支持抽象的机制,如“分解”、“映射”等;软件工程26鼓励分析员使用面向问题的术语思考问题,编写文档;为分析员提供多种可供选择的解决方案;适应需求的变化。适于以上特征的需求获取方法:基于数据流图的结构化分析方法;基于用例(usecase)的建模方法。需求获取技术的关键点在于:a.深入浅出需求获取要尽可能全面、细致。软件工程27获取的需求是个全集,系统真正实现的是个子集。分析时的调研内容并不都纳入到新系统中,目的在于以后的扩充。b.以流程为主线在与用户交流的过程中,应该用流程将所有的内容串起来。如信息、组织结构、处理规则等。这样便于交流沟通。流程描述有宏观,也有微观。既要强调总体的业务流程、全生存周期的业务流程,又要对流程细化,有分支的业务流程。软件工程28需求获取的主要步骤1.开发高层的业务模型理解应用领域,即目标软件的应用环境。如银行、电信公司、书店等。一旦系统分析人员对该领域有了充分了解,就可以建立一个业务模型,描述用户的业务过程,确定用户的初始需求。分析出企业的业务实体,开发或选取必需的构件,建立稳定的软件体系结构。通过迭代,更深入了解应用领域,再回过头来推敲业务模型。软件工程292.定义项目的视图和范围在项目开始之前,在所有干系人中竖立一个共同的愿景,明确供需各方的权利和义务,并发布得到共识的、对项目目标的理解。在共同愿景的确立过程中要做两件事情:a)定义项目范围:项目范围描述项目该做什么,不该做什么,可通过陈述和图表(如用例图或数据流图)来表达;b)定义高层需求:高层需求不涉及过多的细节,主要通过它表示系统的概貌,从而建立需求模型。软件工程303.寻求需求的来源软件需求的来源取决于目标系统的性质和开发环境。典型的需求来源是:1)与潜在用户进行交谈和讨论2)描述现有产品或竞争产品的文档3)系统需求规格说明4)当前系统的问题报告和改进要求5)市场调查和用户问卷调查6)观察用户如何工作7)用户工作的场景分析8)事件和响应软件工程31根据所受限制不同,不同类型的应用系统能够从用户那里获取需求的比例也不同。所谓限制,是指受客观物理规律的限制。相对低的相对高的从人群获取需求的大概百分比应用的类型高度受限的不受限制的导弹制导系统航班控制系统公司财务系统增强版制造控制系统公司财务系统视频游戏军事战略决策支持系统软件工程32如导弹制导系统更多地受物理运动定律的限制,而非人的决策。视频游戏的大部分需求依赖人,因为它是一个想象出来的产品。应用受到的限制越少,能从人们那里获得的需求比例越大。4.识别用户类和用户代表确定目标系统的不同用户类型;挑选出每一类用户和其他项目相关者的代表并与他们一起工作;商定谁是项目需求的决策者。软件工程33不同用户类可能还有不同的非功能需求。不同用户类的需求甚至可能发生冲突,导致需求不一致。即使所有利益相关者的需求一致,也可能由于实现代价高昂,需求不能得到完全满足。用户类可以是人,也可以是与系统打交道的其他应用程序或硬件部件。分析员必须在项目初期便确定产品有哪些不同的用户类,并描述它们的特点,这样就能从每个重要用户类的代表那里获取用户需求。软件工程34每一个项目,包括企业信息系统、商业应用软件、数据包、集成系统、嵌入式系统、互联网Internet应用程序等,都需要有合适的用户来提供用户需求。5.确定目标系统的业务工作流具体到当前待开发的应用系统,确定系统的业务工作流和主要的业务规则。例如,针对信息系统的需求调研方法如下:1)调研用户组织

1 / 192
下载文档,编辑使用

©2015-2020 m.777doc.com 三七文档.

备案号:鲁ICP备2024069028号-1 客服联系 QQ:2149211541

×
保存成功