1、第四章 软件需求分析,周立新 博士北京大学软件与微电子学院,课程提纲,软件需求基本理论和概念 软件需求工程过程 软件需求获取 软件需求分析 软件需求规格说明 软件需求验证 软件需求管理 软件需求实现 软件需求工程新进展 软件需求开发与需求管理工具,内容提要,需求分析面临的困难 需求分析基本方法和工具 数据需求分析 功能需求分析 非功能性需求分析 实时系统需求分析 基于USE CASE的需求分析 基于原型方法的分析,需求分析,分析是指通过对问题域的研究,获得对该领域特性及存在于其中的待解决的问题特性的透彻理解并用文档说明。 需求分析是前面需求获取阶段的继续，通过对所获取的信息进一步加工获得对系统
2、的更精确描述，成为转换成需求规格说明的直接信息元。 但是否将需求分析作为独立的过程？,需求分析的关键点,问题域的结构 问题域的数据 问题域的行为 问题域的事件 问题域的状态 派生需求,只是针对问题域吗？,一.需求分析面临的困难,需求分析是一个项目的开端，也是项目建设的基石。在失败的项目中，80是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。 由于软件项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又面临着很多困难。,二.需求分析基本方法和工具,图1 软件需求工程的组成,绘制关联图 创建用户界面和技术
3、原型 分析需求的可行性 确定需求的优先级 为需求建模 创建数据字典 将需求分解到子系统 应用质量功能调配,需求分析包括：,分析方法,结构化分析 面向对象分析,分析模型描述工具,结构化分析工具 DFD、DD和PSPEC CFD、CSPEC和STD E-R图 面向对象分析工具 用例图，类图，对象图 对象-关系图 对象-行为图,需求分析建模工具,数据流图 实体关系图 状态转换图 对话图 类图 Petri Net,建模技术,面向处理技术 Context diagram 上下文图 Data flow diagram (DFD) 数据流图 流程图 面向数据结构技术 E-R D - Entity Relat
4、ionship Diagrams 面向对象建模 处理和数据相结合 Object and Class 对象和类的技术,需求分析基本方法 结构化分析方法(SA),结构化分析（Structured Analysis,简称SA法）的基本思想：“分解”和“抽象”,分解：把系统的复杂性降低到可以掌握的程度，把大问题分解成若干小问题，然后分别解决。 抽象：即先考虑问题最本质的属性，暂把细节略去，以后再逐层添加细节，直至涉及到最详细的内容。,图4 自顶向下逐层分解,数据流图,数据流图DFD 描述系统逻辑模型 信息在系统中的流动和处理 用途 交流信息的工具 结构化分析和设计的工具,数据流图,数据流图DFD 组成
5、符号 圆框代表加工 箭头代表数据流向 方框代表源点和终点 双杠表示数据文件或数据库 分层 从高层到低层 分解前后的数据流必须一致 命名 数据流 处理,数据流图 DFD练习售书系统,图5 售书系统顶层数据流图,数据流图 DFD练习售书系统,功能需求分析 加工说明PSPEC,加工说明PSPEC 说明DFD中的每个加工 描述工具 结构化语言 判定表 判定树,处理方法：事件列表与功能列表,事件就是要求系统执行某项功能的请求 业务事件与产品事件 对复杂的业务任务采用任务说明、用例说明或数据流图等方法进行解释。 对复杂的功能采用数据流图、算法描述、活动图、数学说明等进行解释。,处理方法：事件列表与功能列表
6、,事件及功能列表的优点 主要作为核对清单，以说明应开发什么。其中对这些功能的详细说明构成了功能需求的主要部分。 开发人员可以方便的检查产品是否实现每一个功能。 用户能够在某种程度上确认业务事件和任务列表。 通过一致性检查确定列表是否完备。,数据需求分析 数据字典DD,DFD中所有元素的定义的集合 内容 数据流 数据流分量 数据存储 处理（一般不用DD描述） 定义数据的方法 自顶向下分解数据,数据需求分析 数据字典DD,数据元素的组合方式 顺序：A+B 选择：A|B 重复：1A5 可选： （A） DD的用途 分析阶段的交流工具 包含控制信息 数据库设计的基础,E-R图,用于对复杂数据的数据分析和
7、建模 实体、属性和关系 组成符号,0：1,1：1,0：m,1:m,E-R图例子,数据需求与功能需求的区别,数据需求指定了系统的存储数据。 功能需求则说明数据的用途，以及如何记录、计算、转换、修改及传输数据等。,数据需求与功能需求的区别：,状态迁移图 STD,STD (State Transition Diagram) 描述软件状态变迁 符号表示 矩形-系统状态 箭头-状态转变方向 规则表达式-事件/触发行为,状 态1,状 态2,事件/触发行为,状态迁移图 STD例子,上下文图,作用 上下文图能很好地概括产品的必要接口，初步确定产品包含了哪些内容，产品之外又包含哪些内容。即说明产品及其环境的视图
8、。 说明产品的范围。 优点： 上下文图为开发任务概括了所有的接口，在开发中或开发后，方便地验证是否已经处理了所有接口。 用户容易理解，并发现遗漏的接口。,对话图,对话图代表了一个高层抽象的用户界面体系结构。 对话图描绘了系统中的对话元素和它们之间的导航连接，但它没有揭示具体的屏幕设计。 对话图可以使你在对需求的理解上探索假设的用户界面概念。 用户和开发者可以通过对话图在用户如何利用系统执行任务上达成共同的视觉界面。 对话图与系统情节叙述相关联，这些叙述还包括对每一个屏幕意图的简短说明。 对话图抓住了用户一系统交互作用和任务流的本质，而不会使你太快陷入到屏幕布局和数据元素的特定细节中。用户可以通
9、过跟踪对话图寻找遗漏、错误或多余的转换，和因此而有遗漏、错误或多余的需求。 你可以把在需求分析过程中形成的对话图用作详细用户界面设计时的指南，最终形成一个执行的对话图，该对话图记录了产品的真正用户界面的体系结构。,对话图示例,非功能性需求分析,所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。 非功能性需求涉及的范围很广，软件产品本身不是孤立存在的，还涉及到诸多外在环境的影响。 非功能性需求必须考虑软件既要可用，又要易用。,实时系统需求分析,实时系统广泛应用在航天、航空、
10、通信、国防等领域。实时系统以计算机技术为基础、以应用为目的、将软件和硬件紧密结合在一起，实现特定功能的系统。 与通用系统相比，实时系统具有一些显著的特点： 实时性 可靠性 可预测性,实时系统需求分析,基于实时系统的特点，在开发一个复杂的实时系统时，一个充分再现系统特性的建模工具至关重要，对于系统分析、设计、实现、成本控制、可重用都具有重要的意义。 可选用UML-RT工具进行实时系统的需求分析。 UML-RT是利用通用建模语言UML的扩展机制并借鉴实时的面向对象的方法ROOM（Real-time Object-Oriented Modeling）的优点发展而来。,实时系统需求分析,UML-RT用
11、协作图表示特定环境下类之间的关系。 UML-RT有两种结构元素：模型结构和模型行为。 模型结构： 封装体 端口 连接器 模型行为： 协议 状态机 定时服务,Petri Net (Activity Diagram),Elements Position Transition Transition arc Marking,Petri Net,行为(功能)建模,FSM有限状态机 - 通过输入输出之间的因果关系对系统的行为进行建模 系统可看作有若干个相互区别的稳定状态 外部刺激使系统从当前某个状态改变到另一个状态 状态转移图State Transition Diagram 状态图State Chart
12、Diagram Specification and description language (SDL)规范与描述语言 Petri Net,基于USE CASE的需求分析 用例图,用例：系统和外部角色的交互 符号表示：,基于USE CASE的需求分析 Use Case图例子,基于USE CASE的需求分析 用例之间的关系,扩展关系使用关系组合关系,类图,面向对象需求分析,因为人类自然地趋向于用“对象”的观点或“方法”来认识问题，分析问题以及解决问题，用基于“对象”的概念模型来建立问题域模型自然成为系统分析员与用户交流的有效工具。 用面向对象的方法进行需求分析，其根本要点在于，利用“对象“的概念
13、模型建立一个针对于问题域的模型，用户和软件工程师通过该模型进行交流。通过在这么一个基于“对象“的问题域模型的基础上形成需求规格说明书。,面向对象需求分析 - 步骤,通过查看相关资料并与用户广泛地接触，自己对问题域有一个大致的了解。在这个基础上，将问题域中与系统和问题有关的对象提取出来。这就是标识对象的工作。 将第一步中抽象出来的对象(类)的之间的关系考虑清楚；如整体与部分、从属关系等； 为“类”提取与系统问题域有关的属性、服务等； 由于要完成一项任务，肯定是有不同的对象互相协作完成的。同时一个对象的属性、服务也是在与相关对象的协作中体现出来的。将问题域中所有任务的对象的协作关系搞清楚，是面向对
14、象需求分析的关键一环。即将问题域中的“剧情”搞清楚，是需求分析的主要工作之一。,面向对象需求分析,以上四步并不是单独的而是互有联系，可以同时进行的。通过，对以上4步工作的反复执行我们就可以建立一个基于对象的问题域的模型。 在该模型的基础上，可以比较容易地产生一个符合用户需求的软件需求规格说明书成为后续工作的基础。,基于原型方法的分析,软件原型是所提议的新产品的部分实现或可能的实现，使用原型有3个主要目的： 明确并完善需求 研究设计选择方案 发展为最终产品 原型法就是不断地运行系统“原型”来进行启发、揭示、判断、修改和完善的系统开发方法。,基于原型方法的分析,对原型的基本要求包括： 体现主要的功
15、能； 提供基本的界面风格； 展示比较模糊的部分以便于确认或进一步明确； 原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。,原型方法的一般过程,基于原型方法的分析,原型可以分为三类： 淘汰(抛弃)式(disposable)：目的达到即被抛弃，原型不作为最终产品。 演化式(evolutionary)：系统的形成和发展是逐步完成的，它是高度动态迭代和高度动态的循环，每次迭代都要对系统重新进行规格说明、重新设计、重新实现和重新评价，所以是对付变化最为有效的方法。 增量式(incremental)：系统是一次一段地增量构造，与演化式原型的最大区别在于增量式开发是在软件总体设计基础上进行的。
16、很显然，其应付变化的能力比演化式差。,基于原型方法的分析 淘汰式原型,利用废弃原型从用例到用户界面设计的活动序列：,Risk Reduction Through Prototyping 通过原型减小风险,原型开发与需求获取 原型开发与需求分析 原型开发与需求规范文档 原型开发与需求验证 原型开发与需求风险管理,使用质量功能部署,质量功能部署(QFD)是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确哪些是客户最关注的特性。QFD将需求分为三类：期望需求，即客户或许并未提及，但若缺少会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若
17、未实现也不会受到责备。,QFD示例,如果你有足够的资源来完成你和你的客户所想做的全部需求，那再好不过了。 但在快速变化的市场环境中，这是不现实的！,设定需求优先级,多种设定需求优先级的规则,设定需求优先级,3GPP Mandatory (M) If a requirement or a message is marked as M, it must be implemented Conditional (C) If a requirement or a message is marked as C, it will be implemented conditionally Optional (
18、O) If a requirement or a message is marked as O, it can be or may not be implemented,设定需求优先级,Covey 1989 High priority requirements are both important (the user needs the capability) and urgent (the user needs it in the next release Medium priority requirements are important (the user needs the capab
19、ility) but not urgent (they can wait for a later release). Low priority requirements are not important and not urgent Urgent but not important, They dont add sufficient value to the product,设定需求优先级,Suggestions 需求获取期间就关注需求优先级的问题 基于Use case标注优先级 基于Scenario标注优先级，尤其对例外的处理。有些例外会对系统产生根本影响如system crash，有些只是轻微的。例外很难穷举，但配以优先级就容易裁决 建立模型可以发现哪个功能更重要，排定优先级 优先级并非在整个开发过程中一成不变的 需求管理方面的问题 可以使用电子表单、表格或矩阵来估计和维护一个功能或USE CASE的优先级,
