第4章_需求分析课件

《第4章_需求分析课件》由会员分享，可在线阅读，更多相关《第4章_需求分析课件（86页珍藏版）》请在金锄头文库上搜索。

1、第四章,4,需求分析,4.1 需求分析概述,需求分析是软件定义时期的最后一个阶段，它的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。并在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。即： - 准确地回答“系统必须做什么?”,在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用。,需求分析的基本概念,1.什么是软件需求分析？ 2.软件需求分析的任务是什么？ 3.需求分析过程/步骤 4.软件需求分析方法 对系统应该提供的服务和所受到的约束进行理解、分

2、析、建立文档、检验的过程； 是系统分析人员和用户共同协商，明确系统的全部功能、性能以及运行规格，并且使用软件开发人员和用户都能理解的语言准确表达出来。,4.1.1 软件需求的重要性,软件需求无疑是当前软件工程中的关键问题，没有需求就没有软件。因而，需求分析是软件开发的基础，所产生的需求规格说明书是以后各阶段开发工作的依据。,美国于1995年开始对全国范围内的8000个软件项目进行跟踪调查。,分析失败的原因发现，与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。,未完成,完成未实施,完成,需求分析的重要性 软件开发的基础和前提 最终目标

3、软件系统验收的标准 避免或者尽早剔除早期的错误,4.1.2 需求分析的困难,软件需求是软件工程中最复杂的过程之一： 应用领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。 非功能性需求建模技术的缺乏，及其与功能性需求有着错综复杂的联系，大大增加了需求工程的复杂性。 沟通上的困难，由于系统分析员、需求分析员等各方面人员有不同的着眼点和不同的知识背景，给需求工程的实施增加了人为的难度。,需求分析的复杂性和面临的困难 片面, 不完全 模糊, 不准确 不一致, 歧义 需求复杂和庞大 因此必须使用系统的方法、借助于一系列行之有效的技术和工具进行软件需求分析,需求内容一般包括：,功能需求 性能需求

4、环境需求 可靠性需求 安全保密要求 用户界面需求,资源使用需求 成本消耗需求 开发进度需求 预先估计以后系统可能达到的目标,软 件需 求,软件需求的内容,软件需求内容,功能需求 它是对系统应该提供的服务、功能以及系统 在特定条件下的行为的描述。它与软件系统的类 型、使用系统的用户等相关，有时需要详细描述 系统的功能、输入/输出、异常等，有时还需要申 明系统不应该做什么。,领域需求 是由软件系统的应用领域所决定的特有的功 能需求，或是对功能的约束。,4.1.3 需求分析的任务,需求分析的任务 通过对应用问题及其环境的理解和分析，准确、一致和完全地刻划用户需求，形成软件需求规格说明书( SRS:

5、Software Requirement Specification )。 借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。,需求分析阶段(需求分析过程)的基本活动 获取和理解用户需求。深入实际，在充分理解用户需求的基础上，获取系统需求。 描述和分析用户需求。进行需求建模、对模型或原型进行分析。 对用户需求进行评审。确认需求，进化需求。确保需求说明准确、完整地表达系统的主要特性，且客户的需要总是不断（连续）增长的 ，进化需求是必要的。,需求分析过程示意图,步骤1:获取和理解用户需求阶段,任务 获取并理解用户需求, 清除用户需求的不一致性, 模糊性和歧义性，帮

6、助用户发现潜在的需求 原则 和用户进行交流和合作 将对原始问题理解与软件开发经验结合,步骤2:描述和分析用户需求阶段,任务 对用户需求进行建模，生成SRS和初步用户手册 SRS : 用户需求(功能, 行为, 性能等) 用户手册:如何操作和使用目标软件，界面描述和使用初步构想，目的 原则 确保SRS的完整性、一致性和准确性 鼓励用户参与SRS以及用户手册的制定 尽可能做到SRS结构清晰，措辞准确和简洁,步骤3:对用户需求进行评审,任务 多方人员一起对SRS进行复核和评审，以确保用户手册和SRS全面、准确、一致地反映用户需求 原则 支持各方（用户，需求分析人员、设计人员）共同参与评审工作,需求获取

7、(requirements elicitation) 是需求工程的主体。,缺乏领域知识,应用领域的问题常常是模糊的、不精确的； 存在默认的知识,如难以描述的常识问题； 存在多个知识源,且多知识源之间可能有冲突； 客户可能的偏见，如不能提供或不想告知你所需要了解的事情。,非常困难，主要原因有：,获取需求的方法,访谈 面向数据流自顶向下求精 简易的应用规格说明技术 快速建立软件原型,(1). 访 谈,正式的访谈 - 系统分析员将提出一些事先准备好的具体问题。 非正式的访谈 - 分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。 当需要调查大量人员的意见时，向被调查人分发

8、调查表是一个十分有效的做法。 在访问用户的过程中使用情景分析技术往往非常有效。,所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。,情景分析技术的用处主要体现在下述两个方面： (1) 它能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。 (2) 由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。需求分析的目标是获知用户的真实需求，而这一信息的惟一来源是用户，因此，让用户起积极主动的作用对需求分析工作获得成功是至关重要的。,(2). 面向数据流自顶向下求精,数据决定了需要

9、的处理和算法，它是需求分析的出发点。 可行性研究阶段产生的是高层数据流图，许多具体的细节没有包括，许多实际的数据元素被忽略，当时分析员还不需要考虑这些细节，现在是定义这些数据元素的时候了。,自顶向下求精过程,有办法吗？ 有！ Go Next !,问题：,使用传统的访谈或面向数据流自顶向下求精方法定义需求时，用户处于被动地位而且往往有意无意地与开发者区分“彼此”。由于不能像同一个团队的人那样齐心协力地识别和精化需求，这两种方法的效果有时并不理想。,这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。,(3). 简易的应用规格说明技术 - 一种面向团队的需

