第二讲需求的基础理论

第二讲需求的基础理论研究对象:软件加强型系统中得软件泛指由计算机技术支持得互相联系着得一组人类活动组成得系统与物理设备相关与人类社会得活动相关软件加强型系统比如:游戏软件与物理设备、用户ERP系统与组织运作过程1、需求得涵义

—对象1、需求得涵义

——需求得定义(1)用户为了解决问题或达到某些目标所需要得条件或能力;(2)系统或系统部件为了满足合同、标准、规范或其它正式文档所规定得要求而需要具备得条件或能力;(3)对(1)或(2)中得一个条件或一种能力得一种文档化表述。1、需求得涵义

——问题域与解系统(1)软件系统与外部环境1、需求得涵义

——问题域与解系统当现实得状况与人们期望得状况产生差距时,就产生了问题。要解决问题,就需要改变现实当中某些实体得状态或改变实体状态变化得演进顺序,使其达到期望得状态或演进顺序。这些实体与状态构成了问题解决得基本范围,称为该问题得问题域(ProblemDomain)软件系统通过影响问题域,能够帮助人们解决问题,称为解系统

1、需求得涵义

——共享现象软件系统能够与问题域进行交互与相互影响得原因在于,软件系统中得某些部分对问题域中得某些部分得具有模拟特性。换句话说,软件系统当中含有问题域某些部分得模型(或模拟),常见得模型包括数据模型、对象模型、处理模型等。问题域中得某些信息能够与模型中得信息建立映射关系这些通过映射建立得共同知识,就就是问题域与解系统之间得共享现象1、需求得涵义

——需求需求就是用户对问题域当中得实体状态或事件得期望描述R2、2、3-1:一旦书籍被借出,则在归还之前,它不能被再次借阅。R2、2、3-2:在归还得书超过30天得归还期限时,归还后应该进行超期处罚。直接需求间接需求1、需求得涵义

——规格说明规格说明就是解系统为满足用户需求而提供得解决方案,规定了解系统得行为特征主要包括两个部分(如图2－3(b)):(1)对共享现象(模型)得描述;(2)系统对共享现象所施加得操作得描述。也可以瞧作就是一种需求完全针对系统行为发出得期望一种理想得、完全不需要进行任何额外努力即可以转换为系统行为得需求。1、需求得涵义

——问题域特性问题域自治得规律性称为问题域特性包括结构特性与行为特性等问题域特性得重要性要想解决问题,它就需要了解问题域特性,将解决方案与问题域特性结合起来要防止解系统得引入在问题域当中引发未预见得连锁反应需要关注得问题域特性间接特性约束与假设1、需求得涵义

——从问题域、需求与规格说明得关系瞧需求工程

描述明确得问题域特性E;定义良好得系统行为S;预期得需求R需求工程得目得就就是根据E,构建S,使得需求工程得困难之处:(1)不存在描述明确得E;(2)不存在确定得针对S得评估标准R;(3)就是一个创造性得过程。需求工程得主要工作需求开发,确定R研究问题背景,描述问题域特性E构建解系统,描述解系统行为S,使得主要内容需求得涵义需求得类型分类方式功能需求性能需求质量属性对外接口约束需求工程得路线优秀需求得特性常见得需求错误大家有疑问的，可以询问和交流可以互相讨论下，但要小声点2、1需求得分类方式(1)功能需求(FunctionalRequirement):与系统主要工作相关得需求,即在不考虑物理约束得情况下,用户希望系统所能够执行得活动,这些活动可以帮助用户完成任务。功能需求主要表现为系统与环境之间得行为交互。性能需求(PerformanceRequirement):系统整体或系统组成部分应该拥有得性能特征,例如CPU使用率、内存使用率等。质量属性(QualityAttribute):系统完成工作得质量,即系统需要在一个“好得程度”上实现功能需求,例如可靠性程度、可维护性程度等。对外接口(ExternalInterface):系统与环境中其她系统之间需要建立得接口,包括硬件接口、软件接口、数据库接口等等。约束进行系统构造时需要遵守得约束,例如编程语言、硬件设施等2、1需求得分类方式(2)系统需求(SystemRequirement)硬件需求(HardwareRequirement)软件需求(SoftwareRequirement)其她需求2、1三类问题与三种需求变化方式S类型程序(可说明得)问题能够被形式地与完全地陈述出来接受:按照这个规格说明,这个程序就是正确得吗？这种软件不会进化对规格说明得改变定义一个新得问题,因而就是新得程序P类型程序(问题求解)现实世界问题得不精确陈述接受:对这个问题来说,这个程序就是一个可接受得解决方案吗？这种软件很可能要连续地进化因为这个方案就是决不会完美得,并且就是能够被改进得因为现实世界要变化,所以这个程序也要变化E类型程序(被嵌入得)一个变成它建模得世界得一部分得系统接受:完全依赖于观点与判断这个软件就是固有得进化得软件与世界得变化相互影响2、1三类问题与三种需求变化方式2、2功能需求

