客观认识需求：类型和属性

《客观认识需求：类型和属性》由会员分享，可在线阅读，更多相关《客观认识需求：类型和属性（60页珍藏版）》请在金锄头文库上搜索。

1、1,客观认识需求：类型和属性,郭树行 中央财经大学信息学院 讲师 北京航空航天大学软件工程研究所 博士 2008-06-27,60,2,目录,软件需求类型 功能性需求 非功能性需求 设计约束需求 软件需求属性,60,3,软件需求类型,系统越大越复杂，出现的需求类型就越多。一个需求类型不过是指需求的一个类。 通过确定需求类型，团队可以把大量需求组织成意义明确且更容易管理的组。 在一个项目中建立不同类型的需求有助于团队成员对变更请求进行分类，并使相互之间的沟通更为清楚明确。 对需求进行分类可以使项目更容易管理。,60,4,需求类型的一种分类方法,需求的种类各种各样。一种分类的方法叫作 FURPS+

2、 模型，它使用首字母缩写词 FURPS 来描述具有以下子类别的主要需求类别。 功能性 可用性 可靠性 性能 可支持性 FURPS+ 中的“+”可提醒您还要包括如下需求： 设计约束 实施需求 接口需求 物理需求,60,5,需求类型模型,需求类型主要分为三类： 功能性需求 非功能性需求 设计约束需求,60,6,需求类型模型,60,7,功能性需求,60,8,功能性需求,功能性需求表示了系统的行为。这些需求通常是面向动作的(“当用户做x时,系统将做y”。)在定义功能性需求时,应该在需求的确切性和通用性或多义性之间寻求较好的平衡。 大多数功能性需求都可以用声明语句或用例来表示。 功能性需求包括： 特性集

3、 功能 安全性,60,9,用例模型,用例模型主要设置有关系统的功能性需求，并用作分析和构架设计的核心输入。 用例模型通过更为详细的事件流得以改进。,60,10,用例模型的主要元素,角色 角色描述 用例 用例描述 简要说明、前置条件、主事件流、备选事件流、后置条件 用例之间的关系(使用、扩展、泛化),60,11,用例模型的UML可视化,用例图 可视化角色、用例、用例关系和系统边界 活动图 可视化用例事件流的结构 顺序图 可视化用例事件流的(动作序列)交互过程，分解对象、消息和动作 类图 可视化用例实体结构关系,60,12,非功能性需求,60,13,非功能性需求,大约有八类非功能性需求： 观感需求

4、： 易用性需求： 性能需求： 可操作性需求： 可维护性和可移植性需求： 安全性需求： 文化和政策需求： 法律需求：,60,14,非功能性需求,60,15,非功能性需求,非功能性软件需求典型地用来表示详细描述定义中的“系统的属性”或者“系统环境的属性”。 非功能性软件需求主要包括和归纳为以下四种： 1.适用性 2.可靠性 3.性能 4.可支持性,60,16,1.可用性(适用性)需求,描述系统可以被预想的用户学习和操作的简单性非常重要。可用性需求可包含如下子类别： 人员因素 美观 用户界面的一致性 联机帮助和环境相关帮助 向导和代理 用户文档 培训材料和培训时间,60,17,可用性(适用性)需求,

5、例如： 指出普通用户和高级用户要高效地执行特定操作所需的培训时间 指出典型任务的可评测任务次数，或者 指出在符合公认的可用性标准（如 IBM 的 CUA 标准和 Microsoft 的 GUI 标准）方面的需求,60,18,用户权利法案(1998),1.用户总是对的,如果系统的使用有问题,那么系统是问题所在,而不是用户。 2.用户有权进行简单安装和卸载软件和硬件系统,并且不产生任何负面效果。 3.用户有权要求系统达到承诺的性能。 4.用户有权获得易于使用的指导(用户指南、在线或语境帮助、出错信息),从而理解和使用系统,达到既定目标,并从问题状况有效而优雅地恢复。 5.用户有权控制系统,并且能使

