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

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

ID:39346511

大小:333.00 KB

页数:60页

时间:2019-07-01

客观认识需求:类型和属性_第1页
客观认识需求:类型和属性_第2页
客观认识需求:类型和属性_第3页
客观认识需求:类型和属性_第4页
客观认识需求:类型和属性_第5页
资源描述:

《客观认识需求:类型和属性》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

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

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

3、明语句或用例来表示。功能性需求包括:特性集功能安全性609用例模型用例模型主要设置有关系统的功能性需求,并用作分析和构架设计的核心输入。用例模型通过更为详细的事件流得以改进。6010用例模型的主要元素角色角色描述用例用例描述简要说明、前置条件、主事件流、备选事件流、后置条件用例之间的关系(使用、扩展、泛化)6011用例模型的UML可视化用例图可视化角色、用例、用例关系和系统边界活动图可视化用例事件流的结构顺序图可视化用例事件流的(动作序列)交互过程,分解对象、消息和动作类图可视化用例实体结构关系6012非功能性需

4、求6013非功能性需求大约有八类非功能性需求:观感需求:易用性需求:性能需求:可操作性需求:可维护性和可移植性需求:安全性需求:文化和政策需求:法律需求:6014非功能性需求6015非功能性需求非功能性软件需求典型地用来表示详细描述定义中的“系统的属性”或者“系统环境的属性”。非功能性软件需求主要包括和归纳为以下四种:1.适用性2.可靠性3.性能4.可支持性60161.可用性(适用性)需求描述系统可以被预想的用户学习和操作的简单性非常重要。可用性需求可包含如下子类别:人员因素美观用户界面的一致性联机帮助和环境相关

5、帮助向导和代理用户文档培训材料和培训时间6017可用性(适用性)需求例如:指出普通用户和高级用户要高效地执行特定操作所需的培训时间指出典型任务的可评测任务次数,或者指出在符合公认的可用性标准(如IBM的CUA标准和Microsoft的GUI标准)方面的需求6018用户权利法案(1998)1.用户总是对的,如果系统的使用有问题,那么系统是问题所在,而不是用户。2.用户有权进行简单安装和卸载软件和硬件系统,并且不产生任何负面效果。3.用户有权要求系统达到承诺的性能。4.用户有权获得易于使用的指导(用户指南、在线或语境

6、帮助、出错信息),从而理解和使用系统,达到既定目标,并从问题状况有效而优雅地恢复。5.用户有权控制系统,并且能使系统响应请求。6019用户权利法案(1998)6.用户有权要求系统提供有关正在进行任务以及进展的清晰、准确而可理解的信息。7.用户有权被明确通知所有有关正确使用软件或硬件的系统需求信息。8.用户有权知道系统的能力限制。9.用户有权与技术提供商联系,并得到合理而有用的响应。10.用户应该是软件和硬件技术和主人,而不是反过来。产品应该简单、直观地使用。60202.可靠性需求可靠性需求应该描述系统到底以哪种用

7、户能够接受的程度运转。需要考虑的可靠性需求有:可用性平均故障间隔时间(MTBF)平均修复时间准确性错误和缺陷率每类错误60212.1可用性系统对于一个使用时间的指定百分比必须是可用的。最极端的情况下,需求可能指定“无停业”可用性,即,一天24小时,一年365天。比较常见的是,规定在上午8点到午夜之间99%或99.9%的可用性。注意需求必须明确定义"可用性"的含意。是否100%的可用性意味着所有的用户在所有时间都能使用系统提供的所有服务?60222.2平均故障间隔时间(MTBF)通常以小时为单位指定,也可以以天、月

8、或年为单位指定。要强调的是,这需要精确:需求必须仔细地定义什么是"故障"。60232.3平均修复时间(MTTR)允许系统出故障后不运转的时间有多长?例如,用户可能会规定90%的系统故障要在5分钟内可修复,99.9%的系统故障要在一小时内修复在这里,精确仍然非常重要:需求必须指明"修复"是否意味着所有用户都可以再一次访问所有服务或者是否完全恢复的子集是可接受的60242.4

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。