需求基础_3

第2章需求基础软件学院代飞2013.春主要内容1.1需求的定义1.2需求的内涵1.3需求的外延1.4需求的特性1.5常见的需求定义错误1.1什么是需求？IEEE关于需求的定义（1）用户为了解决问题或达到目标所需的条件或能力；（用户的角度）（2）系统或系统部件为了满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（开发者的角度）（3）对（1）或（2）中的一个条件或一种能力的文档化表述。1.2需求的内涵软件开发的任务是构造软件系统，并将其部署到现实世界中，通过软件系统与周围环境的交互，解决人们在现实世界中遇到的问题。软件系统现实世界环境接口软件具有模拟性！例子：手工图书管理图书管理系统对照BookStudentpublicclassBook{privateStringname;privatedoubleprice;privateStringauthor;privateStringpublisher;……}问题域和解系统现实世界解系统问题域接口问题：当现实的状况与人们期望的状况产生差距时，就产生了问题。解决办法：要解决问题，就需要改变现实当中某些实体的状态或改变实体状态变化的演进顺序，使其达到期望的状态或演进顺序。问题域（ProblemDomain）：这些实体和状态构成了问题解决的基本范围，称为该问题的问题域解系统（SolutionSystem）：软件解决方案在计算机上的实现，通过影响问题域，能够帮助人们解决问题。共享现象软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对问题域中的某些部分具有模拟特性。问题域中的某些信息能够和软件中的信息建立映射关系。这些通过映射建立的共同知识，就是问题域和解系统之间的共享现象，是问题域和解系统实现交互和互相影响的途径与接口。问题域解系统共享现象现实世界需求的含义需求是用户对问题域当中的实体状态或事件的期望描述R1：一旦书籍被借出，则在归还之前，它不能被再次借阅。R2：在被借阅的书超过30天的归还期限时，归还操作应该触发超期事件。在用户看来，一旦解系统对实体状态或事件的影响满足了他们的期望，问题就解决了。问题域解系统共享现象现实世界需求需求描述是在问题域基础上进行的，所以应可能使用问题域的语言。在被借阅的书超过30天的归还期限时，归还后应该进行超期罚款。直接需求和间接需求直接需求：和解系统直接相关，是对共享现象中实体状态或事件的期望，能够通过解系统直接改变共享知识而予以满足。解系统直接满足这些期望。间接需求：和解系统间接相关，所期望的实体状态和事件存在于问题域之中、共享现象之外。R3：在借阅的书超过30天的借阅期限时，管理员应该通知借书人进行续借。解系统需要改变共同知识而在问题域中引起连锁反应，间接地满足这些期望。规格说明（specification）规格说明是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征。包括两个部分：（1）对共享现象（模型）的描述；（2）系统对共享现象所施加的操作的描述。解决方案解决现实问题的方式：通过改变共同知识，影响问题域的运行，进而满足用户的需求。解系统共享现象现实世界软件问题域问题域解系统共享现象现实世界规格说明问题域特性问题域自治的规律性称为问题域特性包括结构特性和行为特性等问题域特性的重要性要想解决问题，它就需要了解问题域特性，将解决方案和问题域特性结合起来要防止解系统的引入在问题域当中引发未预见的连锁反应约束和假设（不受共享现象的影响，反过来，却能影响共享现象。）从问题域、需求和规格说明的关系看需求工程描述明确的问题域特性E;定义良好的系统行为S;预期的需求R需求工程的目的就是根据E，构建S，使得需求工程的困难之处：（1）不存在描述明确的E；（2）不存在确定的针对S的评估标准R；（3）是一个创造性的过程。需求工程的主要工作需求开发,确定R研究问题背景，描述问题域特性E构建解系统，描述解系统行为S，使得RSE,SRE,RSE,需求概念的外延——需求的分类功能需求（FunctionalRequirement）和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。性能需求（PerformanceRequirement）系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。质量属性（QualityAttribute）系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。对外接口（ExternalInterface）系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。约束进行系统构造时需要遵守的约束，例如编程语言、硬件设施等。功能需求——层次性目标任务系统行为业务需求用户需求系统需求业务需求、用户需求、系统需求业务需求抽象层次最高的需求，是系统建立的战略出发点，表现为高层次的目标（Objective），它描述了组织为什么要开发系统。用户需求（需要极强的背景知识）执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。系统（级）需求用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足用户需求。举例—图书管理系统业务需求为了实现云南大学进入全国50强，图书管理必须信息化！用户需求借阅图书续借图书归还图书图书罚款图书查阅图书入库学生信息管理教师信息管理数据库备份系统需求从功能需求的层次性看需求开发从这个意义上看，需求工程中的需求开发可以看作是一个需求类型转换的过程。业务需求指导需求获取业务需求用户需求转化用户需求为系统需求系统需求性能需求速度（Speed），系统的响应时间。所有的用户查询都必须在10秒内完成。容量（Capacity），系统所能存储的数据量。系统应该能够存储至少10万条销售记录。吞吐量（Throughput），系统在连续的时间内完成的事务数量。解释器每分钟应该至少解析5000条没有错误的语句。负载（Load），系统可以承载的并发工作量。系统应该允许200个用户同时进行正常的工作。实时性（Time-Critical），严格的实时要求。监测到病人异常后，监控器必须在0.5秒内发出警报。质量属性功能性需求：用户对软件系统的显示要求，用户在软件创建之前就可以清晰地向开发者表达的要求；非功能性需求：属于隐式要求，用户在创建之前无法清晰地告诉开发者需要什么样的非功能性特征；系统为了满足规定的及隐含的所有要求而需要具备的要素称为质量；质量属性是为了度量质量要素而选用的特征；质量模型就是能够为质量需求的描述和评价提供工作基础的特征集及特征之间的联系ISO/IEC9126功能性特征子特征简要描述功能性精确性软件准确依照规定条款程度，规定确定了权利、协议的结果或者协议的效果依从性软件符合法定的相关标准、协定、规则或其他类似规定的程度互操作性软件和指定系统进行交互的能力安全性软件阻止对其程序和数据进行未授权访问的能力，未授权的访问可能是有意，也可能是无意的适合性指定任务的相应功能是否存在以及功能的适合程度可靠性成熟性因软件缺陷而导致的故障频率程度容错性软件在故障或者外界违反其指定接口的情况下维持其指定性能水平的能力可恢复性软件在故障后重建其性能水平、恢复其受影响数据的能力、时间和精力依从性软件符合法定的相关标准、协定、规则或其他类似规定的程度可靠性易用性易用性可理解性用户认可软件的逻辑概念和其适用性需要花费的精力可学习性用户为了学会使用软件需要花费的精力可操作性用户执行软件操作和控制软件操作需要花费的精力吸引性软件吸引用户的能力依从性软件符合法定的相关标准、协定、规则或其他类似规定的程度效率效率时间行为执行功能时的响应时间、处理时间和吞吐速度资源行为执行功能时使用资源的数量和时间依从性软件符合法定的相关标准、协定、规则或其他类似规定的程度可维护性可维护性可分析性诊断软件中的缺陷、故障的原因或者识别待修改部分需要花费的精力可改变性进行功能修改、缺陷剔除或者应付环境改变需要花费的精力稳定性因修改导致未预料结果的风险程度可测试性确认已修改软件需要花费的精力依从性软件符合法定的相关标准、协定、规则或其他类似规定的程度可移植性可移植性适应性不需采用额外的活动或手段就能适应不同指定环境的能力可安装性在指定的环境中安装软件需要花费的精力共存性在公共环境中同分享公共资源的其他独立软件共存的能力可替换性在另一个指定软件的环境下，替换该指定软件的能力和需要花费的精力依从性软件符合法定的相关标准、协定、规则或其他类似规定的程度对外接口解系统和其他系统之间的软硬件接口接口的用途接口的输入输出数据格式命令格式异常处理要求用户界面利用专门的人机交互设计文档记录约束总体上限制了开发人员设计和构建系统时的选择范围系统开发及运行的环境。包括目标机器、操作系统、网络环境、编程语言、数据库管理系统等。问题域内的相关标准。包括法律法规、行业协定、企业规章等。商业规则。用户在任务执行中的一些潜在规则也会限制开发人员设计和构建系统的选择范围1.4需求的特性完整性正确性精确性可行性必要性无歧义可验证1.5常见的需求定义错误需求并没有正确反映用户的真实需求；信息遗漏；需求不一致；模糊和歧义的需求；不必要的需求。作业请写出新浪微博或者人人网的功能性需求（业务需求、用户需求和系统需求）和非功能性需求。要求：1）5人为一个小组；2）图文并茂地描述新浪微博或者人人网的功能性需求和非功能性需求；3）图表制作规范；4）4月1日早上1-2节课交纸质文件。谢谢！