4、软件工程(第2章 软件项目的需求分析)

合集下载

软件工程需求分析(精品PPT)

软件工程需求分析(精品PPT)
•确定被开发软件系统的系统元素
•将功能和信息结构分配到这些系统元素中 •需求分析的任务
•深入描述软件的功能和性能 •确定软件设计的约束和软件同其它系统元素的接口细节
•定义软件的其它有效性需求
第四页,共七十七页。
需求(xūqiú)分析的具体任务
•需求分析阶段的具体任务:
•确定对系统的综合要求
•系统功能要求
第四章 析根底
软件工程 需求分 (ruǎn jiàn ɡōnɡ chénɡ)
第一页,共七十七页。
第四章 需求分析 根底 (fēnxī)
• 需求(xūqiú)分析的任务与原那么〔重点〕 • 需求分析的任务 • 需求分析的过程 • 软件需求分析的原那么 • 初步需求获取技术 • 需求建模〔重点〕 • 问题抽象、问题分解与多视点分析 • 支持需求分析的快速原型技术 • 需求规格说明书
第二十六页,共七十七页。
教务管理系统调查分析过程 1、认真学习教务管理方面的知识,重点掌握其中
的名词和术语 2、收集目前教务管理方面资料和软件,了解其特
•了解系统的需求 •软件开发是系统开发的一局部,仔细分析研究系统的需求 规格说明,对软件的需求获取是很有必要的
第十六页,共七十七页。
✓需求调查对象
对组织的高层管理者,进行组织管理目标或经营方 针等组织战略问题的调查
对中层的管理者,进行全部业务流的调查 对业务工作人员,进行详细业务信息的调查
✓市场调查 了解市场对待开发软件有什么样的要求;了解市场上 有无与待开发软件类似的系统
第十页,共七十七页。
需求(xūqiú)分析流程
第十一页,共七十七页。
软件需求(xūqiú)分析的原那么
1、需要能够表达和理解问题的信息域和功能域 信息域应包括:

第二章2系统分析—需求分析.

第二章2系统分析—需求分析.

(3)确定调研方案

调研方式
主导型
用户经验不足,认识不清晰,需要调研人员整理需 求概要内容,提交给用户进行分析和初步确认,最 终由用户和调研实施人员对需求内容进行细化、确 认的过程。 对调研人员要求较高; 与用户真实意图可能存在偏差。

(3)确定调研方案

调研方式
引导型
用户有较为完整、系统的知识、经验积累,调研人 员引导用户将需求阐述完整、清晰,最终由用户对 需求进行确认的过程称之为引导型调研。 用户和调研实施人员相互配合程度高 ; 此种调研方式的进度和质量风险最小 。


……
需求工程的主要阶段
需求工程 需求开发 需求管理
需 求 获 取
需 求 分 析
需 求 规 约
需 求 验 证
变 更 控 制
版 本 控 制
需 求 跟 踪
需 求 状 态 跟 踪
需求规格说明书
需求开发
需求验证 —— 帮 助确定实现了正确 的需求 需求获取 —— 搜集 与探索需求的过程
需求开发 过程
组织机构或用户对系统的高层次目标要求用户使用系统必须要完成的任务必须要实现的软件功能内容层次常见非功能需求可用性计划开机时长平均故障时间间隔mtbf等高效性系统如何高效利用处理器磁盘空间通讯带宽灵活性向产品中加入其它功能需要多大劤力完整性阻止未经授权的访问修改互操作性与其他系统交换数据或服务可靠性无错误的软件执行稳健性系统遭遇无效数据或其他干扰时继续正常运作的程度易用性用户友好易于使用符合人机工程维护性是否易于修正一个缺陷或改劢软件移植性把软件从一个操作系统移植到另一个所需的劤力支持平台数重用性为某个应用所设计的模块能被其他应用重复所用的程度测试软件模块或者所整合产品的难易度量化需求需求类型测量范例观感接受率易用性错误率性能与速度响应时间可靠性停工时间移植性平台数稳健性致命非致命错误比例维护性修改所需的时间和工作量大小源代码行数sourcelinescodesloc认证所符合的诸标准需求的来源调研前活动调研前活动调研实施调研实施识别调研范围组建调研团队确定调研方案调研准备前期沟通识别调研范围组建调研团队确定调研方案调研准备前期沟通决定了需求调研对象调研参与人员和调研周期的长短

软件工程概论课后答案解析

软件工程概论课后答案解析

第1章软件与软件工程的概念1、1 举出您所知道的应用软件的例子。

办公软件、游戏软件、财务软件、银行软件、人事管理软件、工资管理软件、学籍管理软件等。

1、2 认为“软件就就是程序,软件开发就就是编程序。

”这种观点就是否正确?为什么?认为“软件就就是程序,软件开发就就是编程序。

”这种观点就是错误的。

首先,软件就是计算机系统中与硬件相互依存的另一部分,它就是包括程序,数据及其相关文档的完整集合,程序只就是软件的组成部分之一;其次,在软件开发中,编程只就是软件开发过程的一个阶段。

1、3 如果将软件开发比作高楼大厦的建造,可以将软件的设计比作什么?可以将软件的设计比作建筑设计,软件设计的成果相当于建筑设计的设计图纸。

1、4 什么就是软件危机?它有哪些典型表现?为什么会出现软件危机?软件危机:软件危机就是指在计算机软件的开发与维护过程中所遇到的一系列严重问题。

典型表现:(1)对软件开发成本与进度的估计常常很不准确。

(2)用户对“已完成的”软件系统不满意的现象经常发生。

(3)软件产品的质量往往靠不住。

(4)软件常常就是不可维护的。

(5)软件通常没有适当的文档资料。

(6)软件成本在计算机系统总成本中所占的比例逐年上升。

(7)软件开发生产率提高的速度,既跟不上硬件的发展速度,也远远跟不上计算机应用迅速普及深入的趋势。

产生软件危机的原因:除了软件本身的特点,其原因主要有以下几个方面:(1) 缺乏软件开发的经验与有关软件开发数据的积累,使得开发工作计划很难制定。

(2) 软件人员与用户的交流存在障碍,使得获取的需求不充分或存在错误。

(3) 软件开发过程不规范。

如,没有真正了解用户的需求就开始编程序。

(4) 随着软件规模的增大,其复杂性往往会呈指数级升高。

需要很多人分工协作,不仅涉及技术问题,更重要的就是必须有科学严格的管理。