6、系统响应请求。,60,19,用户权利法案(1998),6.用户有权要求系统提供有关正在进行任务以及进展的清晰、准确而可理解的信息。 7.用户有权被明确通知所有有关正确使用软件或硬件的系统需求信息。 8.用户有权知道系统的能力限制。 9.用户有权与技术提供商联系,并得到合理而有用的响应。 10.用户应该是软件和硬件技术和主人,而不是反过来。产品应该简单、直观地使用。,60,20,2.可靠性需求,可靠性需求应该描述系统到底以哪种用户能够接受的程度运转。 需要考虑的可靠性需求有： 可用性 平均故障间隔时间（MTBF） 平均修复时间 准确性 错误和缺陷率 每类错误,60,21,2.1 可用性,系统对于

7、一个使用时间的指定百分比必须是可用的。 最极端的情况下,需求可能指定“无停业”可用性,即,一天24小时,一年365天。 比较常见的是,规定在上午8点到午夜之间99%或99.9%的可用性。 注意需求必须明确定义“可用性“的含意。是否100%的可用性意味着所有的用户在所有时间都能使用系统提供的所有服务?,60,22,2.2 平均故障间隔时间（MTBF）,通常以小时为单位指定,也可以以天、月或年为单位指定。 要强调的是,这需要精确:需求必须仔细地定义什么是“故障“。,60,23,2.3 平均修复时间(MTTR),允许系统出故障后不运转的时间有多长? 例如,用户可能会规定90%的系统故障要在5分钟内可

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

9、能性需求强加条件。 性能需求通常包括以下几类: 事务的响应时间:平均值,最大值。 吞吐量:每秒事务数。 容量:系统可容纳的客户总数或事务数。 退化模式:当系统被降级时,可接受的运转模式。 如果新的系统必须和其他系统用共享硬件资源,则还要对系统到底能够在多大程度上“文明地“使用类似CPU、内存、信道、磁盘空间以及带宽等稀有资源加以规定。,60,28,性能需求,对于一个给定行为，它可以对以下项规定性能参数： 速度、 效率、 可用性、 准确性、 吞吐量、 响应时间、 恢复时间，或 资源用途。,60,29,基于用例的性能模型,评估性能风险 确定关键用例 选择关键性能场景 建立性能目标 构造性能模型 增

10、加软件资源需求 增加计算机资源需求 评价性能模型(修改创建场景) 验证和确认模型 修改产品构思 修正性能目标,60,30,60,31,4.可支持性需求,可支持性是指为了升级或修复,软件被修改的能力。 对某些应用领域,未来可能的升级是可预测的,因此需求可以规定维护小组的简单升级、中等升级以及复杂升级的“响应时间”。 例如,假定我们要建立一个新的工资系统。这种系统的需求之一是必须计算政府为每个职员扣除的税。用户当然知道政府每年会改变计算税的算法,60,32,可支持性需求,可支持性需求可包括： 可测试性、 可扩展性、 可适应性、 可维护性、 兼容性、 可配置性、 可服务性、 可安装性，或 是否可本地

11、化（国际化）。,60,33,设计约束需求,60,34,设计约束定义,设计约束定义为:对系统的设计或开发系统的过程的限制不影响系统的外部行为,但必须被完成以满足技术、商业或合同的义务。 设计约束代表已经批准并必须遵循的设计决定。其中包括软件语言、软件流程需求、开发工具的指定用途、构架及设计约束、购买的构件、类库等。,60,35,设计约束,设计约束常包括: 操作环境,例：用VB编写软件 与已有系统的兼容性,例：新的应用必须能够在新旧两种平台上都能运行 应用标准 项目被开发所使用的规章和标准的实体,60,36,设计需求(设计约束),通常一条需求应该允许一种以上的设计选择:设计是有意识地在多种选择之间

