第1讲客观认识需求类型和属性精.ppt

《第1讲客观认识需求类型和属性精.ppt》由会员分享，可在线阅读，更多相关《第1讲客观认识需求类型和属性精.ppt（60页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第1讲客观认识需求类型和属性601第1页，本讲稿共60页602目录目录软件需求类型软件需求类型功能性需求非功能性需求设计约束需求软件需求属性软件需求属性第2页，本讲稿共60页603软件需求类型软件需求类型系统越大越复杂，出现的需求类型就越多。一个需求类型不过是指需求的一个类。通过确定需求类型，团队可以把大量需求组织成意义明确且更容易管理的组。在一个项目中建立不同类型的需求有助于团队成员对变更请求进行分类，并使相互之间的沟通更为清楚明确。对需求进行分类可以使项目更容易管理。第3页，本讲稿共60页604需求类型的一种分类方法需求类型的一种分类方法需求的种类各种各样。一种分类的方法叫作 FURPS+

2、FURPS+模型，它使用首字母缩写词 FURPS 来描述具有以下子类别的主要需求类别。功能性功能性 可用性可用性 可靠性可靠性 性能性能可支持性可支持性FURPS+中的“+”可提醒您还要包括如下需求：设计约束实施需求接口需求物理需求第4页，本讲稿共60页605需求类型模型需求类型模型需求类型主要分为三类：功能性需求非功能性需求设计约束需求第5页，本讲稿共60页606需求类型模型需求类型模型 第6页，本讲稿共60页607功能性需求功能性需求第7页，本讲稿共60页608功能性需求功能性需求功能性需求表示了系统的行为。这些需求通常是面向动作的(“当用户做x时,系统将做y”。)在定义功能性需求时,应该

3、在需求的确切性和通用性或多义性之间寻求较好的平衡。大多数功能性需求都可以用声明语句或用例来表示。功能性需求包括：特性集 功能 安全性第8页，本讲稿共60页609用例模型用例模型用例模型主要设置有关系统的功能性需求，并用作分析和构架设计的核心输入。用例模型通过更为详细的事件流得以改进。第9页，本讲稿共60页6010用例模型的主要元素用例模型的主要元素角色角色描述用例用例描述简要说明、前置条件、主事件流、备选事件流、后置条件用例之间的关系(使用、扩展、泛化)第10页，本讲稿共60页6011用例模型的用例模型的UMLUML可视化可视化用例图可视化角色、用例、用例关系和系统边界活动图可视化用例事件流的

4、结构 顺序图可视化用例事件流的(动作序列)交互过程，分解对象、消息和动作类图可视化用例实体结构关系第11页，本讲稿共60页6012非功能性需求非功能性需求第12页，本讲稿共60页6013非功能性需求非功能性需求大约有八类非功能性需求：非功能性需求：观感需求：易用性需求：性能需求：可操作性需求：可维护性和可移植性需求：安全性需求：文化和政策需求：法律需求：第13页，本讲稿共60页6014非功能性需求非功能性需求 第14页，本讲稿共60页6015非功能性需求非功能性需求 非功能性软件需求典型地用来表示详细描述定义中的“系统的属性”或者“系统环境的属性”。非功能性软件需求主要主要包括和归纳为以下四种

5、：1.适用性2.可靠性3.性能4.可支持性 第15页，本讲稿共60页60161.1.可用性可用性(适用性适用性)需求需求描述系统可以被预想的用户学习和操作的简单性非常重要。可用性需求可包含如下子类别：人员因素 美观 用户界面的一致性 联机帮助和环境相关帮助向导和代理用户文档培训材料和培训时间第16页，本讲稿共60页6017可用性可用性(适用性适用性)需求需求例如：指出普通用户和高级用户要高效地执行特定操作所需的培训时间指出典型任务的可评测任务次数，或者指出在符合公认的可用性标准（如 IBM 的 CUA 标准和 Microsoft 的 GUI 标准）方面的需求第17页，本讲稿共60页6018用户

6、权利法案用户权利法案(1998)(1998)1.用户总是对的,如果系统的使用有问题,那么系统是问题所在,而不是用户。2.用户有权进行简单安装和卸载软件和硬件系统,并且不产生任何负面效果。3.用户有权要求系统达到承诺的性能。4.用户有权获得易于使用的指导(用户指南、在线或语境帮助、出错信息),从而理解和使用系统,达到既定目标,并从问题状况有效而优雅地恢复。5.用户有权控制系统,并且能使系统响应请求。第18页，本讲稿共60页6019用户权利法案用户权利法案(1998)(1998)6.用户有权要求系统提供有关正在进行任务以及进展的清晰、准确而可理解的信息。7.用户有权被明确通知所有有关正确使用软件或