(5) 缺少有效的软件评测手段,提交给用户的软件的质量不能完全保证。

1、5 什么就是软件工程?软件工程就是指导计算机软件开发与维护的工程学科。

软件工程第二章(可行性分析)

软件工程第二章(可行性分析)

(5) 交付的产品清单。
项目开发计划书供软件开发单位使用。
小结:
1、项目的问题定义、可行性分析和项目计划是总体 规划阶段的工作,重点是项目的可行性分析。
2、可行性分析主要从技术可行性、经济可行性和操 作可行性三方面来分析该项目是否值得开发。
3、可行性分析最后形成的成果是可行性分析报告。

项目的筹备、规划与准备是软件项目实施的前
期工作,它由两个重要的工作阶段构成:一是
项目规划及可行性分析;二是项目需求分析。

一、可行性分析的概念

可行性分析就是解决一个项目是否有可行解以及是
否值得去解的问题。该阶段的主要任务就是用最小
的代价在尽可能短的时间内确定问题是否能够得到 解决。
二、可行性分析的目标和内容
等。
(6) 技术可行性(技术风险评价):技术实力分析、已有的 工作及技术基础和设备条件等等。 (7) 法律可行性分析结果描述。 (8) 可用性评价:汇报用户的工作制度和人员的素质,确 定人机交互功能界面需求。
(9) 其他项目相关的问题:如可能会发生的变更等等。
可行性研究报告由系统分析员撰写,交由项目负责人审查, 再上报给上级主管审阅。 在可行性研究报告中,应当明确项目“可行还是不可行”, 如果认为可行,接下来还要制定项目开发计划书。


识别用户要求 评价系统的可行性 进行经济分析和技术分析 把功能分配给硬件、软件、人、数据库和其它系 统元素 建立成本和进度限制 生成系统规格说明,形成所有后续工程的基础
三、 可行性分析的主要任务
具体地说,分析员应从下面三个方面对项目做出可行性分 析: (1)技术可行性:使用现有的技术能实现这个系统吗? (2)经济可行性:这个系统的经济效益能超过它的开发成本 吗?(详细在后面介绍成本/效益分析) (3)操作可行性:系统的操作方式在该用户组织内行得通吗?

天津大学软件工程课程教学大纲

天津大学软件工程课程教学大纲

2. Course Description This course presents an introduction to the basic concepts of software, objects of
software engineering, traditional procedure-oriented soft development methods and object-oriented soft development methods, so students can master the method to develop high quality software. By learning the software develop process and process management techniques, students can understand how to conduct software metrics and management, how to take quality assurance activities, so the students can plan and manage software development activities effectively.
《软件工程——理论与实践(第三版)》,Pfleeger.S.L,Atlee.J.M.著,高等教 育出版社,2006 年 9 月。
制定人: 审核人: 批准人: 批准日期:
年月日
TU Syllabus for Software Engineering
Code:
2160288
Semester Hours: 56
Chapter 2 Software Process Software Process Model Component-Based Development Process RUP CMM

软件工程各章名词解释

软件工程各章名词解释

