| 软件需求管理（三）需求过程 | 您所在的位置：网站首页 › 移动积分兑换的订单在哪查 › 软件需求管理（三）需求过程 |
软件需求管理（三）需求过程
|
一、需求规格说明
1.1需求规格说明概述
需求获取的目标是得到用户的需求——收集需求信息 需求分析的目标是更深刻的理解用户的需求——界定能够让用户满意的解决方案和准则 需求规格说明的目标是定义用户的需求——准确描述其需求和解决方案 需求规格说明文档的撰写流程如下图：
常见的需求说明文档主要有以下几种：
项目的前景和范围文档被视为属于用户的文档，主要包括的内容有问题域信息、解决方案、需求，内容较为抽象，具有概括性的特点 招标活动是基于用户需求文档进行的 大多数系统开发项目都是以系统需求规格说明文档为基础签约的 对系统规格说明的细化和详细说明会产生软件需求规格说明文档、硬件需求规格说明文档、接口需求规格说明文档和人机交互文档，都是开发文档。
需求规格文档的作者和读者有：项目管理者、设计人员和程序员、测试人员、文档编写人员、维护人员、培训人员、律师 需求规格说明文档—— 手段：信息描述语言的3种类别： 非形式化（文本为主） 半形式化（图形为主） 形式化（数学公式为主） 1.3模版的选择与裁剪
大概样式
指导原则： 写作是一门艺术 文档化的目标是交流 内容组织： 所有内容位置得当 引用或强化，但不重复 表达方式： 形式依赖于内容 使用系统的表达方式 细节描述： 定义术语表或数据字典时应避免的问题有 术语不一致 “方言”问题 错误术语和冗余术语 避免干扰文本 避免歧义词汇 1.5优秀需求规格说明文档的特性完备性 标准（当且仅当） 描述了用户的所有有意义的需求，包括功能、性能、约束、质量属性和对外接口。 每一条需求都是完备的。 定义了软件对所有情况的所有实际输入（无论有效输入还是无效输入）的响应。 为文档中的所有插图、图、表和术语、度量单位的定义提供了完整的引用和标记。 正确的前景和范围 一致性 细节的需求不能同高层次的需求相冲突，例如系统需求不能和业务需求、用户需求互相矛盾 同一层次的不同需求之间也不能互相冲突 根据重要性和稳定性分级 建立需求的优先级 可修改 标准 它的结构和风格使得人们可以对其中任一需求进行容易地、完整地、一致地修改，同时还不会影响文档现有的结构和风格 文档的可修改性要求： 有着条理分明并且易于使用的组织方式，包括目录、索引和显式的交叉引用。 没有重复冗余。 独立表达每个需求，而不是和其他需求混在一起。 可跟踪 1.后向跟踪（Backward traceability） 能找到需求的来源，例如和更早期文档的显式关联。 2.前向跟踪（Forward traceability） 能找到需求所对应的设计单元、实现源代码和测试用例等，它要求每个需求都要有唯一的标识或者可供引用的名称 需求工程过程建立的两个步骤 建立过程框架和选择工作组件 1.6需求规格说明的实践调查不编写正式的需求规格说明文档的原因： 1.时间压力，用非正式文档替代 2.迭代式开发，每次迭代是完成本次需求的正式需求规格说明，最后在整合成完整版本 在需求获取和需求分析当中，可以采用以下一些手段来保证最终需求集的完备性、一致性和正确性： 需求获取需求采集需求表达需求验证 二、需求验证 2.1验证与确认需求验证主要有两层含义：1.验证：正确得到需求2.确认：得到正确的需求 1. 需求验证：以正确的方式建立需求 需求集是正确的、完备的和一致的； 技术上是可解决的； 它们在现实世界中的满足是可行的和可验证的。 2.需求确认：建立的需求是正确的 每一条需求都是符合用户原意的 系统验证：正确的建立系统 系统能够在预期的环境中正确的执行设定的功能。 系统确认：建立的系统是正确的 建立的系统是符合系统需求和系统设计的 验证贯穿于整个软件生命周期，静态分析和测试的两个主要手段
需求验证是专指在需求规格说明完成之后，对需求规格说明文档进行的验证活动 方法：需求评审、原型与模拟 测试用例开发手册编制，利用跟踪关系，自动化分析 2.3需求验证方法 评审原型与模拟开发测试用例用户手册编制利用跟踪关系自动化分析 2.3.1评审由作者之外的其他人来检查产品问题的方法 是主要的静态分析手段 原则上，每一条需求都应该进行评审
检查方法 描述 自由方法（Ad-hoc） 没有为检查人员提供系统化的引导 检查清单（Checklist-Based） 以通用的检查清单来引导检查过程 缺陷（Defect-Based） 用于需求文档，根据缺陷的分类来组织和检查场景 功能点（Function Point-Based） 按照功能点来组织和检查场景 视角（Perspective-Based） 按照不同涉众类型的视角来组织和检查场景 场景（Scenario-Based） 常用的方法 对每一个场景，都利用一系列的问题或者细节要求，来引导检查过程。缺陷、功能点、视角都是场景方法的一个特例。 逐步提升（Stepwise Abstraction） 净室软件开发中的一种方法。阅读者描述一些独立代码段的功能，然后将描述的范围逐步扩大，描述的功能抽象逐步提高，直至阅读人员描述了整个评审物件 2.3.2原型与模拟用于静态方法力所不及的复杂需求 涉及到复杂的动态行为时成本较高
为需求类开发测试用例也可以被看成一个有效的需求验证方法 无法测试的需求并非绝对有问题 排斥性需求和全局非功能性需求通常无法定义测试用例 2.3.4用户手册编制用户手册主要包含以下内容： 1.验证功能需求：对软件系统功能和实现的描述 2.验证项目范围：对系统没有实现的功能的描述 3.验证异常流程需求：问题和故障的解决 4.验证环境与约束需求：系统的安装和启动 2.3.5利用跟踪关系※业务需求（系统特性）=>用户需求（业务、任务）=>系统需求（分析模型） 逐步细化的关系 如果业务需求和用户需求没有得到后项需求（用户需求和系统需求）的充分支持，那么软件需求规格说明文档就存在不完备的缺陷。软件需求规格说明文档描述的是系统级需求，被用来进行需求验证 系统需求=>用户需求=>业务需求 如果不能依据跟踪关系找到一条系统需求的前项用户需求和前项业务需求，那么该需求就属于非必要的需求 2.3.6自动化分析
1.需求澄清 （1）理解偏差：重新进行分析工作 （2）分析遗漏：重新分析和文档化这部分信息 （3）表达不当：重新以合适的方式表达 2.发现缺失需求 重新执行需求获取等一系列工作 3.解决需求冲突 协商解决 4.修正不切实际的期望 项目调整与需求协商 2.5需求验证的实践调查需求验证是重要的 需求验证是容易被忽视的 需求验证的方法是多样的评审和原型最为广泛 三、需求管理 3.1需求管理
是被明确和固定下来的需求集合，是项目团队需要在某一特定产品版本中实现的特征和需求集合 
需求基线的主要描述内容有软件需求（需求基线的关键内容）+和软件需求相关的描述信息 标识符（ID），为后续的项目工作提供一个共同的交流参照。当前版本号（Version），保证项目的各项工作都建立在最新的一致需求基础之上。源头（Source），在需要进一步深入理解或者改变需求时，可以回溯到需求的源头。理由（Rational），提供需求产生的背景知识。优先级（Priority），后续的项目工作可以参照优先级进行安排和调度。状态（Status），交流和具体需求相关的项目工作状况。成本、工作量、风险、可变性（Cost、Effort、Risk、Volatility），为需求的设计和实现提供参考信息，驱动设计和实现工作。 3.3需求跟踪主要目的是：避免在开发过程或者演化过程中与需求基线不一致或者偏离的风险 需求跟踪是以软件需求规格说明文档为基线，在向前和向后两个方向上，描述需求以及跟踪需求变化的能力。 1.前向跟踪是指被定义到软件需求规格说明文档之前的需求演化过程 向需求的跟踪：说明涉众的需要和目标产生了哪些软件需求 从需求向后回溯：说明软件需求来源于哪些涉众的需要和目标 2.后向跟踪是指被定义到软件需求规格说明文档之后的需求演化过程 从需求向后跟踪：说明软件需求是如何被后续的开发物件支持和实现的 向需求的回溯：说明各种系统开发的物件是因为什么原因（软件需求）而被开发出来的 需求的后向跟踪可以帮助项目管理者： 需求的后向跟踪可以帮助客户和用户： 需求跟踪中针对具体需求的设计方案选择、设计假设条件以及设计结果等信息可以帮助设计人员： 需求跟踪信息还可以帮助维护人员： 3.3.2内容需求跟踪实现的具体内容是依赖于项目的跟踪策略的 
3.3.3实现方法
1.矩阵、2.实体关系模型和3.交叉引用
需求的变化是正当和不可避免的，包括：问题发生了改变环境发生了改变需求基线存在缺陷 
3.5需求管理的实践调查
3.5.1需求变更
变更发生的事件越迟，影响越大新增（Added）需求影响最大——影响最大的变更类型缺陷修复是最为频繁的变更类型范围蔓延是常见的风险因素 3.5.2需求管理工具通用的文本处理器（Word Processor）和电子表格（Spreadsheet）使用最为广泛 四、需求工程中的过程管理 4.1需求工程中的过程管理需求工程具有环境依赖性 环境因素： 市场特性 例如，客户定制开发 VS 市场驱动领域特性 例如，成熟领域 VS 不成熟领域，关键性软件 VS 一般应用技术成熟度 高 VS低组织文化 固有习惯项目特性
选择一个适用项目的过程模型，进行定制和本地化 26种需求工程的过程模型，3种典型的需求工程的过程模型： （1）完全线性的过程模型 划分为固定的活动，顺序衔接，运用于需求明确处理、简单应用系统 （2）线性迭代的过程模型：不完全顺序衔接 （3）迭代式的过程模型：复杂的迭代、并发和互相交织的关系 常见三个模板：过程说明模板、活动说明模板、技术说明模板 4.2.2 选择工作组件1.各个需求工程活动需要使用的实践方法和技术； 2.需要使用的支持工具，包括管理工具、建模工具以及各种实践方法要求的工具； 3.执行过程所需要的资源支持，包括可以重用的资源、文档的模版、错误的检查清单等等； 4.执行过程所需要的项目策略支持、过程指南以及各种工作组件的使用帮助。
PDCA模型（Plan-Do-Check-Action）  五、需求工程中的项目管理
5.1需求工程中的项目管理
项目管理：围绕着项目计划而执行的各种项目活动
（1）瀑布模型
（2）增量模型 优点：采用逐步增量和多次发布的方式减少每一次实现的需求范围，降低需求实现的风险，需要可靠的需求基线。软件的问题域比较复杂，但是业务非常成熟而且需求比较稳定 缺点：需求易变或问题域信息很难一次处理完整时并不适用，不利于用户的有效参与。
（3）领域模型 
（4）原型模型 优点： 问题域不成熟，业务活动仍然在不断发展和改变 能够很好的解决各种不确定性 缺点： 提高了需求工程阶段的成本，而且易于发生各种原型风险 
5.4团队管理
组建需求团队维持需求团队内部的有效沟通
5.5需求风险管理
风险产生的原因是对未来不利事件的不确定性 包含5个活动※
1.风险识别 常用方法是建立风险条目的检查表，逐一比照进行项目的风险识别另一个常用方法是驱动因素分析，建立决策模型，推导出可能的风险工作分解也是常用方法，建立工作分解和网络图，2.风险分析 风险分析的特征： 不确定性、损失、严重性、期间、优先级 3.制定风险管理计划 包括3各方面： 风险回避/缓解策略、风险监测、风险应急计划 4.风险跟踪 5.风险控制 5.5.2需求风险管理※风险驱动因素 应对策略 类别 示例 类别 示例 需求复杂性 系统的规模比较复杂 系统的环境比较复杂 涉及的技术比较复杂 需求建模技术 形式化建模技术，例如KAOS 建模方法学，例如UML 特殊技术，例如ERD、DFD 需求稳定性 任务复杂，有着比较大的可变空间 业务领域不稳定 系统需要解决的问题不稳定 业务领域有不确定性 系统需要解决的问题有不确定性 系统的环境约束有不确定性 需求探索技术 迭代式需求开发，例如原型法 协作式需求开发，例如JAD 需求可得性 系统用户的数量众多 缺乏用户参与 需求团队的组织存在缺陷 需求团队地理分散 需求获取技术 面谈、原型、观察等等 六、需求分析概述 6.1面向对象建模与UML概述 6.1.1相关概述面向对象 = 对象 + 类 + 继承 + 通信 面向对象的系统开发过程以体系结构为中心，以用例为驱动，是一个反复渐增的过程； 6.1.2几种典型的OO方法（4种）Booch面向对象方法（OOAD） 螺旋上升过程，强调多次重复。
2．Jacobson的面向对象方法（OOSE） 一种用例驱动的面向对象方法
3.Coad-Yourdon的面向对象方法论（OOA/OOD 4. Rumbaugh（OMT)方法 （1）主题层 （2）类及对象层 （3）结构层 （关系层） （4）属性层 （有的叫特征层） （5）服务层
（1）用例视图 作用：描述系统的功能需求，找出用例和执行者； 适用对象：客户、分析者、设计者、开发者和测试者； 描述使用的图：用例图和活动图；
（2）逻辑视图 作用：描述如何实现系统内部的功能 ； 适用对象：分析者、设计者、开发者 ； 描述使用的图：类图和对象图、状态图、顺序图、合作图和活动图 ； （3）构件视图 作用：描述系统代码构件组织和实现模块，及它们之间的依赖关系 ； 适用对象：设计者、开发者 ； 描述使用的图：构件图 ； （4）进程视图 作用：描述系统的并发性，并处理这些线程间的通信和同步 ； 适用对象：开发者和系统集成者 ； 描述使用的图：状态图、顺序图、合作图、活动图、构件图和配置图 ； （5）配置视图 作用：描述系统的物理设备配置，如计算机、硬件设备以及它们相互间的连接 ； 适用对象：开发者、系统集成者和测试者 ； 描述使用的图：配置图 ； 4种关系
1）依赖：两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。可以扩展为包含、扩展等关系。 2）关联：一种结构关系，连接模型元素及链接实例。聚合、组合是特殊类型的关联。 3）泛化：表示一般与特殊的关系，即“一般”元素是“特殊”关系的泛化。 4）实现：类元之间的语义关系，一个类元指定了由另一个类元保证执行的契约，如接口和实现它们的类或构件之间，用例和实现它们的协作之间。 6.1.5三大类十四种图表示※※※
UML以用例驱动开发过程，以体系结构为中心，以质量控制和风险管理为目标，采用反复迭代循环，渐增式螺旋上升式的开发过程。 6.2用例模型系统的需求包括四个不同的层次：业务需求、用户需求、功能性需求、非功能性需求。 用例图是系统建模的起点 描述系统的概要功能和行为 进行系统用例图绘制主要需要经过以下几个步骤：用户需求、需求分析、需求描述。 6.2.1用例文档的组成※涉众利益 前置条件、后置条件 事件流 基本事件流（S-）— 基本路径备选事件流（A-）— 备选路径补充约束 数据需求（D-）、业务规则（B-） 非功能需求、设计约束 待解决问题 相关图(用例图、活动图、类图) 6.2.2用例粒度用例粒度表示的用例的大小。 用例的粒度从大到小分成以下三个层次：概述级、用户目标级、子功能级。 6.3活动图与需求建模动作状态 ⑴原子性：即不能被分解成更小的部分； ⑵不可中断性：即一旦开始就必须运行到结束； ⑶瞬时性：即动作状态所占用的处理时间通常是极短的 活动状态 动作状态是活动状态的一个特例，如果某个活动状态只包括一个动作，那么它就是一个动作状态。 活动图的起始状态和终止状态 1个起始状态，0个或多个终止状态 6.4类图、对象图、包图元语 6.4.1分类 边界类：系统及其参与者的边界控制类：系统的控制逻辑实体类：系统使用的信息类通常具有三个分栏：名称、属性和操作 类之间的关系可以使用多重性 默认多重性为1 对象图中包含对象（Object）和链（Link）。其中对象是类的特定实例，链是类之间关系的实例 对象名：类名 对象通常只有两个分栏：名称和属性 对象使用链连接，链拥有名称、角色，但是没有多重性 关联类表示的属性和操作仅因为关联的存在而存在：属性和操作与关联两端的对象都无关。 多对多关联可以通过转化为一对多关联而得到简化 关联的基本修饰： （1）关联名即名称（Name） （2）角色（Role） （3）多重性（Multiplicity） （4）聚合（Aggregation） （5）组合（Composition） （6）导航性（Nevigation） （7）关联类 （8）约束 聚合表示事物的整体/部分关系较弱的情况组合表示事物的整体/部分关系较强的情况
包之间可以有依赖和继承等关系。 +：表示其为公有成员，其它类可以访问（可见） -：表示其为私有成员，不能被其他类访问（不可见），可缺省 #：表示其为保护成员，一般用于继承，只能被本类及派生类使用 6.5状态图状态图中每一个状态包含的活动有三个标准事件， entrydoexit转换可以标注与此转换相关的选项，如事件、监护条件和动作。 历史指示器是一个伪状态，可以有几个进入它的状态迁移，但没有离开它的状态迁移 历史状态使得对象能在活动被中断或需要逆行时回到最近的那个状态 
活动图与状态图的比较 活动图与状态图的相同点
活动图与状态图的不同点
|
【本文地址】