第03章 软件需求分析

合集下载

软件工程第3章 软件需求分析

软件工程第3章  软件需求分析
10
Байду номын сангаас
图3.2 学生购买教材的具体模型
11
图3.3 学生购买教材的逻辑模型
12
图3.4 计算机售书系统的逻辑模型
13
3.3 需求分析方法和原则
为了保证项目的正常实施和顺利的完成,必须加强 项目管理和重视项目分析工作。只有从实际出发,切切 实实地把握用户需求、把握用户需求目标、把握用户将 来功能界定,才能保证我们开发工作正确性方向。
1
模型表达软件将要实现的需求,并以“软件需求规 格说明书”的形式作为本阶段工作的结果,为下一阶段 的软件设计提供设计基础。因此,需求分析过程实际上 是一个调查研究、分析综合的过程,是一个抽象思维、 逻辑推理的过程。随着软件系统复杂性的提高及规模的 扩大,需求分析在软件开发中的所处的地位日益突出, 从而也更加困难。
14
(1)软件需求分析理论 如果我们用数学方法来描述软件需求分析,可以将 一个应用软件定义为S,可能应用软件涉及功能性问题 非常广,我们用抽象化理论分析,可以划分为各个功能 域,可以用D1,D2,…,Dn表示,那么,我们可以用一 个表达式描述为:
15
(2)有效性软件需求分析三步法 由于在进行需求分析过程中,常存在客户说不清楚 需求、需求自身经常变动、分析人员或客户理解用户需 求有误等事实。因此,需求分析工作方法,应该定位在 “三个阶段”(也称“三步法”)。 (3)常用的需求分析方法 1)结构化分析方法 2)面向对象的分析方法
6
3.2 需求分析的步骤
3.2 需求分析的步骤 软件开发过程的目的就是要实现目标软件的物理模 型,也就是要确定构成软件系统的系统元素,并将功能 和信息结构分配到这些系统元素中。需求分析的任务之 一就是导出系统的逻辑模型,以解决目标系统“做什么” 的问题。导出逻辑模型有2种途径:一是分析员利用自 己丰富的经验,依据实际调查和分析的结果直接导出; 二是借助于当前系统的逻辑模型推导出目标系统的逻辑 模型(如图3.1所示)。

软件需求分析

软件需求分析

软件需求分析软件需求分析是系统开发过程中的重要环节。

它是指对用户需求进行分析和理解,然后将其转化为可执行的软件需求规格。

软件需求分析的目标是明确软件系统的功能、性能、可靠性、安全性等方面的要求,以便指导软件设计、编码和测试。

以下是软件需求分析的步骤:1. 确定需求的来源和范围:需求可以来自于用户、管理层、市场分析等不同方面,需求的范围可以是整个系统,也可以是系统的一个模块或功能。

2. 收集需求信息:与用户、管理人员、开发人员进行沟通,了解他们的需求和期望。

使用各种技术手段收集和整理需求信息,如面谈、问卷调查、文档分析等。

3. 定义需求:将收集到的需求信息进行整理和分类,并以明确的方式描述出来,如用案例、用例图、需求规格说明书等。

4. 分析需求:对需求进行分析,理解用户的真正需求背后的目标和意图。

分清主次需求,确定需求的优先级和紧急程度。

5. 验证需求:与用户进行验收,确保需求的准确性、完整性、一致性和可行性。

通过原型设计、模拟演示等方式与用户进行互动。

6. 管理需求变更:需求是动态的,可能会随着项目的推进而发生变化。

需要建立一套有效的变更控制机制,及时识别和管理需求变更。

7. 文档化需求:将需求整理为文档形式,包括需求规格说明书、用例文档、用户故事等。

确保需求的清晰可理解,以便于后续的开发和测试工作。

软件需求分析是系统开发过程中非常重要的一环,它直接影响着后续系统的设计、开发和测试工作。

只有明确、准确、全面的需求分析,才能确保最终开发出满足用户期望的软件系统。

第3章软件需求分析[32页]

第3章软件需求分析[32页]

学生
领书单
发书
进书通知
采购
进书通知
书库保管员
缺书登记文件
3.2.2 结构化分析方法案例
继续分解,就可获得第三层数据流图。
缺书登记文件
采购
进书通知
产生补发书 单4 教材存量文件
登记缺书3
补发 书单
凭证
暂缺 书单
学生
无效书单
审查发书1
领书通知
登记发书 和打印领 书单2
领书通知单
学生
发书登记文件
3.2.2 结构化分析方法案例
2.分析建模,提炼需求
通过建立分析模型,提炼需求。图形化的分析模型是说 明软件需求极好的手段,常用的模型有数据流图、实体关系 图、控制流图、状态转化图、用例图、类对象关系及行为图 等。
3.1.2 需求分析的步骤
3.编写需求说明,描述需求
软件需求规格说明必须使用统一格式的文档进行描述。 为了使需求描述具有统一的风格,可以采用已有的且可满足 项目需要的模板。
采购子系统如图被分解为3个加工。
缺书登记文件 按出版社统 计缺书2
按书号汇总 缺书1
教材存量文件
待购教材文件 缺 书 单
教材一览表文件
发书
进书通知
修改教材库 存和待购量3
进书通知
书库保管 员
3.3 面向对象分析方法