名词解释一个三分 五个十五分第一章 绪论1. 软件2. 文档3. 软件工程4. 软件工程过程5. 软件生存周期6. 软件生存周期模型第二章 软件可行性研究与项目开发计划1. 投资回收2. 纯收人第三章 软件需求分析1. 需求分析2. 数据流3. 数据字典4. 加工5. 数据流图第四章 软件概要设计1. 模块2. 模块化3. 抽象4. 信息隐蔽5. 模块独立性6. 耦合性7. 无直接耦合8. 数据耦合9. 标记耦合10. 控制耦合11. 公共耦合12. 内容耦合13. 内聚性14. 偶然内聚15. 逻辑内聚16. 时间内聚17. 通信内聚18. 顺序内聚19. 功能内聚第五章 软件详细设计1. PAD2. 过程设计语言(PDL)第六章 软件编码1. 程序设计风格2. 程序可移植性第七章 软件测试1. 语句覆盖2. 判定覆盖3. 条件覆盖4. 判定/条件覆盖5. 条件组合覆盖6. 路径覆盖7. 环路复杂性8. 黑盒测试9. 白盒测试10. 驱动模块11. 桩模块12. 单元测试13. 集成测试14. 确认测试15. 调试第八章 软件维护1. 维护2. 校正性维护3. 适应性维护4. 完善性维护5. 预防性维护6. 软件可维护性第九章 软件开发的增量模型1. 原型第十章 面向对象的方法1. 对象2. 类3. 消息4. 方法5. 继承性6. 单重继承7. 多重继承8. 多态性9. 抽象10. 信息隐藏11. 链12. 关联第十一章 软件质量与质量保证1. 软件可靠性2. 效率3. 可维护性4. 可移植性5. 可互操作性6. 适应性7. 可重用性8. 软件设计质量9. 软件程序质量10. 冗余第十二章 软件工程管理1. 软件配置管理2. 软件配置项3. 基线4. 文档第十三章 软件开发环境1. 软件开发环境2. 软件工具3. CASE4. CASE生存期5. CASE工作台软件工程自考名词解释答案第一章 绪论1. 计算机程序及其说明程序的各种文档.2. 文档是有关计算机程序功能,设计,编制,使用的方案或图形资料.3. 用科学知识和技术原理来定义,开发,维护软件的一门学科.4. 软件工程过程规定了获取,供应,开发,操作和维护软件时,要实施的过程,活动和任务.5. 软件生存周期是指一个软件从得出开发要求开始直到该软件报废为止的整个时期.6. 软件生存周期模型是描述软件开发过程中各种活动如何执行的模型.第二章 软件可行性研究与项目开发计划1. 投资回收期就是使累计的经济效益等于最初的投资费用所需的时间.2. 在整个生存周期之内的累计经济效益(折合成现在值)与投资之差.第三章 软件需求分析1. 需求分析是指开发人员要准确理解用户的要求,进行细致的调查分析,将用户非不甘落后将用户非不甘落后 需求陈述转化为完整的需求定义,再由需求定义转换到相应的形式功能规约(需求规格说明)的过程.2. 数据流是数据在系统内传播的路径,因此由一组成分固定的数据项组成.3. 数据字典(Data Dic onary, 简称DD)就是用来定义数据流图中的各个成分的具体含义的,它以一种准确的,无二义性的说明方式为系统的分析,设计及维护提供了有关元素的一致的定义和详细的描述.4. 加工又称为数据处理,是对数据流进行某些操作或变换.5. 数据流图,简称DFD,是SA方法中用于表示系统逻辑模型的一种工具,它以图形的方式描绘数据在系统中流动和处理的过程.第四章 软件概要设计1. 模块在程序中是数据说明,可执行语句等程序对象的集合,或者是单独命名和编址的元素,在软件的体系结构中,模块是可组合,分解和更换的单元.2. 模块化是指解决一个复杂问题自顶向下逐层把软件系统划分成若干模块的过程.每个模块完成一个特定的子功能,所有的模块按某种方法组装起来,成为一个整体,完成整个要求的功能.3. 抽象是认识复杂现象过程中使用的思维工具,即抽出事物本质的共同的特性而暂不考虑它的细节,不考虑其他因素.4. 信息隐蔽指在设计和确定模块时,使得一个模块内包含信息(过程或数据),对于不需要这些信息的其他模块来说,是不能访问的.5. 模块独立性指每个模块只完成系统要求的独立的子功能,并且与其他模块的联系最少且接口简单.6. 耦合性也称块间联系.指软件系统结构中各模块间相互联系紧密程序的一种度量.7. 无直接耦合指两个模块之间没有直接的关系,它们分别从属于不同模块的控制与调用,它们之间不传递任何信息.8. 数据耦合指两个模块之间有调用关系,传递的是简单的数据值,相当于高级语言的值传递.9. 标记耦合指两个模块之间传递的是数据结构,如高级语言的数组名,记录名,文件名等这些名字即为标记,其实传递的是这个数据结构的地址.10. 控制耦合指一个模块调用另一个模块时,传递的是控制变量(如开关,标志等),被调模块通过该控制变量的值有选择地执行块内某一功能.11. 公共耦合指通过一个公共数据环境相互作用的那些模块间的耦合.公共数据环境可是是全程变量或数据结构,共享的通信,内存的公共覆盖区及任何存储介质上的文件,物理设备等(也有将共享外部设备分类为外部耦合).12. 当一个模块直接使用另一个模块的内部数据,或通过非正常口转入另一个模块内部,这种模块之间的耦合为内容耦合.13. 内聚块又称块内联系指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的度量.14. 偶然内聚指一个模块内的各处理元素之间没有任何联系.15. 逻辑内聚指模块内执行个逻辑上相似的功能,通过参数确定该模块完成哪一个功能.16. 把需要同时执行的动作组合在一起形成的模块为时间内聚模块.17. 通信内聚指模块内所有处理元素都在同一个数据结构上操作(有时称之为信息内聚),或者指各处理使用相同的输入数据或者产生相同的输出数据.18. 顺序内聚指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行,前一功能元素的输出就是下一功能元素的输入.19. 功能内聚指模块内所有元素共同完成一个功能,缺一不可.因此模块不能再分割.第五章 软件详细设计1. PAD图指问题分析图(Problem Analysis Diagram),是一咱算法描述工具,它是一种由左往右展开的二维树型结构.PAD图的控制流程为自上而下,从左到右地执行.2. 过程设计语言(Process Design Language,简称PDL),也称程序描述语言(Program Descrip on Language),又称为伪码.它是一种用于描述模块自法设计和处理细节的语言.第六章 软件编码1. 程序设计风格指一个人编制程序时所表现出来的特点,习惯逻辑思路等.2. 指程序从一个计算机环境移值到另一个计算机环境的容易程序.第七章 软件测试1. 语句覆盖是指设计足够的测试用例,使被测程序中每个语句至少执行一次.2. 判定覆盖指设计足够的测试用例,使得被测程序中每个判定表达式至少获得一次”真”和”假”值,从而使程序的每一个分支至少都通过一次.3. 条件覆盖指设计足够的测试用例,使得判定表达工中每个条件的各种可能的值出现一次.4. 判定/条件覆盖标准指设计足够的测试用例,使得判定表达式中的每个条件的所有可能取值至少出现一次,并使每个判定表达式所有可能的结果也至少出现一次.5. 条件组合覆盖是比较强的覆盖标准,它是指设计足够的测试用例,使得每个判定表达式中条件的各种可能的值的组合都至少出现一次.6. 路径覆盖是指设计足够的测试用例,覆盖被测程序中所有可能的路径.7. McCabe定义程序图的环路为程序图中区域的个数.区域个数为边和结点圈定的封闭区域数加上图形外的区域数1.8. 黑盒测试是功能测试又称为功能测试或数据驱动测试.9. 白盒测试是对程序中尽可能多和逻辑路径进行测试,检验内部控制结构和数据结构是否有错,实际的运行状态与预期的状态是否一致.10. 驱动模块是用来模拟被测模块的上级调用模块的模块,功能要比真正的上级模块简单得多,它只完成接受测试数据,以上级模块调用被测模块的格式驱动被模块,接收被测模块的测试结果并输出.11. 桩模块用来代替被测试模块所调用的模块它的作用是返回被测模块所需的信息.12. 单元测试指对源程序中每一个程序单元进行测试,检查各个模块是否正确实现规定的功能,从而发现模块在编码中或算法中的错误.13. 集成测试是指在单元测试的基础上,将所有模块按照设计要求组装成一个完整的系统进行测试,故也称组装测试或联合测试.14. 确认测试又称有效性测试.是为了检查软件的功能与性能是否与需求规格说明书中确定的指标相符合所进行的测试.15. 调试是为了确定错误的原因和位置,并改正错误所进行的工作,因此调试也称为纠错.第八章 软件维护1. 在软件运行/维护阶段对软件产品所进行的修改就是维护.2. 为了识别和纠正错误,修改软件性能上的缺陷,应进行确定和修改错误的过程,这个过程就称为校正性维护.3. 随着计算机的飞速发展,计算机硬件,软件及数据环境在不断发生变化,为了使应用软件适应这种变化而修改软件的过程称为适应性维护.4. 在犯罪分子件运行时期中,用户往往会对软件提出新的功能要求与性能要求.这种增加软件功能,增强软件性能,提高软件运行效率而进行的维护活动称为完善性维护.5. 为了提高软件的可维护性和可靠性而对软件进行的修改称为预防性维护.6. 软件可维护性是指软件能够被理解,校正,适应及增强功能的容易程度.第九章 软件开发的增量模型1. 软件开发中的原型是软件的一个早期可运行的版本,它反映了最终系统的重要特性.第十章 面向对象的方法1. 对象是人们要进行研究的任何事物,从最简单的整数到复杂的飞机等均可看作对象,它不仅能表示具体的事物,还能表示抽象的规则,计划或事件.2. 具有相同或相似性质的对象的抽象就是类具有相同或相似性质的对象的抽象就是类3. 对象之间进行通信的构造叫做消息.4. 类中操作的实现过程叫做方法,一个方法有方法名,参数,方法体.5. 继承性是子类自动共享父类数据结构和方法的机制这是类之间的一种关系.6. 在类层次中,子类只继承一个父类的数据结构和方法,称为单重继承.7. 在类层次中,子类继承了多个父亲的数据结构和方法,称为多重继承.8. 多态性是指相同的操作或函数,过程可作用于多用户种类型的对象上并获得不同结果.不同的对象收到同一消息可以产生不同的结果,这种现象称为多态性.9. 抽象是指强调实体的本质,内在的属性,忽略一些无关紧要的属性.10. 信息隐蔽是指所有软件部件内部都有明确的范围以及清楚的外部边界每个软件部件都有友好的界面接口,软件部件的内部实现与外部可访问性分离.11. 链表示对象间的物理与概念联结.12. 关联表示类之间的一种关系,就是一些可能的链的集合.第十一章 软件质量与质量保证1. 软件按照设计要求,在规定时间和条件下不出故障,持续运行的程度.2. 为了完成预定功能,软件系统所需的计算机资源和程序代码数量的程度.3. 找到并改正程序中的一个错误所需代价的程度.4. 将一个软件系统从一个计算机系统或环境移植到另一个计算机系统或环境中运行时所需的工作量.5. 将一个系统耦合到另一个系统所需的工作量.6. 修改或改进一个已投入运行的软件所需工作量的程度.7. 一个软件能再次用于其他相关应用的程度.8. 设计的规格说明书要符合用户的要求.9. 程序要按照设计规格说明所规定的情况正确执行.10. 冗余是指实现系统规定功能是多余的那部分资源,包括硬件,软件,信息和时间.第十二章 软件工程管理1. 软件配置管理,简称SCM,是一组管理整个软件生存期各阶段中变更的活动是一组管理整个软件生存期各阶段中变更的活动2. 软件配置项是软件工程中产生的信息项,它是配置管理的基本单位.3. 基线是软件生存期中各开发阶段的一个特定点,它的作用是把开发各阶段工作的划分更加明确化,使本来连续的工作在这些点上断开,以便于检查与肯定阶段成果.4. 文档是指某种数据媒体和其中所记录的数据.在软件工程中,文档用来表示对需求,工程或结果进行描述,定义,规定,报告或认证的任何书面或图示的信息.它们描述和规定了软件设计和实现的细节,说明使用软件的操作命令.第十三章 软件开发环境1. 软件开发环境是相关的一组软件工具集合,它支持一定的软件开发方法或按照一定的软件开发模型组织而成.2. 软件工具是指为支持计算机软件的开发,维护,模拟,移植或管理而研制的程序系统.3. CASE是一组工具和方法的集合,可以辅助软件开发生命周期各阶段进行软件开发.4. 一个组织中的CASE系统从被始需求到完全废弃这一生存期.5. 一个CASE工作台是一组工具集,支持像设计,实现或测试等特定的软件开发阶段.。

