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

客观认识需求：类型和属性客观认识需求：类型和属性2008-06-272008-06-271目录目录•软件需求类型软件需求类型–功能性需求–非功能性需求–设计约束需求•软件需求属性软件需求属性2软件需求类型软件需求类型•系统越大越复杂，出现的需求类型就越多一个需求类型不过是指需求的一个类•通过确定需求类型，团队可以把大量需求组织成意义明确且更容易管理的组•在一个项目中建立不同类型的需求有助于团队成员对变更请求进行分类，并使相互之间的沟通更为清楚明确•对需求进行分类可以使项目更容易管理3需求类型的一种分类方法需求类型的一种分类方法•需求的种类各种各样一种分类的方法叫作 FURPS+ FURPS+ 模型，它使用首字母缩写词 FURPS 来描述具有以下子类别的主要需求类别 –功能性功能性 –可用性可用性 –可靠性可靠性 –性能性能–可支持性可支持性•FURPS+ 中的“+”可提醒您还要包括如下需求： –设计约束–实施需求–接口需求–物理需求4需求类型模型需求类型模型•需求类型主要分为三类：–功能性需求–非功能性需求–设计约束需求5需求类型模型需求类型模型6功能性需求功能性需求7功能性需求功能性需求•功能性需求表示了系统的行为。

这些需求通常是面向动作的(“当用户做x时,系统将做y”)在定义功能性需求时,应该在需求的确切性和通用性或多义性之间寻求较好的平衡•大多数功能性需求都可以用声明语句或用例来表示 •功能性需求包括：–特性集 –功能 –安全性8用例模型用例模型•用例模型主要设置有关系统的功能性需求，并用作分析和构架设计的核心输入•用例模型通过更为详细的事件流得以改进 9用例模型的主要元素用例模型的主要元素•角色•角色描述•用例•用例描述–简要说明、前置条件、主事件流、备选事件流、后置条件•用例之间的关系(使用、扩展、泛化)10用例模型的用例模型的UMLUML可视化可视化•用例图–可视化角色、用例、用例关系和系统边界•活动图–可视化用例事件流的结构 •顺序图–可视化用例事件流的(动作序列)交互过程，分解对象、消息和动作•类图–可视化用例实体结构关系11非功能性需求非功能性需求12非功能性需求非功能性需求•大约有八类非功能性需求：非功能性需求：–观感需求：–易用性需求：–性能需求：–可操作性需求：–可维护性和可移植性需求：–安全性需求：–文化和政策需求：–法律需求：13非功能性需求非功能性需求14非功能性需求非功能性需求 •非功能性软件需求典型地用来表示详细描述定义中的“系统的属性”或者“系统环境的属性”。

•非功能性软件需求主要主要包括和归纳为以下四种： –1.适用性–2.可靠性–3.性能–4.可支持性 151.1.可用性可用性( (适用性适用性) )需求需求•描述系统可以被预想的用户学习和操作的简单性非常重要可用性需求可包含如下子类别： –人员因素 –美观 –用户界面的一致性  –联机帮助和环境相关帮助–向导和代理–用户文档–培训材料和培训时间16可用性可用性( (适用性适用性) )需求需求•例如：–指出普通用户和高级用户要高效地执行特定操作所需的培训时间–指出典型任务的可评测任务次数，或者–指出在符合公认的可用性标准（如 IBM 的 CUA 标准和 Microsoft 的 GUI 标准）方面的需求17用户权利法案用户权利法案(1998)(1998)•1.用户总是对的,如果系统的使用有问题,那么系统是问题所在,而不是用户•2.用户有权进行简单安装和卸载软件和硬件系统,并且不产生任何负面效果•3.用户有权要求系统达到承诺的性能•4.用户有权获得易于使用的指导(用户指南、或语境帮助、出错信息),从而理解和使用系统,达到既定目标,并从问题状况有效而优雅地恢复•5.用户有权控制系统,并且能使系统响应请求。

