当前位置:
文档之家› 一步步教你如何写需求分析PPT课件
一步步教你如何写需求分析PPT课件
有一个
更直接、更具体的概念,从而能更准确提 出用户需求。(关键的困难在于成本)
.
编制需求分析文档:《需求规格说明书》
任务概述:系统目标,运行环境,条件与限 制
数据描述:
概念模型:E-R图 逻辑模型:数据流图 数据定义:数据字典,加工说明 数据库描述:名称和类型
.
3.2 与用户沟通获取需求的方法
1 访谈
访谈有两种基本形式,分别是正式的和非 正式的访谈。
当需要调查大量人员的意见时,向被调查 人分发调查表是一个十分有效的做法。
在访问用户的过程中使用情景分析技术往 往非常有效。
.
某出版社系统调查表
编号 1 2 3 4 5 6
7 8 9 10 11
提出问题 您在哪个部门工作? 出版业务流程是什么? 您每日都处理那些文件、数据、报表? 工作中手工处理特别麻烦的事情是什么? 工作中手工处理什么问题解决不了?影响效率的问题有哪些? 您认为提高工作效率,节省工作时间,减轻工作强度可采取哪些 办法? 您的部门需要成本核算和统计的内容有哪些? 您的部门采用计算机管理工作情况如何? 如何改进业务流程使之更合理? 哪些问题是目前传统手工方法根本无法解决的? 出版社计算机管理信息系统需要解决什么问题?
确定对系统的综合要求:
1.功能需求:必须完成的所有功能。 2. 性能需求:必须满足的定时约束或容量约
束,通常包括速度(响应时间)、磁盘容量、安 全性等方面的需求。 3. 可靠性和可用性需求:量化了用户可以使 用系统的程度。 4. 出错处理需求:这类需求说明系统对环境 错误应该怎样响应。
.
确定对系统的综合要求:
管理复审:在软件生命周期的每个重要的里 程碑(一般是每个阶段计划、需求分析、设 计、编码、维护)对工程项目的成本、实际 花费、投资回报的前景等从管理的角度进行 审查。
技术审查:在软件生命周期的每个阶段进行 正式而严格的技术审查,尽量发现隐藏的错 误。正式技术评审是软件工程实践者实施的 一项软件质量保证活动。
功能描述:软件功能要求 性能描述:软件性能要求(处理速度、响应
时间、安全限制等)。
.
编制需求分析文档:《需求规格说明书》 (续)
运行描述:用户界面、硬件接口、软件接口、 故障处理等。
质量保证:阐明软件在交付使用前需要进行 的功能测试和性能测试,并且规定源程序和 文档遵守的各种标准。
.
技术审查和管理复审
要建立分析所需要的通信途径,以保证能 顺利地对问题进行分析。
.
用于需求分析的结构话分析方法必须遵守 的准则:
理解并描述问题的信息域,建立数据模型 定义软件必须完成的功能,建立功能模型 描述作为外部事件结果的软件行为,建立行为
模型 对三个模型进行分解,用层次的方法展示细节
.
3.1 需求分析的任务:
5. 接口需求:接口需求描述应用系统与它的环境 通信的格式。常见的接口需求有:用户接口需求; 硬件接口需求;软件接口需求;通信接口需求。
6. 约束:说明用户或环境强加给项目的限制条件。 常见的约束有:精度;工具和语言约束;设计约 束;应该使用的标准;应该使用的硬件平台。
7. 逆向需求:逆向需求说明软件系统不应该做什 么。
.
需求分析的原则
必须能够表达和理解问题的数据域和功能域
数据域:数据流,数据内容和数据结构。 功能域:加工变换。
必须按自顶向下,逐层分解的方式对问题进行 分解和不断细化。
要给出系统的逻辑视图和物理视图。
逻辑视图:给出软件要达到的功能和要处理的数据之 间的关系。
物理视图:给出处理功能和数据结构的实际表示形式。
复杂的数据由许多基本的数据元素组成, 数据结构表示数据元素之间的逻辑关系。 利用数据字典全面的定义数据。利用图 形工具辅助描绘数据结构。
.
从数据流和数据结构出发,逐步细化软件 功能,找出各元素之间的联系,接口特性 和设计上的限制,给出目标系统的详细逻 辑模型。
.
导出系统的逻辑模型:
数据流图 实体-联系图 状态转换图 数据字典 加工处理说明书等
.
需求分析是软件定义时期的最后一个阶段, 它的基本任务是准确地回答“系统必须做什 么?”这个问题。对目标系统提出完整、准确、 清晰、具体的要求。
在需求分析阶段结束之前,系统分析员应该 写出软件需求规格说明书,以书面形式准确 地描述软件需求。
.
在需求分析的过程中,分析员和用户都起 着关键的、必不可少的作用。
8. 将来可能提出的要求:列出那些虽然不属于当 前系统开发范畴,但是据分析将来很可能会提出 来的要求。
.
分析系统的数据要求
软件系统本质上都是信息处理系统,因 此,必须分析系统的数据要求,这是软 件需求分析的一个重要任务。分析系统 的数据要求通常采用建立数据模型的方 法:实体——联系图( E-R图)。
第三章 需求分析
.
第三章 需求分析
3.1 需求分析的任务及需求分析的过程 3.2 与用户沟通获取需求的方法 3.3 数据流图 3.4 实体-联系图 3.5 状态转换图 3.6 其他图形工具 3.7 验证软件需求
.
为了开发出真正满足用户需求的软件产 品,首先必须知道用户的需求。对软件需 求的深入理解是软件开发工作获得成功的 前提和关键,不论我们把设计和编码工作 做得如何出色,不能真正满足用户需求的 程序只会给用户带来失望,给开发者带来 烦恼。
.
评审的主要内容
系统定义的目标是否与用户的要求一致; 系统需求分析阶段提供的文档资料是否齐全; 文档中的所有描述是否完整、清晰、准确反映用户要求; 与所有其它系统成分的重要接口是否都已经描述; 被开发项目的数据流与数据结构是否足够,确定; 所有图表是否清楚,在不补充说明时能否理解; 主要功能是否已包括在规定的软件范围之内,是否都已充分说明; 软件的行为和它必须处理的信息、必须完成的功能是否一致; 设计的约束条件或限制条件是否符合实际; 是否考虑了开发的技术风险; 是否考虑过软件需求的其它方案; 是否考虑过将来可能会提出的软件需求; 是否详细制定了检验标准,它们能否对系统定义是否成功进行确认; 有没有遗漏,重复或不一致的地方; 用户是否审查了初步的用户手册或原型; 软件开发计划中的估算是否受到了影响。