软件工程导论 第2章 可行性分析

软件工程导论 第2章 可行性分析
(1) 技术可行性
(2) 经济可行性 (3) 操作可行性 (4)法律可行性等
复习回顾
1、可行性研究的目的是什么? 用最小的代价在尽可能短的时间内确定问题是否能够解决。 2、可行性研究的任务主要是什么? 了解客户的要求 及现实环境
分析技术、经济和社会因素可行性 编写可行性研究报告 制定初步项目开发计划


按照系统的层次结构进行逐步分解,并以分层的
数据流图反映这种结构关系,能清楚地表达和容
易理解整个系统。
首先画“顶层DFD”
描绘系统的整体逻辑概貌
外部实体 软件 系统
……
外部实体
……
外部实体
外部实体
顶层流图仅包含一个加工,它代表被开发系统。它的输入流
是该系统的输入数据,输出流是系统所输出数据。
其次画中间层流图:对上层父图的处理的细化,形成子图。
没有数据字典数据流图就不严格,没有数据流图
数据字典也难于发挥作用。
数据字典的内容
一般说来,数据字典应该由对下列4类元素 的定义组成: (1) 数据流 (2) 数据流分量(即数据元素)
(3) 数据存储
(4) 处理
2.5.2定义数据的方法
符号 = + [ ]与 | { } m
被定义为
+订货数量+目前价格+主要供应者
+次要供应者
位置:输出到打印机
•例如:
名字:零件编号 别名: 描述:唯一地标识库存清单中 一个特定零件的关键域 定义:零件编号=8{字符}8 位置:订货报表 订货信息 库存清单 事务
名字:订货数量 别名: 描述:某个零件一次订货的数量 定义:订货数量=1{数字}5
位置:订货报表

《软件工程》第2章_软件可行性研究

《软件工程》第2章_软件可行性研究
为了使读者具体了解怎样编写可行性研究报告技术文档, 下面对可行性研究报告的内容要求及写法作一下简要说明。
2.3 可行性研究报告
2.3 可行性研究报告
2.3 可行性研究报告
2.3 可行性研究报告
2.3 可行性研究报告
2.4 小结
可行性研究是抽象和简化了的系统分析和设计的全 过程,它的目标是用最小代价尽快确定问题是否能够解 决,以避免盲目投资带来的巨大浪费。可行性研究是从 技术上、经济上、使用上、法律上分析应解决的问题是 否有可行的解,从而确定该软件是否有可行的解。
上述可行性研究的步骤只是一个经过长期实践总结出来的 框架,在实际的使用过程中,它不是固定的,根据项目的性质、 特点以及开发团队对业务领域的熟悉程度会有些变化。
2.3 可行性研究报告
可行性研究可以归档为一个单独的报告,提供给上级管理 部门,又可以包括在“系统规格说明”的附录中,虽然可行性 报告的形式可以有多种,但最重要的内容应当有:
第二章 软件可行性研究
【本章引言】
在计算机的软件项目开发过程中,只要资源和时间 不加以限制,所有的项目都是可行的。然而,由于资源 缺乏和交付时间限制的困扰,使得基于计算机系统的开 发变得比较困难。因此,尽早对软件项目的可行性做出 细致而谨慎的评估是十分必要的。如果在定义阶段及早 发现将来可能在开发过程中遇到的问题及早做出决定, 可以避免大量的人力、财力、时间上的浪费。
本章简要的介绍了有关可行性研究的任务、步骤, 以及在撰写可行性研究报告时有哪些要求。
2.5 习题
1. 为什么要对计算机软件项目进行可行性研
究?
2. 可行性研究主要研究哪些问题?试说明之。 3. 可行性研究的任务是什么? 4. 可行性研究的步骤? 5. 撰写可行性研究报告的方法?