10、求收集法,使用简易的应用规格说明技术分析需求的典型过程,1. 初步的访谈，通过用户对基本问题的回答，初步确定待解决的问题的范围和解决方案。 2. 开发者和用户分别写出“产品需求”。 3. 开发者和用户开会讨论，共同创建一张意见一致的组合列表。 4. 把与会者分成更小的小组，每个小组的工作目标是为每张列表中的项目制定小型规格说明。小型规格说明是对列表中包含的单词或短语的准确说明。 5. 每个小组向全体与会者展示他们制定的小型规格说明，讨论，以创建出意见一致的确认标准。 6. 由一名或多名与会者根据会议成果起草完整的软件需求规格说明书。,(4). 快速建立软件原型,正如第2章已经讲过的，快速原型就

11、是快速建立起来的旨在演示目标系统主要功能的可运行的程序。 快速建立软件原型是最准确、最有效、最强大的需求分析技术。 快速原型应具备的特性是“快速”、“容易修改”。,快速构建和修改原型，通常使用下述3种方法和工具：,第四代技术 (2) 可重用的软件构件 (3) 形式化规格说明和原型环境,因此系统应该具备以下功能： 基本数据维护功能 基本业务功能 数据库管理功能 信息查询功能,例1：有一个大学图书管理系统，该系统除了一般的图书管理功能外，还能够为学生和教工从其他图书馆借阅图书和文献资料提供服务。,1. 功能需求 基本数据维护功能： 提供使用者录入，修改并进行维护基本数据的途径。基本数据包括读者的信

12、息、图书资料的相关信息，可以对这些信息进行修改，更新。 基本业务功能： 读者借、还书籍的登记管理功能，随时根据读者借、还书籍的情况更新数据库系统，如果书籍已经借出，可以进行预留操作，书籍的编目、入库、更新等操作。,数据库管理功能： 对所有图书信息及读者信息进行统一管理维护的功能，对书籍的借还也要进行详细的登记，以便协调整个图书馆的运作。 信息查询功能： 提供对各类信息的查询功能，如对本图书馆的用户借书信息，还书的信息，书籍源信息，预留信息等进行查询，对其他图书馆的书籍、资料源信息的查询功能。,2.非功能需求 系统安全性需求：为保证系统安全性，对本图书馆的各项功能进行分级、分权限操作，对各类用户

13、进行确认。对其它图书馆借阅图书和文献资料服务控制访问范围：如限IP、限用户等。 对系统可用性的需求：为了方便使用者，要求对所有交互操作提供在线帮助功能。 对系统查询速度的需求：要求系统在20S之内响应查询服务请求。 对系统可靠性的需求：要求系统失败发生率小于1%。,3. 领域需求 例如：对“大学图书管理系统”，提出一些与图书管理的业务相关的需求： 图书编目要求按照中国图书馆分类法进行； 由于版权限制，某些文献资料只能在图书馆规定的阅览室阅读，并限制复制和打印。 第一条需求是对遵循我国图书管理的规定，执行对图书的分类管理的标准。而第二条需求则是版权法对图书馆文献资料的保护的需要，描述了对一类文献

14、资料有限制的使用和服务。,4.1.4 需求分析的方法,功能解析法 结构化分析法 信息建模法 面向对象分析法,功能解析法 将一个系统堪称由若干功能构成的集合，每个功能又可划分成若干个加工（即子功能），一个加工又进一步可分解成若干个子加工 功能分解法由功能、子加工和功能接口三要素组成 本质是用过程抽象的观点看待系统需求,结构化分析法 一种从问题空间到某种表示的映射方法 由数据流图和数据字典组成 适用于数据处理领域的问题,信息建模法 从数据角度对现实世界进行建模 基本工具是E-R图，由实体、属性和联系三个基本要素组成 E-R图中，数据不封闭，没有继承性和消息传递机制,面向对象分析法 是把E-R图中的

15、概念与面向对象程序设计语言中的主要概念结合起来形成的一种分析方法 既采用实体、属性、关系等信息建模方法中的概念，又采用了封闭、类结构和继承性等面向对象程序设计语言中的概念,4.2 结构化分析法,一种面向数据流的传统软件开发方法 以数据流为中心构建软件的分析模型和设计模型 分为： 结构化分析(Structured Analysis 简称SA) 结构化设计(Structured Design 简称SD) 结构化程序设计(Structured Programming 简称SP),4.2.1 结构化分析（SA）概述,1. 自顶向下逐层分解的分析策略 基本思想：抽象与自顶向下的逐层分解(控制复杂性的两个

16、基本手段) 抽象：在每个抽象层次上忽略问题的内部复杂性，只关注整个问题与外界的联系 分解：将问题不断分解为较小的问题，直到每个最底层的问题都足够简单为止,结构化分析方法中的抽象与分解,抽象：从作为整体的软件系统开始(顶层),每一抽象层次上只关注于系统的输入输出 分解：将系统不断分解为子系统、模块 随着分解层次的增加，抽象的级别越来越低，也越接近问题的解(算法和数据结构),结构化分析过程,理解当前的现实环境，获得当前系统的具体模型(物理模型) 从当前系统的具体模型抽象出当前系统的逻辑模型 分析目标系统与当前系统逻辑上的差别，建立目标系统的逻辑模型 为目标系统的逻辑模型作补充,2. 结构化分析工具 数据流图（Data Flow Diagram, DFD）。用于描述系统分解，即描述系统由哪些部分组成，各部分间有什么联系等 数据字典（Data Dictionary, DD）。用于定义数据流图中的数据和加工。 加工规格描述（Process Specification, PS）