面向对象分析方法的使用是要定义所有与将被求解的问题相 关的类,即它们关联的操作和属性,以及类之间的关系。 一般面向对象分析方法进行应用系统需求分析时,不是从考 虑对象开始,而是从对系统将被使用方式的理解起步。如果 系统是人机交互的,则考虑被人使用的方式;如果系统是涉 及过程控制的,则考虑被机器使用的方式;如果系统协调和 控制应用的,则考虑被其他程序使用的方式。面向对象分析 方法总是从理解系统的“使用实例”开始,其基本步骤是: 定义系统的用例,在领域分析的基础上建立问题域的类(对 象模型),然后开始建立对象--关系和对象--行为模型。

软件需求分析

软件需求分析

软件需求分析引言软件需求分析是软件开发过程中的关键步骤之一,它对于确保软件开发项目的成功具有重要意义。

软件需求分析的主要目的是识别、整理和定义用户对软件的需求,以便于开发团队能够设计和实施出符合用户期望的软件系统。

本文将介绍软件需求分析的基本概念、流程以及常用的技术方法。

软件需求分析的概念软件需求分析是指对软件系统进行彻底的调查和研究,以确定用户和其他相关利益相关方对软件的需求。

在软件开发生命周期的早期阶段,软件需求分析将帮助开发团队准确定义软件系统的功能、性能和约束条件。

通过软件需求分析,开发团队可以更好地理解用户的需求,从而提供出更好的解决方案。

软件需求分析的流程1. 需求获取软件需求的获取是软件需求分析的起点。

其中,主要包括用户访谈、问卷调查、观察和文档分析等方法。

用户访谈是一种常用的需求获取技术,通过与用户直接对话,开发团队可以了解到用户对软件系统的期望、功能需求以及其他相关信息。

问卷调查可以借助在线工具,广泛搜集用户的需求信息。

观察则是观察用户在实际使用环境中的行为,从中获取对软件的需求。

2. 需求分析在需求获取阶段完成后,需求分析阶段将开始将这些需求进行归类、整理和分析。

首先,将收集到的需求划分为功能需求和非功能需求,进一步进行细分和梳理。

其次,将需求与系统的约束条件(如时间、成本和技术限制等)进行评估和匹配,以确定哪些需求是可实现的,哪些需求是不可行的。

最后,需求分析阶段还包括建立需求文档,并与利益相关方进行确认和批准。

3. 需求规格说明需求规格说明是将分析出的需求进行详细描述的过程。

在需求规格说明阶段,开发团队将采用适当的模型、工具和方法来规范和记录需求。

其中,用例图、数据流图和状态转移图等模型可以帮助团队更加清晰地描述需求的功能和交互过程。

此外,还可以使用面向对象分析(OOA)和面向对象设计(OOD)等方法来进行需求的建模和分析,以确保需求的准确性和一致性。

4. 需求验证与确认需求验证与确认是对需求进行评审、验证和确认的过程。

软件需求分析

软件需求分析

软件需求分析软件需求分析是软件开发过程中的一个关键阶段,它涉及对软件系统的功能、性能、接口等方面的要求进行深入分析和理解。

这个过程的主要目标是确保软件产品能够满足用户的需求和期望,并具有高质量的性能。

以下是软件需求分析的详细描述:1.定义需求:需求分析的第一步是明确软件系统的目标和功能。

这通常通过与用户、利益相关者或其他相关人员进行交流来实现,以获取他们对软件系统的期望和需求。

这些需求可以包括功能性需求(如系统应该做什么),非功能性需求(如系统的性能要求)以及约束条件(如开发时间和预算)。

2.分析需求:在收集了用户需求后,需求分析团队会对这些需求进行分析和整理。

这个过程可能包括对需求进行分类、排序和优先级划分,以及识别和消除潜在的问题和冲突。

在这个阶段,还需要对需求进行详细的定义和描述,以确保开发团队对用户需求有清晰的理解。

3.制定需求规格说明书:在完成需求分析后,需求分析团队会编写一份详细的需求规格说明书(Requirements Specification Document,简称RSD)。

这份文档将详细描述软件系统的功能、性能、接口和其他要求,并作为开发团队在后续开发过程中的参考依据。

RSD通常会包括用户需求、系统需求、业务需求和其他相关需求。

4.验证需求:在编写完RSD后,需求分析团队会与用户和其他利益相关者进行沟通和验证,以确保他们对RSD中的内容感到满意和认可。

这个过程通常包括评审会议、原型演示和用户测试等活动。

5.管理需求变更:在软件开发过程中,用户需求可能会发生变化。

为了确保软件项目能够按时、按质、按预算完成,需求分析团队需要对需求变更进行有效的管理和控制。

这包括评估变更的影响、更新RSD和与相关人员进行沟通等。

总之,软件需求分析是软件开发过程中不可或缺的一个环节。

通过深入了解用户需求并制定相应的需求规格说明书,可以确保软件产品能够满足用户的期望和要求,并具有高质量的性能。

同时,对需求变更的有效管理也是确保软件项目成功的关键因素之一。