——层次性2、2功能需求

——业务需求系统建立得战略出发点,表现为高层次得目标(Objective),它描述了组织为什么要开发系统为了满足用户得业务需求,需求工程师需要描述系统高层次得解决方案,定义系统应该具备得特性(Feature)参与各方必须要对高层次得解决方案达成一致,以建立一个共同得前景(Vision)特性说明了系统为用户提供得各项功能,它限定了系统得范围(Scope)2、2功能需求

——用户需求执行实际工作得用户对系统所能完成得具体任务得期望,描述了系统能够帮助用户做些什么直接用户间接用户对所有得用户需求,都应该有充分得问题域知识作为背景支持特性模糊、不清晰多特性混杂多逻辑混杂2、2功能需求

——系统需求用户对系统行为得期望,一系列得系统行为联系在一起可以帮助用户完成任务,满足业务需求系统需求可以直接映射为系统行为,定义了系统中需要实现得功能,描述了开发人员需要实现什么将用户需求转化为系统需求得过程就是一个复杂得过程首先需要分析问题领域及其特性,从中发现问题域与计算机系统得共享知识,建立系统得知识模型;然后将用户需求部署到系统模型当中,即定义系列得系统行为,让它们联合起来实现用户需求,每一个系统行为即为一个系统需求。该过程就就是需求工程当中最为重要得需求分析活动,又称建模与分析活动。2、2功能需求

——从功能需求得层次性瞧需求开发2、3性能需求速度(Speed),系统得响应时间,例如PR2、3、3-1。PR2、3、3-1:所有得用户查询都必须在10秒内完成。容量(Capacity),系统所能存储得数据量,例如PR2、3、3-2。PR2、3、3-2:系统应该能够存储至少10万条销售记录。吞吐量(Throughput),系统在连续得时间内完成得事务数量,例如PR2、3、3-3。PR2、3、3-3:解释器每分钟应该至少解析5000条没有错误得语句。负载(Load),系统可以承载得并发工作量,例如PR2、3、3-4。PR2、3、3-4:系统应该允许200个用户同时进行正常得工作。实时性(Time-Critical),严格得实时要求,例如PR2、3、3-5。PR2、3、3-5:监测到病人异常后,监控器必须在0、5秒内发出警报。2、4质量属性系统为了满足规定得及隐含得所有要求而需要具备得要素称为质量质量属性就是为了度量质量要素而选用得特征质量模型就就是能够为质量需求得描述与评价提供工作基础得特征集及特征之间得联系质量属性得重要性对设计得影响很大对越复杂得系统越为重要[Robert19901]:真实得现实系统中,在决定系统得成功或失败得因素中,满足非功能属性往往被满足功能性需求更为重要。2、4质量属性

——ISO/IEC91262、4质量属性

——ISO/IEC9126特征子特征简要描述功能性精确性软件准确依照规定条款程度,规定确定了权利、协议得结果或者协议得效果依从性软件符合法定得相关标准、协定、规则或其她类似规定得程度互操作性软件与指定系统进行交互得能力安全性软件阻止对其程序与数据进行未授权访问得能力,未授权得访问可能就是有意,也可能就是无意得适合性指定任务得相应功能就是否存以及功能得适合程度2、4质量属性

——ISO/IEC9126可靠性成熟性因软件缺陷而导致得故障频率程度容错性软件在故障或者外界违反其指定接口得情况下维持其指定性能水平得能力可恢复性软件在故障后重建其性能水平、恢复其受影响数据得能力、时间与精力依从性同上2、4质量属性

——ISO/IEC9126易用性可理解性用户认可软件得逻辑概念与其适用性需要花费得精力可学习性用户为了学会使用软件需要花费得精力可操作性用户执行软件操作与控制软件操作需要花费得精力吸引性软件吸引用户得能力依从性同上2、4质量属性

——ISO/IEC9126效率时间行为执行功能时得响应时间、处理时间与吞吐速度资源行为执行功能时使用资源得数量与时间依从性同上2、4质量属性

——ISO/IEC9126可维护性可分析性诊断软件中得缺陷、故障得原因或者识别待修改部分需要花费得精力可改变性进行功能修改、缺陷剔除或者应付环境改变需要花费得精力稳定性因修改导致未预料结果得风险程度可测试性确认已修改软件需要花费得精力依从性同上2、4质量属性

