软件工程要点串讲

需求工程
S ystem requirements
elicitation
S ystemrequir ements specification and modeling
User requirements specification
Business req uirements specification
3.4 功能需求与非功能需求
功能性需求与非功能性需求相比较，非功能需求往 往更为关键，因为非功能需求表示的是系统的整体 特征，而功能性需求描述的则是局部功能。
（参看课本例子加强理解）
3.5 使用自然语言描述需求的准则
设计一个标准格式， 以帮助减少遗漏，避免不必 要的细节描述；
使用一致的语言，尤其强调区别强制性需求与希
软件工程要点串讲
第一讲 概 述
1.1 软件工程与软件危机
§ 软件危机指的是软件的发展过程中出现的一系列严 重的问题，如开发效率低下、成本高、可维护性差 。
§ 软件工程被认为是能够解决软件开发严重问题的有 效途径。
1.2 什么是软件?
软件=计算机程序+相关的文档 专业化开发的软件包括：
① 能够提供客户所需功能与性能的计算机程序； ② 用于设置程序的配置文件、用于描述程序结 构及开发过程的系统文档及解释如何使用系统的用 户文档。
望性需求。如使用“必须 ”定义强制性需求，使 用“应该 ”定义希望性需求； 使用文本加亮来突出关键性需求；
尽量避免使用计算机专用术语； 尽可能把需求原理（需求产生的原因）和对应需
求联系在一起。
3.7 需求导出与分析
这个阶段在可行性研究之后进行，通常与需求描述 交叉进行。
需求导出的过程活动包括：需求发现、需求的分类 与组织、优先排序和冲突解决、需求文档化。
软构件是标准的、可以互换的、经过装配可随时使 用的软件模块。
软件复用的意义
软件复用的出发点是使软件系统的开发不再“一切 从零开始”，能够充分利用已有的知识和经验。
软件复用能够在软件开发中避免重复劳动，充分利 用已有的开发成果，，提高开发效率，降低开发成 本。
软件复用还可以避免全新开发可能引入的错误，从 而提高软件的开发质量。
3.7 需求导出与分析
需求的发现与识别是整个过程中最为关键的活动，
负责收集目标系统级现存系统的相关信息并从这些 信息中提炼出用户需求和系统需求。
信息的来源包括已有的文件，系统的信息持有者 （stakeholders）以及相近系统的规约描述。
3.7 需求导出与分析
需求要从多个视点进行分析 视点用来表述不同角度的需求来源（信息持
在分析的基础上精化用例图
用活动图验证用例 SRS
用CRC分析法确定关键抽象 表述域模型中关键抽象之间的
关系 使用从用例场景中得到的对象图
来验证域模型
Use Case form
C RC
要求掌握：
1） 用例图的画法； 2） 用例表（用例规约描述）的基本结构及描述方
法； 3） 活动图的画法 4） 用CRC确定关键抽象的过程； 5） 用类模型表示关键抽象。
1.2 什么是软件?
软件产品可以为一个特定的用户设计开发，也可以 为某一类通用的市场设计开发。
软件产品可以分成： 通用软件（Generic Software）
模糊
定制软件（Bespoke Software） 一个新的软件并不一定是全新开发，可以由现有软
件或可复用软件成分配置形成。
1.3 什么是软件工程 ？
主流技术不兼容.
适用情况
适合中小规模的交互系统; 可用于大型系统的局部开发（如系统界面），可以和瀑
布模型混合使用； 生命周期较短的系统。
2.3 增量式开发
定义框架需求 增量有效性验证
为增量分配需求
设计系统体系结构
开发系统增量
增量集成
系统有效性验证
部署增量
系统未完成 最终系统
增量式开发的特点
计算机。
第二讲 软件过程
2.1 瀑布模型（顺序模型）
2.1 瀑布模型（顺序模型）
A.k.a.: Classic Life Cycle
瀑布模型的特点和适用情况
瀑布模型起源于更一般的系统工程过程，反映了工程 设计的基本思想。
这种模型生硬的把一个软件过程划分成几个界限清晰 的阶段，而且这些阶段前后有严格的顺序，这导致它 很难对用户的需求变更做出及时的调整；
软件工程是涉及软件生产各个方面的一门工程学科 软件工程涉及软件生命周期的各个方面，从软件需
求的确定到软件退役。
1.3 什么是软件工程 ？
软件工程：（1）将系统化的、规范的、可度量的 方法应用于软件的开发、运行和维护的过程，即将 工程化应用于软件；（2）研究（1）中的方法. ——IEEE[IEE93]
P61 图4-12
3.2 可行性研究
可行性研究要决定被提议的系统是否值得去做。
进行可行性研究包括信息评估、信息汇总和书写报 告三部分工作。
3.3 需求的两个不同层次的描述
用户需求
从客户的角度，采用自然语言配合以图表对目标系统应 提供的服务以及系统操作要受到的约束进行的声明。
系统需求
系统需求是一种结构化文档，要运用一些专业的模型详 细的描述系统的功能及其约束。系统需求文档有时也称 为功能描述，应该是精确的，它可以成为双方之间合同 的重要内容，同时作为开发工作的依据。
可维护性（Maintainability）
Software must evolve to meet changing needs;
可依赖性（Dependability）
Software must be trustworthy;
有效性（Efficiency）
Software should not make wasteful use of system resources;
在这种开发方式中，系统不是作为一个整体交付， 而是被分解成若干个增量，每个增量交付系统的部 分功能。
用户的需求按优先级排队，优先级最高的需求被放 入最早交付的增量中。这样，优先级最高的系统功 能就得到最多的测试，系统的可靠性较高。
2.4 基于构件的软件工程
软件复用是指在两次或多次不同的软件开发过程中 重复使用相同或相似软件元素（通常称为可复用构 件、组件或软部件）的过程。
因此，ERD用于数据建模，DFD用于功能建模，STD 用于行为建模。
3.9 UML与面向对象分析方法
3.9.1 理解UML
UML是一种标准的图形化建模语言，它为不同领域的人 们提供一种统一的交流标准，这种标准使得系统构造者 能够用标准的、易于理解的方式建立能表达出他们想象 力的系统蓝图，并使客户、分析员、设计人员、程序员 和系统其它涉及者能够相互理解和达成一致，从而能够 有效地共享和交流设计结果。
3.9.3 需求导出工作流程
业务所属者脑海中的 模型
项目干系人脑海中的 模型
访谈业务所属人获取高层的功能 性需求
访谈项目干系人获得所有的功能 性和非功能性需求
通过SRS文档确定项目约束和风险
愿景文档 SRS
通过SRS文档中的功能性需求创建 项目词典
通过SRS文档创建初始用例图
需求精化工作流程
分析用例场景发现更多细节
3.4 功能需求与非功能需求
功能需求
对系统应提供的功能，系统在特定的输入下做出的反应 及特定条件下的行为的描述。某些情况下还要包括系统 不应做什么。
非功能需求
对系统提供服务或功能时收到的约束进行描述。如时间 约束、开发过程约束和标准等。
领域需求
这种需求来自于系统的应用领域，反映领域特征。可能 是功能需求也可能是非功能需求。
有者、其它相关系统及领域）。每一个视点 代表系统需求的一个子集。
3.8 结构化分析（SA）建模
结构化分析方法是一种面向数据流的系统建模技术， 它从数据加工的角度对系统进行规格描述；
SA帮助分析者理解系统的功能，并采用模型与用 户进行交流；
不同的模型从不同的角度对系统进行描述。
结构化分析建模
基于构件的软件工程
需求描述
构件分析
需求修订
系统验证
VS
基于复用的系统设计 开发与集成
第三讲 需求工程
3.1 需求工程过程
需求工程过程并不具有唯一的模型，在所有 的过程中都会涉及一些共同的活动，它们是：
可行性研究； 需求导出与分析； 需求描述； 需求有效性验证; 需求管理。
需求工程过程
需求检查
对需求文档中定义的需求要进行多种检查， 这些检查包括：
有效性， Does the system provide the functions which best support the customer’s needs?
一致性， Are there any requirements conflicts? 完备性， Are all functions required by the customer
3.10 需求有效性验证
需求有效性验证的目的是检验需求描述是否正确地反 映了客户的意愿。
好的需求对软件系统的开发效率及软件质量起着至关 重要的作用。一个错误发现的越晚，修改它所付出的 代价就越大。
Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.
需要； 4. 进化（ Evolution ）- 按照用户的变更要求不断的改进软件。
软件生命周期是软件过程的另一种形象描述，通常包括需 求定义、分析与描述、软件设计、实现、测试、维护与退 役等活动。
1.6什么是优良软件的属性？
优良的软件应能交付相应的功能与性能，而且应具有良好 的可维护性、可依赖性、有效性和可用性：