需求分析培训_软件开发管理

PPT 内容

1. 软件需求分析培训资料广州新软计算机技术有限公司
2. 目录需求概述需求开发与管理过程需求获取方法需求分析建模方法需求管理工具
3. 什么是软件需求IEEE（美国电气与电子工程师学会，英文全称是：The Institute of Electrical and Electronics Engineers ）软件工程标准词汇表(1997年)中将需求定义为：用户解决问题或达到目标所需的条件或权能(Capability)；系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能；一种反映上面(1)或(2)所描述的条件或权能的文档说明。
4. 需求的类型（1）在UP（统一过程，Unified Process）中，软件需求是根据FURPS+模型来分类的，其中FURPS的含义如下： Functional（功能性） Usability（可用性） Reliability（可靠性） Performance（性能） Supportability（可支持性） “+”是指一些辅助性的和次要的因素：设计约束实施需求接口需求物理需求
5. 需求的类型（2）软件需求类型功能性需求非功能性需求设计约束需求
6. 606功能性需求功能性需求表示了系统的行为。这些需求通常是面向动作的(“当用户做x时,系统将做y”。)在定义功能性需求时,应该在需求的确切性和通用性或多义性之间寻求较好的平衡。大多数功能性需求都可以用声明语句或用例来表示。功能性需求包括：特性集功能安全性
7. 607非功能性需求大约有八类非功能性需求：观感需求易用性需求性能需求可操作性需求可维护性和可移植性需求安全性需求文化和政策需求法律需求
8. 608设计约束需求设计约束定义为:对系统的设计或开发系统的过程的限制不影响系统的外部行为,但必须被完成以满足技术、商业或合同的义务。设计约束代表已经批准并必须遵循的设计决定。其中包括软件语言、软件流程需求、开发工具的指定用途、构架及设计约束、购买的构件、类库等。设计约束常包括: 操作环境,例：用VB编写软件与已有系统的兼容性,例：新的应用必须能够在新旧两种平台上都能运行应用标准项目被开发所使用的规章和标准的实体
9. 需求的一般属性创建需求的时间需求的版本号创建需求的作者负责认可该需求的人员需求涉及的子系统使用的验证方法或接受的测试标准
10. 需求的类型属性1 状态 2 优先级 3 工作量 4 风险 5 稳定性 6 目标发布版 7 职责分配 8 原因
11. 需求中人员角色剖析涉众风险承担者客户领域专家变更控制经理系统分析员
12. 什么是好的需求好的需求是正确的、无歧义的、可检验和可验证的并且是可跟踪的。好的需求集合是完整的、一致的和可修改的。(IEEE软件需求规格说明标准)
13. 目录需求概述需求开发与管理过程需求获取方法需求分析建模方法需求管理工具
14. 需求过程所涉及的工作
15. 需求开发——包括需求获取、需求分析、编写需求规格说明、验证需求四个阶段，在这四个阶段执行以下活动：确定产品所期望的用户类；获取每个用户类的需求；了解实际用户任务和目标以及这些任务所支持的业务需求；分析源于用户的信息以区别业务需求、功能需求、质量属性、业务规则，建议解决的方法和附加的信息；分解需求，并将需求中的一部分分配给软件组件；了解相关属性的重要性；划分实施优先级；编写需求规格说明和模型；评审需求规格，验证对用户需求的正确理解和认识。需求开发
16. 需求管理——是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性，以及与其它需求和其它项目工件之间的可追踪性。需求管理活动包括定义需求基线评审需求变更并评估每项需求变更对软件产品的影响从而决定是否实施它。以一种可控制的方式将需求变更融入当前的软件项目。让当前的项目计划和需求保持一致。估计变更所产生的影响并在此基础上协商新的约定实现通过需求可跟踪对应的设计、源代码和测试用例。在整个项目过程中跟踪需求状态及其变更情况。需求管理
17. 过程工作流业务现状与前景调研：采用会谈、文档收集、观察等传统的需求获取方法，获取预期目标的信息及其系统的环境。业务分析：根据获取的系统环境等初始材料，抽象出系统的目标；目标演化形成软件功能包图：将目标精化、分解到可操作的软件目标；客户需求验证：审查软件目标合理性、完备性软件包的用例图建模：从软件需求层目标模型中，映射获取系统的组织级、系统级及子功能级用例，包括用例之间的相互关系。用例分析：获取顺序图等。用例规约：创建用例卡，融合形成完整结构文档产品需求验证：审查软件需求的合理性、完备性、一致性
18. 目录客观认识需求需求开发与管理过程需求获取方法需求分析建模方法需求管理工具
19. 需求获取的主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、系统环境等，对任务进行分析、从而开发、捕获和修订用户的需求，以建立良好的沟通渠道和方式。需求获取需要执行以下活动：确定需求开发过程编写项目视图和范围文档获取涉众请求选择每类用户的产品代表建立典型的以用户为核心的队伍让用户代表确定用例召开应用程序开发联系会议分析用户工作流程确定质量属性和其它非功能需求需求获取
20. 访谈和调研和用户进行访谈和调研通常是适用于任何环境下的最重要最直接的方法之一。访谈的一个主要目标是确保访谈者的偏见或主观意识不会干扰自由的交流。 “环境无关问题”就是不涉及任何背景的问题。通过几次这样的访谈，开发人员和系统分析员能获得一些问题域中的知识，对要解决的问题有进一步的理解。访谈和调研
21. 专题讨论会是一种可用于任何情况下的软件需求调研方法。专题讨论会的目的是鼓励软件需求调研并且在很短的时间内对讨论的问题达成一致。专题讨论会一般由开发团队的成员主持，主要讨论系统应具备的特征或者评审系统特性。专题讨论会前的准备工作是能否成功的举行会议的关键。专题讨论会
22. 脑力风暴脑力风暴是一种对于获取新观点或创造性的解决方案而言非常有用的方法。通常，专题讨论会的一部分时间是用于进行脑力风暴，找出关于软件系统的新想法和新特征。脑力风暴包括两个阶段：想法产生阶段和想法精化阶段。脑力风暴
23. 场景串联场景串联的目的是为了尽早的从用户那里得到用户对建议的系统功能的意见。场景串联提供了用户界面以说明系统操作流程，它容易创建和修改，能让用户知道系统的操作方式和流程。根据与用户交互的方式，场景串联被分成三种模式：静态的场景串联、动态的场景串联以及交互的场景串联。选择提供哪种场景串联是根据系统的复杂性和需求缺陷的风险来确定的。场景串联
24. 目录需求概述需求开发与管理过程需求获取方法需求分析建模方法需求管理工具
25. 需求分析的任务需求分析的任务：就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。
26. 为软件目标集创建包图包图是按照目标、职能和业务需求的相关性，从总体上把系统的软件目标对等划分成为若干个需求包，由这些包相互关联构成的结构图。包图用分层UML包图来描述。包应该具有内聚性和相对独立性。即需求包内部的需求之间应该具有较高的关联性，而各个需求包之间的关联关系应该尽量地少。根据需求结构的层次性，如果需要，需求包可以继续分解和细化。包图是系统分析时确定系统逻辑结构重要依据。
27. 27目标模型FM三种视图FeaturesThe Refinement ViewsThe Constraint ViewsThe Interaction Views记录了目标间的精化关系记录了目标间的交互关系记录了目标间的约束关系目标模型 = 目标 + 关系 (精化 + 约束 + 交互)
28. 28PGM的结构使用目标模型作为项目范围的识别方法基本思想把目标作为项目建设要求的基本描述实体使用目标以及目标间的关系刻画项目范围空间产品期望产品目标目标关联面向目标的项目范围视图
29. 包图每一个需求用一个包来表示，称为需求包。包与包之间用组成关系关联起来。需求包可以逐层分解，构成分层用例需求结构。需求结构图有两种形式：书店信息系统需求结构图
30. 书店信息系统需求结构图
31. 为包进行用例图建模1．用例图建模 2．用例的动态行为分析
32. 用例建模的基本原理软件目标是用例建模的依据。软件目标是用例引入的主要来源。用例图描述用例建模的结果。一个系统的全部用例图构成该系统的需求模型。用例分析是软件行为分析的手段。
33. 用例分析用例(Use Case)是用户与系统之间，为达到确定目的所进行的一次交互活动。用户向系统提供某些交互要求，系统向用户反馈可见的结果。用例是系统功能需求的反映，一个用例描述用例的一项功能。用例是系统功能需求的反映。
34. 参与者用例边界包含关系用例图(Use Case Diagram)用来描述软件系统向交互活动参与者提供的一组相关的功能。在一个用例图中，有一个或多个参与者与一个或多个用例相互关联。参与者计划管理订单管理合同管理到货管理计划订购采购员计划员书目管理供书商管理
35. 事务管理分解功能用例图编辑员工基本信息浏览员工基本信息输出员工信息员工基本信息管理员工工资计算员工工资发放员工工资管理编辑员工勤绩信息员工勤绩统计员工勤绩管理浏览员工勤绩信息办公员包含关系依赖关系
36. 用例规约用例说明(UseCase Explanation)是对功能用例图中的用例做出的说明。在用例说明中，需要描述用例的编号、名称、参与者和用例的功能以及交互过程。（说明文本格式目前尚未统一，下表仅供参考。）
37. 11637用例描述文档模板用例名称用例编号版本号作者创建时间评审者测试者批准者主要参与者简要描述触发事件前置条件事件流后置条件规则描述可选事件流非功能性需求修改历史
38. 用例卡模版说明名称。名称无疑应该表明用户的意图或用例的用途，如“研究班招生”。标识符 [可选]。唯一标识符，如 "UC1701"，在项目的其他元素（如类模型）中可用它来引用这个用例。说明。概述用例的几句话。参与者 [可选]。与此用例相关的参与者列表。尽管这则信息包含在用例本身中，但在没有用例图时，它有助于增加对该用例的理解。状态 [可选]。指示用例的状态，通常为以下几种之一：进行中、等待审查、通过审查或未通过审查。频率。参与者访问此用例的频率。这是一个自由式问题，如用户每次录访问一次或每月一次。前置条件。一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足。后置条件。一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足。被扩展的用例 [可选]。此用例所扩展的用例（如果存在）。扩展关联是一种广义关系，其中扩展用例接续基用例的行为。这是通过扩展用例向基用例的操作序列中插入附加的操作序列来实现的。这总是使用带有 <> 的用例关联来建模的。被包含的用例 [可选]。此用例所包含用例的列表。包含关联是一种广义关系，它表明对处于另一个用例之中的用例所描述的行为的包含关系。这总是使用带有 <> 的用例关联来建模的。也称为使用或具有 (has-a) 关系。假设 [可选]。对编写此用例时所创建的域的任何重要假设。您应该在一定的时候检验这些假设，或者将它们变为决策的一部分，或者将它们添加到操作的基本流程或可选流程中。基本操作流程。参与者在用例中所遵循的主逻辑路径。因为它描述了当各项工作都正常进行时用例的工作方式，所以通常称其为适当路径 (happy path) 或主路径 (main path) 。可选操作流程。用例中很少使用的逻辑路径，那些在变更工作方式、出现异常或发生错误的情况下所遵循的路径。修改历史记录 [可选]。关于用例的修改时间、修改原因和修改人的详细信息。风险 [可选]。如果存在，则为与此用例的开发相关的问题或操作项目的列表。决策。关键决策的列表，这些决策通常由您的 SME 作出，并属于用例的内容。将这些决策记录下来对于维护团体记忆库 (group memory) 是相当重要的。
39. 11639用活动图建模用例的路径用活动图建模用例路径。确定主事件流和备选事件流(各个动作序列)。建模事件流层的事件和条件。说明规则和约束。
40. 40活动图活动图用于对一个系统的动态方面建模。活动图是描述交互关系的一种方式，着重体现对象的工作流程；当对象进行交互的同时，自身也要完成一些工作即活动。活动图描述这些活动以及它们之间的顺序。
41. 41活动图活动图由动作状态组成，它包含完成一个动作的活动的规约(即规格说明) 。当一个动作完成时，将离开该动作状态。活动图中的动作部分还可包括消息发送和接收的规约。
42. 42活动图中的基本图符元素活动的起点活动的终点活动组合活动判断同步条泳道对象：信号接收信号发送信息流数据流信号流注释体及注释连接
43. 例.在线购书系统支付流程
44. 11644用顺序图建模单个事件流用顺序图建模单个事件流,找出动作序列中的交互对象,分析对象交互,并建模动作层的事件和条件,说明每个动作的规则和约束。
45. 22145顺序图多数情况下，使用顺序图来阐明用例实现，即说明对象如何通过交互来执行全部或部分用例的行为。可以用一个或多个顺序图来阐明实现用例的对象交互过程。在典型的组织结构中，主事件流将有一个顺序图，而每个独立的用例分支流都分别有一个顺序图。
46. 22146顺序图的三个元素1. 顺序图展示了几个对象之间的动态协作关系,显示了对象之间的交互，即系统执行的某一特定时间点所发生的事。 2. 用来显示对象之间发送的消息以及发送的消息的时间顺序。 3.对象之间发送的消息的时间顺序。
47. 22147顺序图多数情况下，使用顺序图来阐明用例实现，即说明对象如何通过交互来执行全部或部分用例的行为。可以用一个或多个顺序图来阐明实现用例的对象交互过程。在典型的组织结构中，主事件流将有一个顺序图，而每个独立的用例分支流都分别有一个顺序图。
48. 22148顺序图中的基本元素对象注释简单消息异步消息同步消息回归消息发送异步消息返回消息能创建对象的同步消息删除标志删除消息注释连接分支生命线: 自身调用消息
49. 49实例：讨论学生与课程类的动态关系
50. 50协作图协作图用于描述相互合作的对象间的交互关系和链接关系。虽然顺序图和协作图都用来描述对象间的交互关系，但侧重点不一样。顺序图着重体现交互的时间顺序协作图则着重体现交互对象间的静态链接关系。
51. 51协作图协作图强调参加交互的对象的组织。顺序图和协作图都来自UML的元模型中相同的信息，所以两者在语义上是等价的。它们可以从一种形式的图转换为另一种形式的图，而不丢失任何信息。交互图用于对系统的动态方面建模。这些动态方面可能涉及一个系统的体系结构的任意视图中的任何种类的实例的交互，包括类(含主动类)、接口、构件和节点的实例的交互。
52. 22152协作图中的基本图符元素对象多个对象链接组成链接聚集链接指向源的简单消息指向目的的简单消息指向源的异步消息指向目的的异步消息指向源的同步消息指向目的的同步消息注释注释连接
53. 53实例：讨论学生与课程类的动态关系
54. 11654用状态图建模对象的状态状态图描绘事件与对象状态的关系。当对象接受了一个事件以后,它的下个状态取决于当前状态及所接受的事件。由事件引起的状态改变称为“转换”。如果一个事件并不引起当前状态发生转换,则可忽略这个事件。通常,用一张状态图描绘一类对象的行为,它确定了由事件序列引出的状态序列。但是,也不是任何一个对象类都需要有一个状态图来描绘它的行为。
55. 55状态图的应用概念状态图定义了状态机的表示符号，在对象的生命周期中,状态机用来捕捉由外部事件引起的变化。事件对对象发出命令,命令导致对象发生变化，反过来影响对象的行为。状态图建模对象生命周期各个时期的状态以及引起变化的事件。对于一个在一段时间内连续运行的软件系统，一定是由许多对象在不断的交互，在交互过程中只有对象在不断的改变状态其交互才具有意义，并且对用户具有价值。
56. 56状态图状态图通常是对类描述的补充，它说明该类的对象所有可能的状态以及哪些事件将导致状态的改变．状态图只是对单个对象建立模型。表达单个对象所处的可能状态及状态之间的转移一个事件可以是另一个对象向它发送的一条消息，或者是满足了某些条件．状态的改变称为迁移(transition)．一个状态迁移还可以有与之相关的动作，该动作指出状态迁移时应做什么．
57. 57状态所具有的属性对象在交互中具有不同的状态。状态可以转换或变换、转移。状态的变换需要事件触发。触发一个状态变换完成需要执行一个动作。
58. 58状态图的基本图符元素初态终态中间状态复合状态条件判断标志并发条历史标志转移注释注释这接
59. 59判断标志：用于实现状态间的条件分支转移。历史标志：对复合状态中的某个子状态做标志，说明该子状态是退出复合状态时最后所处的状态。
60. 60 转移包括5部分信息源状态: 闲置目标状态: 拨号事件拿起话筒事件参数: (按下的键) 条件条件表达式键=0.1.2.3.4.5.6.7.8.9.Redial 动作动作表达式:/Redial=SetRedial(Redisal) 其中: 返回值变量:Redial 动作表达式名字: SetRedial 动作表达式参数:(Redisal)
61. 软件(产品)需求说明书 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. 软件功能规约 4.1 概述 4.2 软件包的用例模型 4.3 用例规约分析说明 5 软件功能限制因素 5.1 概述 5.2 非功能需求 5.3 设计约束需求 6. 风险分析 6.1 软件面临的主要风险 6.2 风险的处理策略 7. 遗留问题最终完整产品需求说明书目录样例
62. 需求验证的方法几种需求验证的基本方法。 1) 自查法自查法由需求分析人员对自己所确定的用例需求进行审核和验证，纠正需求中存在的问题。自查法又可以分为多种具体方法。第一种是小组审查法，即由一名分析人员向开发小组中其他人员介绍用例需求，小组中的成员进行提问，由介绍人进行解答。 2) 用户审查法分析人员可以把《用例需求说明书》提交给用户，有条件时可以同时编写一份针对此需求的《用户使用说明书》并提交给用户，用户找出不满意或认为不能实现的需求，双方再对这些有争议的需求进行讨论，最后达成一致认识。
63. 3) 专家审查法专家审查法是指聘请业务领域、用例、政策、法律等方面的专家对用例需求进行审查。 4) 原型法原型法是对存在的有争议或拿不准的需求，通过建立原型进行验证，以确定需求的正确性。
64. 需求变更管理是项目管理中非常重要的一项工作。有效的需求变更管理能对变更带来的潜在影响及可能的成本费用进行评估。需求变更管理中活动一般包括：确定需求变更控制过程建立需求变更控制委员会进行需求变更影响分析建立需求基准版本和需求控制版本文档维护需求变更的历史记录跟踪每项需求的状态跟踪所有受需求变更影响的工作产品衡量需求稳定性需求变更管理
65. 目录需求概述需求开发与管理过程需求获取方法需求分析建模方法需求管理工具
66. 需求管理工具Rational Rose Rational ClearCase Rational RequisitePro Borland Caliber Rational XDE
67. THE END Thank you!

需求分析培训

weihual

贡献于2012-05-15

需求分析培训

PPT 内容

PPT 图集

相关PPT