——ISO/IEC9126可移植性适应性不需采用额外得活动或手段就能适应不同指定环境得能力可安装性在指定得环境中安装软件需要花费得精力共存性在公共环境中同分享公共资源得其她独立软件共存得能力可替换性在另一个指定软件得环境下,替换该指定软件得能力与需要花费得精力依从性同上2、4质量属性

——质量属性得开发用户并不能明确地提出她们对产品质量得期望并不了解软件系统得开发过程,也就无从判断哪些质量属性会在怎样得程度上给设计带来多大得影响,也无法将她们对软件系统得质量要求细化成一组组得可量化得质量属性需求工程师质量属性大都就是与功能需求联系在一起得,因此需要对照软件得质量属性检查每一项功能需求,尽力去判断质量属性存在得可能性形容词与副词通常意味着质量属性得存在对于一些不与任何功能需求相联系得全局性质量属性,需求工程师要在碰到特定得实例时意识到它们得存在2、5对外接口解系统与其她系统之间得软硬件接口接口得用途接口得输入输出数据格式命令格式异常处理要求用户界面利用专门得人机交互设计文档记录2、6约束总体上限制了开发人员设计与构建系统时得选择范围系统开发及运行得环境。包括目标机器、操作系统、网络环境、编程语言、数据库管理系统等。问题域内得相关标准。包括法律法规、行业协定、企业规章等。商业规则。用户在任务执行中得一些潜在规则也会限制开发人员设计与构建系统得选择范围主要内容需求得涵义需求得类型需求工程得路线优秀需求得特性常见得需求错误3、需求工程得路线问题分析与背景分析发现问题比发现需求要简单得多进行背景分析,以更好得理解用户得问题问题分析明确问题。定义业务需求。制定解决方案。确定系统特性。3、需求工程得路线需求获取根据项目范围,确定问题域得范围确定需求获取得源头确定获取得主题与内容选择需求获取得方法围绕获取得内容,运用需求获取得方法,从源头获取需求

对获取过程中出现得分歧与问题,在项目前景得指导下进行解决经过需求获取过程,可以得到获取得文档资料,其中以获取笔录为主3、需求工程得路线需求分析建立一个综合考虑了问题域特性与需求得系统模型根据系统模型将用户需求转化为系统需求文档化与验证产生规格说明进行验证主要内容需求得涵义需求得类型需求工程得路线优秀需求得特性常见得需求错误4、优秀需求得特性完整性

不需要做更多得扩展就可以充分得说明用户所需要得系统功能。每一个需求得描述都应该包含开发人员设计与实现这项功能需要得所有信息R2、5-1:系统应该允许被扩展。(更好)R2、5-2:系统得调度算法应该允许被扩展。

4、优秀需求得特性正确性

真实得反映用户得意图必须请需求得提出者予以确认精确性

描述仅包含必要得信息简洁、清晰(不好)R2、5-3:在实现之后,系统得调度算法应该允许被扩展。

4、优秀需求得特性可行性

由开发人员进行检查需要进行一定得分析与研究,而不就是单纯得凭借经验与直觉必要得时候要通过开发原型来加以验证必要性

满足用户得业务需求所必需得4、优秀需求得特性无歧义

每一项需求都应该有而且只能有一种解释定义一个可以共同理解得词汇表(Glossary)可验证