软件工程03-需求分析

软件工程03-需求分析

软件工程03.需求分析软件工程03.需求分析1.引言1.1 编写目的本文档旨在对软件需求进行详细的分析和描述,以便为软件开发团队提供明确的指导,确保软件开发过程中有一个清晰的方向和目标。

1.2 读者对象本文档的主要读者对象为软件开发团队成员、项目经理和相关利益相关者,包括技术和非技术人员。

1.3 背景在软件工程开发过程中,需求分析阶段是非常重要的一环。

通过对用户需求进行分析和整理,可以确保开发的软件具有良好的功能和性能,并满足用户的期望。

2.需求概述2.1 业务需求在这个章节中,我们将对软件开发项目的业务需求进行详细的描述。

包括用户需求、功能需求和性能需求等。

2.2 用户需求在这个章节中,我们将详细描述用户对软件的期望和需求。

例如,用户希望软件能够提供什么功能,以及对用户界面的要求等。

2.3 功能需求在这个章节中,我们将详细描述软件需要实现的各个功能。

每个功能需求都应该具有明确的描述,包括输入、处理和输出等。

2.4 性能需求在这个章节中,我们将详细描述软件在性能方面的要求。

例如,软件需要支持多少用户同时使用,响应时间要求等。

3.系统规约3.1 功能性规约在这个章节中,我们将详细描述软件系统的功能性规约。

例如,软件的总体结构和各个模块之间的关系等。

3.2 可靠性规约在这个章节中,我们将详细描述软件系统的可靠性规约。

例如,软件需要具备多少的可用性和可靠性等。

3.3 可维护性规约在这个章节中,我们将详细描述软件系统的可维护性规约。

例如,软件需要能够方便地进行维护和更新等。

4.接口需求4.1 用户界面在这个章节中,我们将详细描述软件的用户界面设计。

包括界面的布局、颜色和字体等。

4.2 硬件接口在这个章节中,我们将详细描述软件与硬件之间的接口要求。

例如,软件需要与某些特定的硬件设备进行通信等。

4.3 软件接口在这个章节中,我们将详细描述软件与其他软件之间的接口要求。

例如,软件需要与某些特定的软件进行数据交换等。

03第三章 软件需求分析精品PPT课件

03第三章 软件需求分析精品PPT课件

统计资料:
In 1994, the Standish Group surveyed over 350 companies about their over 8000 software projects to find out how well they were faring. The results are sobering. Thirty-one percent of the software projects were canceled before they were completed. Moreover, in large companies, only 9% of the projects were delivered on time and cost what they were budgeted, and 16% met those criteria in small companies (Standish 1994).
2021/1/1
仲恺农业技术学院计算机与电子工程学院
4
在美国高科技历史上曾有过令人痛心的事件: 大家知道,DEC曾经是美国三大计算机公司之一,几年前
被康柏收购,从地球上消失,成为美国计算机界一大憾事。 DEC曾以众多的高新技术著称于世。其中,它在最后的几年里 研发出的 Alpha 计算机芯片更以卓越的技术在性能上超过了 Intel, sun 和其他厂家的芯片。微软也曾大力协助 DEC ,将 Windows Nt 移植到 Alpha 系统,然而,Alpha 在市场上彻底地 失败了,成为 DEC 最终失败的原因之一。
the Ariane-5, a space rocket belonging to the European Space Agency (ESA). On June 4, 1996, on its maiden flight, the Ariane-5 was launched and performed perfectly for approximately 40 seconds. Then, it began to veer off course. At the direction of an Ariane ground controller, the rocket was destroyed by remote

软件工程03-需求分析

软件工程03-需求分析

软件工程03-需求分析1、介绍在软件工程中,需求分析是一个关键的阶段,它旨在理解用户需求并确定一个系统或软件的功能和非功能需求。

本文档旨在详细描述需求分析的过程和结果。

2、项目概述在本章节中,将介绍项目的目标、范围和背景信息。

提供项目的背景和目的,明确软件需求分析的上下文。

3、用户需求描述主要用户群体,分析他们的需求和期望。

可能包括用户故事、使用案例或用户需求文档。

4、系统功能需求在本章节中列出系统的所有功能需求。

可以使用功能需求文档、使用案例或其他方法来详细描述每个功能需求。

5、系统性能需求描述系统的性能要求,如响应时间、吞吐量和容量要求等。

6、可靠性需求明确系统的可靠性要求,包括系统的可用性、可靠性、容错性等。

7、安全需求描述系统的安全要求,包括数据安全、身份验证和访问控制等。

8、可维护性需求说明系统的可维护性要求,如可扩展性、可修改性和易于测试等。

9、可移植性需求描述系统的可移植性要求,如平台的兼容性、系统的可移植性和可配置性等。

10、界面需求描述系统与用户、硬件和其他软件之间的交互。

包括用户界面设计、硬件接口和软件接口等。

11、数据需求描述系统需要存储、处理和管理的数据。

包括数据结构、数据库和数据流等。

12、非功能需求在本章节中描述其他非功能需求,如易用性、可访问性和可靠性等。

13、附录列出本文档所涉及的附件,如用户调研报告、需求变更记录和用户界面设计图等。

