2019实用需求开发过程简述.ppt

上传人:上海哈登 文档编号:2856524 上传时间:2019-05-29 格式:PPT 页数:31 大小:657.52KB
返回 下载 相关 举报
2019实用需求开发过程简述.ppt_第1页
第1页 / 共31页
2019实用需求开发过程简述.ppt_第2页
第2页 / 共31页
2019实用需求开发过程简述.ppt_第3页
第3页 / 共31页
2019实用需求开发过程简述.ppt_第4页
第4页 / 共31页
2019实用需求开发过程简述.ppt_第5页
第5页 / 共31页
点击查看更多>>
资源描述

《2019实用需求开发过程简述.ppt》由会员分享,可在线阅读,更多相关《2019实用需求开发过程简述.ppt(31页珍藏版)》请在三一文库上搜索。

1、实用需求开发过程综述,要旨,学会“以目标为基础、以用例为中心的三次迭代式需求分析”的过程 体会“初始、细化、构造与移交四步走”的路线,第一次迭代(初始):学会进行项目目标分解、进行项目目标可研分析,构造提交项目目标模型,形成项目大纲 第二次迭代(细化):学会进行用例图建模,进行客户需求分析,构造提供软件功能模型,形成客户需求文档 第三次迭代(构造):学会对用例进行“三位”一体的描述方式,分析软件用例的动态行为,构造提交用例的业务流程图、实体类图、原型图,形成产品需求说明书。 需求验证(移交):学会从需求类型与属性角度评估需求的质量,移交产品需求说明书,初始:目标建模(早期需求分析),目标方法在

2、实际项目中的运用,第一步:建立业务目标到软件功能目标的转化模型 第二步:建立业务限制因素到软件非功能目标的转化 第三步:建立软件功能目标与非功能目标之间的双向束定关系,第一步:业务目标建模,6,包图,每一个需求用一个包来表示,称为需求包。包与包之间用组成关系关联起来。需求包可以逐层分解,构成分层用例需求结构。需求结构图有两种形式:,书店信息系统需求结构图,书店信息系统需求结构图,第二步:业务限制因素分析,9,第三步:两种底层目标的束定,为包进行用例建模,细化:用例建模,用例建模的基本原理,软件目标是用例建模的依据。 软件目标是用例引入的主要来源。 用例图描述用例建模的结果。一个系统的全部用例图

3、构成该软件包的需求模型。,用例,用例(Use Case)是用户与系统之间,为达到确定目的所进行的一次交互活动。用户向系统提供某些交互要求,系统向用户反馈可见的结果。用例是系统功能需求的反映,一个用例描述用例的一项功能。 用例是系统功能需求的反映。,用例图(Use Case Diagram)用来描述软件系统向交互活动参与者提供的一组相关的功能。在一个用例图中,有一个或多个参与者与一个或多个用例相互关联。,参与者,计划管理,订单管理,合同管理,到货管理,计划订购,采购员,计划员,书目管理,供书商管理,事务管理功能用例图,事务管理分解功能用例图,包含关系,依赖关系,构造:用例的动态行为分析,用例分析

4、是软件行为分析的手段,诸如:在线支付用例的三位一体描述 业务流程图 实体类图 界面原型图,用例规约,用例说明(UseCase Explanation)是对功能用例图中的用例做出的说明。在用例说明中,需要描述用例的编号、名称、参与者和用例的功能以及交互过程。(说明文本格式目前尚未统一,下表仅供参考。),用例卡模版,名称。名称无疑应该表明用户的意图或用例的用途,如“研究班招生”。 标识符 可选。唯一标识符,如 “UC1701“,在项目的其他元素(如类模型)中可用它来引用这个用例。 说明。概述用例的几句话。 参与者 可选。与此用例相关的参与者列表。尽管这则信息包含在用例本身中,但在没有用例图时,它有

5、助于增加对该用例的理解。 状态 可选。指示用例的状态,通常为以下几种之一:进行中、等待审查、通过审查或未通过审查。 频率。参与者访问此用例的频率。这是一个自由式问题,如用户每次录访问一次或每月一次。 前置条件。一个条件列表,如果其中包含条件,则这些条件必须在访问用例之前得到满足。 后置条件。一个条件列表,如果其中包含条件,则这些条件将在用例成功完成以后得到满足。 被扩展的用例 可选。此用例所扩展的用例(如果存在)。扩展关联是一种广义关系,其中扩展用例接续基用例的行为。这是通过扩展用例向基用例的操作序列中插入附加的操作序列来实现的。这总是使用带有 的用例关联来建模的。 被包含的用例 可选。此用例

6、所包含用例的列表。包含关联是一种广义关系,它表明对处于另一个用例之中的用例所描述的行为的包含关系。这总是使用带有 的用例关联来建模的。也称为使用或具有 (has-a) 关系。 假设 可选。对编写此用例时所创建的域的任何重要假设。您应该在一定的时候检验这些假设,或者将它们变为决策的一部分,或者将它们添加到操作的基本流程或可选流程中。 基本操作流程。参与者在用例中所遵循的主逻辑路径。因为它描述了当各项工作都正常进行时用例的工作方式,所以通常称其为适当路径 (happy path) 或主路径 (main path) 。 可选操作流程。用例中很少使用的逻辑路径,那些在变更工作方式、出现异常或发生错误的

7、情况下所遵循的路径。 修改历史记录 可选。关于用例的修改时间、修改原因和修改人的详细信息。 风险 可选。如果存在,则为与此用例的开发相关的问题或操作项目的列表。 决策。关键决策的列表,这些决策通常由您的 SME 作出,并属于用例的内容。将这些决策记录下来对于维护团体记忆库 (group memory) 是相当重要的。,软件(产品)需求说明书 1. 引言 1.1 项目简介 1.2 编写说明 1.3 参考资料 2. 目标 2.1 概述 2.2 业务目标 2.2.1 总目标 2.2.2 业务目标 2.2.3 限制性因素 3. 软件功能结构 3.1 软件包结构图 3.2 软件包的说明 4. 软件功能规

8、约 4.1 概述 4.2 软件包的用例模型 4.3 用例规约分析说明 5 软件功能限制因素 5.1 概述 5.2 非功能需求 5.3 设计约束需求 6. 风险分析 6.1 软件面临的主要风险 6.2 风险的处理策略 7. 遗留问题,最终完整产品需求说明书目录样例,移交:通过验证发布需求,需求验证的方法,几种需求验证的基本方法。 1) 自查法 自查法由需求分析人员对自己所确定的用例需求进行审核和验证,纠正需求中存在的问题。自查法又可以分为多种具体方法。第一种是小组审查法,即由一名分析人员向开发小组中其他人员介绍用例需求,小组中的成员进行提问,由介绍人进行解答。 2) 用户审查法 分析人员可以把用

9、例需求说明书提交给用户,有条件时可以同时编写一份针对此需求的用户使用说明书并提交给用户,用户找出不满意或认为不能实现的需求,双方再对这些有争议的需求进行讨论,最后达成一致认识。,3) 专家审查法 专家审查法是指聘请业务领域、用例、政策、法律等方面的专家对用例需求进行审查。 4) 原型法 原型法是对存在的有争议或拿不准的需求,通过建立原型进行验证,以确定需求的正确性。,需求移交的目的: (1)形成甲乙双方的工程实施技术合同 (2)确定了施工团队的施工方案、依据 (3)达成了多方公认的验收依据、标准,需求移交的方式: (1)了解需求的属性与类型 (2)度量需求类型的完备性 (3)度量需求属性的质量,END,

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 其他


经营许可证编号:宁ICP备18001539号-1