《(精编)软件工程教学第四章需求分析》由会员分享，可在线阅读，更多相关《(精编)软件工程教学第四章需求分析（31页珍藏版）》请在金锄头文库上搜索。
1、(精编)软件工程教学第四章需求分析软件需求需求工程分析建模需求管理本章小结学习目标本章介绍需求分析的意义概念和方法了解结构化分析方法和需求管理的关键活动要求学会运用实体关系图数据流图和状态控制图进行结构化分析建模能够编写软件需求规格说明学习方法正确理解需求工程涉及的基本概念结合具体实例运用结构化分析技术从而达到理论学习及在实际项目中应用的目的难重点本章的学习重点在于理解软件需求的概念和重要性熟悉需求开发和需求管理的基本思想和主要活动掌握结构化的分析方法难点是怎样在实际的软件项目中灵活运用这些思想和方法课前思考软件需求存在什么问题什么是软件需求什么是需求工程常见的需求分析方法是什么需求分析的结果
2、可以验证吗需求规格说明有什么质量要求本节知识点软件需求的定义需求的层次导致需求缺陷的原因随着计算机技术的飞速发展软件已经成为人们生活中不可缺少的一部分人们在使用软件的过程中常常会抱怨它无法执行某些基本操作但对于软件开发人员而言用户不断提出新的要求是一件多么烦人的事其实在软件开发过程中遇到的许多问题都是由于收集编写协商修改软件需求过程中的失误带来的诸如信息收集不全功能不明确交流不充分文档不完善需求发生变化等可以这样说软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的祸根开发软件系统最为困难的部分就是准确说明开发什么最为困难的概念性工作便是编写详细的技术需求包括所有面向用户面向机器和其
3、它软件系统的接口IEEE软件工程标准词汇表将需求定义为1用户解决问题或达到目标所需的条件或能力2系统或系统部件要满足合同标准规范或其它正式规定文档所需具有的条件或能力3一种反映上面1或2所描述的条件或能力的文档说明下面列出其他几种关于需求的定义需求是用户所需要的并能触发一个程序或系统开发工作的说明需求是从系统外部能发现系统所具有的满足于用户的特点功能及属性等需求是指明必须实现什么的规格说明它描述了系统的行为特性或属性是在开发过程中对系统的约束软件需求包括四个不同的层次即业务需求用户需求和功能需求另外还有非功能需求软件需求各组成部分之间的关系如下图所示业务需求反映了组织机构或客户对系统或产品高层
4、次的目标要求它们在项目视图与范围文档中予以说明用户需求描述了用户使用产品必须要完成的任务可以在用例模型或方案脚本中予以说明功能需求定义了开发人员必须实现的软件功能使得用户能完成他们的任务从而满足了业务需求非功能需求是从各个角度对系统的约束和限制反映了应用对软件系统质量和特性的额外要求非功能需求包括过程需求产品需求和外部需求三类其中过程需求有交付实现方法和标准等需求产品需求包含性能可用性实用性可靠性可移植性安全保密性容错性等方面的需求外部需求有法规成本操作性等需求需求工程中的缺陷将给项目的成功带来极大风险导致缺陷的原因主要包括以下方面缺乏足够的用户参与客户经常不明白为什么收集需求和确保需求质量需
5、花费那么多功夫开发人员可能也不重视用户的参与究其原因一是因为与用户合作不如编写代码有意思二是因为开发人员觉得已经明白用户的需求了在某些情况下与实际使用产品的用户直接接触很困难而客户也不太明白自己的真正需求然而在项目的早期让具有代表性的用户直接参与到开发队伍中并一同经历整个开发过程很重要用户需求不断增加在开发过程中用户需求经常发生变化但是不断的变更会使其整体结构越来越乱整个程序也难以理解和维护如果要减少需求变更的影响范围就必须在项目的开始对项目视图范围目标约束限制和成功标准给予明确说明并将此说明作为评价需求变更和新特性的参照框架需求模棱两可模棱两可是需求规格说明中最严重的问题它意味着不同的人对需
6、求说明产生了不同的理解或者是同一个人能用不止一个方式来解释某项需求说明模棱两可的需求带来的后果便是返工-重做一些你认为已做好的事情返工会耗费开发总费用的40而7085的重做是由于需求方面的错误引起的添加不必要的特性有时候开发人员力图增加一些用户欣赏但需求规格说明中并未涉及的新功能然而常常是用户并不认为这些功能性很有用开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路具体提供哪些功能要在客户的需要和允许时限内的技术可行性之间求得平衡规格说明过于简单客户往往不明白需求分析的重要性只是提供一份十分简略的规格说明仅涉及产品概念上的内容然后让开发人员在项目进展中去完善从而导致开发人员先建立产品
7、结构再完成需求说明忽略了用户分类大多数产品是由不同的人使用其不同的特性使用频繁程度也有所差异使用者受教育程度和经验水平也不尽相同如果你不能在项目早期就针对所有这些主要用户进行分类的话必然导致有的用户对产品感到失望总体来说导致需求缺陷的原因主要体现在三个方面需求的沟通与理解需求的变化与控制需求说明的明确与完整需求工程中的缺陷将给项目成功带来极大风险如产品的成本过高产品的功能和质量无法完全满足用户的期望等等即使一个项目团队的人员和配备都很不错但不重视需求过程也会付出惨痛的代价本节知识点需求工程的内容需求获取需求分析编写需求文档需求验证需求工程是指应用已证实有效的原理和方法系统地描述出待开发系统及其
8、行为特征和相关约束通常需求工程由一些过程组成可分为需求开发和需求管理两部分需求开发的主要活动确定产品所期望的用户类获取每个用户类的需求了解实际用户任务和目标以及这些任务所支持的业务需求分析源于用户的信息以区别用户任务需求功能需求业务规则质量属性建议解决方法和附加信息将系统级的需求分为几个子系统并将需求中的一部份分配给软件组件了解相关质量属性的重要性商讨实施优先级的划分将所收集的用户需求编写成规格说明和模型评审需求规格说明确保对用户需求达到共同的理解与认识并在整个开发小组接受说明之前将问题都弄清楚需求管理的主要活动定义需求基线评审提出的需求变更评估每项变更的可能影响从而决定是否实施它以一种可控制
9、的方式将需求变更融入到项目中使当前的项目计划与需求一致估计变更需求所产生影响并在此基础上协商新的承诺让每项需求都能与其对应的设计源代码和测试用例联系起来以实现跟踪在整个项目过程中跟踪需求状态及其变更情况今天我们引入需求工程的概念强调用工程化的方法进行需求开发和需求管理其中需求开发是采用有效方法获得高质量需求的过程而需求管理则是在需求说明形成之后有效地控制其变更的过程二者缺一不可一工作内容聆听用户的需求分析和整理所获取的信息形成文档化的描述二基于用例的方法随着面向对象技术的发展基于用例的方法在需求获取和建模方面应用得越来越普遍这种方法是以任务为中心和以用户为中心的比起使用以功能为中心的方法它可以
10、使用户更清楚地认识到新系统允许他们做什么用例模型以用户和任务为中心将整个工作的焦点集中在从用户的角度说明系统能够干什么完全不考虑具体的实现细节从而达到准确地理解客户需求的目的在用例模型中角色和用例是两个基本概念分别代表着系统外部的执行者和系统应包含的功能因此建立用例模型的主要工作是确定角色确定用例和描述用例A确定角色角色代表着与系统交互的人或事通过确认系统功能使用者和维护者以及与系统接口的其他系统或硬件设备等可以有效地识别出系统角色B确定用例一个完整的系统包含若干个用例每个用例具体说明应完成的功能识别用例首先要确定系统所能反映的外部事件并把这些事件与参与的执行者和特定的使用实例联系起来最终绘制
11、出用例图C描述用例单纯地使用用例图不能提供用例所具有的全部信息因此需要使用文字描述那些不能反映在图形上的信息用例描述实际上是关于角色与系统如何交互的规格说明要求清晰明确没有二义性建立用例模型是一种需求获取的有效方法其简洁清晰的描述方式容易被软件人员和用户共同理解和接受这种方法已经在许多大型系统的开发中取得成效实践证明它能有效地解决用户参与的问题需求分析主要是对收集到的需求进行提炼分析和仔细审查以确保所有的风险承担者都明白其含义并找出其中的错误遗漏或其它不足的地方形成完整的分析模型分析的目的在于开发出高质量的和具体的需求从而支持项目的估算和软件的设计开发和测试需求分析的主要活动包括绘制系统关联图
12、创建用户接口原型分析需求可行性确定需求的优先级别创建数据字典为需求建立模型绘制系统关联图这种关联图用于定义系统与系统外部实体间的界限和接口的简单模型创建用户接口原型当开发人员或用户不能确定需求时开发一个用户接口原型可以使许多概念和可能发生的事更为直观明了用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题同时找出需求文档与原型之间所有的冲突之处分析需求可行性在允许的成本和性能要求下分析每项需求实施的可行性明确与每项需求实现相联系的风险包括与其它需求的冲突对外界因素的依赖和技术障碍确定需求的优先级别应用分析方法来确定用例产品特性或单项需求实现的优先级别以优先级为基础确定产品版本将包括哪些
13、特性或哪类需求当允许需求变更时在特定的版本中加入每一项变更并在那个版本计划中作出需要的变更为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明它们能提供不同的信息与关系以帮助找到不正确的不一致的遗漏的和冗余的需求这些模型包括数据流图实体关系图状态变换图对话框图对象类及交互作用图等创建数据字典数据字典是对系统用到的所有数据项和结构的定义以确保开发人员使用统一的数据定义在需求阶段数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语分析建模的方法有很多其中最重要的两种方法是结构化分析和面向对象分析结构化分析方法提供实体关系图数据流图和状态转换图三种图形模型分别进行数据建
14、模功能建模和动态建模人们习惯于用自然语言来描述软件需求但这会产生许多意想不到的问题如不精确二义性等因此需要采用适当的方法形成一致的完备的和无二义性的软件需求规格说明通常编写软件需求规格说明有三种方法将结构化语言与自然语言结合编写文本型文档建立可视化的模型采用形式化的方法进行需求规格说明软件需求规格说明是需求开发的最终结果它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件软件需求规格说明不仅是系统测试和用户文档的基础也是所有子系列项目规划设计和编码的基础软件需求规格说明是用户分析人员和设计人员之间进行理解和交流的手段测试人员可以根据软件需求规格说明中对产品行为的描述制定测试计划
15、测试用例和测试过程文档人员根据软件需求规格说明和用户界面设计编写用户手册等软件需求规格说明指导着整个系统的开发过程评审过的需求规格说明需要进行变更控制a引言概要叙述软件需求规格说明便于读者理解文档如何编写以及如何阅读和解释在软件项目中开发组织应该采用一种标准的软件需求规格说明的模板现在有许多软件需求规格说明模板可以使用这里介绍其中的一种a1目的对产品进行定义在该文档中详尽说明了这个产品的软件需求包括修正或发行版本号如果这个软件需求规格说明只与整个系统的一部分有关系那么就只定义文档中说明的部分或子系统a2文档约定描述编写文档时所采用的标准或排版约定包括正文风格提示区或重要符号a3预期的读者和阅读建议列举了软件需求规格说明所针对的不同读者例如开发人员项目经理营销人员用户测试人员或文档的编写人员描述了文档中剩余部分的内容及其组织结构提出了最适合于每一类型读者阅读文档的建议a4产品范围提供了对指定的软件及其目的的简短描述包括利益和目标a5参考文献列举了编写软件需求规格说明时所参考的资料或其它资源可能包括用户界面风格指导合同标准系统需求规格说明使用实例文档或相关产品的软件需求规格说明在这里应该给出详细的信息包括标题名称作者版本号日期出版单位或资料来源以方便读者查阅这些文献b综合描述这一部分概述了正在定义的产品以及它所运行的环境使用产品的用户和已知的限制假设和依赖b1产品的前景描