14、法律名词及注释本节包含文档中涉及的法律名词的解释和注释。

软件工程中的软件需求管理

软件工程中的软件需求管理

需求与设计的关联
建立需求-设计映射
确保设计是基于准确需求的
需求验证
验证设计是否符合需求规格
持续跟踪需求变化
不断迭代确认需求和设计的一致性
需求跟踪工具
JIRA
强大的项目管理和 跟踪工具
VersionOne
适用于敏捷开发的 需求跟踪软件
Trello
简单直观的需求管 理工具
●05
第五章 需求管理工具
需求管理工具概述
需求管理工具是通过软件工具来支持需求管理活动的工 具,包括需求收集工具、需求建模工具、需求跟踪工具 等。这些工具可以帮助团队更好地管理和跟踪需求,提
高项目管理效率。
常用的需求管理工具
JIRA
功能强大,适用于大型团队
Trello
简单易用,适用于小型团队
Rational RequisitePro
软件需求的分类
功能性需求
指明系统应该做什么
非功能性需求
指明系统应该如何做
软件需求管理的重要性
按时交付
预算内完成
满足用户需求
有效的需求管理可以确保项目 按时交付
有效的需求管理可以确保项目 在预算内完成
有效的需求管理可以确保项目 满足用户需求
软件需求管理的挑战
需求不明确
需求可能存在不明 确、不完整、不一大型团队需要强大 的需求管理功能
预算
需求管理工具费用 也是考虑因素
项目需求
不同项目需要不同 的需求管理方法
易用性
工具易用性影响团 队使用效率
需求管理工具的使用
培训团队成员
建立统一流程
有效使用工具
团队沟通
对工具的培训可以提高团队使 用效率 定期更新培训内容以跟上工具

软件需求分析

软件需求分析

软件需求分析软件需求分析是软件工程中至关重要的一个环节。

它涉及对软件系统需求的识别、理解和建模,以确保软件开发团队能够准确把握用户的需求,并将其转化为可执行的软件规格说明。

本文将介绍软件需求分析的步骤和方法,以及其在软件开发过程中的重要性。

1. 需求识别需求识别是软件需求分析的第一步,它旨在确定用户的真实需求。

这一步骤通常包括与客户进行交流,收集并整理用户的需求信息。

在这个阶段,分析师需要精确理解用户的业务流程和目标,并考虑到相关技术和约束条件。

可以通过访谈用户、观察实际操作、分析文档等方式来获取需求信息。

2. 需求分析需求分析是软件需求分析的核心环节,它通过对收集到的需求信息进行深入分析和理解,识别出用户的关键需求。

在这一步骤中,分析师需要使用建模工具和方法,例如数据流图、用例图、活动图等,来描述系统的功能、性能和约束条件。

通过需求分析,可以帮助开发团队明确开发目标,提高开发效率。

3. 需求验证需求验证是为了确保需求的正确性、完整性和一致性。

在这个阶段,分析师需要与用户进行沟通和确认,以确保需求的准确传达。

可以通过可行性研究、原型验证、强制性约束等方式来验证需求的有效性。

需求验证的目的是减少开发过程中的需求变更,降低项目风险。

4. 需求管理需求管理是软件需求分析的最后一步,它涉及需求文档的管理、变更控制和版本追踪。

在需求管理过程中,分析师需要建立一个有效的变更控制机制,确保对需求变更的审查和批准。

此外,还需要及时更新需求文档,以保持需求信息的一致性和可追溯性。

软件需求分析对于软件开发过程的成功非常关键。

它可以帮助开发团队准确把握用户需求,避免开发偏离预期目标,节省时间和资源成本。

通过清晰、准确地定义软件需求,可以提高软件系统的可靠性和可维护性。

需要注意的是,软件需求分析是一个迭代的过程,需要与用户密切合作,并及时进行反馈和调整。

只有在与用户的持续交流中,才能确保需求的准确理解和有效传达。

因此,软件需求分析不仅仅是一个技术活动,更是一项与人沟通和协作的艺术。

软件工程第3章软件需求分析

软件工程第3章软件需求分析






规定任何一个数据流子图必须与它上一 层的一个加工对应,两者的输入数据流 和输出数据流必须一致。此即父图与子 图的平衡 可以在数据流图中加入物质流,帮助用 户理解数据流图 图上每个元素都必须有名字 数据流图中不可夹带控制流 初画时可以忽略琐碎的细节,以集中精 力于主要数据流
数据词典
数据词典与数据流图配合,能清楚 地表达数据处理的要求 词条描述 对于在数据流图中每一个被命名的 图形元素,均加以定义,其内容有:名 字,别名或编号,分类,描述,定义, 位臵,其它等
软件原型的分类

在软件开发中,原型是软件 的一个早期可运行的版本, 它反映最终系统的部分重要 特性。 探索型:目的是要弄清对 目标系统的要求,确定所 希望的特性,并探讨多种 方案的可行性。
实验型:这种原型用于大规
模开发和实现之前,考核方 案是否合适,规格说明是否 可靠。