12、作出抉择。 设计需求常称为设计约束，它规定或约束了系统的设计。 只要有可能,我们就应该让设计人员来做这种抉择,而不应该在需求中指定它,因为只有设计人员最有资格评价每种选择的技术价值和经济价值。 只要我们对设计做了规定不允许选择(“用Oracle DBMS“)设计就会受到约束,就会丧失某种程度的灵活性和开发自由度。,60,37,设计约束,几乎所有项目都会有一些设计约束。通常,处理它们的最佳途径是遵循以下指南: 把它们和其他需求区分开来 把所有设计约束统一放到整个需求包中的某个特定位置,或者使用一些特殊的属性以便可以被聚合。 确定每个设计约束的来源 为每条约束的理由建档,60,38,实施需求,实施

13、需求规定或约束了系统的编码或构建。例如： 所需标准、 实施语言、 数据库完整性策略、 资源限制和 操作环境。,60,39,接口需求,接口需求规定了 系统必须与之交互操作的外部项，或 对这种交互操作所使用的格式、时间或其他因素的约束。,60,40,物理需求,物理需求规定了系统必须具备的物理特征；例如， 材质、 形状、 尺寸和 重量。 这种需求类型可用来代表硬件要求，如 物理网络配置需求。,60,41,软件需求属性,60,42,需求属性,可以为需求和其他相关的模型元素设置属性，以便于追踪它们的一般状态。每个项目都可能有其特定的属性集，而且所追踪元素的类型不同，属性也会有所不同。 每个需求类型都有一

14、组唯一属性，与在该级别上定义的每个需求相关联。 对于已确定的每一需求类型，都应列出将要使用的属性，并简要解释其含义。,60,43,需求属性,需求类型和每种类型的属性是为整个项目定义的，由此确保了团队上下使用的一致性。 需求的多维性以及不同类型的需求（每种类型都有自己的属性）对于组织大量需求和管理项目的整体规模来说是不可或缺的。 为每个需求类型提供一个矩阵，其中一条轴上列出需求，而另一个轴上列出所有属性。对于每个需求，显示其各自属性的状态。,60,44,一般属性,创建需求的时间 需求的版本号 创建需求的作者 负责认可该需求的人员 需求涉及的子系统 使用的验证方法或接受的测试标准,60,45,需求

15、类型的属性,1 状态 2 优先级 3 工作量 4 风险 5 稳定性 6 目标发布版 7 职责分配 8 原因,60,46,需求属性的作用,定义和更新需求属性值是需求管理成本的一部分。 精心挑选属性最小子集能帮助你有效管理项目。,60,47,需求属性的作用,如果为项目需求选择了适当的属性和可追踪性，将有助于： 评估需求变更对项目的影响 评估测试故障对需求的影响（例如：若测试出现故障，则需求将得不到满足） 管理项目的规模 核实通过实施系统所有需求都已实现 核实应用程序仅仅执行了预期的任务 管理变更,60,48,1.需求状态,在整个开发过程中,跟踪每个需求的状态是需求管理的一个重要方面。 在每一可能的

16、状态类别中,如果你周期性地报告各状态类别在整个需求中所占的百分比将会改进项目的监控工作。 假如你有清晰的要求,指定了允许修改状态信息的人员和每个状态变更应满足的条件,跟踪需求状态才能正常工作。,60,49,建议的需求状态表,60,50,2.优先级,由营销经理、产品经理或业务分析员设置。 并非所有创建的需求都处在同一级别上。通过按照各项需求对最终用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见。用于管理规模并确定开发的优先级。 描述的优先级的四个方面(收益、损失、成本、风险),60,51,优先级,关键 必不可少的特性。不实现这些特性就无法使系统满足客户的需要。所有关键特性都必须在发布时实现，否则将错过预定的发布时间。 重要 对于系统在大多数应用中的有效性及效率都较为重要的特性。很难通过其他方式来实现这方面的功能。如果遗漏了某项重要特性，可能会影响客户或用户满意度，甚至会影响收入，但发布并不会因为缺少某一项重要特性而延期。 有用 有些特性在不太典型的应用中比较有用，或者可以合理而有效地实现其替代