- 1. 邸书灵
信息科学与技术学院
2013-3-15软件工程概论 Introduction to Software Engineering
- 2. 知识回顾软件项目管理
3.4 软件项目规划
3.5 软件风险管理
3.6 软件配置管理
软件成本估算技术：
1专家判断
2类比估算
3COCOMO模型风险识别（7大类）。风险级别、风险评估、风险规划、风险监控配置项标识、版本控制、系统构建、变更控制，配置工具软件规模常用估算方法包括代码行技术、功能点技术2
- 3. 第一章 概述
1.1 软件
1.2 软件工程
1.3 软件工程知识体系
1.4 软件工程职业道德规范第二章 软件过程
2.1 软件过程的概念
2.2 软件过程模型
2.3 案例：MS的软件开发过程第三章 软件项目管理
3.1 软件项目管理概述
3.2 人员组织与管理
3.3 项目沟通管理
3.4 软件项目规划
3.5 软件风险管理
3.6 软件配置管理3
- 4. 第四章 需求工程4.1 软件需求
4.2 需求工程过程
4.3 需求获取技术
4.4 案例：小型图书资料管理系统4
- 5. 软件需求的重要性软件需求是决定软件开发是否成功的一个关键因素
需求分析可以帮助开发人员真正理解业务问题
需求分析是估算成本和进度的基础
需求分析可以避免构建错误的系统，从而减少不必要的浪费
软件规格说明有助于开发人员与客户在“What to do”问题上达成正式契约
需求分析形成了软件开发的基线，有助于管理软件的演化和变更
软件需求是软件质量的基础，为系统测试验收提供标准5
- 6. 第四章 需求工程4.1 软件需求
4.1.1 业务需求
4.1.2 用户需求
4.1.3 功能需求和非功能需求
4.1.4 系统需求6
- 7. 4.1 软件需求(Software Requirements)人们对软件需求有各自的描述。
客户所说的需求在开发人员看来是一个较高层次的产品概念。
开发人员所说的需求在用户看来又好像是详细设计。
人们从不同的角度和不同的程度反映各自的要求，形成了不同层次的需求。7
- 8. 4.1 软件需求IEEE给出的软件需求定义：
用户解决问题或达到目标所需的条件或能力。
系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
一种反映上面 ① 或 ② 所描述的条件或能力的文档说明。
对定义的理解
软件需求的概念涵盖了用户角度（系统的外部行为）和开发人员角度（系统的内部特性）两个方面，其中的关键在于需求一定要文档化。8
- 9. 4.1 软件需求不同角度的需求
业务需求：定义了软件的远景和范围。
用户需求：反映了用户使用该系统需
要完成的任务。
功能需求：系统需要具备的功能。
非功能需求：系统应该具备的性能。
系统需求：面向开发人员、详细描述系统应该做什么。
软件的功能需求必须根据用户需求来考虑，而且应该与业务需求定义的目标相一致。9
- 10. 4.1.1 业务需求业务需求
定义了项目的远景和范围，即确定软件产品的功能范围、发展方向、目标客户和价值来源
业务需求的内容
业务：产品属于哪类业务范畴？应该完成什么功能？需要为什么服务？
客户：产品为谁服务？目标客户是谁？
特性：产品区别于其他竞争产品的特性是什么？
价值：产品的价值体现在什么方面？
优先级：产品功能特性的优先级次序是什么？10
- 11. 案例：小型图书资料管理系统问题描述
某学院打算开发一个小型图书资料管理系统 MiniLibrary，该系统基于 Internet 实现教师和学生对各种图书资料的借阅、查询和管理。
图书管理员负责管理各种图书资料，查询图书资料信息，并进行图书的借阅管理。
注册用户可以通过 Internet 随时查询图书资料信息和个人借阅情况，预订目前借不到的图书资料，并可以快捷地查找和浏览所需要的电子资料。
系统可以提供适当的浏览器供用户阅读电子文献资料。
要求用户界面友好，响应速度快，具有良好的可扩展性 。11
- 12. 案例：小型图书资料管理系统业务要求
各种图书资料的借阅、查询和管理；
使用计算机实现图书资料的日常管理，提高工作效率和服务质量；
用户通过网络查询和浏览电子资料，改变原有的借阅模式；
由于版权的限制，某些电子资料只能让用户浏览和打印而不能下载。12
- 13. P73~74。文档：项目远景和范围13
- 14. 用户需求
从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特性。
用户需求的描述
原则：应该易于用户的理解。一般不采用技术性很强的语言，而是采用自然语言和直观图形相结合的方式进行描述。
问题：自然语言表达容易含糊和不准确。4.1.2 用户需求14
- 15. 用户可以通过 Internet 随时查询图书信息和个人借阅情况，并可以快捷地查找和浏览所需要的电子资料。
分析：上述需求描述包含了三个不同的需求
用户可以通过 Internet 随时查询图书信息。
用户可以通过 Internet 随时查询个人借阅情况。
用户可以通过 Internet 快捷地查找和浏览所需要的电子资料。
问题
“随时”和“快捷”是对系统功能的约束，十分模糊。案例：小型图书资料管理系统15
- 16. 功能需求描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。
举例：MiniLibrary
用户可以从图书资料库中查询或者选择其中的一个子集。
系统可以提供适当的浏览器供用户阅读电子文献。
用户每次借阅图书应该对应一个唯一的标识号，它被记录到用户的帐户上。4.1.3 功能需求和非功能需求16
- 17. 非功能需求从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，例如响应时间、数据精度、可靠性、开发过程的标准等。
举例：MiniLibrary
系统应在 20 秒之内响应所有的请求。
系统每周 7 天、每天 24 小时都可以使用。
对于一个没有经验的用户而言，经过两个小时的培训就可以使用系统的所有功能。
4.1.3 功能需求和非功能需求17
- 18. 4.1.3 功能需求和非功能需求非功能需求的类型18
- 19. 4.1.3 功能需求和非功能需求非功能需求的度量19
- 20. 系统需求是更加详细地描述系统应该做什么。主要面向开发人员，是开发人员进行软件的基础。
系统需求模型的描述有3种方法
结构化英语PDL：介于自然语言和形式语言之间的半形式语言，它试图把自然语言的非形式化性与程序设计语言的严格语法和控制结构结合起来。
可视化模型：使用图形化符号辅之以文本释义定义系统模型。如数据流图、UML语言、实体联系图等。
形式化方法：基于状态机或集合等数学概念描述系统模型。如Z语言。4.1.4 系统需求20
- 21. 第四章 需求工程4.2 需求工程过程
4.2.1 需求获取
4.2.2 需求分析
4.2.3 需求规格说明
4.2.4 需求验证
4.2.5 需求管理21
- 22. 4.2 需求工程过程需求工程是应用已证实有效的原理和方法，并通过合 适的工具和符号，系统地描述出待开发系统及其行为 特征和相关约束。
需求获取：开发人员聆听客户的需求，观察用户的行为；
需求分析：分析和整理所收集的用户需求；
需求规格说明：以文档形式，精确地阐述一个软件系统 必须提供的功能和性能以及它所要考虑的限制条件；
需求验证：使用评审和商议等有效手段对其进行验证， 最终形成一个需求基线；
需求管理：在开发过程中有效地管理和控制需求变更。22
- 23. 4.2.1 需求获取需求获取是在问题及最终解决方案之间架设桥梁的第一步。
需求获取应该集中在用户任务上。
聆听用户的需要：和各个层次的用户充分交流
分析和整理所获取的信息：确定软件的功能、性能、接口、约束等
形成文档化的描述：描述需要各种人员的理解和 认同23
- 24. 4.2.2 需求分析需求分析(Requirement Analysis)是对收集到的需求进行提炼、分析和认真审查，以确保所有的项目相关人员都明白其含义，并找出其中的错误、遗漏或其它不足的地方，形成完整的分析模型。
需求分析的目的在于开发出高质量的和详细的需求，从而支持项目估算、软件设计、软件开发和软件测试。24
- 25. 4.2.2 需求分析需求分析的主要工作
定义系统边界：系统与外部实体的界限
建立软件原型：找出需求文档与原型间差异
分析需求可行性：在成本允许和性能要求下确定与系统实现相联系的风险
确定需求优先级：以保证在规定时间和预算下达到最好效果
建立需求分析模型：核心工作。类图、状态图、交互图等
创建数据字典：定义系统所有数据及结构25
- 26. 需求规格说明(SRS, Software Requirement Specification)
是需求开发的结果。精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。
作用：
成为用户、分析人员和设计人员之间进行理解和交流的手段
支持系统测试活动
用于规划和控制系统的开发过程
4.2.3 需求规格说明26
- 27. SRS应包含的主要内容
功能：软件应该提供什么功能？
外部接口：软件如何与人、系统硬件和其他系统等进行相互作用？
性能：软件系统在运行速度、可用性、响应时间、恢复时间等方面有什么要求？
特性：软件系统在可移植性、可维护性、安全性等方面有什么考虑?
设计约束：是否存在必要的标准、开发语言、数据库、资源限制、运行环境等因素的影响和策略4.2.3 需求规格说明27
- 28. 不应该包括在 SRS 中的内容
项目开发计划
产品保证计划
软件设计细节
4.2.3 需求规格说明28
- 29. 编写需求规格说明的原则
原则 1：只描述“做什么”而无须描述“怎么做”
原则 2：必须说明运行环境
原则 3：考虑用户、分析员和实现者的交流
对形式化和自然语言之间作出恰当的选择
明确的理解最重要，不存在十全十美的软件规格说明书
原则 4：力求寻找到恰如其分的需求详细程度
一个有益的原则就是编写单个的可测试需求文档4.2.3 需求规格说明29
- 30. 编写需求规格说明的原则
原则 5：文档段落不宜太长
原则 6：避免使用模糊的、主观的术语
如用户友好、容易、简单、迅速、有效、许多、最新技术
建议：采用一种标准的 SRS 模板
4.2.3 需求规格说明30
- 31. P78~81。SRS （IEEE 830－1998 ）31
- 32. 需求验证
为确保需求正确、完整地表达必要的质量特点。
通过评审的方式发现规格说明中的错误或缺陷。
修改后再评审。
一般采用由不同代表（分析人员、客户、设计人员、测试人员）组成的评审组会议。
针对总体目标、主要功能和性能、测试指标。
质量特性
正确性、无二义性、完整性、可验证性、一致性、可修改性和可跟踪性等。4.2.4 需求验证32
- 33. 1正确性(correctness)
需求规格说明对系统功能、行为、性能等的描述 须与用户的期望相吻合，代表了用户的真正需求。
审查需求的正确性应该考虑的问题
用户参与需求过程的程度如何？
每一个需求描述是否准确地反映了用户的需要？
系统用户是否已经认真考虑了每一项描述？
需求可以追溯到来源吗？
举例：下面的需求描述正确吗？
在用户每次存钱的时候系统将进行信用检查。4.2.4 需求验证33
- 34. 2无二义性(unambiguous )
需求规格说明中的描述对于所有人都只能有一种 明确统一的解释。
审查需求的无二义性应该考虑的问题
需求规格说明是否有术语词汇表？
具有多重含义或未知含义的术语是否已经定义？
需求描述是否可量化和可验证？
每一项需求都有测试准则吗？
举例：下面的需求描述是无歧义的吗？
如果用户试图透支，系统将采取适当的行动。4.2.4 需求验证34
- 35. 3完整性(completeness )
需求规格说明应该包括软件要完成的全部任务，不能遗漏任何必要的需求信息。
审查需求的完整性应该考虑的问题
是否存在遗漏的功能或业务过程？
每个定义的功能之间是否有接口？
是否定义了功能的使用者？
是否已经清楚定义了用户与功能之间的交互？
是否定义了与外部过程或系统的接口？
所描述的内容是否可映射到业务过程中？
文档中是否存在待确定的功能引用？
文档中是否存在未定义的术语和引用？
文档的各个部分是否都完整？
需求是否包括非功能属性的描述？4.2.4 需求验证35
- 36. 4 可验证性(verifiability )
需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认。
审查需求的可验证性应该考虑的问题
在需求文档中是否存在不可验证的陈述，诸如“用户界面友好”、“容易”、“简单”、“快速”、“健壮”、“最新技术”等？
所有描述都是具体的和可测量的吗？
举例：下面的两个需求描述中哪一个难以验证？
系统将在 20 秒内响应所有有效的请求。
如果用户试图透支，系统将采取适当的行动。4.2.4 需求验证36
- 37. 5一致性(consistency )
需求规格说明对各种需求的描述不能存在矛盾， 如术语使用冲突、功能和行为特性方面的矛盾 以及时序上的不一致等。
审查需求的一致性应该考虑的问题
文档的组织形式是否易于一致？
不同功能的描述之间是否存在矛盾？
是否存在有矛盾的需求描述和术语？
文档中是否存在时序上得不一致？
举例：下面的两个需求描述是否有矛盾？
系统允许立即使用所存的资金。
只有在手工验证所存资金后，系统才能允许使用。4.2.4 需求验证37
- 38. 6可修改性(modifiability )
需求规格说明的格式和组织方式应保证后续的修改能够比较容易和协调一致。
审查需求的可修改性应该考虑的问题
是否存在明显的需求交叉引用？
是否有内容列表和索引？
是否存在冗余需求，如存在，它们是交叉引用吗？4.2.4 需求验证38
- 39. 7可跟踪性(trackability )
每一项需求都能与其对应的来源、设计、源代码和测试用例联系起来。
可跟踪性的两种形式
每一项需求都可以在早期的文档中追溯到其来源，例如备忘录、法规、会议记录等。
每一项需求都有唯一的名称或索引号，与后期实现对应。
举例：下面的需求描述记录了早期的文档来源。
系统将在 20 秒内响应所有有效的请求。
［来自与用户的面谈，备忘录编号 #1234］4.2.4 需求验证39
- 40. 软件需求的最大问题在于难以清楚确定以及不断发生变化。因此必须有效管理需求。
需求管理是分析变更影响并控制变更的过程，主要包括变更控制、版本控制和需求跟踪等活动。
4.2.5 需求管理40
- 41. 1需求变更控制：是在一定的程序下有效地实施整个变更过程。包括以下几部分：
仔细评估已建议的变更；
挑选合适的人选对变更做出决定；
变更应及时通知所有涉及的人员；
项目要按一定的程序实施变更。4.2.5 需求管理41
- 42. 2需求文档的版本控制
是管理需求的一个必要方面。
每个版本都必须统一确定，及时提示涉及人员。
每个需求文档都应包括一个修改版本的历史情况。
在需求变更后，附加一些评语描述变更原因对后 续工作非常有用。
4.2.5 需求管理42
- 43. 3需求跟踪：帮助全面地分析变更带来的影响，以便做出正确的变更决策。
需求跟踪包括编制每个需求同系统元素之间的联系文档，从而建立了需求的跟踪链。
当需求发生变化时，使用需求跟踪可以确保不忽略每个受到影响的系统元素，需求变更的正确实施可以降低由此带给项目的风险。4.2.5 需求管理43
- 44. 4需求管理工具：手工进行需求管理很困难，因此需要合适的需求管理工具。
P86。4.2.5 需求管理44
- 45. 4.3 需求获取技术需求获取的关键在于通过与用户的沟通和交流，收集和理解用户的各项要求。
有哪些需求获取技术?
用户面谈
需求专题讨论会
现场考察
原型化方法
基于用例的方法45
- 46. 第四章 需求工程4.3 需求获取技术
4.3.1 面谈
4.3.2 需求专题讨论会
4.3.3 观察用户工作流程
4.3.4 原型化方法
4.3.5 基于用例的方法46
- 47. 4.3.1 面谈一种重要而直接的方法。基本要点：
事先列出要询问的问题，并记录下来
面谈时，不要选择自己能够回答的问题
面谈中，应该参考事先准备的面谈模版，以保证提出问题的正确性和必要性，并记录答案
面谈后，分析总结面谈记录，找到主要的用户需求。47
- 48. 4.3.1 面谈P87~89：面谈过程示例。48
- 49. 4.3.2 需求专题讨论会一种最有力的技术。与会者可以再应用需求上达成共识、对操作过程尽快取得统一意见。
过程
准备：宣传动员，确定参加，后勤保障，分发资料
安排日程：会议议程
开会：掌控气氛，营造气氛，记录意见49
- 50. 4.3.2 需求专题讨论会优点
协助建立一支高效的团队
所有的风险承担人都畅所欲言
促进风险承担人和开发团队之间达成共识
能够揭露和解决那些妨碍系统成功的行政问题
能够很快产生初步的系统定义50
- 51. 4.3.3 观察用户工作流程有时客户无法有效表达自己的需求，面谈和会议也不能解决问题，这种情况下，观察用户工作流程是一种较好的方法。
两种方式
被动观察：在用户不受干扰和影响的情况下，摄录用户工作过程
主动观察：开发人员直接参与用户工作
需要较长一段时间，观察可能使用户紧张。51
- 52. 4.3.4 原型化方法通过使系统或者其中一部分可视化以获得客户的反馈，从而有效解决早起需求不明确的问题。
此后的两种工作方式
抛弃式：原型评价后被抛弃不用。
演化式：原型评价后继续使用，演化为系统的一部分。52
- 53. 4.3.5 基于用例的方法特点
以任务和用户为中心，
有助于客户了解系统功能
有助于开发人员理解用户需求
可以采用面向对象分析和设计方法将用例转化为设计模型。
通过用例模型，明确系统功能
确定参与者：与系统交互的人或事
确定用例：用例图
描述用例：进一步文字描述53
- 54. 小 结需求工程
4.1 软件需求
4.2 需求工程过程
4.3 需求获取技术
4.4 案例：小型图书资料管理系统业务需求、用户需求、系统需求、功能需求与非功能需求。基本活动：需求获取、 需求分析、需求规格说明需求验证、需求管理。 面谈、专题会、观察、原型化方法、基于用例方法54
- 55. 作业p96：4.1、4.2、4.3
复习：面向对象基础（第六章）