进化型:这种原型的目的 不在于改进规格说明,而是 将系统建造得易于变化,在 改进原型的过程中,逐步将 原型进化成最终系统。
第一层数据流图
细化每一功能
销售细化
细化每一功能
采购细化
检查和修改数据流图的原则





数据流图上所有图形符号只限于前述四种基 本图形元素 数据流图的主图必须包括前述四种基本元素, 缺一不可 数据流图的主图上的数据流必须封闭在外部 实体之间 每个加工至少有一个输入数据流和一个输出 数据流 在数据流图中,需按层给加工框编号。编号 表明该加工所处层次及上下层的亲子关系
x = a+b x = [a,b],x = [a|b] x = {a}, x = 3{a}8 x = (a) x = “a” x = 1..9

软件需求工程

软件需求工程

●07
第7章 总结
软件需求工程
软件需求工程是软件开发过程中至关重要的 一环。完善的需求工程能够提高软件项目的 成功率和用户满意度。在软件开发中,需求 工程是整个过程的基石,决定了软件最终的
质量和用户体验。
提高软件项目的成 功率
软件需求工程的重要性
降低项目成本
提升用户满意度
减少开发风险
准确的需求分析能够确保 开发团队理解客户需求,
性。
建立需求跟踪矩阵
需求跟踪管理
不变更不冗余
保证需求不丢失
监控需求变更
追踪需求的实现情况和变 更历史
确保需求稳定性和可追溯 性
确保开发过程中需求不被 遗漏
及时发现并处理需求变更
需求变更控制
控制变更范围
避免不必要的需求变更
评估变更影响
及时调整项目计划
避免进度延误
保证项目按计划顺利进行
需求问题管理
评估结果
用户满意度 需求实现情况
需求评估和反馈
用户反馈
收集意见 处理建议
需求调整
根据评估结果 改进软件质量
优化需求
提升功能性能
修复问题
解决软件缺陷
改进质量
提高用户体验
需求调整和改进
需求管理流程
软件需求管理包括需求库管理、项目需求管 理、需求优化和迭代、需求评估和反馈,通 过合理的管理流程确保软件开发顺利进行。
对收集的需求进行分析、整理、确认,确保需求的准确性和完整性
需求规格说明
将需求转化为具体的规格说明,明确软件的功能和性能要求
软件需求工程与其他工程的比较
软件需求工程
软件设计
软件测试
软件维护
侧重于对用户需求的收集和管 理 注重需求的准确性和用户体验 需求分析是关键步骤

软件工程导论第五版张海藩第03章-需求分析

软件工程导论第五版张海藩第03章-需求分析
第3章 需求分析
3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-联系图 (?) 3.5 数据规范化(?) 3.6 状态转换图+有穷状态机 3.7 其他图形工具 3.8 验证软件需求 3.9 小结
需Байду номын сангаас分析的意义
软件需求的深入理解是软件开发工作获得成 功的前提条件,不论我们把设计和编码做得如何 出色,不能真正满足用户需求的程序只会令用户 失望,给开发带来烦恼。
软件需求规格说明书,是需求分析阶段得出的最主要 的文档。
软件需求说明书的编写提示(GB856T—88)
1 引言 1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料
2 任务概述 2.1 目标 2.2 用户的特点 2.3 假定和约束
软件需求说明书的编写提示(GB856T—88)
3 需求规定
建模方法
在过去的数年中,人们提出了许多种分析建模的方法,其中两种 在分析建模领域占有主导地位:
第一种是结构化分析 (Structured Analysis,SA),70年代末由 DeMarco等人提出,这是传统的建模方法。该方法不是被所有的使用 者一致地使用的单一方法,众多科学家对其进行了扩充,因此它是发 展了超过30年的一个混合物。
2) 项目相关人员用自己的语言表达需求,这些 语言包含很多工作中的专业术语和专业知识。系统分 析员没有这些知识和经验,而他们又必须了解这些需 求。
3)不同的项目相关人员有不同的需求,可能以 不同的方式表达,分析人员必须发现所有潜在的需求 资源,而且能发现这些需求的相容或冲突之处。
4)经济和业务环境决定了分析是动态的,需求 在分析过程中会发生变更。个别需求的重要程度会改 变,新的需求会从新的项目相关人员那里得到。

第三章需求分析阶段

第三章需求分析阶段

P2.1
P2.2 P2.3 P3
添加
删除 课程 管理 统计
S02
S07 S04 S05
S04
F02
F02
添加新的成绩
IF S01要改动 DO P2.2 ENDIF 从S04读取各科成绩信息 根据F01进行课程分类管理 从F02读取数据,生成统计结果
S05 S07
空 F02
表3-4 数据处理定义表
实训3-2《图书馆书目查询管理系统》
实训3-1
编号 S1 S2 S3 S4 数据流名称 学生情况 学生分数 班级分类 各科成绩 说明 -
数据字典的设计与定义
数据流定义表如表3-1所示。
数据流组成 E02+E03+E04+E05+E06+E07 E01+E02+ E08+E09+E10 E01+E02+E03+E04+ E05+E06+E07+E08 E01+E09+E010
编号数据流名称说明数据流组成流通量备注s1学生情况s2学生分数e01e02e08e09e10s3班级分类e01e02e03e04e05e06e07e08s4各科成绩s5课程成绩s6查询结果s7统计表31数据流定义表实训31数据字典的设计与定义数据元素dataelement定义表数据流定义表如表32所示编号数据元素名称类型长度值域备注e01学生学号inte02学生姓名nchar20e03学生性别chare04出生日期smalldatetimee05家庭住址nchar50e06政治面貌nchar20e07联系电话char20e08所在班级nchar20e09课程名称nchar20e10课程成绩smallint0100表32数据流定义表实训31数据字典的设计与定义数据存储文件datastorefile定义表数据存储文件定义表如表33所示