7、硬件的系统需求信息。8.用户有权知道系统的能力限制。9.用户有权与技术提供商联系,并得到合理而有用的响应。10.用户应该是软件和硬件技术和主人,而不是反过来。产品应该简单、直观地使用。第19页，本讲稿共60页60202.2.可靠性需求可靠性需求可靠性可靠性需求应该描述系统到底以哪种用户能够接受的程度运转。需要考虑的可靠性需求有：可用性平均故障间隔时间（MTBF）平均修复时间准确性错误和缺陷率每类错误第20页，本讲稿共60页60212.1 2.1 可用性可用性系统对于一个使用时间的指定百分比必须是可用的。最极端的情况下,需求可能指定“无停业”可用性,即,一天24小时,一年365天。比较常见的是,

8、规定在上午8点到午夜之间99%或99.9%的可用性。注意需求必须明确定义可用性的含意。是否100%的可用性意味着所有的用户在所有时间都能使用系统提供的所有服务?第21页，本讲稿共60页60222.2 2.2 平均故障间隔时间（平均故障间隔时间（MTBFMTBF）通常以小时为单位指定,也可以以天、月或年为单位指定。要强调的是,这需要精确:需求必须仔细地定义什么是故障。第22页，本讲稿共60页60232.3 2.3 平均修复时间平均修复时间(MTTR)(MTTR)允许系统出故障后不运转的时间有多长?例如,用户可能会规定90%的系统故障要在5分钟内可修复,99.9%的系统故障要在一小时内修复在这里,

9、精确仍然非常重要:需求必须指明修复是否意味着所有用户都可以再一次访问所有服务或者是否完全恢复的子集是可接受的 第23页，本讲稿共60页60242.4 2.4 准确性准确性产生数字输出的系统要求有多高的精确度?例如,金融系统的结果必须准确到分还是厘?第24页，本讲稿共60页60252.5 2.5 错误和缺陷率错误和缺陷率通常是用错误数/KLOC(千行代码)表示或每个功能点的错误数表示最大错误和缺陷率。第25页，本讲稿共60页60262.6 2.6 每类错误每类错误通常分为微小的错误、显著的错误和关键性错误三类。需求必须定义什么是关键性的错误,例如数据的完全丢失或者系统的某些功能完全不能使用。第2

10、6页，本讲稿共60页60273.3.性能需求性能需求性能需求可对功能性需求强加条件。性能需求通常包括以下几类:事务的响应时间:平均值,最大值。吞吐量:每秒事务数。容量:系统可容纳的客户总数或事务数。退化模式:当系统被降级时,可接受的运转模式。如果新的系统必须和其他系统用共享硬件资源,则还要对系统到底能够在多大程度上文明地使用类似CPU、内存、信道、磁盘空间以及带宽等稀有资源加以规定。第27页，本讲稿共60页6028性能需求性能需求对于一个给定行为，它可以对以下项规定性能参数：速度、效率、可用性、准确性、吞吐量、响应时间、恢复时间，或 资源用途。第28页，本讲稿共60页6029基于用例的性能模型

11、基于用例的性能模型评估性能风险确定关键用例选择关键性能场景建立性能目标构造性能模型增加软件资源需求增加计算机资源需求评价性能模型(修改创建场景)验证和确认模型修改产品构思修正性能目标第29页，本讲稿共60页6030第30页，本讲稿共60页60314.4.可支持性需求可支持性需求可支持性是指为了升级或修复,软件被修改的能力。对某些应用领域,未来可能的升级是可预测的,因此需求可以规定维护小组的简单升级、中等升级以及复杂升级的“响应时间”。例如,假定我们要建立一个新的工资系统。这种系统的需求之一是必须计算政府为每个职员扣除的税。用户当然知道政府每年会改变计算税的算法 第31页，本讲稿共60页6032

