用实例说明需求工程的设计原则和描述方法ppt
合集下载
需求管理流程ppt课件
“软件需求可定义为： 用户解决某一问题或达到某 一目标所需的软件功能。系统或系统构件为了满足合同、 规约、标准或其他正式实行的文档而必须满足或具备的 软件功能。”
2
为 什 么 要 进 行 需 求 管 理?
评测和验证有效的软件开发流程标准得到了推广 和普及 为什么现在仍然频繁发生的软件项目失败的事件？ 为什么仍有那么多的项目受到延期、预算超支和 质量问题的困扰？ 如何才能提高系统的质量？
不接受
接受
小问题 自行解决
变更影响分析报告
修改SRS
修改开发计划
修改其它相关文档
17
需
• 一、职能：
求 管
• 评审——需求分析及讨论 • 跟踪——需求修改进度 • 监督——需求整改质量保证
理
委
• 二、会议制度：
员
• 每周定期召开需求管理会议
会
18
• 产品研发步骤：
• 一、产品需求文档：
职
• 二、讨论（发散思维），排列出优先等级
提供一种机制，以分析需求、评估可行性、协商
是 合理的解决方案、无歧义地规约解决方案、确认规约
需 以及在开发过程中管理这些被确认的需求规约。包括6
求 个步骤：
管
获取（需求诱导）
理？ 分析（需求分析和谈判）
规定（规约）
系统建模
验证（需求确认）
需求管理（控制与变更管理）
5
需
1. 需求不总是显而易见的，它可来自各个方面。
管
• 变更过程管理：确定一个选择、分析和决策需求变更的
理
过程
的
• 需求跟踪：定义需求之间的关系及需求和设计之间的关
规
系，记录并维护这些关系
2
为 什 么 要 进 行 需 求 管 理?
评测和验证有效的软件开发流程标准得到了推广 和普及 为什么现在仍然频繁发生的软件项目失败的事件？ 为什么仍有那么多的项目受到延期、预算超支和 质量问题的困扰？ 如何才能提高系统的质量？
不接受
接受
小问题 自行解决
变更影响分析报告
修改SRS
修改开发计划
修改其它相关文档
17
需
• 一、职能：
求 管
• 评审——需求分析及讨论 • 跟踪——需求修改进度 • 监督——需求整改质量保证
理
委
• 二、会议制度：
员
• 每周定期召开需求管理会议
会
18
• 产品研发步骤：
• 一、产品需求文档：
职
• 二、讨论（发散思维），排列出优先等级
提供一种机制，以分析需求、评估可行性、协商
是 合理的解决方案、无歧义地规约解决方案、确认规约
需 以及在开发过程中管理这些被确认的需求规约。包括6
求 个步骤：
管
获取（需求诱导）
理？ 分析（需求分析和谈判）
规定（规约）
系统建模
验证（需求确认）
需求管理（控制与变更管理）
5
需
1. 需求不总是显而易见的，它可来自各个方面。
管
• 变更过程管理：确定一个选择、分析和决策需求变更的
理
过程
的
• 需求跟踪：定义需求之间的关系及需求和设计之间的关
规
系，记录并维护这些关系
软件工程PPT4
MiniLibrary：参与者
确定场景
确定参与者和场景的关键在于理解业务领域，这需 要理解用户的工作过程和系统的范围。 确定场景的问题
–参与者希望系统执行的任务是什么？ –参与者访问什么信息？谁生成数据？ –参与者需要通知系统的哪些外部变化？（时间和频率） –系统需要通知参与者什么事件？（时间）
MiniLibrary：借书
场景名称：借书 参与者实例：Bob，图书管理员；John，普通读者 事件流程：
1.John向Bob提供个人的注册号、所借图书的编号和书名等； 2.Bob在系统中查询该图书是否在图书馆； 3.Bob登记John的借书记录，并将图书借给John。
其他流程：
1.图书已被借出或者不存在： Bob告诉John无法借出。 2.John不是合法注册用户： Bob 请求John注册后在借书。
功能需求
功能需求
–描述系统应该提供的功能或服务，通常涉及用户或外部系 统与该系统之间的交互，一般不考虑系统的实现细节。
举例：MiniLibrary
–用户可以从图书资料库中查询或者选择其中的一个子集。 –系统可以提供适当的浏览器供用户阅读电子文献。 –用户每次借阅图书应该对应一个唯一的标识号，它被记 录到用户的帐户上。
内容提纲
软件需求
软件需求
①用户解决问题或达到目标所需的条件或能力。 ②系统或系统部件要满足合同、标准、规范或其它正式规定文 档所需具有的条件或能力。 ③一种反映上面①或②所描述的条件或能力的文档说明。
对定义的理解
–软件需求的概念涵盖了用户角度（系统的外部行为）和开 发人员角度（系统的内部特性）两个方面，其中的关键在于 需求一定要文档化。
05_需求管理的原则与实现
需求管理的主要活动
为达到软件过程能力成熟度模型的第二级，组织必 须具有在软件开发与管理的六个关键过程域（ key process areas，K PA）以展示达到目标的能力。需 求管理是其中之一，它的目标如下：
1) 把软件需求建立一个基线供软件工程和管理使用。 2) 软件计划，产品和活动同软件需求保持一致。
需求约定是需求开发和需求管理之间的桥梁， 需求管理包括在工程进展过程中维持需求约 定集成性和精确性的所有活动，需求管理强 调：
y 控制对需求基线的变动。 y 保持项目计划与需求一致。 y 控制单个需求和需求文档的版本情况。 y 管理需求和联系链之间的联系或管理单个需求和
其它项目可交付品之间的依赖关系。 y 跟踪基线中需求的状态。
需求约定是需求开发和需求管理之间的桥梁需求管理包括在工程进展过程中维持需求约需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动需求管理强调
议题
需求管理和过程能力成熟度模型 需求管理步骤 需求管 步骤 需求规格说明的版本控制 需求属性 度量需求管理的效果
将需求工程分为需求开发和需求管理。需求开发包 括对 个软件项目需求的获取、分析、规格说明及 括对一个软件项目需求的获取、分析、规格说明及 验证。典型需求开发的结果应该有项目视图和范围 文档、使用实例文档、软件需求规格说明及相关分 析模型。经评审批准，这些文档就定义了开发工作 的需求基线（ b a s e l i n e）。这个基线在客户和 开发人员之间就构筑了计划产品功能需求和非功能 需求的一个约定（ a g r e e m e n t）。工程项目可 能会有其它的约定，例如可交付性、约束条件、进 度安排、预算及合同约定等。但这些均超出了本书 范围。
通用技术 必修1 第3章-设计的一般过程、原则、评价
2、明确问题
1）值不值； 2）能不能；
3.1设计的一般过程
【案例分析】 • 陈晨发现了什么问题？
户
• 产生了什么需求？
外
活
动
无
处
坐
3.1设计的一般过程 分析案例中的陈晨等同学在设计的发现与明确阶段进 行了哪些具体工作？
主要环节
具体工作内容
调查需求
就小凳的一般需求进行调查
统计分析
统计分析，绘制图表
双缸半自动 洗衣机
增加了甩 干功能
双缸半自动 洗衣机 VS
全自动滚筒 洗衣机
洗涤、甩干 于一缸，增 加烘干功能
3.2设计的一般原则
在设计的过程中如何来 实现创新呢？
3.2设计的一般原则
下面的两个键盘是否存在创新？
3.2设计的一般原则
这件名为“T3”的咖 啡桌由Luca Casini设 计，SPHAUS制造，参 加了2004年9月在意大 利维罗纳举办的家具 展览。桌面为彩色的 玻璃，支架部分由一 整根钢管制成，外观 简单，深具现代感。
一个是衣挂， 另一个还是衣挂!
3.2设计的一般原则
虽有乎千金之玉卮，至贵而无当，漏 不可盛水，则人孰注浆哉？ ——韩非子
这句话说明了什么问题？
2、实用原则
实用性是指设计的产品为实现其目的而 具有的基本功能。
3.2设计的一般原则
产品实用性的内涵是很丰富的，包括： 物理功能：性能、构造、效率、精度、可靠性。 生理功能：方便性、安全性、宜人性。 心理功能：造型、色彩、机理、装饰。 社会功能：产品象征、显示个人的价值、兴趣、爱好和社会 地位。
3.方案构思（头脑风暴活动）
根据设计要求，大胆构思， 挖掘创造潜力，提出多个设想。
1）值不值； 2）能不能；
3.1设计的一般过程
【案例分析】 • 陈晨发现了什么问题？
户
• 产生了什么需求？
外
活
动
无
处
坐
3.1设计的一般过程 分析案例中的陈晨等同学在设计的发现与明确阶段进 行了哪些具体工作？
主要环节
具体工作内容
调查需求
就小凳的一般需求进行调查
统计分析
统计分析，绘制图表
双缸半自动 洗衣机
增加了甩 干功能
双缸半自动 洗衣机 VS
全自动滚筒 洗衣机
洗涤、甩干 于一缸，增 加烘干功能
3.2设计的一般原则
在设计的过程中如何来 实现创新呢？
3.2设计的一般原则
下面的两个键盘是否存在创新？
3.2设计的一般原则
这件名为“T3”的咖 啡桌由Luca Casini设 计，SPHAUS制造，参 加了2004年9月在意大 利维罗纳举办的家具 展览。桌面为彩色的 玻璃，支架部分由一 整根钢管制成，外观 简单，深具现代感。
一个是衣挂， 另一个还是衣挂!
3.2设计的一般原则
虽有乎千金之玉卮，至贵而无当，漏 不可盛水，则人孰注浆哉？ ——韩非子
这句话说明了什么问题？
2、实用原则
实用性是指设计的产品为实现其目的而 具有的基本功能。
3.2设计的一般原则
产品实用性的内涵是很丰富的，包括： 物理功能：性能、构造、效率、精度、可靠性。 生理功能：方便性、安全性、宜人性。 心理功能：造型、色彩、机理、装饰。 社会功能：产品象征、显示个人的价值、兴趣、爱好和社会 地位。
3.方案构思（头脑风暴活动）
根据设计要求，大胆构思， 挖掘创造潜力，提出多个设想。
系统工程与需求工程方法详解演示文稿
➢ 将问题分解为层次结构的系统和子系统，每个系统和子系统是
可以理解、建模和管理的，识别每个系统的输入和输出，以便
能理解、定义和建模它们与其所处环境之间的交互方式；
➢ 因为没有一个系统是完全正确的，能反应一个不断变化世界的发
杂性，所以要准备好试验不同的系统模型直到找到一个最合适的。
第18页，共38页。
➢ 一个系统保留太长时间是有害的。 ➢ 必须领会到系统分析时没有完全正确的答案；
第19页，共38页。
4.1.3 系统分析员
1. 系统分析员职责
❖ 研究使用单位的存在问题和需要，理解组织（使用单位）的目标、 结构和业务过程；
❖ 确定利用信息技术的优势，改进使用单位工作的最佳方法；
❖ 帮助系统用户和管理者定义新的或增强的系统的需求
公告、公司新闻等。
第36页，共38页。
•收集和研究业务文档的优缺点
❖ 优点
第11页，共38页。
➢ 稳定的不稳定的系统。一个稳定的系统表现为动态平衡，或通过状态 改变对内部和外部事件做出反应，但改变是非常微小的或返回到一个接 近于以前的状态；一个不稳定的系统对内部和外部的反应是不确定的、 不可预期的或大多时候 比例失调。
➢ 自适应和非自适应的系统（或活动的和非活动的系统）。一个 自适应或活动的系统是一个能回应环境变化和外部干预事件的 系统；一个非自适应或非活动的系统是对环境变化和外部干预 事件不能做出回应的系统。
第29页，共38页。
访谈过程中：
❖ 要注意观察身体语言和感情流露，帮助准确理解；
❖ 要坦诚，并创造和谐的环境； ❖ 要告诉被访问者调查内容的用途；
❖ 以自己的理解复述被访性问题，时刻领会调查不是评价或批评；
❖ 要使用清晰和准确的语言，不要使用过于专业术语； ❖ 避免冗长和复杂的问题，及时中止不必要的访谈； ❖ 不要用“你们”对一组人提问等； ❖ 大部分时间是倾听和记录。
可以理解、建模和管理的，识别每个系统的输入和输出，以便
能理解、定义和建模它们与其所处环境之间的交互方式；
➢ 因为没有一个系统是完全正确的，能反应一个不断变化世界的发
杂性，所以要准备好试验不同的系统模型直到找到一个最合适的。
第18页，共38页。
➢ 一个系统保留太长时间是有害的。 ➢ 必须领会到系统分析时没有完全正确的答案；
第19页，共38页。
4.1.3 系统分析员
1. 系统分析员职责
❖ 研究使用单位的存在问题和需要，理解组织（使用单位）的目标、 结构和业务过程；
❖ 确定利用信息技术的优势，改进使用单位工作的最佳方法；
❖ 帮助系统用户和管理者定义新的或增强的系统的需求
公告、公司新闻等。
第36页，共38页。
•收集和研究业务文档的优缺点
❖ 优点
第11页，共38页。
➢ 稳定的不稳定的系统。一个稳定的系统表现为动态平衡，或通过状态 改变对内部和外部事件做出反应，但改变是非常微小的或返回到一个接 近于以前的状态；一个不稳定的系统对内部和外部的反应是不确定的、 不可预期的或大多时候 比例失调。
➢ 自适应和非自适应的系统（或活动的和非活动的系统）。一个 自适应或活动的系统是一个能回应环境变化和外部干预事件的 系统；一个非自适应或非活动的系统是对环境变化和外部干预 事件不能做出回应的系统。
第29页，共38页。
访谈过程中：
❖ 要注意观察身体语言和感情流露，帮助准确理解；
❖ 要坦诚，并创造和谐的环境； ❖ 要告诉被访问者调查内容的用途；
❖ 以自己的理解复述被访性问题，时刻领会调查不是评价或批评；
❖ 要使用清晰和准确的语言，不要使用过于专业术语； ❖ 避免冗长和复杂的问题，及时中止不必要的访谈； ❖ 不要用“你们”对一组人提问等； ❖ 大部分时间是倾听和记录。
软件工程PPT课件
02
需求分析的方法包括功能分析 、数据流图、实体关系图等。
03
需求分析过程中需要关注需求 的可实现性和可验证性，以确 保开发的软件能够满足用户的 需求。
需求规格说明
01
需求规格说明是软件需求工程的重要输出，它详细描述了软件 系统的功能、性能、安全等方面的要求。
02
需求规格说明应该清晰、准确、完整，并且易于理解和验证。
软件架构的重要性
软件架构决定了软件系统的性能、 可维护性、可扩展性和安全性等 关键特性，是软件设计过程中最 重要的环节之一。
常见的软件架构
常见的软件架构包括单体应用架 构、微服务架构、服务导向架构 等，不同的架构适用于不同的应 用场景。
数据设计
数据设计概述
数据设计是指对软件系统中的 数据进行规划、组织、存储和
06
软件维护工程
软件维护的定义与分类
总结词
软件维护是软件工程的重要环节，涉及对已交付软件产品的修改、完善和优化。
详细描述
软件维护是指在软件交付后，为了改正错误、改进性能或其他目的，对软件进行的修改活动。根据维护活动的内 容和性质，软件维护可分为纠错性维护、适应性维护、完善性维护和预防性维护。
软件维护的过程
管理的方法和过程。
数据模型
数据模型是数据设计的核心， 包括概念数据模型、逻辑数据 模型和物理数据模型等。
数据存储
数据存储是数据设计的关键环节 ，需要考虑数据的存储介质、存 储方式和存储容量等因素。
数据安全
数据安全是数据设计的重要考 虑因素，包括数据的加密、备
份、恢复和访问控制等。
界面设计
界面设计概述
需求规格说明
将收集到的需求整理成文档，明确软件的功能、性能、安全 性等要求。
《软件工程》PPT课件
问题定义（续）
系统全部弄清楚了。还有一些人可能会给你展示一些企业的十分详 尽的管理示图，如物资流管理图、生产管理图、计划财务管理图等。 因为他们也可能认为，只要分析员把这些图看懂了，就会对他们要 建立的系统搞清楚了。
但是，在问题定义阶段千万不要陷入到这些表格和图纸中。因为不 管是表格还是图纸，其中都包含了大量的、只有用户才能懂的术语。 当然，并不是说在问题定义阶段，这些图纸表格没有一点作用。对 一些关键性的语汇可以请用户讲清楚，这样有利于问题定义的准确 性。
快速原型（续）——类型之三
为了保证软件产品的质量，在总体设计和详细设计过程中，用 原型来验证总体结构或某些关键算法。如果设计方案验证完成后就 将原型丢弃，则构造原型的工具不必与目标系统的生产环境一致。 如果想把原型作为最终产品的一部分，原型和目标系统可使用同样 的程序设计语言。
快速原形的开发过程
问题定义的目的是要在短时间内，对用户的要求有一个比较准确的 估计，对要实现的系统规模做到胸中有数。但仅有这些还不够，还 要搞清用户不打算干什么，在这个系统中哪些内容不用实现。工作 的宗旨是搞清要做什么并划清要实现的系统的范围边界。
在完成问题定义的过程中，用户在一开始，可能会给你大堆大堆的 表格，因为他们可能认为只要把表格给你讲清楚，你就会对这个
系统定义与用户 需求分析
原型设计 编码
完善原 型
测试原 型
产品系统的设 计实现
第三课时
喷泉模型 软件重用模型
第一章第三课时
喷泉模型
基于喷泉模型，Hodge等人提出将软件开发过程
划分为概念模型分析、系统设计、对象设计与实现、
测试和系统组装集成等五个阶段，它也体现出分析
和设计之间的重叠 ①概念模型分析：这个阶段主
软件工程PPT课件第3章 软件需求分析
–多个来回
6
软件需求分析的通信途径
7
分析建模
结构化分析模型 面向对象分析模型 分析模型描述工具
DFD、DD和PSPEC（加工规约）
CFD、CSPEC（控制规约）和STD E-R图 用例图，对象-关系图，对象-行为图
8
结构化分析模型
数据对象 说明 E-R图 加工说明 DFD图
44
数据流图
数据流图(DFD)是一种图形化技术，它描绘信息
流和数据从输入移动到输出的过程中所经受的变换 。 在数据流图中没有任何具体的物理部件，它只是 描绘数据在软件中流动和被处理的逻辑过程。 数据流图是系统逻辑功能的图形表示，即使不是 专业的计算机技术人员也容易理解它，因此是分析 员与用户之间极好的通信工具。 此外，设计数据流图时只需考虑系统必须完成的 基本逻辑功能，完全不需要考虑怎样具体地实现这 些功能。
2
需求分析的结构化分析方法准则
(1) 必须理解并描述问题的信息域，根 据这条准则应该建立数据模型。 (2) 必须定义软件应完成的功能，这条 准则要求建立功能模型。 (3) 必须描述作为外部事件结果的软件 行为，这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模 型进行分解，用层次的方式展示细节。
40
分析模型的元素
数据字典(DD)：模型核心(中心库) E-R图(ERD)： 数据流图(DFD)
指明数据在系统中移动时如何被变换; 描述对数据流进行变换的功能;
DFD中每个功能的描述包含在加工规约 (小说明)。
状态变迁图(STD)
指明作为外部事件的结果,系统将如何 动作。
41
3.4.2 数据建模
4
需求分析的任务和步骤
软件工程课程ppt课件
项目管理工具
如Microsoft Project、JIRA等，用于项目计划制定、 任务跟踪和团队协作。
团队协作与沟通
团队协作的重要性
建立高效协作机制，提 高团队整体效能。
沟通技巧
倾听、表达清晰、及时 反馈等，促进团队成员 之间的有效沟通。
协作工具
如Git、GitHub、 Confluence等，支持版 本控制、代码托管和团 队协作。
软件工程课程ppt课 件
目录
• 软件工程概述 • 软件需求分析 • 软件设计 • 软件开发 • 软件测试与质量保证 • 软件维护与演化 • 软件工程管理与实践
01
软件工程概述
软件工程的定义与发展
定义
软件工程是一门研究用工程化方法构建和维护有效、实用和高质量的软件的学科。
发展历程
从20世纪60年代的软件危机开始，软件工程逐渐发展成为一个独立的学科领域，经历了瀑布模 型、螺旋模型、敏捷开发等不同的开发模式和方法。
阐述持续集成和持续交付的概念、原 理和实践，以及如何通过持续集成和 持续交付来加速软件的演化过程并提 高软件的质量。
07
软件工程管理与实践
项目管理方法与工具
传统项目管理方法
包括瀑布模型、螺旋模型等，强调项目计划、进度控 制和风险管理。
敏捷项目管理方法
如Scrum、Kanban等，注重快速响应变化、持续集 成和交付。
兼容性测试
测试软件在不同硬件、操 作系统、浏览器等环境下 的兼容性。
自动化测试
使用自动化工具进行软件 测试，提高测试效率和准 确性。
缺陷管理与跟踪
缺陷记录
详细记录缺陷信息，包括缺陷描述、重现 步骤、严重程度等。
缺陷分析
对缺陷进行统计分析，找出缺陷产生的原 因和规律。
如Microsoft Project、JIRA等，用于项目计划制定、 任务跟踪和团队协作。
团队协作与沟通
团队协作的重要性
建立高效协作机制，提 高团队整体效能。
沟通技巧
倾听、表达清晰、及时 反馈等，促进团队成员 之间的有效沟通。
协作工具
如Git、GitHub、 Confluence等，支持版 本控制、代码托管和团 队协作。
软件工程课程ppt课 件
目录
• 软件工程概述 • 软件需求分析 • 软件设计 • 软件开发 • 软件测试与质量保证 • 软件维护与演化 • 软件工程管理与实践
01
软件工程概述
软件工程的定义与发展
定义
软件工程是一门研究用工程化方法构建和维护有效、实用和高质量的软件的学科。
发展历程
从20世纪60年代的软件危机开始，软件工程逐渐发展成为一个独立的学科领域，经历了瀑布模 型、螺旋模型、敏捷开发等不同的开发模式和方法。
阐述持续集成和持续交付的概念、原 理和实践，以及如何通过持续集成和 持续交付来加速软件的演化过程并提 高软件的质量。
07
软件工程管理与实践
项目管理方法与工具
传统项目管理方法
包括瀑布模型、螺旋模型等，强调项目计划、进度控 制和风险管理。
敏捷项目管理方法
如Scrum、Kanban等，注重快速响应变化、持续集 成和交付。
兼容性测试
测试软件在不同硬件、操 作系统、浏览器等环境下 的兼容性。
自动化测试
使用自动化工具进行软件 测试，提高测试效率和准 确性。
缺陷管理与跟踪
缺陷记录
详细记录缺陷信息，包括缺陷描述、重现 步骤、严重程度等。
缺陷分析
对缺陷进行统计分析，找出缺陷产生的原 因和规律。
需求工程过程PPT课件
2.2.2 分层的数据流图
一、数据流图的图符 四种基本图形符号：
T
A
B
*
C
T
A
B
*
C
T
A
B
+
C
T
A
B
+
C
T
A
B
C
+
T
A
B
C
+
* 与
+ 或
互斥
+
“先全局后局部,先整体后细节,先抽象后具体” 通常可将这种分层的DFD图,分为顶层、中间层、底层。 具体步骤： 1。先确定系统范围，画出顶层的DFD图。 2。逐层分解顶层DFD图，获得若干中间层DFD图。 3。画出底层的DFD图。
一批 订单
出版社档案文件
订货存根文件
画图步骤 ： 1、确定外部实体及输入、输出数据流。 2、确定分解顶层的加工。 3、确定使用的文件。 4、用数据流将各部分连接起来，形成数据封闭。
注意：标注各加工框及数据流名称。
例1：图书预定系统（顶层DFD图）
2.2.2 数据流图
数据流图（Data Flow Diagram，DFD）是描述系统中数据流程的图形工具，它标识了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换为逻辑输出所需的加工处理。
数据存储
数据源点 或终点
加 工
加工名
数据流
数据流名
文件名
实体名
箭 头
圆或椭圆
单或双杠
矩形框
还有一些辅助的图例:
2.2.3 画分层DFD图的方法
顶层图说明了系统的边界,即系统的输入和输出数据流，顶层图只有一张。底层图由一些不能再分解的加工组成，这些加工都已足够简单，称为基本加工。在顶层和底层之间的是中间层。中间层的数据流图描述了某个加工的分解，而它的组成部分又要进一步分解。 画各层DFD图时，“由外向内”。
一、数据流图的图符 四种基本图形符号：
T
A
B
*
C
T
A
B
*
C
T
A
B
+
C
T
A
B
+
C
T
A
B
C
+
T
A
B
C
+
* 与
+ 或
互斥
+
“先全局后局部,先整体后细节,先抽象后具体” 通常可将这种分层的DFD图,分为顶层、中间层、底层。 具体步骤： 1。先确定系统范围，画出顶层的DFD图。 2。逐层分解顶层DFD图，获得若干中间层DFD图。 3。画出底层的DFD图。
一批 订单
出版社档案文件
订货存根文件
画图步骤 ： 1、确定外部实体及输入、输出数据流。 2、确定分解顶层的加工。 3、确定使用的文件。 4、用数据流将各部分连接起来，形成数据封闭。
注意：标注各加工框及数据流名称。
例1：图书预定系统（顶层DFD图）
2.2.2 数据流图
数据流图（Data Flow Diagram，DFD）是描述系统中数据流程的图形工具，它标识了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换为逻辑输出所需的加工处理。
数据存储
数据源点 或终点
加 工
加工名
数据流
数据流名
文件名
实体名
箭 头
圆或椭圆
单或双杠
矩形框
还有一些辅助的图例:
2.2.3 画分层DFD图的方法
顶层图说明了系统的边界,即系统的输入和输出数据流，顶层图只有一张。底层图由一些不能再分解的加工组成，这些加工都已足够简单，称为基本加工。在顶层和底层之间的是中间层。中间层的数据流图描述了某个加工的分解，而它的组成部分又要进一步分解。 画各层DFD图时，“由外向内”。
需求工程(第二讲)需求工程过程33
信息科学与技术学院
前景与范围的关系
前景关系到整个产品。当产品的战略定位或
业务目标随时间发生改变时，前景也会变化。范
围则只与一个特定项目，或实现产品功能下一增 量的某次迭代相关。
产品前景包括了每一个计划产品版本的范围
产品目录
版本1.0的 项目范围
版本1.1的 项目范围
版本1.1的 项目范围
版本n的 项目范围
难点：缺乏领域知识,应用领域的问题常常是模糊的、不精确 的；
– 存在默认的知识,如难以描述的常识问题；
– 存在多个知识源,且多知识源之间可能有冲突； – 客户可能的偏见，如不能提供或不想告知你所需要了解的事 情。
信息科学与技术学院
案例
3个月前，甲新加入一家公司。很快他进入到一个项目里， 这个项目是为某公司提供一个信息管理系统，主要是管理 供应商的情况。当时项目刚处于初期，主要是获取需求， 做DEMO，然后去为客户作演示。其中主要是甲做开发。 • 甲以前主要一直做系统的开发和设计工作，加入这个项目 后，公司希望他作为项目的PM，来推动这个项目往前走。 • 然而,甲对这个客户行业（某工程行业）非常不了解，因 此对获取需求毫无办法，虽然他也希望能参考一些类似的 系统，但一直没有找到。所以基本上就是公司有客户关系 的人零零碎碎的发过一些需求，然后他去照着做。最近， 客户终于认为甲做的系统并不适合他们。所以这个项目可 以说是失败了，于是，公司认为甲没有达到要求，解除了 合同。
信息科学与技术学院
通过业务需求定义前景
回顾：
业务需求（ business requirement）表示组织或客户高层次的目标。
来源：项目投资人、购买产品的客户、实际用户的管理者、市场
营销部门或产品策划部门。 内容：描述了组织为什么要开发一个系统，即组织希望达到的目
前景与范围的关系
前景关系到整个产品。当产品的战略定位或
业务目标随时间发生改变时，前景也会变化。范
围则只与一个特定项目，或实现产品功能下一增 量的某次迭代相关。
产品前景包括了每一个计划产品版本的范围
产品目录
版本1.0的 项目范围
版本1.1的 项目范围
版本1.1的 项目范围
版本n的 项目范围
难点：缺乏领域知识,应用领域的问题常常是模糊的、不精确 的；
– 存在默认的知识,如难以描述的常识问题；
– 存在多个知识源,且多知识源之间可能有冲突； – 客户可能的偏见，如不能提供或不想告知你所需要了解的事 情。
信息科学与技术学院
案例
3个月前，甲新加入一家公司。很快他进入到一个项目里， 这个项目是为某公司提供一个信息管理系统，主要是管理 供应商的情况。当时项目刚处于初期，主要是获取需求， 做DEMO，然后去为客户作演示。其中主要是甲做开发。 • 甲以前主要一直做系统的开发和设计工作，加入这个项目 后，公司希望他作为项目的PM，来推动这个项目往前走。 • 然而,甲对这个客户行业（某工程行业）非常不了解，因 此对获取需求毫无办法，虽然他也希望能参考一些类似的 系统，但一直没有找到。所以基本上就是公司有客户关系 的人零零碎碎的发过一些需求，然后他去照着做。最近， 客户终于认为甲做的系统并不适合他们。所以这个项目可 以说是失败了，于是，公司认为甲没有达到要求，解除了 合同。
信息科学与技术学院
通过业务需求定义前景
回顾：
业务需求（ business requirement）表示组织或客户高层次的目标。
来源：项目投资人、购买产品的客户、实际用户的管理者、市场
营销部门或产品策划部门。 内容：描述了组织为什么要开发一个系统，即组织希望达到的目
需求工程
需求工程任务
需求工程为以下工作提供了良好的机制： 理解客户需要什么，分析要求，评估可行 性，协商合理的方案，无歧义地详细说明 方案，确认规格说明，管理需求以至将这 些需求转化为可运行系统。需求工程过程 通过执行七个不同的活动来完成：起始、 导出、精化、协商、规格说明、确认和管 理。
起始
通常都是当确定了商业要求或发现了潜在 的新市场、新服务时项目才开始。业务领 域的共利益者定义业务用例，确定市场的 宽度和深度，进行粗略的可行性分析，并 确定项目范围的工作说明。 在项目起始阶段，软件工程师会询问一些 似乎与项目无直接关系的问题。目的是对 问题、方案需求方、期望方案的本质、客 户和开发人员之间初步的交流和合作的效 果建立基本的谅解。
首次提问
最后一组问题关注于沟通活动本身的效率。
你是回答这些问题的合适人选吗？你的回答 是“正式的”吗？ 我的提问和你想解决的问题相关吗？ 我的问题是否太多了？ 还有其他人员可以提供更多的信息吗？ 还有我应该问的其他问题吗？
首次提问
ቤተ መጻሕፍቲ ባይዱ
这些问题将有助于“打破坚冰”，并有助 于交流的开始，而且这样的交流对需求导 出的成功至关重要。但是，会议形式的问 与答并非一定是会取得成功的好方法。事 实上，Q&A会议应该仅仅用于首次接触， 然后就应该用需求诱导形式（包括问题求 解、协商和规格说明）取代。
可用的跟踪表
特征跟踪表：显示需求与重要的、客户可 见的系统/产品特征的关系。 来源跟踪表：标识每个需求的来源。 依赖跟踪表：指明需求之间是如何相互关 联的。 子系统跟踪表：按照需求所控制的子系统 对需求分类。 接口跟踪表：显示需求与内部和外部系统 接口的关系。
3-需求工程(2)
加细每一个加工框（不封闭）
处理订单细化
顾客
订单
检验订单 1.1
有效订单
可供货单
检验库存 1.2
缺货信息
缺货登记 1.3
供货处理细化
库存记录
可供货单
库存记录
修改库存并保存 订单 2.1
登记过的 订单
开备货单 2.2
缺货记录
备货单
仓库
订单记录 Neusoft Computer Science and Technology Department copy right
为数据对象的实例命名； 描述这个实例； 建立对另一个数据对象的另一个实例的引用； 主码：为了唯一地标识数据对象的某一个实例，定
义数据对象中的一个属性或几个属性为主码 (key)， 书写为_id。
例如在“学生”数据对象中用“学号”做关键码，它可唯一 地标识一个“学生”数据对象中的实例。
关系： 各个数据对象的实例之间的关联。
Neusoft Computer Science and Technology Department copy right
数据流程图的注意点
DFD上所有图形符号只限于前述四种基本元素 DFD主图必须包括前述四种基本元素，缺一不可 DFD的主图上的数据流必须封闭在外部实体之间 每个加工至少有一个输入数据流和一个输出数据流 在数据流图中，需按层给加工框编号。编号表明该加工
如一个学生“张鹏”选修两门课程“软件工程”与 “计算机网络”，学生与课程的实例通过“选修” 关联起来。
软件工程பைடு நூலகம்
第三章 需求工程（2）
任务2 构建功能模型
需求分析 结构化分析法 功能建模
任务3 构建数据模型 任务4 构建行为模型
需求工程
• 需求跟踪是指通过比较需求文档与后续工作成果之间的对 应关系，确保产品依据需求文档进行开发，建立与维护 “需求——设计——编程——测试”之间的一致性，确保 所有工作成果符合用户需求。需求跟踪是一项需要进行大 量手工劳动的任务，在系统开发和维护的过程中一定要随 时对跟踪联系链信息进行更新。需求跟踪能力的好坏会直 接影响产品质量，降低维护成本，容易实现复用，同时， 需求跟踪还需要建设方的大力支持。
开发系统描述
系统需求 开发系统设计 子系统组件需求 （子系统需求） 开发子系统设计 子系统组件需求 （下层子系统需求）
抽象模型
解 决 方 案 领 域
系统设计 框架
子系统设 计框架
二、需求的重要性
• 美国于1995年开始的一项调查的结果有力的证明了需求的 重要性。 • 在调查中，他们对全国范围内的 8000 个软件项目进行跟 踪调查，结果表明，有1/3的项目没能完成，而在完成的 2/3 的项目中，又有1/2的项目没有成功实施。他们仔细 分析失败的原因后发现，与需求过程相关的原因占45%， 而其中缺乏最终用户的参与以及不完整的需求又是两大首 要原因，各占13%和12%。
三、需求开发
• 3、需求文档编写阶段
编写原则
◆明确认识 ◆认清对象 ◆抓住要点 ◆具体描述
三、需求开发
• 3、需求文档编写阶段 明确认识
对于编写需求文档的人员来讲，所要关注的问题是：最终需要的是什么， 大致的模型，而不用去在意这个过程怎么实现。 前提：需求的讨论与沟通 （1）总的需求的可行性 （2）核心功能的实现 （3）思路的调整或细节化补充 （4）找出最优方案
三、需求开发
• 1、需求获取
（一）访谈与调查
• 在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不 要过于详细，允许有一定的灵活性。一般按照如下原则进行准备： – 所提问的问题应该循序渐进，从整体的方面开始提问，接下来的 问题应有助于对前面的问题更好的理解和细化； – 不要限制用户对问题的回答，这有可能会引出原先没有注意的问 题； – 提问和回答在汇总后应能够反映用户需求的全貌
软件工程--需求工程
业务需求：这项需求是用户高层机 构决定的，它确定了系统的目标、 规模和范围 。
–用户需求：用户需求是用户使用该 软件要完成的任务。最终用户的工 作过程、所涉及的信息、当前系统 的工作情况、与其它系统的接口等 等。
–
功能需求：定义了软件开发人员必 须实现的软件功能。
–非功能需求：是对功能需求的补充， 可以分为两类，一类是对用户来说 可能很重要的属性，包括：有效性、 高效性、灵活性、完整性、互操作 性、可靠性、健壮性、可用性。另 一类是对开发者来说很重要的质量 属性，包括：可维护性、可移植性、 可重用性、可测试性.
库房客 户端 采购客 户端 订货组 客户端
仓库事物处理 采购 库存 客户 销售 供应商 信 息
采购订货报警
票据打印机1
采购申请单
采购申请处理
销售 开票
销售开票
销售单
销售 提货
票据打印机2
销售提货
• 数据流程图是描绘系统逻辑模型的图形工具，只描绘信息 在系统中的流动和处理情况，不反映系统中的物理部件， 数据流程图使用四个标准的基本符号 。
软件需求分析规格说明书
– 由开发方提供。 – 这份文档是软件开发的重要阶段产品。软件需 求分析规格说明书的主要内容是使用自然语言 和一些图形符号描述用户需求和软件要实现的 功能，详细描述数据关系和数据存储、软件处 理流程、与外部系统（角色）的接口，以及软 件安全性、可靠性、可扩充性、可移植性等非 功能性需求描述。 – 该文档的提交时间是需求分析阶段结束之前。
数据字典表 编号： 使用频率： 使用权限： 名称 名称： 来源/去向： 保存时间： 简称 键值 类型 长度 值域 初值 备注
特别说明：
• 实体关系图本身不属于结构化分析方法。 但是，在实际工作中，为了描述数据之间 的关系，常常在结构化方法的基础上用实 体关系图反映数据流（数据存储）之间的 关系。
–用户需求：用户需求是用户使用该 软件要完成的任务。最终用户的工 作过程、所涉及的信息、当前系统 的工作情况、与其它系统的接口等 等。
–
功能需求：定义了软件开发人员必 须实现的软件功能。
–非功能需求：是对功能需求的补充， 可以分为两类，一类是对用户来说 可能很重要的属性，包括：有效性、 高效性、灵活性、完整性、互操作 性、可靠性、健壮性、可用性。另 一类是对开发者来说很重要的质量 属性，包括：可维护性、可移植性、 可重用性、可测试性.
库房客 户端 采购客 户端 订货组 客户端
仓库事物处理 采购 库存 客户 销售 供应商 信 息
采购订货报警
票据打印机1
采购申请单
采购申请处理
销售 开票
销售开票
销售单
销售 提货
票据打印机2
销售提货
• 数据流程图是描绘系统逻辑模型的图形工具，只描绘信息 在系统中的流动和处理情况，不反映系统中的物理部件， 数据流程图使用四个标准的基本符号 。
软件需求分析规格说明书
– 由开发方提供。 – 这份文档是软件开发的重要阶段产品。软件需 求分析规格说明书的主要内容是使用自然语言 和一些图形符号描述用户需求和软件要实现的 功能，详细描述数据关系和数据存储、软件处 理流程、与外部系统（角色）的接口，以及软 件安全性、可靠性、可扩充性、可移植性等非 功能性需求描述。 – 该文档的提交时间是需求分析阶段结束之前。
数据字典表 编号： 使用频率： 使用权限： 名称 名称： 来源/去向： 保存时间： 简称 键值 类型 长度 值域 初值 备注
特别说明：
• 实体关系图本身不属于结构化分析方法。 但是，在实际工作中，为了描述数据之间 的关系，常常在结构化方法的基础上用实 体关系图反映数据流（数据存储）之间的 关系。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
❖ 参考书目：包含了对所有和该软件相关的文档的引 用，其中包括其他的软件工程文档、技术参考文献、 厂商文献以及标准。
❖ 附录：包含了规约的补充信息，表格数据、算法的 详细描述、图表以及其他材料。
需求验证
❖ 需求验证目的是要检验需求是否能够反映用户的意愿 ❖ 评审人员评审时往往需要检查以下内容：
1. 系统定义的目标是否与用户的要求一致； 2. 系统需求分析阶段提供的文档资料是否齐全；文档中的描述
1、问题分解
❖ 什么是问题分解
降低解决问题的复杂度; 获取和分析问题本身所 固有的整体-部分关系
图书馆系统
❖ 读者管理 ❖ 图书管理 ❖ 借阅管理
子问题1
整个问题 子问题3
子问题2
2、问题抽象(1/2)
❖ 什么是抽象?
抓住问题的本质,获取一般和特殊关系
问题抽象(2/2)
❖ 读者抽象(提取成份)
❖ 什么是多视点分析
从多个角度、不同层面上分析和描述用户需求
❖ 为什么需要多视点分析
人的认识具有片面性(瞎子摸象) 多视点可以帮助我们全面把握用户的需求
❖ 多视点分析：
例如围绕着超市收银系统
❖ 顾客希望？ ❖ 收银员希望？ ❖ 经理希望？ ❖ 系统管理员希望？
最终的软件系统是相关方的综合体，各种期 望可能存在冲突，需要进一步分析权衡
❖ 功能描述：描述解决问题所需的每个功能。其中包 括，为每个功能说明一个处理过程；叙述设计约束； 叙述性能特征；用一个或多个图形来形象地表示软 件的整体结构和软件功能与其他系统元素间的相互 影响。
❖ 行为描述：描述作为外部事件和内部产生的控制特 征的软件操作。
❖ 检验标准：描述检验系统成功的标志。即对系统进 行什么样的测试，得到什么样的结果，就表示系统 已经成功实现了。它是“确认测试”的基础。
❖ 会议应该讨论那些非正式讨论不能解决 的问题
❖ 通常会议分为三个阶段：
叙述阶段 讨论阶段 决策阶段
内容摘要
❖需求工程概述 ❖需求获取 ❖需求分析、协商与建模 ❖需求规约与验证 ❖需求管理
需求规约的原则-1
❖从现实中分离功能，即描述要“做 什么”而不是“怎样实现”
认识模型，而不是设计或实现的模型 使用面向处理的规约语言(或称系统定义语言)
需求调研实例—学生选课系统
❖ 第一阶段：了解基本情况
请教务处老师介绍背景，如学生总数、课程数量、选课 相关的基本制度等
❖ 第二阶段：制订访谈计划，深入讨论相 关需求
除了学生还有哪些相关用户? 选课规则(学分、课程人数限制等)、退课规则 了解客户ຫໍສະໝຸດ 系统的期望：准确、访问速度快… ……
需求调研实例—学生选课系统
名字 性别 单位 类别 照片 Email 电话
3、需求建模(1/2)
❖ 什么是需求模型 ❖ 为什么需要建模
需求建模(2/2)
❖ 注意
不要涉及软件设计和实现细节
❖ 需求建模方法
面向数据流的结构化分析方法 (SA) 面向数据结构的分析方法 面向对象的分析方法 (OOA)
4、多视点分析
需求工程的六个阶段
❖需求获取：资料收集 ❖需求分析与协商：理解分析整理 ❖系统建模：用模型描述(写下来) ❖需求规约：完善需求文档并定稿 ❖需求验证：验证确认 ❖需求管理：整体规划及变更管理
内容摘要
❖需求工程概述 ❖需求获取 ❖需求分析、协商与建模 ❖需求规约与验证 ❖需求管理
需求获取方法与策略
需求规约的原则-2
❖ 规约必须包括系统运行环境 ❖ 规约必须是可操作的
需求规约的原则-3
❖ 规约必须允许不完备性并允许扩充 ❖ 规约必须局部化和松散耦合
需求规约
❖ 引言：陈述软件目标，在基于计算机的系统语境内 进行描述。
❖ 信息描述：给出软件必须解决问题的详细描述，记 录信息内容和关系、流和结构。
内容摘要
❖需求工程概述 ❖需求获取 ❖需求分析、协商与建模 ❖需求规约与验证 ❖需求管理
❖ Alan Davis 把需求工程定义为“直到 （但不包括）把软件分解为实际架构构 件之前的所有活动” (强调做什么)
❖ Herb Krasner定义了需求工程的五阶段 生命周期：需求定义和分析、需求决策、 形成需求规格、需求实现与验证、需求 演进管理
❖1、建立与用户、开发人员、分析人 员之间顺畅的通信途径
❖2、深入客户方进行访谈与调查 ❖3、观察用户操作流程 ❖4、组成各方联合小组 ❖5、使用基于用况(Use Case)的方法
访谈与调查的原则
❖ 所提问的问题应该循序渐进 ❖ 不要限制用户对问题的回答 ❖ 提问和回答在汇总后应能够反映用户
需求的全貌——不断汇总-反馈-汇总
用实例说明需求工程的设计原则 和描述方法
计算机学院 关皓文 201313273
需求的定义
用户解决一个问题或达到一个目标所需要的一种 状况或能力(主观需求)
系统为了满足一种约定、标准、规格说明或其它 正式文件而必须满足或拥有的一种状况或能力 （客观需求）
以上两种状态或能力的文档化表示（需求文档）
需求分析原则
❖ 必须能够表示和理解问题的信息域(数据)
❖ 必须能够定义软件将完成的功能
❖ 必须能够表示软件的行为(作为外部事件 的结果)
❖ 必须划分描述数据、功能和行为的模型 (分离描述)，从而可以分层次地揭示细节
❖ 分析过程应该在基本信息基础上不断细化
需求描述和分析技术
1. 问题分解 2. 抽象 3. 建模 4. 多视点
是否完整、清晰、准确地反映了用户要求； 3. 被开发项目的数据流与数据结构是否确定且充足； 4. 主要功能是否已包括在规定的软件范围之内，是否都已充分
❖ 第三阶段：基本了解需求后就一些关键细节 通过问卷进行明确
在已经了解总体选课人数之后，需要进一步了解通常情 况下的选课持续时间、是否按院系逐步开放选课、选课 人数的一般分布等—与性能设计密切相关
推荐关键管理人员使用USB Key设备，经济上是否可以 接受
……
内容摘要
❖需求工程概述 ❖需求获取 ❖需求分析、协商与建模 ❖需求规约与验证 ❖需求管理
需求协商
❖ 讨论需求冲突，折衷方案 ❖ 协商不是简单的逻辑或技术上的争论 ❖ 要注意组织和行政方面的因素
不一致的目标 责任的丧失或转移 组织文化 组织管理态度和士气 部门差异
❖ 通常会议是解决冲突最快的方式
❖ 参加者：发现冲突、遗漏或重叠的分析 员，以及可以解决发现的问题的项目相 关人员
❖ 附录：包含了规约的补充信息，表格数据、算法的 详细描述、图表以及其他材料。
需求验证
❖ 需求验证目的是要检验需求是否能够反映用户的意愿 ❖ 评审人员评审时往往需要检查以下内容：
1. 系统定义的目标是否与用户的要求一致； 2. 系统需求分析阶段提供的文档资料是否齐全；文档中的描述
1、问题分解
❖ 什么是问题分解
降低解决问题的复杂度; 获取和分析问题本身所 固有的整体-部分关系
图书馆系统
❖ 读者管理 ❖ 图书管理 ❖ 借阅管理
子问题1
整个问题 子问题3
子问题2
2、问题抽象(1/2)
❖ 什么是抽象?
抓住问题的本质,获取一般和特殊关系
问题抽象(2/2)
❖ 读者抽象(提取成份)
❖ 什么是多视点分析
从多个角度、不同层面上分析和描述用户需求
❖ 为什么需要多视点分析
人的认识具有片面性(瞎子摸象) 多视点可以帮助我们全面把握用户的需求
❖ 多视点分析：
例如围绕着超市收银系统
❖ 顾客希望？ ❖ 收银员希望？ ❖ 经理希望？ ❖ 系统管理员希望？
最终的软件系统是相关方的综合体，各种期 望可能存在冲突，需要进一步分析权衡
❖ 功能描述：描述解决问题所需的每个功能。其中包 括，为每个功能说明一个处理过程；叙述设计约束； 叙述性能特征；用一个或多个图形来形象地表示软 件的整体结构和软件功能与其他系统元素间的相互 影响。
❖ 行为描述：描述作为外部事件和内部产生的控制特 征的软件操作。
❖ 检验标准：描述检验系统成功的标志。即对系统进 行什么样的测试，得到什么样的结果，就表示系统 已经成功实现了。它是“确认测试”的基础。
❖ 会议应该讨论那些非正式讨论不能解决 的问题
❖ 通常会议分为三个阶段：
叙述阶段 讨论阶段 决策阶段
内容摘要
❖需求工程概述 ❖需求获取 ❖需求分析、协商与建模 ❖需求规约与验证 ❖需求管理
需求规约的原则-1
❖从现实中分离功能，即描述要“做 什么”而不是“怎样实现”
认识模型，而不是设计或实现的模型 使用面向处理的规约语言(或称系统定义语言)
需求调研实例—学生选课系统
❖ 第一阶段：了解基本情况
请教务处老师介绍背景，如学生总数、课程数量、选课 相关的基本制度等
❖ 第二阶段：制订访谈计划，深入讨论相 关需求
除了学生还有哪些相关用户? 选课规则(学分、课程人数限制等)、退课规则 了解客户ຫໍສະໝຸດ 系统的期望：准确、访问速度快… ……
需求调研实例—学生选课系统
名字 性别 单位 类别 照片 Email 电话
3、需求建模(1/2)
❖ 什么是需求模型 ❖ 为什么需要建模
需求建模(2/2)
❖ 注意
不要涉及软件设计和实现细节
❖ 需求建模方法
面向数据流的结构化分析方法 (SA) 面向数据结构的分析方法 面向对象的分析方法 (OOA)
4、多视点分析
需求工程的六个阶段
❖需求获取：资料收集 ❖需求分析与协商：理解分析整理 ❖系统建模：用模型描述(写下来) ❖需求规约：完善需求文档并定稿 ❖需求验证：验证确认 ❖需求管理：整体规划及变更管理
内容摘要
❖需求工程概述 ❖需求获取 ❖需求分析、协商与建模 ❖需求规约与验证 ❖需求管理
需求获取方法与策略
需求规约的原则-2
❖ 规约必须包括系统运行环境 ❖ 规约必须是可操作的
需求规约的原则-3
❖ 规约必须允许不完备性并允许扩充 ❖ 规约必须局部化和松散耦合
需求规约
❖ 引言：陈述软件目标，在基于计算机的系统语境内 进行描述。
❖ 信息描述：给出软件必须解决问题的详细描述，记 录信息内容和关系、流和结构。
内容摘要
❖需求工程概述 ❖需求获取 ❖需求分析、协商与建模 ❖需求规约与验证 ❖需求管理
❖ Alan Davis 把需求工程定义为“直到 （但不包括）把软件分解为实际架构构 件之前的所有活动” (强调做什么)
❖ Herb Krasner定义了需求工程的五阶段 生命周期：需求定义和分析、需求决策、 形成需求规格、需求实现与验证、需求 演进管理
❖1、建立与用户、开发人员、分析人 员之间顺畅的通信途径
❖2、深入客户方进行访谈与调查 ❖3、观察用户操作流程 ❖4、组成各方联合小组 ❖5、使用基于用况(Use Case)的方法
访谈与调查的原则
❖ 所提问的问题应该循序渐进 ❖ 不要限制用户对问题的回答 ❖ 提问和回答在汇总后应能够反映用户
需求的全貌——不断汇总-反馈-汇总
用实例说明需求工程的设计原则 和描述方法
计算机学院 关皓文 201313273
需求的定义
用户解决一个问题或达到一个目标所需要的一种 状况或能力(主观需求)
系统为了满足一种约定、标准、规格说明或其它 正式文件而必须满足或拥有的一种状况或能力 （客观需求）
以上两种状态或能力的文档化表示（需求文档）
需求分析原则
❖ 必须能够表示和理解问题的信息域(数据)
❖ 必须能够定义软件将完成的功能
❖ 必须能够表示软件的行为(作为外部事件 的结果)
❖ 必须划分描述数据、功能和行为的模型 (分离描述)，从而可以分层次地揭示细节
❖ 分析过程应该在基本信息基础上不断细化
需求描述和分析技术
1. 问题分解 2. 抽象 3. 建模 4. 多视点
是否完整、清晰、准确地反映了用户要求； 3. 被开发项目的数据流与数据结构是否确定且充足； 4. 主要功能是否已包括在规定的软件范围之内，是否都已充分
❖ 第三阶段：基本了解需求后就一些关键细节 通过问卷进行明确
在已经了解总体选课人数之后，需要进一步了解通常情 况下的选课持续时间、是否按院系逐步开放选课、选课 人数的一般分布等—与性能设计密切相关
推荐关键管理人员使用USB Key设备，经济上是否可以 接受
……
内容摘要
❖需求工程概述 ❖需求获取 ❖需求分析、协商与建模 ❖需求规约与验证 ❖需求管理
需求协商
❖ 讨论需求冲突，折衷方案 ❖ 协商不是简单的逻辑或技术上的争论 ❖ 要注意组织和行政方面的因素
不一致的目标 责任的丧失或转移 组织文化 组织管理态度和士气 部门差异
❖ 通常会议是解决冲突最快的方式
❖ 参加者：发现冲突、遗漏或重叠的分析 员，以及可以解决发现的问题的项目相 关人员