L-第三章-软件工程课件需求分析

L-第三章-软件工程课件需求分析
6
教学要求
教学目的:了解需求分析的任务和步骤、评 审标准和过程;掌握基本技术,理解需求规 格说明书的作用与组成。 教学重点:基本技术、需求规格说明书的作 用与组成。 教学难点:基本技术。
7
需求分折简介
软件需求指用户对所开发的软件在功能、 性能、环境、可靠性等各方面的要求。
需求分析主要回答待开发的系统必须 “做什么”,并用 《 需求规格说明书 》 的 形式准确、详细、规范地表达出来。
8
注意
①需求分析阶段,系统分析员的主要关注点 是“做什么( what ) ” ,不是“怎样做 ( how)”; ②需求分析阶段,系统分析员应该给出软件 求规格书。
9
§3.1需求分析的任务
四项主要任务: 1 、确定对系统的综合要求 2 、分析系统的数据要求 3 、导出系统的逻辑模型 4 、修正系统开发计划
34
一、基本概念(2)
联系:客观事物之间的联系。联系分为三种: 一对一( 1 : 1 ) .班级和班长 一对多联系( 1 : N ) .班级和学生,系与教师,学生与宿舍 多对多联系( M : N ) 课程与学生,教师和课程,学生和学会 二、 E 一 R 图的结构 三种基本元素:
35
例:教学E-R图
46
注意的原则 ( 1 )
数据流图上所有图形符号只限于前述四种基本图 形元素; 数据流图的主图必须包括前述四种基本元素,缺 一不可; 数据流图的主图上的数据流必须封闭在外部实体 之间; 每个数据处理至少有一个输入数据流和一个输出 数据流; 在数据流图中,需按层给数据处理框编号。编号 表明该处理所处层次及上下层的亲子关系;
36

仓库,职工,零件和供应商的ER图
37
三、如何建立实体一联系图?

第03章 软件需求分析

第03章 软件需求分析

101 102 103 104
丁一 王二 张三 李四
车工 车工 钳工 电工
80 80 75 70
金工 金工 动力 动力
李明 李明 赵杰 赵杰
表3-3
W2关系数据库
表3-2 W1关系数据库
从上表的W2中的数据库看出仍存在严重缺点:数据冗余大,增 删改麻烦。采取第三范式来避免以上缺点。
※ 第三范式:满足第二范式的条件,每个非关键字属性都仅由关键 字决定,而且一个非关键字属性不能仅仅是对另一个非关键字属性的进 一步描述(即每一个非关键字的属性都不传递依赖于关键字)。 将上表的W2分解为如下的W21、W22、W23关系数据库。 工号 姓名 工种 车间
分析数据 流图
用户复查
细化数 据流图
不需分解
4、修正开发计划
我们讲过在可行性研究阶段,写出了一份开发计划。经过需求分 析阶段的工作,对系统的成本和进度有了更准确的估计之后,对开发 计划进行修正。 5、书写文档 根据需求分析阶段的基本任务,可以完成以下的文档资料。 (1)系统规格说明。主要描述目标系统的慨况、功能要求、性能要 求、运行要求和将来可能提出的要求。 (2)数据要求。主要包括数据字典、数据结构的层次方图或Warnier 图。 (3)用户系统描述(相当用户手册) 。从用户使用系统的角度描述 系统。包括系统功能和性能的描述、使用系统的主要步骤和方法、系 统的用户责任等。 (4)修正的开发计划。包括修正后的成本估计、资源使用计划、进度 计划等。
基本加工逻辑说明
对数据流图的每一个基本
加工,必须有一个基本加 工逻辑说明 基本加工逻辑说明必须描 述基本加工如何把输入数 据流变换为输出数据流的 加工规则
加工逻辑说明必须描述实
现加工的策略而不是实现 加工的细节 加工逻辑说明中包含的信 息应是充足的,完备的, 有用的,没有重复的多余 信息
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