12、可支持性需求可支持性需求可支持性需求可包括：可测试性、可扩展性、可适应性、可维护性、兼容性、可配置性、可服务性、可安装性，或 是否可本地化（国际化）。第32页，本讲稿共60页6033设计约束需求设计约束需求第33页，本讲稿共60页6034设计约束定义设计约束定义设计约束定义为:对系统的设计或开发系统的过程的限制不影响系统的外部行为,但必须被完成以满足技术、商业或合同的义务。设计约束代表已经批准并必须遵循的设计决定。其中包括软件语言、软件流程需求、开发工具的指定用途、构架及设计约束、购买的构件、类库等。第34页，本讲稿共60页6035设计约束设计约束设计约束常包括:操作环境,例：用VB编写软件与

13、已有系统的兼容性,例：新的应用必须能够在新旧两种平台上都能运行 应用标准项目被开发所使用的规章和标准的实体 第35页，本讲稿共60页6036设计需求设计需求(设计约束设计约束)通常一条需求应该允许一种以上的设计选择:设计是有意识地在多种选择之间作出抉择。设计需求常称为设计约束设计约束，它规定或约束了系统的设计。只要有可能,我们就应该让设计人员来做这种抉择,而不应该在需求中指定它,因为只有设计人员最有资格评价每种选择的技术价值和经济价值。只要我们对设计做了规定不允许选择(用Oracle DBMS)设计就会受到约束,就会丧失某种程度的灵活性和开发自由度。第36页，本讲稿共60页6037设计约束设计

14、约束几乎所有项目都会有一些设计约束。通常,处理它们的最佳途径是遵循以下指南:把它们和其他需求区分开来把所有设计约束统一放到整个需求包中的某个特定位置,或者使用一些特殊的属性以便可以被聚合。确定每个设计约束的来源 为每条约束的理由建档 第37页，本讲稿共60页6038实施需求实施需求实施需求规定或约束了系统的编码或构建。例如：所需标准、实施语言、数据库完整性策略、资源限制和 操作环境。第38页，本讲稿共60页6039接口需求接口需求接口需求规定了 系统必须与之交互操作的外部项，或 对这种交互操作所使用的格式、时间或其他因素的约束。第39页，本讲稿共60页6040物理需求物理需求物理需求规定了系统

15、必须具备的物理特征；例如，材质、形状、尺寸和 重量。这种需求类型可用来代表硬件要求，如 物理网络配置需求。第40页，本讲稿共60页6041软件需求属性软件需求属性第41页，本讲稿共60页6042需求属性需求属性可以为需求和其他相关的模型元素设置属性，以便于追踪它们的一般状态。每个项目都可能有其特定的属性集，而且所追踪元素的类型不同，属性也会有所不同。每个需求类型都有一组唯一属性，与在该级别上定义的每个需求相关联。对于已确定的每一需求类型，都应列出将要使用的属性，并简要解释其含义。第42页，本讲稿共60页6043需求属性需求属性需求类型和每种类型的属性是为整个项目定义的，由此确保了团队上下使用的

16、一致性。需求的多维性以及不同类型的需求（每种类型都有自己的属性）对于组织大量需求和管理项目的整体规模来说是不可或缺的。为每个需求类型需求类型提供一个矩阵，其中一条轴上列出需求，而另一个轴上列出所有属性。对于每个需求，显示其各自属性的状态。第43页，本讲稿共60页6044一般属性一般属性创建需求的时间需求的版本号创建需求的作者负责认可该需求的人员需求涉及的子系统使用的验证方法或接受的测试标准第44页，本讲稿共60页6045需求类型的属性需求类型的属性1 状态2 优先级3 工作量4 风险5 稳定性6 目标发布版7 职责分配8 原因第45页，本讲稿共60页6046需求属性的作用需求属性的作用定义和更

17、新需求属性值是需求管理成本的一部分。精心挑选属性最小子集能帮助你有效管理项目。第46页，本讲稿共60页6047需求属性的作用需求属性的作用如果为项目需求选择了适当的属性和可追踪性，将有助于：评估需求变更对项目的影响 评估测试故障对需求的影响（例如：若测试出现故障，则需求将得不到满足）管理项目的规模 核实通过实施系统所有需求都已实现 核实应用程序仅仅执行了预期的任务 管理变更 第47页，本讲稿共60页60481.1.需求状态需求状态在整个开发过程中,跟踪每个需求的状态是需求管理的一个重要方面。在每一可能的状态类别中,如果你周期性地报告各状态类别在整个需求中所占的百分比将会改进项目的监控工作。假如