18用户权利法案用户权利法案(1998)(1998)•6.用户有权要求系统提供有关正在进行任务以及进展的清晰、准确而可理解的信息•7.用户有权被明确通知所有有关正确使用软件或硬件的系统需求信息•8.用户有权知道系统的能力限制•9.用户有权与技术提供商联系,并得到合理而有用的响应•10.用户应该是软件和硬件技术和主人,而不是反过来产品应该简单、直观地使用192.2.可靠性需求可靠性需求•可靠性可靠性需求应该描述系统到底以哪种用户能够接受的程度运转•需要考虑的可靠性需求有： –可用性–平均故障间隔时间（MTBF）–平均修复时间–准确性–错误和缺陷率–每类错误202.1 2.1 可用性可用性•系统对于一个使用时间的指定百分比必须是可用的•最极端的情况下,需求可能指定“无停业”可用性,即,一天24小时,一年365天•比较常见的是,规定在上午8点到午夜之间99%或99.9%的可用性•注意需求必须明确定义"可用性"的含意是否100%的可用性意味着所有的用户在所有时间都能使用系统提供的所有服务? 212.2 2.2 平均故障间隔时间（平均故障间隔时间（MTBFMTBF））•通常以小时为单位指定,也可以以天、月或年为单位指定。

•要强调的是,这需要精确:需求必须仔细地定义什么是"故障" 222.3 2.3 平均修复时间平均修复时间(MTTR)(MTTR) •允许系统出故障后不运转的时间有多长?•例如,用户可能会规定90%的系统故障要在5分钟内可修复,99.9%的系统故障要在一小时内修复•在这里,精确仍然非常重要:需求必须指明"修复"是否意味着所有用户都可以再一次访问所有服务或者是否完全恢复的子集是可接受的 232.4 2.4 准确性准确性•产生数字输出的系统要求有多高的精确度?例如,金融系统的结果必须准确到分还是厘? 242.5 2.5 错误和缺陷率错误和缺陷率•通常是用错误数/KLOC(千行代码)表示或每个功能点的错误数表示最大错误和缺陷率 252.6 2.6 每类错误每类错误•通常分为微小的错误、显著的错误和关键性错误三类•需求必须定义什么是"关键性的"错误,例如数据的完全丢失或者系统的某些功能完全不能使用263.3.性能需求性能需求•性能需求可对功能性需求强加条件•性能需求通常包括以下几类:–事务的响应时间:平均值,最大值–吞吐量:每秒事务数•容量:系统可容纳的客户总数或事务数•退化模式:当系统被降级时,可接受的运转模式。

•如果新的系统必须和其他系统用共享硬件资源,则还要对系统到底能够在多大程度上"文明地"使用类似CPU、内存、信道、磁盘空间以及带宽等稀有资源加以规定27性能需求性能需求•对于一个给定行为，它可以对以下项规定性能参数： –速度、 –效率、 –可用性、 –准确性、 –吞吐量、 –响应时间、 –恢复时间，或 –资源用途 28基于用例的性能模型基于用例的性能模型•评估性能风险•确定关键用例•选择关键性能场景•建立性能目标•构造性能模型•增加软件资源需求•增加计算机资源需求•评价性能模型(修改创建场景)•验证和确认模型•修改产品构思•修正性能目标29304.4.可支持性需求可支持性需求•可支持性是指为了升级或修复,软件被修改的能力•对某些应用领域,未来可能的升级是可预测的,因此需求可以规定维护小组的简单升级、中等升级以及复杂升级的“响应时间”•例如,假定我们要建立一个新的工资系统这种系统的需求之一是必须计算政府为每个职员扣除的税用户当然知道政府每年会改变计算税的算法 31可支持性需求可支持性需求•可支持性需求可包括： –可测试性、 –可扩展性、 –可适应性、 –可维护性、 –兼容性、 –可配置性、 –可服务性、 –可安装性，或 –是否可本地化（国际化）。