软件工程课件第2章

软件工程课件第2章
过程,也就是在较高层次上以较抽象的方式进 行的系统分析和设计的过程。
精选ppt
6
可行性研究的内容: 首先进一步分析和澄清问题定义,导出系统的
逻辑模型; 然后从系统逻辑模型出发,探索若干种可供选
择的主要解法(即系统实现方案); 对每种解法都研究它的可行性,至少应该从三
方面研究每种解法的可行性 。
精选ppt
3
关于系统规模和目标的报告书
1.项目名称:教材销售系统 2.问题:人工发售教材手续繁杂,且易出错。 3.项目目标:建立一个高效率、无差错的微机教材销售
系统。 4.项目规模:利用现有微型计算机,软件开发费用不超
过5000元。 5.初步想法:建议在系统中增加对缺书的统计与采购功
能。 6.可行性研究:建议进行大约10天的可行性研究,研究
该装配厂使用一台小型计算机,处理更新库存清单主文 件和产生定货报告。零件库存量的每一次变化称为一个事务, 由放在仓库中CRT终端输入到计算机中;系统中的库存清单 程序对事务进行处理,更新存储在磁盘上的库存清单主文件, 并且把必要的订货信息写在磁带上。最后,每天由报告生成 程序读一次磁带,并且打印出订货报告。
包括开发和运行该系统所需要的各种资源 如硬件、软件、人员和组织机构等 3. 费用预算:分阶段的人员费用、机时费用及其他费用 4. 进度安排:各阶段起始时间、完成文档及验证方式 5. 要交付的产品清单
精选ppt
16
8. 书写文档提交审查 把可行性研究各个步骤的工作结果写成清晰的
文档,请用户、客户组织的负责人及评审组审 查,以决定是否继续这项工程及是否接受分析 员推荐的方案。
库存清单 主文件
报告生成程序
定货报告
第三层:合成后的系统流程图

软件工程中的软件项目启动与规划

软件工程中的软件项目启动与规划

●05
第五章 软件质量管理
什么是软件质量管理
软件质量管理是确保软件产品 符合用户需求和标准的管理过 程。通过对软件开发过程的监 控和控制,确保软件产品具有 高质量、高可靠性和高安全性。 软件质量管理是软件工程中非 常重要的一个环节,关乎用户 体验和产品质量的提升。
软件质量管理的方法
编写测试计划
设计灵活,可以方 便地扩展功能。
高效性
保证系统运行的高 效性和性能。
软件架构设计的模式
MVC模式
将系统划分为 Model、View和 Controller,分离 业务逻辑和界面显
示。
分层架构
将系统划分为 Presentation、 Business和Data 层,实现业务逻辑 和数据访问的分离。
微服务架构
软件项目启动与规划
制作人: 时间:2024年X月
目录
第1章 软件项目启动 第2章 软件项目规划 第3章 软件需求分析 第4章 软件架构设计 第5章 软件质量管理
第6章 软件项目总结与回顾
●01
第一章 软件项目启动
什么是软件项目启动
软件项目启动是软件工程项目 管理中的第一个阶段,确定项 目的目标和范围,确保项目的 可行性等。在项目启动阶段, 团队需要明确项目目标、项目 需求、项目限制条件等,为项 目实施和管理打下基础。
软件需求分析的方法
采访用户
与用户沟通,了解 他们的需求和期望
分析需求文档
整理和分析用户提 供的需求文档,提
取关键信息
观察用户操作
观察用户在实际操 作中的行为,发现
需求
原型设计
创建软件原型,让 用户更直观地了解
功能和界面
软件需求分析的重要性

软件工程(邓良松)第二章

软件工程(邓良松)第二章

第2章 软件要求定义
应该收集、研究和分析现有系统的文档资料,实地考察现 有系统,在考察的基础上,访问有关人员,然后描绘现在系统 的高层系统流程图(见2.1.3节), 与有关人员一起审查该系统流 程图是否正确。系统流程图反映了现有系统的基本功能和处理 流程。 (3) 建立新系统的高层逻辑模型。根据对现有系统的分析 研究,逐渐明确新系统的功能、处理流程以及所受的约束,然 后使用建立逻辑模型的工具——数据流图和数据字典(见8.3、8.4 节)来描述数据在系统中的流动和处理情况。注意,现在还不是 软件需求分析阶段,不是完整、详细的描述,只是概括地描述 高层的数据处理和流动。
第2章 软件要求定义
1. 技术可行性 技术可行性 对要开发项目的功能、 性能和限制条件进行分析, 确定在 现有的资源条件下,技术风险有多大,项目是否能实现,这些 即为技术可行性研究的内容。这里的资源包括已有的或可以搞 到的硬件、软件资源,现有技术人员的技术水平和已有的工作 基础。 技术可行性常常是最难解决的方法,因为项目的目标、功 能和性能比较模糊。技术可行性一般要考虑的情况包括: (1) 开发的风险: 在给出的限制范围内, 能否设计出系统 并实现必须的功能和性能? (2) 资源的有效性: 可用于开发的人员是否存在问题? 可用 于建立系统的其他资源是否具备?
第2章 软件要求定义
输入变更记录
库存管理模块
订货信息
报告生成模块 订货报告
库存
图 2.1 库存管理系统的系统流程图
第2章 软件要求定义
2.1.4 成本 效益分析 成本—效益分析
成本—效益分析的目的是从经济角度评价开发一个新的软 件项目是否可行。成本一效益分析首先是估算将要开发的系统 的开发成本,然后与可能取得效益进行比较和权衡。效益分有 形效益和无形效益两种。有形效益可以用货币的时间价值、 投资回收期和纯收入等指标进行度量;无形效益主要从性质上、 心理上进行衡量,很难直接进行量的比较。系统的经济效益等 于因使用新的系统而增加的收入加上使用新的系统可以节省的 运行费用。运行费用包括操作人员人数、工作时间和消耗的物 资等。下面主要介绍有形效益的分析。