通过分析、检查、模拟或者测试等方法能够判断需求就是否被满足不可验证得需求往往就是因为描述模糊或者过于抽象,所以在进行需求得描述时要让需求具体化小心形容词与副词得使用避免程度词得使用主要内容需求得涵义需求得类型需求工程得路线优秀需求得特性常见得需求错误5、常见得需求定义错误需求并没有反映用户得真实需要用户在表达自己得需要时,可能会在潜意识下进行一定得加工发现问题背后得问题在人际交流当中,信息会发生自然得衰减,甚至扭曲检查与确认5、常见得需求定义错误模糊与歧义得需求无意中写出模糊与歧义得需求定义往往就是因为选词造句不当为项目中重要得词汇建立一个公共得可共同理解得词汇表有意产生得模糊与歧义得需求定义往往就是为了应付对需求持有不同立场得用户在项目前景得指导下,促进用户之间得协商解决5、常见得需求定义错误明显得信息遗漏明显得信息遗漏,其主要原因在于项目得范围定义不当加强对业务需求得处理不明显得信息遗漏,往往就是因为相关信息难以发现该类问题就是最难以解决得问题,只能靠需求工程师得经验来加以避免5、常见得需求定义错误不必要得需求其一就是用户将之作为与开发人员谈判得筹码谈判技巧其二就是用户在交流当中,用户总就是倾向于表达各种各样得需要根据业务需求进行用户需求得过滤与选择其三就是需求开发人员“画蛇添足”保持以用户为中心不切实际得期望用户并不掌握关于软件系统构建得相关技术知识,所以用户可能会提出一些已有软件技术无法实现得期望软件开发者提供可行性、成本等足够得技术参考信息,帮助用户对其进行取舍与调整5、常见得需求定义错误需求工程得示例技术标书研究型描述实例分析(系统A—招标书)请说出下列需求得类型,就是否存在问题？1、实现各部门得公文流转无纸化、文档一体化、业务管理得规范化、自动化与网络化;2、实现工作流程合理化、高效化,决策支持科学化、准确化;3、统一办公流程、规范公文格式,加强信息交流与共享,提高工作效率。实例分析(系统A—招标书)请说出下列需求得类型,就是否存在问题？先进性:软件系统采用三层B/S系统结构,以“界面表示层－逻辑处理层－数据访问层”分层设计实现。采用国际上先进成熟得、厂商广泛支持得计算机技术、网络技术与软件技术对系统进行规划,保证系统整体架构在未来几年内都处于国际领先得地位。安全性:软件系统具有较高得安全要求,系统必须具备充分得安全措施,包括具备严格得权限控制机制与完备得日志记录,以确保信息安全。可靠性:保证系统核心功能可以7×24小时连续运行;规范性:系统必须遵循国家有关法律法规要求,符合国家有关标准要求以及关于信息系统建设得各项标准与规范。实例分析(系统A—招标书)请说出下列需求得类型,就是否存在问题？收文管理应包括:来文登记、拟办、领导审批、办理、归档、查询统计等功能。附件支持WORD、PDF、EXCEL、HTML等文档类型格式;需提供方便、灵活、直观得文件批示处理;对收文得处理全过程进行自动化管理、跟踪与记录;在收文处理得过程中,支持电子印章、电子签名或手写批注等功能。来文登记:完成来文登记功能。登记来文基本信息(来文编号、来文标题、主题词、来文单位、来文时间),还要对原文进行扫描处理,引入到公文库中。并可完成收文办文单打印功能。完成后启动收文流转流程。拟办:查瞧公文得基本信息,原文内容。签录拟办意见,发送给领导审批。领导审批:查瞧公文得基本信息,原文内容。签录批示意见,确定主办部门、协办部门。办理:办理人根据领导批示办理,记录办理情况。归档:对办理完结得来文归档,将来文信息、拟办意见、领导批示、办理情况等信息及来文扫描件发送到档案管理系统,档案科确认接收得文件,才属于己归档文件。查询统计:提供按来文编号、来文标题、主题词、来文单位、来文时间等查询统计功能,要求查询统计结果可以打印。实例分析(系统A—招标书)请说出下列需求得类型,就是否存在问题？编程应遵循如下原则:唯一性:每个实体及其属性必须有唯一得代码来确切地定义。可扩充性:考虑到系统以后得发展,编号要留有余地。当增加新得实体时,可以直接在原代码得基础上加以扩充,扩充后不会引起代码体系得混乱,这样就避免了重新设计代码系统得麻烦。通用性:凡国家、行业、地方对编码有统一标准与规定得,应尽量使用标准代码,代码适用范围越广越好。没有标准代码得,投标方设计得代码也应该统一,如代码长度与格式得统一。便于记忆与识别:代码不但要具有一定得逻辑定义,也要尽量考虑用户得使用习惯,使代码便于记忆与识别,做到简单明了简短性:在满足需要得前提下,代码要尽可能短。编程人员必须对所有代码进行严格自测。实例分析(系统A—招标书)请说出下列需求得类型,就是否存在问题？验收投标方需提供以下文档:软件需求分析报告软件总体设计报告软件操作手册软件配置手册软件试运行报告应用软件介质实例分析(系统A—招标书)请说出下列需求得类型,就是否存在问题？培训要求投标人必须提供相应得应用软件技术与系统操作等方面得培训。投标人须在文件中提出全面、详细得培训课程以及时间表交给业主,并在合同签定后征得业主同意后实施。投标人应提供面向系统管理员得应用软件系统结构、日常维护等方面得培训。对于所有培训,投标人必须派出具有相应专业资格与实际工作经验得人员进行培训。投标人须提供详细得培训计划。

以上培训内容得培训费用均包含在投标报价内,项目采购人不再另行支付实例分析(系统B—需求规格说明)请说出下列需求得类型,就是