32设计约束需求设计约束需求33设计约束定义设计约束定义•设计约束定义为:对系统的设计或开发系统的过程的限制不影响系统的外部行为,但必须被完成以满足技术、商业或合同的义务•设计约束代表已经批准并必须遵循的设计决定其中包括软件语言、软件流程需求、开发工具的指定用途、构架及设计约束、购买的构件、类库等34设计约束设计约束•设计约束常包括: –操作环境,例：用VB编写软件–与已有系统的兼容性,例：新的应用必须能够在新旧两种平台上都能运行 –应用标准–项目被开发所使用的规章和标准的实体 35设计需求设计需求( (设计约束设计约束) )•通常一条需求应该允许一种以上的设计选择:设计是有意识地在多种选择之间作出抉择•设计需求常称为设计约束设计约束，它规定或约束了系统的设计•只要有可能,我们就应该让设计人员来做这种抉择,而不应该在需求中指定它,因为只有设计人员最有资格评价每种选择的技术价值和经济价值•只要我们对设计做了规定不允许选择("用Oracle DBMS")设计就会受到约束,就会丧失某种程度的灵活性和开发自由度 36设计约束设计约束•几乎所有项目都会有一些设计约束通常,处理它们的最佳途径是遵循以下指南:–把它们和其他需求区分开来–把所有设计约束统一放到整个需求包中的某个特定位置,或者使用一些特殊的属性以便可以被聚合。

–确定每个设计约束的来源 –为每条约束的理由建档 37实施需求实施需求•实施需求规定或约束了系统的编码或构建例如： –所需标准、 –实施语言、 –数据库完整性策略、 –资源限制和 –操作环境 38接口需求接口需求•接口需求规定了 系统必须与之交互操作的外部项，或 对这种交互操作所使用的格式、时间或其他因素的约束 39物理需求物理需求•物理需求规定了系统必须具备的物理特征；例如， –材质、 –形状、 –尺寸和 重量 •这种需求类型可用来代表硬件要求，如 –物理网络配置需求 40软件需求属性软件需求属性41需求属性需求属性•可以为需求和其他相关的模型元素设置属性，以便于追踪它们的一般状态每个项目都可能有其特定的属性集，而且所追踪元素的类型不同，属性也会有所不同•每个需求类型都有一组唯一属性，与在该级别上定义的每个需求相关联•对于已确定的每一需求类型，都应列出将要使用的属性，并简要解释其含义42需求属性需求属性•需求类型和每种类型的属性是为整个项目定义的，由此确保了团队上下使用的一致性•需求的多维性以及不同类型的需求（每种类型都有自己的属性）对于组织大量需求和管理项目的整体规模来说是不可或缺的。

•为每个需求类型需求类型提供一个矩阵，其中一条轴上列出需求，而另一个轴上列出所有属性对于每个需求，显示其各自属性的状态43一般属性一般属性•创建需求的时间•需求的版本号•创建需求的作者•负责认可该需求的人员•需求涉及的子系统•使用的验证方法或接受的测试标准44需求类型的属性需求类型的属性•1 状态          •2 优先级         •3 工作量           •4 风险        •5 稳定性          •6 目标发布版           •7 职责分配    •8 原因        45需求属性的作用需求属性的作用•定义和更新需求属性值是需求管理成本的一部分•精心挑选属性最小子集能帮助你有效管理项目46需求属性的作用需求属性的作用•如果为项目需求选择了适当的属性和可追踪性，将有助于： –评估需求变更对项目的影响 –评估测试故障对需求的影响（例如：若测试出现故障，则需求将得不到满足） –管理项目的规模 –核实通过实施系统所有需求都已实现 –核实应用程序仅仅执行了预期的任务 –管理变更 471.1.需求状态需求状态•在整个开发过程中,跟踪每个需求的状态是需求管理的一个重要方面。