软件工程-第2章-数据流图

软件工程-第2章-数据流图
可行性研究阶段 软件需求分析阶段

Data flow diagram of the main graphic elements (主要图形元素)
编号 加工 名称
Example of DFD:
DFD of Bank Withdrawals Process
描述银行取款过程的数据流图
Example of DFD:

Each element must have a name DFD can not be attached to control flow In the beginning, the trivial details could be ignored, in order to concentrate on the main data stream
图上每个元素都必须有名字 数据流图中不可夹带控制流 初画时可以忽略琐碎的细节,以集中精力于主要数据流

Naming for each elements of DFD If it is difficult to give a name, it is possible because DFD decomposition problem Data Flow (Database): Using data noun Processing: using verb-object phrase. Data source: using normal noun
Tools of Software Need Analyzing 需求分析工具
Ning Hong-yun 2009.8
Tools of Software Need Analyzing 需求分析工具

Data flow diagram ( DFD, 数据流图)

第二章 软件可行性研究与项目开发计划(软件工程)

第二章 软件可行性研究与项目开发计划(软件工程)

第二章软件可行性研究与项目开发计划2.1可行性研究在进行任何一项较大的工程时,首先都要进行可行性分析和研究。

目的就是用最小的代价在尽可能短的时间内确定该软件项目是否能够开发,是否值得去开发。

2.1.1可行性研究的任务首先需要进行概要的分析研究,初步确定项目的规模,目标,约束和限制。

分析员再进行简要的需求分析,抽象出项目的逻辑结构,建立逻辑模型。

从逻辑模型出发,经过压缩的设计,探索出若干种可供选择的解决方法,对每种解决方法都要研究它的可行性。

主要从三个方面考虑:1.技术可行性对要开发的项目的功能、性能、限制条件进行分析,确定在现有的资源条件下,技术风险有多大,项目是否能实现。

技术可行性是最难解决的,它一般要包括:(1)开发的风险:在给出的限制范围内,能否设计出系统并实现必须的功能和性能。

(2)资源的有效性:人力资源以及用于建立系统的其他资源是否具备。

(3)技术:目前的技术水平能否支持这个系统。

(4)开发人员在评估技术可行性时,一旦估计错误,将会出现灾难性后果。

2.经济可行性进行开发成本的估算以及了解取得效益的评估,确定要开发的项目是否值得投资开发。

3.社会可行性要开发的项目是否存在任何侵犯、妨碍等责任问题,要开发项目的运行方式在用户组织内是否行得通,现有管理制度、人员素质、操作方式是否可行。

2.1.2 可行性研究的具体步骤典型性的可行性研究有下列步骤:1.确定项目规模和目标分析员对有关人员进行调查访问,仔细阅读和分析有关的材料,对项目的规模和目标进行定义和确认,清晰地描述项目的一切限制和约束,确保分析员正在解决的问题确实是要解决的问题。

2.研究正在运行的系统收集、研究、分析现有系统的文档资料,实地考察现有系统,在考察的基础上,访问有关人员,然后描述现有系统的高层系统流程图,与有关人员一起审查该系统流程图是否正确。

这个系统流程图反映了现有系统的基本功能和处理流程。

3.建立新系统的高层逻辑模型根据对现有系统的分析研究,逐步明确了新系统的功能、处理流程以及所受的约束,然后使用建立逻辑模型的工具——数据流图和数据字典来描述数据在系统中的流动和处理情况。

软件工程实验报告——需求分析

软件工程实验报告——需求分析

《软件工程》实验报告酒店管理系统需求分析目录1.系统需求概述01.1背景说明01.2部门划分01.3各子系统的功能02.用例建模02.1参与者列表12.2用例列表12.3用例图12.4用例规格说明22.5辅助需求23.对象建模23.1确定类与对象23.2确定关联23.3确定属性33.4确定服务33.5系统类图44.动态建模44.1顺序图44.2状态图65. 总结71.系统需求概述1.1背景说明酒店管理系统是一个面向酒店用来进行酒店日常管理的系统。

该系统能能够为酒店的管理者对酒店进行比较精确的管理。

酒店管理系统的功能包括以下内容:支持用户进行酒店客房的预定、酒店客房的退订以及退房付款等操作;支持客房部门对用户的预定、退订、退房等进行操作;当客户订房时进行客房查询:如查询客房是否可以预定;当客户退订或退房时:如进行客房状态修改等。

酒店管理系统能够支持财务部门对整个酒店财务进行正常管理。

如客房部在用户退房时的付款管理等。

并整理某一时间段内酒店的整体收益以及员工的薪水管理1.2部门划分⑴管理者用于整体的统计操作,它的主要职责有:①.管理员工。

给员工编号登记其基本信息,及其所在部门,职位等。

②.客房管理。

对客房的信息进行录入。

⑵客房服务部门对客房的管理,主要职责:①.登记旅客信息,确认其身份,登记其入住、退房时间。

②统计各类房间的客满程度。

1.3各子系统的功能系统划分为三个小部分:管理者子系统、财务子系统、住宿子系统。

①管理者子系统Ⅰ、对新来的员工进行基本信息录入。

{员工号、姓名、性别、年龄、部门号、职务、工资}Ⅱ、对于离职的员工信息进行删除②住宿子系统Ⅰ、来客登记:客人信息{房间号、房间类别、客人名字、证件号码、入住时间、退房时间时间}Ⅱ、房间管理:旅客入住,对用户信息进行登记并对相应房间数量进行修改;退房时,删除所有信息2.用例建模⑴员工信息管理用例描述:员工信息管理包含的用例有添加员工、查询员工信息、修改员工信息以及删除员工信息。

软件工程习题答案

软件工程习题答案

