1、需求工程12345软件需求概述软件需求工程过程软件需求捕获技术软件需求分析与建模软件需求变更管理CONTENT软件需求作为软件生命周期的前期阶段，其重要性越来越突出，到20世纪80年代中期到90年代，逐步形成了软件工程的子领域需求工程。90年代后，需求工程成为软件界研究的重点之一。从1993年起，每两年举办一次需求工程国际研讨会（ISRE），1994年起，每两年举办一次需求工程国际会议（ICRE）。一些关于需求工程的工作小组相继成立，使需求工程的研究得到了迅速进展。软件需求的基本概念 确定系统将要实现的各项要求 数据分析 定义逻辑模型 适应需求变更需求分析的任务软件需求的基本概念 软件人员要从
2、用户角度考虑软件需求 以流程为主线 尽量重用软部件 划分需求的优先级 需求变更要及时反馈需求分析的原则软件需求的内容软件需求功能需求数据*用户操作性能需求时间空间安全性领域需求其它需求法律需求道德需求预期需求12345软件需求概述软件需求工程过程软件需求捕获技术软件需求分析与建模软件需求变更管理CONTENT需求工程把所有与需求直接相关的活动通称为需求工程。需求开发过程域 需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生用户需求说明书。需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“
3、问答分析法”和“建模分析法”两类。需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计工作。需求管理过程域 需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的
4、变更，防止需求变更失去控制而导致项目发生混乱。需求工程的过程需求工程中的参与人员需求工程的过程需求工程过程中的活动 需求获取 需求分析与建模 需求评审 需求变更与迭代需求工程的迭代模型需求工程的过程可行性分析技术/成本分析需求获取需求分析需求验证需求变更基线需求管理基线(Baseline)基线的概念来自于软件的配置管理。基线是软件生存期中各开发阶段末尾的特定点，又称里程碑。由正式的技术评审而得到的软件配置项协议和软件配置的正式文本才能成为基线。基线的作用是把各阶段工作的划分更加明确化，以便于检验和肯定阶段成果。（如：事务与回滚）软件开发各阶段的基线需求工程的过程贯穿整个需求工程的全过程。在需求
5、工程管理过程中存在两大难题：一是需求确认困难；二是需求不断变更。需求确认的目的是为了：软件需求规格说明书正确描述系统功能和特征；通过可行性分析论证、需求获取和需求分析过程，能正确得到用户需求；需求内容满足一致性、完整性、正确性、可修改性和可验证性；需求为后续系统设计、实现、验收测试提供充分的准备。需求工程的过程需求变更开发前的需求变更 成本较低开发开始后的需求变更 成本较高需求工程的过程基本的需求变更管理过程变更描述变更分析变更修改申请需求变更确认后的需求变更确认12345软件需求概述软件需求工程过程软件需求捕获技术软件需求分析与建模软件需求变更管理CONTENT需求获取技术需求获取是需求分析
6、的前提，没有完整、正确的获取用户需求，就不能保证软件产品质量。因此，软件人员与用户交流需要好的方法，以便能达成共识。个别会谈和小组会议 问卷调查 面向用例的场景分析 快速原型法需求捕获的基本步骤1.确定涉众（Stakeholder）和用户类型（命名、简要描述、涉众代表、特征、能力）；2.确定涉众代表（命名、简要描述、责任、参与）；3.在项目中加入涉众代表（访谈、问卷、顾问、评审、角色扮演）；4.创建共同的构想（问题定义、系统范围、用户目标、非功能需求前景文档）；5.采用传统的需求捕获技术捕获需求；6.组建需求分析队伍（少量、有问题域知识）。需求捕获：人的重要性需求正确与否，决定着今后的一切活动
7、是否有价值捕获需求这个过程只能够发生在人和人之间，任何标注符号如UML，都不会在捕获需求方面提供任何帮助。UML只是一种记录需求的工具需求分析人员的主要任务：探索需求需求发现（捕获）就是一切开发是把人们的期望转化成一种能够满足其期望的产品的过程。“计划本身什么都不是，而编制计划的过程就是一切”。-艾森豪威尔产品什么都不是，而开发的过程就是一切。发现什么都不是，而发现过程（探索过程）就是一切。探索需求的定义一个过程一个发现的过程一个试图发现的过程一个试图发现期望的过程一个试图发现对新产品的期望的过程一个试图发现人们对新产品的期望的过程帮助客户产生真正的需求客户不知道自己想要什么 如果客户并不了解
8、他们的需求是什么，就会常常看到他们反复无常。可以通过问问题来使事情更加精确。客户不知道自己的需求是否可行 成本可行：告诉客户，我们能满足他们的需求，但是这需要成本。如果你没有告诉他们所需的成本，他们当然不会知道那些需求是不切实际的。技术可行：软件工程师只能根据目前可行的技术水平（或本团队可以达到的技术水平）确定用户的需求是否可实现。司机（客户）和汽车（软件开发团队）司机决定汽车应该往哪个方向开，开多快。客户确定需求的变化。汽车需要向司机提供方向盘，速度，发动机转速，温度等汽车运行状况信息。软件开发团队需要向客户提供开发进度情况。汽车离不开司机：不能总是处于自动驾驶（巡航）状态，即使看上去很顺利
9、，司机也不应该把视线从前方道路上移开。软件开发团队离不开客户的监督：否则会偏离用户需求，造成开发和测试等资源的浪费，影响产品质量和进度。有效的需求人员为什么难以产生？大多数需求分析人员都是从开发人员成长起来的。工作中，我们长时间一言不发，面对着冰冷的显示器，手指在键盘上翻飞，嘴角带着神秘的微笑，用一种奇怪的符号在写着什么。我们生活在一个数字的世界中，我们当中可能很多人从来没有和任何一个客户接触过。可是突然有一天，我们发现自己不得不面对一大群用户，更加糟糕的是这些人竟然不懂什么是C+，也没有听说过互联网。“天啦，我能和他们说什么啊？”优秀程序员=有效的需求分析员？程序员所接受的教育，程序员的工作
10、并不能教会他们如何成为一个有效的需求分析员。就像编码，测试，项目管理一样，需求分析也存在着大量的技巧。很难想象不经过艰苦的训练就能够很好的掌握一种编程语言，需求分析也是一样。但是现实中，很多的程序员没有经过任何的训练就变成了一个需求分析员，变成了一个缺乏足够技巧的需求分析员。什么是有效的需求分析 员在陌生的领域内能学得更快，而且还要用共同的语言和用户进行交流能在需求捕获和分析过程中和用户建立真正的伙伴关系能够在错综复杂的现象中发现问题背后的问题（the problem behind the problem）怎么建立真正的伙伴关系？1.转变态度。我们知道用户的业务目标是什么吗？我们知道用户三年甚
11、至更久的发展方针是什么吗？我们知道我们的软件能够给用户带来哪些利益吗？用户把我们当作朋友吗？2.培养人际关系。需求分析不是做交易，不是把收了钱就可以置诸脑后的一锤子买卖。我们要真诚的面对客户，用真心换取真心，尽力和用户成为朋友。3.我们要展开我们的商业想象力。大胆寻求满足用户需求的更佳途径。象用户一样看待事物远远不够，我们要争取看得更清晰，也就是常说的“超越用户”。发现问题背后的问题当一个软件项目开始后，用户的要求往往是开发完成某个功能（如人事管理，财务等）的软件，用来解决目前存在的问题。但是软件真正能够给用户创造的价值是什么，这是每一个需求分析员必需思考的问题。发现问题背后的问题示例：饭店里
12、的顾客与服务员的小故事发现问题背后的问题用户需要开发一个人事管理软件，表面上的需求可能是更方便的对员工进行管理，但是实质上的需求可能是通过人事管理软件来解决工作纪律松散、考勤不严格、人员流动随意等问题。用户需要开发一个财务软件，除了更好的管理资金，其真正的目的可能是为了解决内部财务制度混乱的问题。如果需求分析只是停留在表面的问题，而不能够发现用户真正关心的问题，很难相信开发出来的软件能够让用户发自内心的满意。用共同的语言进行交流应该努力的去熟悉用户的行业，学习用户使用的术语，标准，以便能够准确的理解用户。应该尽量不使用IT行业的术语，而采用浅显易懂的口头语言来解释IT行业中高深莫测的术语，以便
13、用户能够很好的理解。需求捕获需要“不择手段”需求之所以难以捕获，是因为它们存在与用户的头脑中。有效的需求分析员必须用自己智慧、行动和真诚去发现需求、挖掘需求。好的方法和习惯能够让我们的需求分析更加有效。哪些人适合做需求捕获？乐于学习的人善于学习的人具有快速学习能力的人“花心”的人能站在用户立场上思考的人不“自私”的人不以自我为中心的人性格和技能不同的人组成的小而平衡的团队需求捕获的辅助工具脑图软件：MindManager（Virtual your mind）适合于头脑风暴法的场合激光安防系统需求示例导出为正式文档：Word，Powerpoint和html12345软件需求概述软件需求工程过程软
14、件需求捕获技术软件需求分析与建模软件需求变更管理CONTENT软件需求分析与建模结构化需求分析与建模 面向数据的数据建模 面向数据流的功能建模 面向状态转换的行为建模面向对象需求分析与建模 用例分析技术需求分析与建模方法的选择与结合结构化需求分析与建模结构化分析方法 最初由Douglas Ross提出，由DeMarco推广，由Ward和Mellor以及后来的Hatley和Pirbhai扩充，逐渐形成结构化分析方法的框架，它是最具代表性的分析建模方法。结构化分析和建模的主要目的是为了减少分析时的错误，通过自顶向下建立系统逻辑模型，降低系统设计时的复杂性，提高系统的可维护性。结构化需求分析与建模结
15、构化分析的核心是数据。数据包括在分析、设计和实现中涉及的概念、术语、属性等所有内容，并把这些内容定义在数据字典中。围绕数据字典，完成功能模型、数据模型和行为模型的结构化建模过程。面向数据的数据建模 通常使用实体-联系图(entity-relationship：ER图)来建立数据模型或ER模型 ER图中包含了实体(即数据)、关系和属性等3种基本成分具有相同属性的实体具有相同的特征和性质，用实体名及其属性名集合来抽象和刻画同类实体实体所具有的某一特性，一个实体可由若干个属性来刻画数据对象彼此之间相互连接的方式称为联系，也称为关系姓名性别专业姓名性别年级课程名称成绩教师学生教学NM面向数据的数据建模
16、ER图在需求分析阶段用来描述信息需求和要存储在数据库中的信息的类型在随后的逻辑设计阶段，ER模型要映射到逻辑模型如关系模型上；最后要在物理设计期间映射到物理模型上。面向数据流的功能建模 数据流图（Data Flowing Diagram，DFD）是结构化建模中最流行的功能建模工具 DFD描述从数据输入、数据转换到数据输出的全过程 DFD图可以分层，分层的DFD更进一步刻画了系统的功能分解 外部系统用户目标系统输入数据输入数据输出数据输出数据外部系统用户外部系统用户目标系统输入数据输入数据输出数据输出数据外部系统用户外部系统用户目标系统输入数据输入数据输出数据输出数据外部系统用户面向数据流的功能
17、建模数据加工，实现数据变换。其中要注明加工的名字。外部实体，即数据源或外部系统。其中要注明数据源或外部系统的名字。数据存储。其中注明数据存储名字或编号。数据流，描述变换的加工数据及数据流方向。箭头上部要注明数据流的名字。DFD图基本图形符号DFD图的分解过程确定系统的外部信息源、数据源或与外部系统的接口。画出顶层（0层）DFD图。第一次精化：划分系统的子系统。逐层求精：对各子系统进一步精化。DFD图可以用来表示任何抽象级别的系统功能，随着系统功能和信息的逐渐增加，DFD图通过分解来逐层细化用户需求。分解步骤如下：DFD图命名 对DFD图中各部分元素的命名切忌用空洞的名词，这样不仅会给系统设计带
18、来歧义，而且难以确定数据的结构和组织方式。命名时应遵循以下原则：用名词或名词短语，避免使用空洞、无意义的词汇；尽量使用需求描述中的已有词和领域术语；命名出现困难时，考虑是否是数据流划分是否正确，并重获需求；顶层DFD图中的加工名就是软件项目的名字；分层DFD图中，数据存储一般局限在某一层或少数几层中。DFD图分层注意事项在逐层细化DFD图时，还要注意以下几点：父图和子图的平衡关系 DFD图的编号 平衡规则 s2.12.22.32.42.52.62.71231.11.23.13.23.3DFD图分层示例面向状态转换的行为建模 状态转换图（Status Transition Diagram，STD
19、）通过描述系统状态及引起状态转换的事件来表示系统行为。STD图同时也反映了事件执行的行为。由一个状态转换到另一个状态的关联就是状态转换，它表明状态变换是有序变换过程，用有向箭头表示。状态变换是由事件或条件触发的，因而箭头上应说明事件名称或触发条件。如果状态间转换没有事件触发，则前一状态结束信息就是转换到下一状态的触发条件。STD图主要由状态、转换和事件的图形符号构成。面向状态转换的行为建模状态是可观察到的行为，是同一数据对象在系统的不同运行时刻所具有的行为属性值，是事件触发后一系列动作的结果。面向状态转换的行为建模事件是指在某一时刻发生的事情，是触发状态转换的条件或一系列动作。在中间状态的符号
20、中，活动即是事件。STD图定义了3个标准事件，它们都没有参数：entry事件：用于说明转换到该状态的特定动作；exit事件：用于说明触发该状态的特定动作；do事件：用于说明处于当前状态时执行的动作。面向状态转换的行为建模数据字典 数据字典以结构化方式定义了在数据建模、功能建模和行为建模过程中涉及到的所有数据信息、控制信息。它是当前系统的软件词典，提供用户和软件人员的概念解释，也提供在系统开发过程中各种有关数据和控制的描述信息，使得系统所有的相关人员对信息有共同的、一致的理解。词条描述 定义式 Warnier图词条描述详细说明了数据和控制信息在系统内的传播途径。它分为数据流词条、数据元素词条、加
21、工词条和存储文件词条等内容的定义。数据字典DD （Data Dictionary）词条描述结构化需求分析与建模数据元素名：词数据元素名：词类型：文字（类型：文字（char*类型）类型）长度：任意长度长度：任意长度取值范围：取值范围：1名次名次|代词代词|动词动词|副词副词|形容词形容词|数量词数量词|介词介词|连词连词|助词助词n相关的数据元素：小词性相关的数据元素：小词性相关数据元素的数据结构：字符型（不能为空）相关数据元素的数据结构：字符型（不能为空）DD结构化需求分析与建模例如，x=ab，表示x由a和b组成。例如，x=a,b，x=a|b，表示x由a或由b组成。例如，x=a，表示x由0个或
22、多个a组成。例如，x=3a8，表示x中至少出现3次a,至多出现8次a，也可表示为mn .符 号 含 义 解 释 .,.|.m.n (.)“.”.被定义为 与 或 或 重复 重复 可选 基本数据元素 连结符 例如，x=(a)，表示a可在x中出现,也可不出现。例如，x=“a”，表示x为取值为a的数据元素。例如，x=1.9，表示x可取1到9之中的任一值。Warnier图，是描述信息层次结构的一种工具。类似于一种结构式语言，它用到下列三种符号:顺序执行 选择执行 循环执行 B1 B1 B1 B2 +B2 B3 B2 B3 n结构化需求分析与建模加工逻辑 加工逻辑也称过程说明，用于描述DFD中加工部分的
23、流程或算法 加工逻辑的表达形式主要有PDL，判定树，判定表，流程图等 过程设计语言（Process Design Language）是在伪代码的基础上，扩充了模块的定义与调用、数据定义和输入输出而形成的。它的控制结构与伪代码相同。PDL是一种用于描述模块算法设计和细节处理的语言面向对象需求分析与建模UML（统一建模语言）是面向对象分析与建模技术的通用语言；用例分析技术是UML中用于需求分析和建模的技术；用例分析技术是一个需求分析技术，是在传统的需求捕获技术的基础上使用的，并无法替代这些技术；用例分析技术是一种合成技术，将在需求捕获中收集而来的零散的特性合成为用例和用例描述；用例分析技术的核心不
24、是用例图，而是用例描述。用例分析技术用例分析技术是Ivar Jacobson先生于1967年在爱立信公司开发AXE交换机时开始研究，并于1986年总结、发布的一项源于实践的需求分析技术。Ivar先生在加盟Rational之后，与其他人合作提出了UML、完善了RUP，用例分析技术也因此被人广泛了解和关注。用例分析技术为软件需求规格化提供了一个基本的元素，而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。用例可以使开发团队与客户之间的交流更加顺畅。用例图示例用例图用例图着重于从系统外部参与者的角度来描述系统需要提供哪些功能，并且指明了这些功能的参与者是谁；用例图在UM
25、L方法中占有十分重要的地位，甚至称UML是一种用例图驱动的开发方法。用例图描述系统外部的参与者与系统的用例之间的某种联系。用例是指对系统提供的功能（或称系统的用途）的一种描述；（功能需求的捕获）参与者是那些可能使用这些用例的人或外部系统；用例和参与者之间的联系描述了“谁使用哪个用例”。用例要素参与者：Actor参与者，定义了用户在系统交互过程中扮演的角色，其可以是一个人，也可以是另一个相关的系统。用例：Use case用例实例（场景）是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果，一个用例定义一组用例实例（场景）。一个用例应为参与者提供（实现）一个价值。用例描述：事件流 就
26、像类对应于对象一样，一个用例的实例就是使用场景，用例就是对使用场景进行抽象的总结。用例描述前置条件：指在用例启动时，参与者（Actor）与系统应置于什么状态，这个状态应该是系统能够检测到的、可观测的；后置条件：用例结束时，系统应置于什么状态，这个状态也应该是系统能够检测得到的、可观测的；基本事件流：基本事件流是对用例中常规、预期路径的描述，也被称为Happy day场景，这时大部分时间所遇到的场景；它将体现系统的核心价值；扩展事件流：主要是对一些异常情况、选择分支进行描述。事件流表达的是流程和算法，可以用其他图形技术来表达，如流程图，活动图，PDL等。用例分析说明用例设计反映功能需求，不易表达
27、性能需求用例连接开发的上下游 粒度过大：对设计者无用，不能提供足够的信息 粒度过小：客户无法理解专业术语，无法通过良好的迭代过程获取稳定和完整的需求 用例采用半形式化描述以满足双方的要求用例分析团队 人数：2-3人 不同背景，不同性格的人用例分析工具IBM Rational Suite之RequistePro需求管理工具需求列表IBM Rational Suite之RequistePro需求管理工具需求矩阵，分析需求冲突软件需求分析与建模技术选择传统软件开发采用结构化目前主要采用面向对象分析与建模技术并不完全排除结构化分析与建模技术，如流程图数据建模技术出现很多技术和工具整合两者，如ORM12
28、345软件需求概述软件需求工程过程软件需求捕获技术软件需求分析与建模软件需求变更管理CONTENT需求变更产生的原因 需求变更可以发生在软件开发的任意时刻 有几种原因使需求分析变得困难l客户说不清楚需求；l需求自身经常变动；l分析人员或客户理解有误。变更的来源：l（外部）需求的变更l（内部）需求的变更 开发阶段内部发生的变更 开发过程解决不了的变更“据历史记载，没有一个软件的需求改动少于三次。唯一只改动需求两次的客户是个死人。这个可怜的家伙还是在运送第三次需求的路上被车子撞死的。”积极应对还是消极抵抗？需求变更过程如何减少变更的影响 在软件建立时变更是不可避免的，因为在进行变更前没有仔细分析，
29、或没有进行变更控制，变更加剧了项目中软件人员之间的混乱。配置管理是一个管理学科，它对配置项（包括软件项）的开发和支持生存期给与技术上的和管理上的指导。配置管理的应用取决于项目的规模、复杂程度和风险大小。软件配置管理能协调软件开发，使混乱减少到最小。软件配置管理是一种标识、组织和控制修改的技术，目的是最有效的提高生产率。是对下列工作进行技术和行动指导与监督的一套规范：对配置项的功能特性和物理特性进行标识和文件编制工作；控制这些特性的更动情况；记录并报告这些更动进行的处理和实现的状态。如何管理变更尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求
30、上，否则将会吃尽苦头。在合同中一定要说清楚“做什么”和“不做什么”。必须满足和协调涉众的利益（某县委机关裁员的故事）使用SCM管理变更软件配置管理是一种“保护伞”活动，它应用于整个软件工程过程。SCM活动的目标是为了：(1)标识变更；(2)控制变更；(3)确保变更正确地实现；(4)向其他有关的人报告变更。变更控制管理 变更控制组（Change Control Board）也称为配置控制组（Configuration Control Board），是配置项变更的监管组织。其任务是对建议的配置项变更做出评价、审批以及监督已批准的变更的实施。软件配置项通过评审作为基线，将准许进入配置库（实施检入Ch
31、eck-in），开始“冻结”。由于多种原因需要变更就需要提出“变更请求”。在得到批准的情况下，允许配置项从库中检出（Check-out）捕获的需求评审受控通过提交未通过变更变更请求表CRF变更请求号 软件版本号申请 *申请人 *申请日期 *变更部位 *变更优先性 *变更概述 *变更预期效果 *附件分析与审批*受影响工作项*估计工作量投入 *成本 *其他影响 *假设*效果 *分析日期 *分析人 *是否批准 *理由 *审批日期 *批准人 *发行版本 实施状态*受影响的每一个工作项 库标识 项标识 变更描述 出库版本 出库日期及时间 变更工作量 验证工作量 入库版本 入库日期及时间*说明*变更结束日期及时间*变更结束负责人变更请求表CRF（续）变更控制过程单击此处编辑母版标题样式 单击此处编辑母版文本样式 第二级 第三级 第四级 第五级本章小结 需求分析是软件开发的前期阶段，决定着软件开发活动的基本方向，地位非常重要；需求捕获是需求分析的前提条件，如果不能从客户那里捕获到真正的需求，后期的软件开发活动将事倍功半；传统的结构化需求分析和建模方法正逐渐被面向对象方法所取代，两者不是你死我活的关系，可以共存；需求不可能不变更，但可以用软件配置管理方法进行有效的管理。本章结束