18、你有清晰的要求,指定了允许修改状态信息的人员和每个状态变更应满足的条件,跟踪需求状态才能正常工作。第48页，本讲稿共60页6049建议的需求状态表建议的需求状态表 状态状态状态定义状态定义已建议该需求已被有权提出需求的人建议已批准该需求已被分析,估计了其对项目余下部分的影响,已用一个确定的产品版本号或创建编号分配到相关的基线中,软件开发团队已同意实现该项需求已实现已实现需求代码的设计、编写和单元测试己验证使用所选择的方法已验证了实现的需求己删除计划的需求已从基线中删除,但包括一个原因说明和做出删除决定的人员第49页，本讲稿共60页60502.2.优先级优先级由营销经理、产品经理或业务分析员设置

19、。并非所有创建的需求都处在同一级别上。通过按照各项需求对最终用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见。用于管理规模并确定开发的优先级。描述的优先级的四个方面(收益、损失、成本、风险)第50页，本讲稿共60页6051优先级优先级关键必不可少的特性。不实现这些特性就无法使系统满足客户的需要。所有关键特性都必须在发布时实现，否则将错过预定的发布时间。重要对于系统在大多数应用中的有效性及效率都较为重要的特性。很难通过其他方式来实现这方面的功能。如果遗漏了某项重要特性，可能会影响客户或用户满意度，甚至会影响收入，但发布并不会因为缺少某一项重要特性而延期。有用有些特性在不

20、太典型的应用中比较有用，或者可以合理而有效地实现其替代特性，因而这些特性的使用频率相对较低。即使发布版中并未包括某一项有用的特性，也不会对收入或客户满意度造成严重的影响。第51页，本讲稿共60页60523.3.工作量工作量由开发团队设置。由于有些特性所需的时间和资源多于其他特性，所以估计团队工作周数或个人工作周数、所需的代码行数或功能点数，是一种最佳方式，用来估计复杂程度并预计在给定时间限度内能完成哪些工作。用于管理规模并确定开发的优先级。第52页，本讲稿共60页60534.4.风险风险由开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚或是项目取消。虽然可以对风险级别

21、进行细分，但大多数项目经理都认为将风险归为高、中、低就足够了。通过评测项目团队估计进度的不确定性，一般都可以间接地对风险进行评估。第53页，本讲稿共60页60545.5.需求的稳定性问题需求的稳定性问题未知需求用户可能认为他们已经知道了自已需要什么，可是在开始使用时他们却发现自已真正的需要和原来所想的并不一致。不稳定需求我们已经知道了大致需求，但细节仍处于不断变化之中。被误解的需求即使需求明确稳定，实现人员也常常理解的不够细，因而不能开发出令人满意的产品。第54页，本讲稿共60页6055稳定性稳定性由分析员和开发团队设置，设置的依据是特性发生变化的可能性或团队对特性的理解发生变化的可能性。用于

22、协助确定开发优先级并确定下一步需要继续获取哪些项。可为稳定性定义三个级别稳定待确定经常变化第55页，本讲稿共60页60566.6.目标发布版目标发布版记录将首次展示特性的产品版本。该字段可用于将前景前景文档中的职责分配给特定的基线发布版。如果将其与状态字段结合，就可以提出、记录和讨论发布版的各种特性，而此时还不必前进到开发阶段。只有状态设置为“已并入”且目标发布版已定义的特性才将被实现。管理规模时，可以增加目标发布版本号，这样该项特性虽然仍保留在前景前景文档中，但将安排在以后发布。第56页，本讲稿共60页60577.7.职责分配职责分配在许多项目中，特性会被分配给各个“特性团队”，它们负责进一

23、步获取需求，并编写软件需求和实施方案。这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。第57页，本讲稿共60页60588.8.原因原因此文本字段用于跟踪所需特性的来源。需求的提出总有其具体的原因。此字段用于陈述解释或陈述解释所引用的内容。例如，引用内容可以是产品需求规约的页码及行号，或是某次重要的客户访谈录像的会议记录标号。第58页，本讲稿共60页6059软件需求属性矩阵软件需求属性矩阵 属性属性需求需求需求需求状态状态优先优先级级工作工作量量风险风险稳定稳定性性产品产品版本版本职责职责分配分配原因原因功能需求非功能需求设计约束第59页，本讲稿共60页6060ENDEND第60页，本讲稿共60页