软件⼯程习题答案第1章软件⼯程概述参考答案⼀. 选择题1. B2. A3. B4. B5. D6. B7. D8. A9. D⼆. 填空题1. 设计编码测试2. 软件费⽤可靠性可维护性可重⽤性及⽣产率等3. 计算机软件开发和维护4. 分解抽象和信息隐蔽⼀致性确定性5. 软件的总⽬标待开发软件的需求6. ⼆三7. 计划阶段开发阶段维护阶段8. 软件需求明确9. 制定计划风险分析开发实施⽤户评估三. 名词解释1. 软件的定义如下:在运⾏中能提供所希望的功能和性能的指令集,使程序能正确运⾏的数据结构,描述程序研制过程和⽅法所⽤的⽂档。

2. 软件⼯程是指导计算机软件开发和维护的⼀门学科。

3. 软件危机指的是软件开发和维护过程中遇到的⼀系列严重问题。

4. 就是从提出软件产品开始,直到该软件产品被淘汰的全过程。

5. 瀑布模型⼜称⽣存周期模型,由B.M.Boehm提出,是软件⼯程的基础模型。

其核⼼思想是按⼯序将问题化简,将功能的实现与设计分开,便于分⼯协作。

6. 螺旋模型将瀑布模型与演化模型结合起来,并且加⼊两种模型均忽略了的风险分析,弥补了两者的不⾜。

四. 简答题1. 软件既是知识产品,⼜是与汽车,建筑物⼀样的⼯业产品,此外,软件还具有类似艺术,学术那样的知识性创造和特点,软件的特点如下:软件是⼀种逻辑实体,⽽不是具体的物理实体,因⽽它具有抽象性;软件是通过⼈们的智⼒活动,把知识与技术转化成信息的⼀种产品,是在研制、开发中被创造出来的;在软件的运⾏和使⽤期间,没有硬件那样的机械磨损、⽼化问题;软件的开发和运⾏经常受到计算机系统的限制,对计算机系统有着不同程度的依赖关系;软件的开发尚未完全摆脱⼿⼯的开发⽅式;软件的开发费⽤越来越⾼,成本相当昂贵;软件的开发是⼀个复杂的过程,因⽽管理是软件开发过程中必不可少的內容。

2. 软件危机主要表现如下:产品不符合⽤户的实际需要;软件开发⽣产率提⾼的速度远远不能满⾜客观需要,软件的⽣产率远远低于硬件⽣产率和计算机应⽤的增长速度,使⼈们不能充分利⽤现代计算机硬件提供的巨⼤潜⼒;软件产品的质量差;对软件开发成本和进度的估计常常不准确;软件的可维护性差;软件⽂档资料通常既不完整也不合格;软件的价格昂贵,软件成本在计算机系统总成本中所占的⽐例逐年上升。

软件工程讲义_第二章

软件工程讲义_第二章

演化过程模型评述[NOG00]
首先,原型开发(和其他更加复杂的演化过程) 由于构建产品需要的周期数目不确定,给项目策 划带来了困难。 其次,演化软件过程没有确定演进的最快速度。 如果演进的速度太快,完全没有间歇时间,项目 肯定会陷入混乱;反之,如果演进速度太慢,则 会影响生产率…… 再次,软件过程应该侧重于灵活性和可扩展性, 而不是高质量。为了追求高质量而延长开发时间 势必造成产品推迟交付,从而失去进入市场的良 机。

过程模式

过程模式提供了一种有效的机制来描述各 种软件过程。模式使得软件工程组织能够 从高层抽象开始,开发层次化的过程描述。 高层抽象描述又进一步细化为一系列步骤 模式以描述框架活动,然后每一个步骤模 式又进一步逐层细化为更详细的任务模式。 过程模式一旦建立起来,就可以在过程变 体的定义中复用——即软件开发队伍可以 将模式作为过程模式的构建模块,定制特 定的过程模型。

演化过程模型评述

演化模型的初衷是采用迭代或者增量的方式开 发高质量软件。可是,用演化模型也可以做到强 调灵活性、可扩展性和开发速度。软件开发团队 及其经理所面临的挑战就是在这些严格的项目和 产品参数与客户(软件质量的最终仲裁者)满意 度之间找到一个合理的平衡点。
专用过程模型
专用过程模型具有传统过程模型的一些特 点,但是,专用过程模型往往应用面较窄, 只适用于某些特定的软件工程方法。 在某些情况下,这些专用过程也许更确切 地应该称为技术的集合或方法论,是为了 实现某一特定的软件开发目标而制定的。 但它们确实也提出了一种过程。
模式名称:应能清楚地表述该模式在软件过程中的功能。 驱动力:模式使用环境及主要问题, 以明确主要难点 并可能影响解决方案。 类型:定义模式类型。 启动条件:描述模式应用的前提条件。 问题:描述模式将要解决的问题。 解决办法:描述模式的实现。 结束条件:描述模式成功执行之后的结果。 相关模式:以层次或其他图的方式列举与该模式相关的 其他模式。 已知应用实例:介绍该模式的具体实例。

软件工程需求分析

软件工程需求分析

软件工程需求分析
首先,需求获取是需求分析的基础。

开发团队需要与用户沟通,了解用户的实际需求。

可以通过面对面的会议、问卷调查或者用户需求收集工具等方式进行需求获取。

在这个过程中,开发团队需要主动询问用户的需求,以确保他们完全理解用户的期望。

其次,需求分析需要准确明确的目标。

开发团队需要对需求进行分类和排序,以确定哪些需求是最重要的。

在确定需求优先级时,开发团队可以考虑与用户合作确定,也可以参考相似项目的经验。

接下来,需求分析需要制定合适的文档。

在需求分析的过程中,开发团队需要编写软件需求规格说明书(SRS),以记录各种需求详细信息。

这样的文档需要描述软件的功能需求、性能需求、安全需求以及其他非功能性需求。

编写完整的文档可以确保需求准确传达给开发团队。

此外,需求分析需要广泛的共享和讨论。

开发团队需要与利益相关者进行定期的讨论和交流,以确保需求的理解和沟通。

这样可以在早期的开发阶段发现并解决潜在的问题或错误,降低开发风险。

最后,需求分析需要反馈和验证。

开发团队在开发过程中需要持续地与用户沟通,获取用户的反馈。

这样可以及时调整需求和开发方向,保证软件的质量和用户满意度。

总的来说,软件工程需求分析是软件开发过程中至关重要的一环。

它需要开发团队与用户密切合作,准确获取和理解用户需求。

通过制定合适的文档和定期的讨论,可以确保需求清晰明确并得到广泛共享。

