软件工程基础(胡思康)第2章课件.pptxVIP

S;S;实际项目经验表明：用户自身对将要开发的系统也并不是完全理解，对需求目标的陈述带有主观片面性、模糊性、不一致性，甚至还会出现错误；用户不会把需求按照功能、性能、行为、约束等特性对需求分门别类。;只有运用系统的方法学，并借助需求分析提供的方法和工具，才能把软件系统功能、性能的总体陈述转化为具体的软件需求规格说明，奠定软件开发的基础。;软件需求实际上就是准确回答“系统必须做什么”的问题。这一阶段还不能确定系统如何实现，而是确定系统必须完成的任务是什么，用户操作流程是什么顺序，系统约束条件如何规定。;;;;;;;;;;;需求分析的内容;描述系统提供的服务和在特定条件下的行为。包括系统登录、输入、响应、输出、异常等，有时还需要特别说明系统不应该做什么。通过需求分析，划分出系统必须完成的所有功能。 完整性（尽量得到所有用户提出的服务）和一致性（功能需求不能有相互矛盾之处）。;“简历信息自动获取系统” 基本业务功能 用户管理功能 数据管理功能;规定了软件必须满足的时间上或空间上的约束，通常包括系统响应时间、主存容量、存储容量、安全性、压力等方面的需求。 “简历信息自动获取系统” 提取简历信息准确性的要求 对系统安全性的要求 对系统可靠性的要求 ;具体应用范围。 “简历信息自动获取系统” 简历文本内容符合一般简历的要求，包括姓名、年龄、专业等必要信息，否则该简历文本会被系统自动放弃。 ;与软件系统有关的外在约束，如法律需求、道德需求、外部数据交换需求、预期需求等。 “简历信息自动获取系统” 随着互联网文件格式标准和企业发展的需要，对以XML格式或企业提供的简历模版编写的简历，系统预期将要能自动获取信息。 ;S;需求工程中的参与人员;需求工程过程是一个可行性研究、需求获取、需求分析与建模、需求评审的迭代过程。 可行性研究：最初的计划阶段---确定问题是否能够解决。其目的不是确定问题如何去解决，而是确定问题是否值得去解（技术可行性、操作可行性、经济可行性、法律可行性）。;需求工程过程是一个可行性研究、需求获取、需求分析与建模、需求评审的迭代过程。 需求获取：通过获取技术（对系统领域知识有一定了解的前提下），得到用自然语言描述的问题陈述和功能陈述。;需求工程过程是一个可行性研究、需求获取、需求分析与建模、需求评审的迭代过程。 需求分析与建模：以需求获取文档为基础，逐步细化需求中的软件功能，找出系统各元素间的依赖和调用关系、接口特性和设计上的性能约束。之后用软件开发方法提供的图形工具，用形式化或半形式化的定义来描述初步需求。将目标系统的物理模型转换为详细的逻辑模型，形成最终的软件需求规格说明书和初步的用户手册。;需求工程过程是一个可行性研究、需求获取、需求分析与建模、需求评审的迭代过程。 需求评审：进行技术审查和管理复审，再次确保所采纳的技术方案在技术上是可行的，在操作上是符合用户习惯的，在经济上是有效的，在法律上是合法的。;需求工程的迭代模型;需求工程的管理——贯穿整个需求工程的全过程。在需求工程管理过程中存在两大难题：一是需求确认困难；二是需求不断变更。 ;对传统的需求变更管理过程来说，主要包括软件配置、软件基线和变更审查。 软件配置的目的是确保所做的工作是可回朔的，能够恢复原来工作的文档、代码等内容，也能跟踪目前工作结果的来龙去脉。需要进行软件配置的内容称为软件配置项，主要有两类：一是属于产品自身需要的内容，如开发文档、代码、数据等；二是为软件产品服务的内容，如进度计划、人员安排、报告等。;对传统的需求变更管理过程来说，主要包括软件配置、软件基线和变更审查。 软件基线由一组软件配置项组成。当软件配置项处于稳定状态后（如需求文档经过评审以后），就确定了这组软件配置项的基线。在后续的开发过程中，软件配置项发生变更，则这一变更须通过变更审查并确定，变更才能记录在软件配置项中，并通知与之有关的人员。;需求获取是需求分析的前提，没有完整、正确的获取用户需求，就不能保证软件产品质量。因此，软件人员与用户交流需要好的方法，以便能达成共识。 ;需求工程的管理—需求变更;S;个别会谈：会谈的双方是分析员、用户以及系统领域专家。用户提供对系统功能、性能等方面的需求；领域专家提供系统背景知识、领域需求等方面的知识。在这个过程中，分析员学习和掌握系统背景知识，保证需求获取的正确性。;小组会议：对于系统的不同用户，由于操作流程的不同，使用功能的不同，对软件运行环境要求的不同，他们对系统的需求也不尽相同。小组会议保证各方需求获取的完整性、一致性。;谈话提纲 用户背景 系统背景 维护;分析员给用户提供规范的问卷表，帮助用户明晰问题的主旨。 P40 表2-1;分析员实际观察用户的手工操作过程，体验用户在工作中所遇到的不便和困难。 用户环境就是将来系统运行的场景，用户