用实例说明需求工程的设计原则和描述方法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
需求分析的任务和步骤
- 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设备，经济上是否可以 接受
……
内容摘要
❖需求工程概述 ❖需求获取 ❖需求分析、协商与建模 ❖需求规约与验证 ❖需求管理
需求协商
❖ 讨论需求冲突，折衷方案 ❖ 协商不是简单的逻辑或技术上的争论 ❖ 要注意组织和行政方面的因素
不一致的目标 责任的丧失或转移 组织文化 组织管理态度和士气 部门差异
❖ 通常会议是解决冲突最快的方式
❖ 参加者：发现冲突、遗漏或重叠的分析 员，以及可以解决发现的问题的项目相 关人员