2、用户复查 、 请用户对上一个分析步骤中得出结果仔细地进行复查。从输 请用户对上一个分析步骤中得出结果仔细地进行复查。 数据流图以及数据字典和简明的算法描述向用 入端开始,借助数据流图以及数据字典和简明的算法描述 入端开始,借助数据流图以及数据字典和简明的算法描述向用 户解释输入数据是怎样一步一步地转变成输出数据的。 户解释输入数据是怎样一步一步地转变成输出数据的。
即对数据进行哪些处理、 即对数据进行哪些处理、 每个处理的逻辑功能等
为了把用户的数据表达清楚,通常建立一个概念性的数 为了把用户的数据表达清楚, 据模型(也称信息模型)。 据模型(也称信息模型)。 概念性数据模型是一种面向问题的数据模型, 概念性数据模型是一种面向问题的数据模型,按照用户 是一种面向问题的数据模型 的观点来对数据和信息建模。 的观点来对数据和信息建模。它描述了从用户角度看到的数 反映用户的现实环境,与软件的实现方法无关。 据,反映用户的现实环境,与软件的实现方法无关。 概念性数据模型常用的方法是实体 联系的方法 概念性数据模型常用的方法是实体—联系的方法(也 实体 联系的方法( 模型)。是用ER图描述现实世界中的实体 模型)。是用 图描述现实世界中的实体。 称ER模型)。是用 图描述现实世界中的实体。
表3-1 需求规格说明书提纲
1、引言 、 1.1 目的 1.2 背景 1.3 定义 1.4 参考资料 2、项目概述 、 2.1 产品描述 2.2 产品功能 2.3 用户特点 2.4 一般约束 2.5 假设与依据 3.1.1.1 引言 3.1.1.2 输入 3.1.1.3 输出 3.1.1.4 加工 3.1.2 外部接口 3.1.2.1 用户接口 3.1.2.2 硬件接口 3.1.2.3 软件接口 3.1.2.4 通讯接口 3、具体需求 、 3.1 功能需求 3.1.1 规格说明 3.2 性能需求 3.2.1 数据精度 3.2.2 时间特性 3.2.3 适应性 3.3 设计约束 3.4 属性需求 3.4.1 安全性 3.4.2 可维护性 3.4.3 保密性 …… 附录 索引
二、分析过程
1、沿数据流图回溯 、
沿数据流图从输出端往输入端回溯,确定每个数据元素的来源, 沿数据流图从输出端往输入端回溯,确定每个数据元素的来源,同 时初步定义算法。在可行性研究阶段的高层数据流基础上, 时初步定义算法。在可行性研究阶段的高层数据流基础上,设计细节的数 据元素。 据元素。 通常把分析过程中得到的有关数据元素的信息记录在数据字典 数据字典中 通常把分析过程中得到的有关数据元素的信息记录在数据字典中,把 对算法的简明描述记录在IPO图中。 对算法的简明描述记录在 图 通过分析而补充的数据流、数据存储和处理, 通过分析而补充的数据流、数据存储和处理,应该添加到数据流图的 适当位置上。 适当位置上。
需求分析的具体任务之四) 4、修正系统开发计划(需求分析的具体任务之四) 、
在分析过程中对系统更深入更具体的了解, 在分析过程中对系统更深入更具体的了解,可以比较准 确地估计系统的成本和进度,修正以前制定的开发计划。 确地估计系统的成本和进度,修正以前制定的开发计划。 5、开发原型系统(样机模型) (需求分析的具体任务之五) 、开发原型系统(样机模型) 需求分析的具体任务之五) 在第一章我们讲过软件开发三种模型当中,有一种原型 在第一章我们讲过软件开发三种模型当中, 模型(也称样机模型)。在需求分析当中, )。在需求分析当中 模型(也称样机模型)。在需求分析当中,使用样机的主要 目的是: 目的是:使用户通过实践获得关于未来的系统将怎样为他们 工作的更直接更具体的概念, 工作的更直接更具体的概念,从而可以更准确地提出和解决 他们的要求。 他们的要求。
在分析过程中必须充分重视和使用数据流图、 在分析过程中必须充分重视和使用数据流图、数据字典和算法 描述工具。分析过程中产生的问题依靠用户来回答, 描述工具。分析过程中产生的问题依靠用户来回答,分析员对系统的 认识必须经过用户的检验和确认。最后必须完成正式的用户复查文档 认识必须经过用户的检验和确认。最后必须完成正式的用户复查文档 说明书。 3、细化数据流图 、 通过了用户复查以后,分析员就要把数据流图进行细化, 通过了用户复查以后,分析员就要把数据流图进行细化,通过功 能分解可以完成数据流图的细化。细化之后得到一组新的数据流图 数据流图。 能分解可以完成数据流图的细化。细化之后得到一组新的数据流图。 随着分析过程的进展,经过问题和解答的反复循环,分析员对目 随着分析过程的进展,经过问题和解答的反复循环, 标系统越来越清楚,最终得到对系统数据和功能要求的满意了解。 标系统越来越清楚,最终得到对系统数据和功能要求的满意了解。 概括了上述分析的过程。 图 3-1 概括了上述分析的过程。
1、ER模型 ER模型中包含“实体”、“联系”和“属性”等三个基本 成分。 存在的且可相互区分的事物 图中用矩形 (1)实体: 客观世界中存在的且可相互区分的事物。在ER图中用矩形 )实体: 客观世界中存在的且可相互区分的事物。 图中用
框代表。 代表。 图中用菱形框代表。 (2)联系:客观世界中的事物间的联系。在ER图中用菱形框代表。联 )联系:客观世界中的事物间的联系。 图中用菱形框代表 系又分三种: 系又分三种: ※一对一联系(1:1) 一对一联系( : ) 例如,一个部门一个经理,而每个经理只能在一个部门任职,则部 例如,一个部门一个经理,而每个经理只能在一个部门任职, 门与经理是一对一的联系。 门与经理是一对一的联系。 ※一对多联系(1:N) 一对多联系( : ) 例如,每个教师可教多门课程,但每门课程只能有一个教师来教, 例如,每个教师可教多门课程,但每门课程只能有一个教师来教, 则教师与课程是一对多的联系。 则教师与课程是一对多的联系。 ※多对多联系(M:N) 多对多联系( : ) 例如,一个学生可以上多门课程,而每门课程可以有多个学生来学, 例如,一个学生可以上多门课程,而每门课程可以有多个学生来学, 则学生与课程是多对多的联系。 则学生与课程是多对多的联系。
Final stage of Definition phase
ቤተ መጻሕፍቲ ባይዱ
一、需求分析的任务
需求分析是软件定义的最后一个阶段, 需求分析是软件定义的最后一个阶段,它的基本任务是 准确地回答“系统必须做什么? 准确地回答“系统必须做什么?” ,确定系统必须完成哪些 完整、 的要求。 工作,对目标系统提出完整 准确、清晰、具体的要求 工作,对目标系统提出完整、准确、清晰、具体的要求。 需求分析是从可行性研究阶段产生的文档和数据流图出 从数据流图中的基本功能出发, 发,从数据流图中的基本功能出发,仔细研究这些功能并进 一步将它们具体化。 一步将它们具体化。 需求分析阶段的具体任务: 需求分析阶段的具体任务:
4、修正开发计划
我们讲过在可行性研究阶段,写出了一份开发计划。 我们讲过在可行性研究阶段,写出了一份开发计划。经过需求分 析阶段的工作,对系统的成本和进度有了更准确的估计之后, 析阶段的工作,对系统的成本和进度有了更准确的估计之后,对开发 计划进行修正。 计划进行修正。 5、书写文档 、 根据需求分析阶段的基本任务,可以完成以下的文档资料。 根据需求分析阶段的基本任务,可以完成以下的文档资料。 (1)系统规格说明。主要描述目标系统的慨况、功能要求、性能要 )系统规格说明。主要描述目标系统的慨况、功能要求、 运行要求和将来可能提出的要求。 求、运行要求和将来可能提出的要求。 (2)数据要求。主要包括数据字典、数据结构的层次方图或 )数据要求。主要包括数据字典、数据结构的层次方图或Warnier 图。 (3)用户系统描述(相当用户手册) 。从用户使用系统的角度描述 )用户系统描述(相当用户手册) 系统。包括系统功能和性能的描述、使用系统的主要步骤和方法、 系统。包括系统功能和性能的描述、使用系统的主要步骤和方法、系 统的用户责任等。 统的用户责任等。 (4)修正的开发计划。包括修正后的成本估计、资源使用计划、进 )修正的开发计划。包括修正后的成本估计、资源使用计划、 度计划等。 度计划等。 6、审查和复审(技术审查和管理复审) 、审查和复审(技术审查和管理复审)
3、导出系统的逻辑模型(需求分析的具体任务之三) 、 需求分析的具体任务之三) 根据系统的综合要求和系统的数据要求的结果, 根据系统的综合要求和系统的数据要求的结果,导出 系统的详细的逻辑模型。通常用数据流图、数据字典和主 系统的详细的逻辑模型。通常用数据流图、 要的处理算法描述。 要的处理算法描述。
系统功能要求 系统性能要求
1、确定对系统的综合要求(包括)
可靠性要求、 可靠性要求、出错要 求、接口要求 将来可能提出的要求
2、分析系统的数据要求(需求分析的具体任务之二) 、 需求分析的具体任务之二)
软件需求分析的一个重要任务是分析系统的数据要求。 软件需求分析的一个重要任务是分析系统的数据要求。 通常采用建立概念模型的方法(具体方法在后二节讲解)。 概念模型的方法 通常采用建立概念模型的方法(具体方法在后二节讲解)。 复杂的数据由许多基本的数据元素组成, 复杂的数据由许多基本的数据元素组成,数据结构表示 数据元素之间的逻辑关系。 数据元素之间的逻辑关系。利用数据字典可以全面准确地定 义数据,但是不够形象直观 缺点)。为了提高可理解性, 不够形象直观( )。为了提高可理解性 义数据,但是不够形象直观(缺点)。为了提高可理解性, 常常利用图形工具(软件需求分析工具之一) 常常利用图形工具(软件需求分析工具之一)辅助描绘数据 结构。常用的图形工具有层次方框图和Warnier图(具体在 结构。常用的图形工具有层次方框图和 图 后二节讲解)。 后二节讲解)。 软件系统经常使用各种长期保存的信息, 软件系统经常使用各种长期保存的信息,这些信息通常 以一定的方式组织并存储在数据库或文件中, 以一定的方式组织并存储在数据库或文件中,为减少数据冗 需要简化修改数据的过程,通常需要把数据结构规范化。 余,需要简化修改数据的过程,通常需要把数据结构规范化。 具体在后二节讲解)。 (具体在后二节讲解)。
第三章 软件需求分析
相关文档
最新文档