网站开发与设计岗位职责,中国核工业第五建设有限公司面试,中国监察报电子版,黑五手表网站系列文章目录
系统架构设计高级技能 软件架构概念、架构风格、ABSD、架构复用、DSSA#xff08;一#xff09;【系统架构设计师】 系统架构设计高级技能 系统质量属性与架构评估#xff08;二#xff09;【系统架构设计师】 系统架构设计高级技能 软件可靠性分析与设计…系列文章目录
系统架构设计高级技能 · 软件架构概念、架构风格、ABSD、架构复用、DSSA一【系统架构设计师】 系统架构设计高级技能 · 系统质量属性与架构评估二【系统架构设计师】 系统架构设计高级技能 · 软件可靠性分析与设计三【系统架构设计师】 系统架构设计专业技能 · 软件工程之需求工程 系列文章目录一、 需求工程概述二、 需求开发主线、目标2.1 需求分类2.2 需求获取2.3 需求分析2.3.1 结构化分析方法 - SA2.3.1.1 SA - 数据字典DD2.3.1.2 SA - 数据流图DFD2.3.1.3 SA - 状态转换图STD2.3.1.4 SA - E-R图/实体联系图 2.3.2 面向对象的分析方法 - OOA2.3.2.1 OOA - UML2.3.2.2 OOA - UML 41视图2.3.2.3 OOA - 用例模型与分析模型2.3.2.4 需求分析工具2.3.2.4.1 使用用例建模系统需求2.3.2.4.2 数据建模与分析2.3.2.4.3 过程建模2.3.2.4.4 面向对象分析与建模 2.4 需求定义形成需求规格2.5 需求确认与验证 三、 需求管理支持保障3.1 定义需求基线3.2 需求的状态3.3 需求变更管理3.4 需求变更管理过程3.5 需求风险3.6 需求跟踪 一、 需求工程概述
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。
需求工程Requirement EngineeringRE 是指应用已证实有效的原理、方法通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束。
需求工程由需求获取、需求分析、形成需求规格或称为需求文档化、需求确认与验证、需求管理5个阶段如图 软件需求规格说明书Software Requirement SpecificationSRS SRS具体包括功能需求、非功能需求和约束。约束包括设计约束和过程约束。批准的SRS是需求开发和需求管理之间的桥梁。
需求管理 需求管理是一个对系统需求变更、了解和控制的过程包括变更控制、版本控制、需求跟踪等活动。 二、 需求开发主线、目标
2.1 需求分类 需求分类
1业务需求业务需求是指反映企业或客户对系统高层次的目标要求通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围。
2用户需求用户需求描述的是用户的具体目标或用户要求系统必须能完成的任务。也就是说用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式对用户使用的场景scenarios进行整理从而建立用户需求
3系统需求系统需求是从系统的角度来说明软件的需求包括功能需求、非功能需求和设计约束等。
质量功能部署QFD
它是一种将用户要求转化成软件需求的技术其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标QFD将软件需求分为三类分别是常规需求、期望需求和意外需求。
1基本需求也叫常规需求用户认为系统应该做到的功能或性能实现越多用户会越满意。
2期望需求用户想当然认为系统应具备的功能或性能但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现会让用户感到不满意。
3意外需求意外需求也称为兴奋需求是用户要求范围外的功能或性能但通常是软件开发人员很乐意赋予系统的技术特性实现这些需求用户会更高兴但不实现也不影响其购买的决策。
2.2 需求获取
方法特点收集资料把与系统有关的、对系统开发有益的信息收集起来。阅读历史文档对收集数据性的信息较为有用。 用户访谈1对1-3有代表性的用户了解主观想法交互好。成本高要有领域知识支撑。问卷调查用户多无法—一访谈成本低。现场观摩针对较为复杂的流程和操作。参加业务实践有效地发现问题的本质和寻找解决问题的办法。联合需求计划(JRP)高度组织的群体会议各方参与了解想法消除分歧交互好成本高。情节串联板(原型法)一系列图片通过这些图片来讲故事。抽样调查/采样基于数理统计降低成本快速获取。 样本大小a*(可信度系数/可接受的错误)2注:a一般取0.25 用户访谈 用户访谈是最基本的一种需求获取手段其形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题有针对地进行而非结构化则是只列出一个粗略的想法根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行毕竟不可能把什么都一一计划清楚应该保持良好的灵活性。 用户访谈具有良好的灵活性有较宽广的应用范围。但是也存在着许多困难例如用户经常较忙难以安排时间面谈时信息量大记录较为困难沟通需要很多技巧同时需要系统分析师具有足够的领域知识等。另外在访谈时还可能会遇到一些对于企业来说比较机密和敏感的话题。因此这看似简单的技术也需要系统分析师具有丰富的经验和较强的沟通能力。 问卷调查 问卷调查与用户访谈相比问卷调查可以在短时间内以低廉的代价从大量的回答中收集数据问卷调查允许回答者匿名填写大多数用户可能会提供真实信息问卷调查的结果比较好整理和统计。但是问卷调查最大的不足就是缺乏灵活性其他缺点还有 ① 双方未见面系统分析师无法从用户的表情等其他动作来获取一些更隐性的信息用户也没有机会立即澄清对问题有含糊或错误的回答。 ② 用户有可能在心理上会不重视一张小小的表格不认真对待从而使得反馈的信息不全面。 ③ 调查表不利于对问题进行展开的回答无法了解一些细节问题。 ④ 回答者的数量往往比预期的要少无法保证用户会回答问题或进一步说明所有问题。 抽样调查/采样 抽样调查/采样是指从种群中系统地选出有代表性的样本集的过程通过认真研究所选出的样本集可以从整体上揭示种群的有用信息。对于信息系统的开发而言现有系统的文档文件就是采样种群。当开始对一个系统做需求分析时查看现有系统的文档是对系统有初步了解的最好方法。但是系统分析师应该查看哪些类型的文档当文档的数据庞大无法一一研究时就需要使用采样技术选出有代表性的数据。采样技术不仅可以用于收集数据还可以用于采集访谈用户或者是采集观察用户。在对人员进行采样时上面介绍的采样技术同样适用。通过采样技术选择部分而不是选择种群的全部不仅加快了数据收集的过程而且提高了效率从而降低了开发成本。另外采样技术使用了数理统计原理能减少数据收集的偏差。 但是由于采样技术基于统计学原理样本规模的确定依赖于期望的可信度和已有的先验知识很大程度上取决于系统分析师的主观因素对系统分析师个人的经验和能力依赖性很强要求系统分析师具有较高的水平和丰富的经验。 联合需求计划JRP JRP是一种相对来说成本较高的需求获取方法但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起通过有组织的会议来讨论需求。通常该会议的参与人数为618人召开时间为15小时。 JRP的主要意图是收集需求而不是对需求进行分析和验证。实施JRP时应把握以下主要原则 ① 在JRP实施之前应制订详细的议程并严格遵照议程进行。 ②按照既定的时间安排进行。 ③尽量完整地记录会议期间的内容。 ④在讨论期间尽量避免使用专业术语。 ⑤充分运用解决冲突的技能。 ⑥会议期间应设置充分的间歇时间。 ⑦鼓励团队取得一致意见。 ⑧保证参加JRP的所有人员能够遵守事先约定的规则。
2.3 需求分析
需求分析一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性因此需要分析人员把杂乱无章的用户要求和期望转化为用户需求这就是需求分析的工作。
需求分析的任务 1绘制系统上下文范围关系图 2创建用户界面原型 3分析需求的可行性 4确定需求的优先级 5为需求建立模型 6创建数据字典 7使用QFD质量功能部署) 2.3.1 结构化分析方法 - SA
结构化分析方法SA的核心是数据字典。围绕这个核心有三个层次的模型分别是数据模型功能模型行为模型状态模型。
结构化分析的步骤如下 1分析业务情况做出反映当前物理模型的数据流图Data Flow DiagramDFD。 2推导出等价的逻辑模型的DFD。 3设计新的逻辑系统生成数据字典和基元描述。 3建立人机接口提出可供选择的目标系统物理模型的DFD。 5确定各种方案的成本和风险等级据此对各种方案进行分析。 6选择一种方案。 7建立完整的需求规约。
结构化分析方法SA是数据流和控制流常用手段是数据流图DFD和数据字典。 2.3.1.1 SA - 数据字典DD
数据字典是需求分析建立模型的核心。是为数据流图中的每个数据流、文件、加工以及组成数据流或文件的数据项做出说明。
数据字典有4类条目数据流、数据项、数据存储和基本加工。包括了数据元素数据结构数据流加工逻辑和外部实体。如下图
2.3.1.2 SA - 数据流图DFD
数据流图DFD是用数据流图表示功能模型DFD说明系统所完成功能从数据传递和加工的角度利用图形符号通过逐层细分描述系统的各个部件的功能和数据在他们之间传递的情况来说明系统所完成的功能。如下图
其中DFD还会有“顶层DFD图”和“0层DFD图”。
如上图有如下几种“图元”描述
另附一个错误的DFD图如下
如上图错误
加工3.1.2有输入但是没有输出称之为“黑洞”。 加工3.1.3有输出但没有输入。称之为“奇迹”。 加工3.1.1中输入不足以产生输出我们称之为“灰洞”。
2.3.1.3 SA - 状态转换图STD
用状态转换图表示行为模型STD通过描述系统的状态和引起系统状态转换的事件来表示系统的行为指出做为特定事件的结果将执行哪些动作。如下图
2.3.1.4 SA - E-R图/实体联系图
ER图主要描述实体属性以及实体之间的关系。另外ER模型是结构化时代的模型与产物在面向对象和UML中是没有的。如下图
什么是弱实体 举例说明在人事管理系统中职工子女的信息就是以职工的存在为前提的子女实体是弱实体子女与职工的联系是一种依赖联系。所以职工是实体也可以成为强实体。 强实体与弱实体的联系只能是11或1N。
2.3.2 面向对象的分析方法 - OOA
相关的几个概念
对象属性[数据] 方法[操作] 对象ID/标识ID类[详细见下] 实体类/控制类/边界类 实体类往往和数据库有对应的关系是不是数据类型 控制类衔接实体类和边界类的类边界类在一个系统的边界上和外部进行沟通的类这三个类似于MVC模型之间的关系它们的思想是一样的继承与泛化复用机制它是一种紧耦合。因为当父类变的时候子类不得不变。继承是对已有实例封装隐藏对象的属性和实现细节仅对外公开接口多态不同对象收到同样的信息产生不同的结果接口一种特殊的类它只有方法定义没有对方法的实现重载一个类可以有多个同名的参数类型不同的方法。函数同名但参数不一样是其特点消息和消息通信消息是异步通信的覆盖与重写子类的同名方法覆盖父类的同名方法组合与聚合聚合关系汽车部件和整车的关系整体与部分生命周期不同组合关系部门与公司的关系。公司倒闭的话部门也完完整体与部分生命周期相同
OOA大致上遵循如下5个基本步骤
1确定对象和类这里所说的对象是对数据及其处理方式的抽象它反映了系统保存和处理现实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述它包括如何在一个类中建立一个新对象的描述。 2确定结构结构是指问题域的复杂性和连接关系。类成员结构反映了泛化-特化关系整体-部分结构反映整体和局部之间的关系。 3确定主题主题是指事物的总体概貌和总体分析模型。 4确定属性属性就是数据元素可用来描述对象或分类结构的实例可在图中给出并在对象的存储中指定。 5确定方法方法是在收到消息后必须进行的一些处理方法:方法要在图中定义并在对象的存储中指定。对于每个对象和结构来说那些用来增加、修改、删除和选择的方法本身都是隐含的虽然它们是要在对象的存储中定义的但并不在图上给出而有些则是显示的。
2.3.2.1 OOA - UML
OOA需求分析的UML统一建模语言与平台和语言无关由基本构造块规则和公共机制构成。
UML基本构造块之事物【重要组成部分】
事务描述结构事物最静态的部分包括类接口协作用例活动类构件和节点行为事物代表时间和空间上的动作包括消息动作次序连接分组事物看成是个盒子如包和构件注释事物UML模型的解释部分。描述说明和标注模型的元素
UML基本构造块之关系【把事物紧密联系在一起】
关系描述依赖关系一个事物发生变化影响另一个事物包含关系和扩展关系都属于依赖泛化关系特殊一般关系特殊元素的对象可替换一般元素的对象关联关系描述了一个链链是对象之间的连接实现关系接口与类之间的关系一个类指定了由另一个类保证执行的契约
UML基本构造块之图【多个相互关联的事物的集合】
图描述静态图结构图类图描述一组类接口协作和它们之间的关系。对象图描述一组对象以及它们之间的关系。对象图往往只在需要描述复杂算法时才会使用画出来的对象图往往不会只有一个对象。构件图也叫组件图是描述软件内部物理组成的一种图。系统里有哪些构件 构件之间有啥联系。描述一个封装的类和它的接口端口以及由内嵌的构件和连接件构成的内部结构。强调由小的部件构件大的系统。部署图表示为软件和硬件之间的映射。为了完成系统需要什么样配置的操作系统内存CPU等不在它范畴内它只解决开发的系统如何去部署的问题。制品图描述计算机中一个系统的物理结构。制品包括文件数据库和类似的物理比特集合。包图将某些类放入“包”中通过包图来组织业务概念图。组合结构图展示该部分内容“内部”参与者的配置情况。这个图不常用。动态图行为图用例图系统与外部参与者的交互。描述一组用例参与者及他们之间的关系的图。顺序图强调按时间顺序。顺序图和通信图我们又称其为交互图。顺序图能够表达用户与系统的复杂交互过程。通信图也叫协作图它强调的是相互之间关系是顺序图的另外一种表达。定时图消息跨越不同对象或角色的实际时间。交互图的一种。交互概览图活动图与顺序图的结合。这个图不常用。活动图类似程序流程图表示流程性的东西和并行的行为。它将进程或其他计算结构展示为计算内部一步步的控制流和数据流它专注于系统的动态视图它对系统功能建模和业务流程建模特别重要并强调对象间的控制流程。状态图从某个物品的状态是如何变化的角度来展示流程。 UML规则
是构造块如何放在一起的规定包括为构造块命名给一个名字以特定含义的语境即范围怎样使用或看见名字即可见性事物如何正确、一致地相互联系即完整性运行或模拟动态模型的含义是什么即执行。
UML公共机制
是指达到特定H标的公共UML方法主要包括规格说明详细说明、修饰、公共分类通用划分和扩展机制4种。规格说明是事物语义的细节描述它是模型真正的核心UML为每个事物设置了一个简单的记号还可以通过修饰来表达更多的信息UML包括两组公共分类类与对象类表示概念而对象表示具体的实体)、接门与实现接口用来定义契约而实现就是具体的内容)扩展机制包括约束扩展了UML构造块的语义允许增加新的规则或修改现有的规则、构造型扩展UML的词汇用于定义新的构造块和标记值扩展了UML构造块的特性允许创建新的特殊信息来扩展事物的规格说明。
UML中的概念
类是描述具有相同属性、方法、关系和语义的对象的集合一个类实现一个或多个接口。接口是指类或构件提供特定服务的一组操作的集合接口描述了类或构件的对外的可见的动作。构件是物理上或可替换的系统部分它实现了一个接口集合。提供一组接口的实现是组成事物的元素。包是用于把元素组织成组的通用机制它一个构件的抽象化的概念是把类元按照一定的规则分成组或称为模块。用例是描述一系列的动作产生有价值的结果。协作定义了交互的操作是一些角色和其它事物一起工作提供一些合作的动作这些动作比事物的总和要大。节点是一个物理元素它在运行时存在代表一个可计算的资源通常占用一些内存和具有处理能力。
2.3.2.2 OOA - UML 41视图
现有的UML再有的UML视图
UML采用41视图来描述软件和软件的开发过程其中进程视图绘制了所设计的并发与同步结构部署视图表示软件到硬件的映射和分布结构UML中的类图可以用来表示41视图中逻辑视图最终形成用例视图用来得到需求分析模型。
“41”视图模型是从不同的视角、使用多个并发的视图来组织软件架构的描述。
“41”视图模型具有普遍适用性实践证明能在许多大型项目中成功运用。
2.3.2.3 OOA - 用例模型与分析模型
在OOA的需求分析中图的应用是经常被用到的。大部分的以用例模型和分析模型的建立为主线其中用例模型采用用例图来构建分析模型用类型表示。其它细节情况也可以建立其它交互图。 2.3.2.4 需求分析工具
2.3.2.4.1 使用用例建模系统需求
用例建模来源于面向对象建模技术但该技术也在非对象开发环境中比较流行用例建模技术对传统的系统分析和设计工具进行了补充例如数据建模和过程建模 也提供了架构决策和用户界面设计决策的基础。
用例建模促进并鼓励了用户参与具有如下优点
提供了捕捉功能需求的工具。有助于将系统分解为更易于管理的小块。提供了与用户以及其他关心系统的关联人员进行交流的工具。辅助估计项目范围、投入和进度。提供了需求跟踪的工具。提供了确定数据对象或实体的起点。提供了设计用户和系统接口的功能规格说明。
为了决定用例的重要性项目经理或者系统分析员将填写用例分级和评估矩阵并使用来自关联人员和开发团队的输入构造用例依赖关系图。
1、项目经理使用称为用例分级和评估矩阵决定用例的优先级。该矩阵使用6个标准按1 ~ 5级评估用例。6个标准是
对架构设计的重要影响。容易实现但包含重要功能。包含有风险、时间紧迫或复杂的功能。需要大量的研究或者新的、有风险的技术。包含主要的业务功能。将增加或者减少费用。
2、有些用例依赖于其他用例其中一个用例使系统处于一种状态该状态是另一个用例的前置条件。我们使用用例依赖关系图建模这种依赖关系。用例依赖关系图具有以下优点
系统事件及其状态的图形化表述有利于对系统功能的理解。有助于确定遗漏的用例。通过描述哪个用例更关键并需要最高优先权有助于推动项目管理。
2.3.2.4.2 数据建模与分析
数据建模是一种为数据库定义业务需要的技术因为数据模型最终要实现成数据库所以数据建模有时称为数据库建模。下图是一个简单的数据模型称为实体关系图。
数据建模的系统概念
实体属性数据类型、域、默认值键关系
如何构造数据模型
获取实体。构造上下文数据模型包含基本业务实体及它们之间的自然关系。基于键的数据模型确定每个实体的键。泛化层次体系父实体、子实体。具有完整属性的数据模型。分析数据模型规范化第一范式、第二范式、第三范式。将数据需求映射到地点数据–地点–CRUD矩阵。
2.3.2.4.3 过程建模
过程建模源自传统的软件工程方法可能的过程模型包括程序结构图、逻辑流程图或决策表。本节重点介绍系统分析的过程模型即数据流图。 数据流图是一种描述通过系统的数据流以及系统实施的工作或处理过程的工具。同义词包括泡式图、转换图和过程模型。
过程建模的系统概念
外部代理常见的同义词包括外部实体。数据存储是一个数据的“仓库”同义词包括文件和数据库。过程即处理是在输入数据流或条件上执行或者对输入数据流或条件做出响应的工作同义词是转换。分解图、层次图。注意避免过程中三种常见的错误1有输入没有输出黑洞2)有输出但没有输入奇迹3)输入不足以产生输出灰洞如输入一个雇员地址输出一张财务报表。数据流所有的过程至少都有一个输入流和一个输出流。数据流是过程与系统环境之间的通信。在数据流图中有时需要描述分支的数据流或合并的数据流。分支的数据流是一个分成多个数据流的数据流表示一个数据流的所有或者部分路由到不同目的地。合并的数据流是多个数据流合并成一个数据流后的数据流。合并的数据流指示了不同来源的数据流可以合并成一个报文供后续处理。
如何构造过程模型
构造上下文数据流图0号数据流图。构造系统功能分解图。事件响应或用例清单构建分解图后下一步是确定系统必须响应什么业务事件外部事件、时序事件、状态事件。发现并确定事件和响应的更成功的方法之一是用例的技术。用例分析是确定并建模业务事件、谁触发事件以及系统如何响应事件的过程。事件分解图把事件处理过程增加到分解图中。事件图以分解图为提纲可以为每个事件过程绘制一个事件图。构造系统图从原始的上下文图中的单个过程“爆炸”出来在单张图中显示了系统的所有事件显示了子系统的所有事件。 构造基本图具有较复杂的事件图的事件过程应该扩展成一个更详细的基本数据流图每个基本过程都是内聚的也就是说仅完成一件事。完成规格说明对以上完成的数据流图中的每个数据流、数据存储和基本过程进行描述并写进资料库中。对于过程内部的逻辑描述我们可以使用结构化英语自然英语编程逻辑用于说明过程模型中的基本过程的内部逻辑。但许多过程是由复杂的条件组合的即业务策略使用结构化英语不容易表达此时可以使用决策表。
2.3.2.4.4 面向对象分析与建模
面向对象分析涉及到定义信息系统的静态和动态行为模型而非定义数据和过程模型这是传统开发方法的特点。对象的标识对象的数据部分属性对象的行为。
2.4 需求定义形成需求规格 需求定义的过程也就是形成需求规格说明书SRS的过程通常有两种需求定义的方法分别是严格定义方法和原型方法。
严格定义法的特点所有需求都能够被严格定义开发人员和用户之间能够准确而清晰的交流采用图形文字能够充分体现最终系统。
原型法并非所有的需求都能在开发前被准确的说明项目参加者之间通常存在交流上的困难需要实际的可供用户参与的系统模型有合适的系统开发环境反复是完全需要和值得提倡的需求一旦确定就应该遵从严格的方法。
2.5 需求确认与验证 需求规格说明书SRS的需求验证也称为需求确认其活动是为了确定以下几个方面的内容
1SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。 2SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。 3需求是完整的和高质量的。 4需求的表示在所有地方都是一致的。 5需求为继续进行系统设计、实现和测试提供了足够的基础。
需求验证包括了需求评审和需求测试。
需求评审包括了正式评审和非正式评审。需求验证是需要做用户签字确认但往往实施起来比较困难因为需求验证时签字就要负责任它是验收的标准之一此时的规格说明书SRS就是需求基线。需求的评审需要用户的参与。
需求测试不是运行类的测试而是设计测试用例进行测试比如告诉你输入是什么输出是什么所以更加接近于想像性测试它是验证方向对不对该不该做的过程。需求测试仅仅是基于文本需求进行“概念”上的测试。然而以功能需求为基础SA方法或者从用例派生出来OO方法的测试用例可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例但是涉及测试用例的简单动作可以解释需求的许多问题。这种测试用例通常称为概念测试用例即不是真正执行的测试用例它们可以发现SRS中的错误、二义性和遗漏还可以进行模型分析以及作为用户验收测试的基础。在正式的系统测试中还可以将它们细化成测试用例。
三、 需求管理支持保障
在软件需求工程中需求管理贯穿于整个过程中它的最基本的任务就是明确需求并使项目团队和用户达成共识即建立需求基线。另外还要建立需求跟踪能力联系链确保所有用户需求都被正确地应用并且在需求发生变更时能够完全地控制其影响范围始终保持产品与需求的一致性。
需求管理是可重复级的一个关键过程域其目标是为软件需求建立一个基线供软件开发及其管理使用使软件计划、产品和活动与软件需求保持一致。从软件需求工程的角度来看需求管理包括在软件开发过程中维持需求一致性和精确性的所有活动包括控制需求基线保持项目计划与需求一致控制单个需求和需求文档的版本情况管理需求和联系链之间的联系或管理单个需求和项目其他可交付物之间的依赖关系跟踪基线中需求的状态。
3.1 定义需求基线
需求开发的结果应该有项目视图和范围文档、用例文档和SRS以及相关的分析模型。经评审批准这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定它是需求开发和需求管理之间的桥梁。
基线是一个软件配置管理的概念它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE的定义基线是指已经通过正式评审和批准的规约或产品它可以作为进一步开发的基础并且只能通过正式的变更控制系统进行变化。在软件工程范围内基线是软件开发中的里程碑其标志是有一个或多个软件配置项的交付且已经经过正式技术评审而获得认可。例如SRS文档通过评审其中的错误已经被发现并纠正则就变成了一个基线。根据国家标准《计算机软件配置管理计划规范》GB/T 12505-1990的规定基线可以分为功能基线、指派基线和产品基线三种通过评审后的SRS软件需求规格说明书属于指派基线。
3.2 需求的状态 在需求状态的变化中项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求如果不是通过有管理的处理过程就有可能因为疏忽而被遗漏。同时也应关注被交付的需求因为可交付物是项目的成果体现而可交付物的主要内容就是对需求的实现。
3.3 需求变更管理 CCB变更控制委员会也成配置控制委员会。 要让变更有序进行首先需要有一个统一的单位来负责这个单位一般叫变更控制委员会Change Control Board也叫配置控制委员会Configuration Control Board。CCB由项目干系人中有代表性的人员组成人数没有限制一个人也可以。CCB有能力在管理上做出承诺对建议的配置项变更做出评价、审批及监督已批准变更的实施。CCB是决策机构一般不参与具体的变更执行工作。
3.4 需求变更管理过程 1问题分析和变更描述。当提出一份变更提议后需要对该提议做进一步的问题分析检查它的有效性从而产生一个更明确的需求变更提议。 2变更分析和成本计算。当接受该变更提议后需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认应该进行是否执行这一变更的决策。 3变更实现。当确定执行该变更后需要根据该变更的影响范围按照开发的过程模型执行相应的变更。在计划驱动过程模型中往往需要回溯到需求分析阶段开始重新作对应的需求分析、设计和实现等步骤;在敏捷开发模型中往往会将需求变更纳入到下一次迭代的执行过程中。
常见的需求变更策略
1所有需求变更必须遵循变更控制过程。 2对于未获得批准的变更不应该做设计和实现工作。 3变更应该由项目变更控制委员会决定实现哪些变更。 4项目风险承担者应该能够了解变更的内容。 5绝不能从项目配置库中删除或者修改变更请求的原始文档。 6每一个集成的需求变更必须能跟踪到一个经核准的变更请求以保持水平可追踪性。
3.5 需求风险
带有风险的做法有①无足够用户参与。②忽略了用户分类。③用户需求的不断增加。④模凌两可的需求。⑤不必要的特征。⑥过于精简的SRS。⑦不准确的估算。
变更产生的原因①外部环境的变化。②需求和设计做的不够完整。③新技术的出现。④公司机构重组造成业务流程的变化。
3.6 需求跟踪 SRS中的每个软件配置项的需求到其涉及的系统或子系统需求都要具有双向可追踪性。所谓双向跟踪包括正向跟踪和反向跟踪正向跟踪是指检查SRS中的每个需求是否都能在后继工作成果中找到对应点反向跟踪也称为逆向跟踪是指检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。