同时,持续的反馈和验证可以及时修正需求和开发方向,提高软件的质量。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
查,在分析、综合中逐步细化软件功能,划分 各个子功能。这里也包括对数据域进行分解, 并分配到各个子功能上,以确定系统的构成及 主要成分,并用图文结合的形式,建立起新系 统的逻辑模型。
需求与需求分析
• 3、编写文档 • (1)编写“需求说明书”,把双方共
同的理解与分析结果用规范的方式描述 出来,作为今后各项工作的基础。
的要求,进行细致的调查分析,将用户 非形式的需求陈述转化为完整的需求定 义,再由需求定义转换到相应的形式功 能规约(需求规格说明)的过程。
需求与需求分析
• 需求分析难点主要体现在以下几个方面: • 1、问题的复杂性 • 2、交流障碍 • 3、不完备性和不一致性 • 4、需求易变性
需求与需求分析
• 二、需求分析的任务 • 需求分析的基本任务是要准确地定义新
帐单
机票 旅客
记帐文件
飞机票预订系统的数据流图
结构化分析
• 加工的命名规则: • 每个加工都要有名字,加工的名字最好
使用动宾词组 • 在分层的数据流图中,加工还应编号,
顶层的加工名就是软件项目的名字
户要求 • 与所有其他系统成分的重要接口是否都已经描

需求与需求分析
• 四、需求分析的原则 • 1、划分(可以把一个复杂问题按功能
进行分解并可逐层细化)
需求与需求分析
• 2、抽象(捕获问题空间的“一般/特殊” 或“特例”关系)
• 3、投影(捕获问题空间的多维“视 图”)
结构化分析
• 一、结构化方法概述 • 1、结构化方法 • 结构化方法是软件工程产生后首先提出
结构化分析
• DFD就是一种描述数据变换的图形工具, 是结构化分析方法最普遍采用的表示手 段,但数据流图并不是结构化分析模型 的全部,数据字典和小说明为数据流图 提供了补充,并用以验证图形表示的正 确性、一致性和完整性,三者共同构成 了结构化分析的模型。
结构化分析
• 1、基本图形符号(数据流图的四个基 本成分)
需求与需求分析
• (2)编写初步用户使用手册,着重反 映被开发软件的用户功能界面和用户使 用的具体要求。
• (3)编写确认测试计划,作为今后确 认和验收的依据。
• (4)修改完善项目开发计划。
需求与需求分析
• 4、需求分析评审 • 系统定义的目标是否与用户的要求一致 • 系统需求分析阶段提供的文档资料是否齐全 • 文档中所有描述是否完整、清晰、准确反映用
最长 • 是面向数据流进行需求分析的方法 • 非常适合于数据处理类型的软件的需求
分析 • 相应的支持工具多,发展较为成熟
结构化分析
• 4、优点: • (1)简单、实用 • (2)适合于瀑布模型,易为开发者掌
握 • (3)成功率较高 • (4)特别适合于数据处理中的应用,
对其他领域的领域也基本适应
结构化分析
方框,表示数据的源点或终点
圆或椭圆,表示加工
结构化分析
• 1、基本图形符号(数据流图的四个基 本成分)
双杠,表示数据存储
箭头,表示数据流
结构化分析
• 加工:是对数据进行处理的单元,它接 受一定的输入数据,对其进行处理,并 产生输出。
• 数据存储:信息的静态存储。
结构化分析
• 数据源或终点:表示系统和环境的接口, 是系统之外的实体,可以是人、物或其 他软件系统。其中,数据源是数据数据 流的起点,终点是数据流的最终目的地。
系统的目标,为了满足用户需要,回答 系统必须“做什么”的问题。
需求与需求分析
• 用户需求分为两大类:功能性需求和非功能性 需求。
• 前者定义了系统做什么,包括系统的所有输入、 输出以及如何从输入映射到输出;后者定义了 系统工作时的特性,例如系统对效率、可靠性、 安全性、可维护性、可移植性、吞吐量以及符 合某种标准等的要求。
指标,如存储容量、运行时间等限制。
需求与需求分析
• (3)环境需求:指软件运行时所需要 的软、硬件(如机型、外设、操作系统 和数据库管理系统等)的要求。
• (4)用户界面需求:即人机交互方式、件的逻辑模型 • 分析人员对获取的需求,进行一致性的分析检
• 5、存在问题 • (1)对于规模较大的项目,特别复杂
的应用不太适应 • (2)难于解决软件重用的问题 • (3)难于适应需求的变化 • (4)难于彻底解决维护问题
结构化分析
• 二、数据流图Data-flow diagram, DFD • 数据流图是SA方法中用于表示系统逻辑模型
的一种工具,它以图形的形式描绘数据在系统 中流动和处理的过程。 • 结构化分析方法把任何软件系统都视作一个数 据变换装置,它接受各种形式的输入,通过变 换产生各种形式的输出。
来的软件开发方法,它也是一种实用的 开发方法,由结构化分析、结构化设计 和结构化程序设计构成。
结构化分析
• 2、基本思想: • 该方法基于模块化的思想,采用“自顶
向下,逐步求精”的技术对系统进行划 分。 • 分解和抽象是它的两个基本手段。
结构化分析
• 3、特点 • 它是使用最早的开发方法,使用时间也
• 数据流:表示数据和数据流向。
结构化分析
• 2、实例:飞机票预订系统 • 问题描述:旅行社凭订票单进行机票的
预订,售票员查询航班目录文件,检查 是否有满足预订条件的机票,如果有, 那么将费用记入记帐文件,并准备机票, 最后将帐单和机票交给旅客。
订票单 旅行社
预订 机票
航班
航班目录
费用 记帐
准备 机票
需求分析的任务就是借助于当前系统的逻辑模型导出 目标系统的逻辑模型,解决目标系统是“做什么”的问题。
需求与需求分析
• 三、需求分析的步骤 • 1、问题识别 • 双方确定对问题的综合需求。这些需求包括: • (1)功能需求:指所开发的软件必须具备什
么样的功能,这是最重要的。 • (2)性能需求:指待开发的软件的技术性能
软件工程
第2章 软件项目的需求分析
第2章 软件项目的需求分析
• 本章要点 • 1、了解软件需求分析的原则和任务 • 2、了解软件需求的获得方法 • 3、掌握结构化分析方法及其描述工具 • 4、了解需求规格说明和需求评审的主
要内容
需求与需求分析
• 一、需求分析的特点 • 需求分析是指开发人员要准确理解用户
相关文档
最新文档