•在每一可能的状态类别中,如果你周期性地报告各状态类别在整个需求中所占的百分比将会改进项目的监控工作•假如你有清晰的要求,指定了允许修改状态信息的人员和每个状态变更应满足的条件,跟踪需求状态才能正常工作 48建议的需求状态表建议的需求状态表状态状态状态定义状态定义已建议该需求已被有权提出需求的人建议已批准该需求已被分析,估计了其对项目余下部分的影响,已用一个确定的产品版本号或创建编号分配到相关的基线中,软件开发团队已同意实现该项需求已实现已实现需求代码的设计、编写和单元测试己验证使用所选择的方法已验证了实现的需求己删除计划的需求已从基线中删除,但包括一个原因说明和做出删除决定的人员492.2.优先级优先级•由营销经理、产品经理或业务分析员设置•并非所有创建的需求都处在同一级别上通过按照各项需求对最终用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见用于管理规模并确定开发的优先级•描述的优先级的四个方面(收益、损失、成本、风险)50优先级优先级•关键–必不可少的特性不实现这些特性就无法使系统满足客户的需要所有关键特性都必须在发布时实现，否则将错过预定的发布时间。

•重要–对于系统在大多数应用中的有效性及效率都较为重要的特性很难通过其他方式来实现这方面的功能如果遗漏了某项重要特性，可能会影响客户或用户满意度，甚至会影响收入，但发布并不会因为缺少某一项重要特性而延期•有用–有些特性在不太典型的应用中比较有用，或者可以合理而有效地实现其替代特性，因而这些特性的使用频率相对较低即使发布版中并未包括某一项有用的特性，也不会对收入或客户满意度造成严重的影响513.3.工作量工作量•由开发团队设置•由于有些特性所需的时间和资源多于其他特性，所以估计团队工作周数或个人工作周数、所需的代码行数或功能点数，是一种最佳方式，用来估计复杂程度并预计在给定时间限度内能完成哪些工作用于管理规模并确定开发的优先级524.4.风险风险•由开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚或是项目取消•虽然可以对风险级别进行细分，但大多数项目经理都认为将风险归为高、中、低就足够了•通过评测项目团队估计进度的不确定性，一般都可以间接地对风险进行评估535.5.需求的稳定性问题需求的稳定性问题•未知需求–用户可能认为他们已经知道了自已需要什么，可是在开始使用时他们却发现自已真正的需要和原来所想的并不一致。

•不稳定需求–我们已经知道了大致需求，但细节仍处于不断变化之中•被误解的需求–即使需求明确稳定，实现人员也常常理解的不够细，因而不能开发出令人满意的产品54稳定性稳定性•由分析员和开发团队设置，设置的依据是特性发生变化的可能性或团队对特性的理解发生变化的可能性•用于协助确定开发优先级并确定下一步需要继续获取哪些项•可为稳定性定义三个级别–稳定–待确定–经常变化556.6.目标发布版目标发布版•记录将首次展示特性的产品版本•该字段可用于将前景前景文档中的职责分配给特定的基线发布版如果将其与状态字段结合，就可以提出、记录和讨论发布版的各种特性，而此时还不必前进到开发阶段•只有状态设置为“已并入”且目标发布版已定义的特性才将被实现•管理规模时，可以增加目标发布版本号，这样该项特性虽然仍保留在前景前景文档中，但将安排在以后发布567.7.职责分配职责分配•在许多项目中，特性会被分配给各个“特性团队”，它们负责进一步获取需求，并编写软件需求和实施方案•这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责578.8.原因原因•此文本字段用于跟踪所需特性的来源•需求的提出总有其具体的原因。

此字段用于陈述解释或陈述解释所引用的内容•例如，引用内容可以是产品需求规约的页码及行号，或是某次重要的客户访谈录像的会议记录标号58软件需求属性矩阵软件需求属性矩阵59ENDEND60。