需求分析基础

上传人:一*** 文档编号:243425865 上传时间:2024-09-23 格式:PPT 页数:71 大小:1.32MB
返回 下载 相关 举报
需求分析基础_第1页
第1页 / 共71页
需求分析基础_第2页
第2页 / 共71页
需求分析基础_第3页
第3页 / 共71页
点击查看更多>>
资源描述
单击以编辑,母版标题样式,单击以编辑母版文本样式,第二级,第三级,第四级,第五级,需求分析基础,3,第三,章,软件需求作为软件生命周期的第一个阶段,其重要性越来越突出,到,20,世纪,80,年代中期,逐步形成了,软件工程的子领域,需求工程。,90,年代后,需求工程成为软件界研究的重点之一。从,1993,年起,每两年举办一次需求工程国际研讨会(,ISRE,),,1994,年起,每两年举办一次需求工程国际会议(,ICRE,)。一些关于需求工程的工作小组相继成立,使需求工程的研究得到了迅速进展。,3.1,软件需求工程的基本概念,对系统应该提供的服务和所受到的约束进行理解、分析、建立文档、检验的过程,需求工程,1.,什么是软件需求工程?,2.,软件需求工程的任务是什么?,3.,需求工程过程,4.,软件需求分析方法,软件需求的重要性,软件需求无疑是当前软件工程中的关键问题,,没有需求就没有软件,。,美国于,1995,年开始对全国范围内的,8000,个软件项目进行跟踪调查。,分析失败的原因发现,与需求过程相关的原因占了,45%,,而其中,缺乏最终用户的参与以及不完整的需求又是两大首要原因,,各占,13%,和,12%,。,未完成,完成未实施,完成,软件需求的困难,软件需求是软件工程中最复杂的过程之一:,应用领域的广泛性,,它的实施无疑与各个应用行业的特征密切相关。,非功能性需求建模技术的缺乏,,及其与功能性需求有着错综复杂的联系,大大增加了需求工程的复杂性。,沟通上的困难,,由于系统分析员、需求分析员等各方面人员有不同的着眼点和不同的知识背景,给需求工程的实施增加了人为的难度。,软 件需 求,用 户需 求,系 统需 求,功能需求,非功能需求,领域需求,由客户管理员、,用户等提出,软件需求的内容,一、软件需求内容,功能需求,它是对系统应该提供的服务、功能以及系统,在特定条件下的行为的描述。它与软件系统的类,型、使用系统的用户等相关,有时需要详细描述,系统的功能、输入,/,输出、异常等,有时还需要申,明系统不应该做什么。,领域需求,是由软件系统的应用领域所决定的特有的功,能需求,或是对功能的约束。,非功能需求,产品需求,机构需求,外部需求,互操作,需求,道德,需求,立法,需求,性能,需求,空间,需求,交付,需求,实现,需求,标准,需求,隐私,需求,安全,性需求,可用性,需求,效率,需求,可靠性,需求,可移植,性需求,传统需求分析,在传统软件工程生命周期中,涉及需求的阶段称作需求分析。一般来说,需求分析的作用是:,定义软件的范围及必须满足的约束;,确定软件的功能和性能及与其他系统成分的接,口,;,建立数据模型、功能模型和行为模型;,最终提供需求规格说明,并用于作为评估软件,质量的依据。,二、需求工程的活动,需求工程是系统工程和软件工程的一个交叉分支,涉,及到软件系统的目标、软件系统提供的服务、软件系统的,约束和软件系统运行的环境。它还涉及这些因素和系统的,精确规格说明以及系统进化之间的关系。它也提供现实需,求和软件能力之间的桥梁。,需求工程,系统目标,系统服务,软件约束,运行环境,需求工程的基本活动包括:,获取需求,;,深入实际,在充分理解用户需求的基础上,获取系统需求。,需求,分析与建模;,进行需求建模、对模型或原型进行分析。,确认需求,;,确保需求说明准确、完整地表达系统的主要特性。,进化需求,。客户的需要总是不断(连续)增长的 ,进化需求是必要的。,一、,需求获取,(,requiremente,licitation,),是需求工程的主体。,缺乏领域知识,应用领域的问题常常是模糊的、不精确的;,存在默认的知识,如难以描述的常识问题;,存在多个知识源,且多知识源之间可能有冲突;,客户可能的偏见,,如不能提供,或不想告知,你所需要了解的事情。,非常困难,主要原因有:,需求获取技术,需求抽取的方法一般有:,1.,面谈法,重要而直接,简单的,需求获取技术。,2.,问卷调查法,是对面谈法的补充。,3.,需求专题讨论会,最有力的,需求获取技术。有利 于 培养高效团队。,4.,观察用户的工作流程,适用于用户无法准确表达需求的情况。,5.,原型化方法,6.,基于用例的方法,还有知识工程方法等如:场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。,面谈的对象主要有用户和领域专家:,1,) 面谈前的准备要充分;,2,) 面谈后注意认真分析总结;,3,) 注意掌握面谈的人际交流技能。,需求获取技术,需求抽取的方法一般有:,1.,面谈法,重要而直接,简单的,需求获取技术。,2.,问卷法调查法,是对面谈法的补充。,3.,需求专题讨论会,最有力的,需求获取技术。有利 于 培养高效团队。,4.,观察用户的工作流程,适用于用户无法准确表达需求的情况。,5.,原型化方法,6.,基于用例的方法,是从多个用户中收集需求信息的有效方式 ,一般问卷设计形式:,1,)多项选择问题 ;,2,)评分问题 ;,3,)排序问题 。,需求获取技术,需求抽取的方法一般有:,1.,面谈法,重要而直接,简单的,需求获取技术。,2.,问卷法调查法,是对面谈法的补充。,3.,需求专题讨论会,最有力的,需求获取技术。有利 于 培养高效团队。,4.,观察用户的工作流程,适用于用户无法准确表达需求的情况。,5.,原型化方法,6.,基于用例的方法,由开发方和用户方共同召开,操作步骤:, 开发方根据双方制定的,需求调研计划,召开相关需求主题沟通会;, 会后开发方整理出,需求调研记录,提交给用户方确认;, 如果此主题还有未明确的问题则再次沟通,否则开始下一主题;, 所有需求都沟通清楚后,开发方根据历次,需求调研记录,整理出,用户需求说明书,,提交给用户方确认签字。,因此系统应该具备以下功能:, 基本数据维护功能, 基本业务功能, 数据库管理功能, 信息查询功能,例,1,:有一个大学图书管理系统,该系统除了一般的图书管理功能外,还能够为学生和教工从其他图书馆借阅图书和文献资料提供服务。,1.,功能需求,基本数据维护功能:,提供使用者录入,修改并进行维护基本数据的途径。基本数据包括读者的信息、图书资料的相关信息,可以对这些信息进行修改,更新。,基本业务功能:,读者借、还书籍的登记管理功能,随时根据读者借、还书籍的情况更新数据库系统,如果书籍已经借出,可以进行预留操作,书籍的编目、入库、更新等操作。,数据库管理功能:,对所有图书信息及读者信息进行统一管理维护的功能,对书籍的借还也要进行详细的登记,以便协调整个图书馆的运作。,信息查询功能:,提供对各类信息的查询功能,如对本图书馆的用户借书信息,还书的信息,书籍源信息,预留信息等进行查询,对其他图书馆的书籍、资料源信息的查询功能。,2.,非功能需求, 系统安全性需求:,为保证系统安全性,对本图书馆的各项功能进行分级、分权限操作,对各类用户进行确认。对其它图书馆借阅图书和文献资料服务控制访问范围:如限,IP,、限用户等。, 对系统可用性的需求:,为了方便使用者,要求对所有交互操作提供在线帮助功能。, 对系统查询速度的需求:,要求系统在,20S,之内响应查询服务请求。, 对系统可靠性的需求:,要求系统失败发生率小于,1%,。,3.,领域需求,例如:对“大学图书管理系统”,提出一些与图书管理的业务相关的需求:, 图书编目要求按照,中国图书馆分类法,进行;, 由于版权限制,某些文献资料只能在图书馆规定的阅览室阅读,并限制复制和打印。,第一条需求是对遵循我国图书管理的规定,执行对图书的分类管理的标准。而第二条需求则是版权法对图书馆文献资料的保护的需要,描述了对一类文献资料有限制的使用和服务。,二、,需求分析与建模,需求分析和建模又包含三个层次的工作。,1,、需求分析,2,、需求建模(分为企业,建模,、功能需求,建模,和非功能需求,建模,等),3,、,需求规格说明,不同的描述方式。,主要对收集到的需求进行提炼、分析和认真审查,确保所有参加人员取得一致共识。找出错误、遗漏和不足,建立完整的分析模型。,需求分析常用技术,为了降低软件的复杂度,便于对问题的分析和理解,常采用以下技术:,1.,分解,将大问题分解为小问题,通常是自顶而下,不断细化的过程。,2.,抽象,抓住问题的本质特性,从不同抽象层次进行分析,提出解决问题的方案。,3.,多视点,注意从各类开发人员和不同用户的角度考虑问题,才能获得 对系统的全面完整的需求。,三、需求的有效性验证,(,一,),需求验证的重要性,.,由于需求是软件开发的第一阶段,直接影响后面各阶段的开发。,.,需求的可变性必须进行验证。,软件需求,软件设计,软件编码,软件测试,运行维护,做什么,怎么做,三、需求的有效性验证,(,二,),需求验证的内容,1,.,有效性检查,指功能需求是否符合用户所提出的需求。,2.,一致性检查,系统功能描述及约束是否一致。,3.,完备性检查,是否包含所有系统用户的需求和,约束。,4.,可检验性检查,是否能设计出一组验证方法,确定了检验的标准。,四、需求管理,需求管理贯穿需求分析全过程,包括,:,需求管理,变更控制,建议变更,分析影响,交流,合并,测量需求的稳定性,版本控制,定义需求文档版本,确定单个需求文档版本,需求跟踪,定义与其他需求的链接,定义与其他系统元素的链接,需求状态跟踪,定义需求状态,跟踪所有需求状态,四、需求管理,需求管理的所有活动中,最重要的是,“,需求变更管理”,,包括,:,问题分析和变更描述,变更分析和成本计算,变更实现,修正后的需求,识别出的问题,需求管理过程需要,CASE (Computer Aided Software Engineering),工具支持。,1.,传统的变化管理,基本内容包括软件配置、软件基线和变化审查。,2.,新的管理方法,软件家族法,。即软件产品线方法,该方法是源于工业界产品线的概念,关注于一个软件企业如何组织一组具有共性特征的,相似产品的生产,并应用软件复用的相关原理与技术。,多视点方法,。它可以用于管理不一致性并进行关于变化的推理。是从多个视点出发在软件工具的协助下对需求描述,进行自动需求建模,从而提高需求模型的完整性。,需求变更管理方法,需求工程过程,可行性研究,需求导出,和分析,需求描述,需求有效性,验证,可行性报告,系统模型,用户需求和,系统需求,需求文挡,3.2,需求分析方法,功能分解方法,将系统看作若干功能模块的集合,每个功能又可,以分解为子功能,子功能还可继续分解,分解的结果即,是系统的雏形。,存在问题,1.,需要人工完成,2.,无法对描述的准确度进行验证。,3.,难以适应需求的变化。,问题空间,功能,子功能,映射,1,客房预定系统,2,前台接待系统,3,前台收银系统,4,帐务系统,5,管家系统,6,电话系统,7,客历系统,8,合约系统,9,经理系统,10,总经理系统,11,密码管理系统,12,报表系统,13,帐务报表,酒店管理系统,例:,按照功能分解为以下子系统:,盘存,/,销售系统,1.0.0,销售处理,1.1.0,盘存处理,1.2.0,例:,盘存,/,销售系统,用户提出系统应有以下功能,:,计算买主订单,准备销售报表,建立买主文件和应收帐发票,运行更新的盘存文件,产生托运单和包装单,保证库存及时订货,计算销售,记录,1.1.1,产生销售,报表,1.1.2,核对买主,贷方金额,1.1.3,验证库存,量级,1.2.1,产生货运,订单,1.2.2,执行买主,汇票,1.2.3,产生盘存,报表,1.2.4,3.2,需求分析方法,结构化分析方法,是一种以数据、数据的封闭性为基础,从问题空,间到某种表示的映射方法,由数据流图,(,DFD,图,),表示。,顾客,出版社,验证,订单,汇总,订单,订单,出版社,订单,图书目录文件,顾客档案,待处理订单文件,正确,订单,一批,订单,出版社档案文件,订货存根文件,3.2,需求分析方法,面向对象的分析方法,面向对象分析方法,(,OOA,),的关键是识别问题域内的对象,分析它们之间的关系,并建立起三类模型。,信息建模法,是从数据的角度对现实世界建立系统的信息模型,基本工具是,ER,图。是由实体、属性和关系组成的网络图。,E-,实体,是一个或一组对象;,R-,关系,,实体之间联系或交互作用。,注意:信息建模与面向对象分析的区别!,3.2.1,结构化分析方法,分解:,对于一个复杂的系统,为了将复杂性降低到可以掌握的程度,可以把大问题分解成若干小问题,然后分别解决(如右图)。,一、,SA,法的基本思想,“,分解”和“抽象”。,抽象:,分解可以分层进行,即先考虑问题最本质的属性,暂把细节略去,以后再逐层添加细节,直至涉及到最详细的内容,这种用最本质的属性表示一个系统的方法就是“抽象”。,1.1,1.2,1.3,x,2,1,3,2.1,2.2,2.3,1.1,1.3,基本思想与步骤,三、,SA,法的描述方法,1,、分层的数据流图,(DFD,图,),2,、数据词典,3,、描述加工逻辑的结构化语言、判定表及判定树,二、,SA,法的步骤,当前系统,具体模型,建立,当前系统,逻辑模型,抽象,目标系统,逻辑模型,建立,完善的系统逻辑模型,改进,深入调查,研究,分析用户需求,用,DFD,图描述,分析系统需求,用,DFD,图描述,修改完善,DFD,图,增添功能,顾客,出版社,验证,订单,汇总,订单,订单,出版社,订单,图书目录文件,顾客档案,待处理订单文件,正确,订单,一批,订单,出版社档案文件,订货存根文件,画图步骤 :,1,、确定外部实体及输入、输出数据流。,2,、确定分解顶层的加工。,3,、确定使用的文件。,4,、用数据流将各部分连接起来,形成数据封闭。,注意:标注各加工框及数据流名称。,例一 图书预定系统(顶层,DFD,图),三、,数据流图,数据流图(,Data Flow Diagram,,,DFD,),是描述系统中数据流程的图形工具,它描述了将系统的逻辑输入转换为逻辑输出所需的加工处理过程。,数据存储,数据源点,或终点,加 工,加工名,数据流,数据流名,文件名,实体名,箭 头,圆或椭圆,单或,双杠,矩形框,还有一些辅助的图例,:,一、数据流图的图符,基本图形符号:,T,A,B,*,C,T,A,B,*,C,T,A,B,+,C,T,A,B,+,C,T,A,B,C,+,T,A,B,C,+,*,与,+,或,互斥,+,X,1,3,2,1.1,1.2,1.4,1.3,2.1,2.2,1.1.1,1.1.2,2.1.3,2.1.2,2.1.1,2.2.2,2.2.3,2.2.1,顶层,中 间 层,底 层,先全局后局部,先整体后细节,先抽象后具体,.,0,图,1,图,2,图,1.1,图,2.1,图,2.2,图,分层,DFD,图,需求案例分析,案例一 医院病房监护系统,(采用结构化分析方法),案例二 网上竞拍系统,(采用基于用例的方法),一、问题的描述,在医院,ICU,病房里,将病症监视器安置在每个病床,对病人进行监护。监视器将病人的组合病症信号实时地传送到中央监护系统进行分析处理。,在中心值班室里,值班护士使用中央监护系统对病员的情况进行监控,监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析,当病症出现异常时,系统会立即自动报警,并打印病情报告和更新病历。,根据医生的要求随时打印病人的病情报告,系统还定期自动更新病历。,案 例 一,医院病房监护系统,经过初步的需求分析,得到系统功能要求:,1,、监视病员的病症,(,血压、体温、脉搏等,),。,2,、定时更新病历。,3,、病情出现异常情况时报警。,4,、随机地产生某一病员的病情报告。,例,2,:医院病房监护系统,产生,病情报告,监视病情,更新病历,2.2.3,实例:医院病房监护系统,请分析软件,系统,需求,!,1,、监视病员的病症,采集病症信号,(,血压、体温、脉搏等,),。,组合病症信号。,将模拟,病症信号转换为数字信号(,A-D,转换)。,2,、定时更新病历,将,病症信号进行格式化并加入更新日期、时间。,更新病历库中病人的信息。,可人工设定更新,病历的时间间隔。,3,、病情出现异常情况时报警,根据标准病症信号库中的值,判断是否报警。,将报警信号转换为各种模拟信号(,D-A,转换)。,实时打印病情报告,立即更新病历。,4,、随机地产生某一病员的病情报告,二、系统功能需求,局部监视,更新日志,产生病情报告,非功能需求,1,、监视器与网络的,可靠性要求,,涉及人的生命安全。,2,、,效率需求,中对时间、空间的需求,所采集的病症信号数据量大。,3,、,互操作需求,如要求监视器采样频率可人工调整等。,4,、对病人病历的,隐私的要求。,病员,护士,护士,病员监,护系统,病员,日志,病症信号,要求报告,病症,报告,报警,顶 层,DFD,图,医院病房监护系统分层,DFD,图,顶层确定了系统的范围,其外部实体为病员和护士,护士,病员,护士,第一层:,病员,护士,护士,中央监视,病员,日志,病症信号,要求报告,病症,报告,报警,局部监视,生成报告,病员极限,更新日志,病员数据,格式化,病员数据,生理信号,极限值,1,3,2,4,日志数据,日志数据,医院病房监护系统顶层,DFD,图,紧急报告,第二层:加工,“,中央监视,”,分解,医院病房监护系统二层,DFD,图,计算超过,极限值否,病员,数据,超过,极限值,报警,开解信号,产生,报警信息,病员极限,格式化,病员数据,体温,血压、体温脉搏,生理信号,极限值,时间,脉搏,血压,日期,时钟,格式化,病员数据,3.1,3.2,3.3,3.4,紧急报告,计算超过,极限值否,病员,数据,超过,极限值,报警,开解信号,产生,报警信息,病员极限,格式化,病员数据,体温,血压、体温、,脉搏,生理信号,极限值,时间,脉搏,血压,日期,时钟,格式化,病员数据,3.1,3.2,3.3,3.4,第二层:加工,“,中央监视,”,分解,医院病房监护系统分层,DFD,图,第一层,格式化,病员数据,生理信号,极限值,病员,护士,护士,中央监视,病员,日志,病症信号,要求报告,病症,报告,报警,局部监视,生成报告,病员极限,更新日志,病员数据,1,3,2,4,日志数据,紧急报告,紧急报告,加工分解的原则,自然性,:,概念上合理、清晰;,均匀性,:理想的分解是将一个问题分解成大小均匀的几个部分;,分解度:,一般每一个加工每次分解最多不要超过个子加工,分解应分解到基本加工为止。,四、 画分层,DFD,图的基本原则,数据守恒与数据封闭原则,数据守恒是指加工的输入,/,出数据流是否匹配,,即每一个加工既有输入数据流又有输出数据流。,数据封闭是对整个系统而言。,合理使用文件,当文件作为某些加工之间的交界面时,文件必须画出来,一旦文件作为数据流图中的一个独立成份画出来了,那么他同其他成份之间的联系也应同时表达出来。,注意,DFD,图不是流程图,不表示软件的控制流程。,四、 画分层,DFD,图的基本原则,子图与父图的“平衡”,父图中某个加工的输入输出数据流应该同相应的子图的输入输出相同,(,相对应),分层数据流图的这种特点称为子图与父图“平衡”。,五、 分层,DFD,图的改进,DFD,图须经过,反复修改,,才能获得最终的目标系统,的,DFD,图。从以下方面改进,DFD,图:,1,、,检查数据流的正确性,数据,守恒, 子图、父图的平衡, 文件使用是否合理。特别注意输入,/,出文件的数,据流。,2,、改进,DFD,图的易理解性, 简化加工之间的联系(联系越少,独立性越强,,易理解性越好)。, 改进分解的均匀性。, 适当命名(各成分名称无二义性,准确、具体),分层数据流图只是表达了系统的“分解”,为了完整地描述这个系统,还需借助“,数据词典,”和“,小说明,”对图中的每个数据和加工给出解释。,对数据流图中包含的所有元素的定义的集合构成了数据词典。词典中可有以下四种类型的条目,:,六、 数据词典,(DD),数据流 文件 数据项 加工,A,、,数据流条目,给出某个数据流的定义,通常是列出该,数据流的各组成数据项。,例如:报名单姓名单位名年龄性别课程名,常用符号:、()、,C,、,数据项条目,数据项条目给出某个数据单项的定义,通常是数据项的值类型,允许的取值范围。,B,、,文件条目,给出某个文件的定义,文件的定义通常是列出文件记录的组成数据流。例如:,订单文件订单编号顾客名称产品名称订货数量交货日期,D,、,加工条目,加工类条目就是“加工小说明”。一般应该单独列出。,七、 加工说明,结构化语言,判定表,判定树,对,DFD,图中每一个基本加工都必须有一个,小说明,给出该加工的精确描述。小说明中应精确地描述加工的激发条件、加工逻辑、优先级、执行频率和出错处理等。加工逻辑是其中最基本的部分,指用户对这个加工的逻辑要求。,对基本加工说明有三种描述方式:,结构化语言是介于自然语言和形式语言之间的一种半形式语言,是自然语言的一个受限制的子集。,一般分为两层结构:外层语法较具体,为控制结构(顺序、选择、循环),内层较灵活,表达,“,做什么,”,。,(一) 结构化语言,例如:外层可为以下结构:,1,、顺序结构,2,、选择结构,IFTHEN-ELSE; CASE-OF-ENDCASE,;,3,、,循环结构,WHILE-DO; REPEAT-UNTIL,判定表是一种二维的表格,常用于较复杂的组合条件(与结构化语言比较)。,条件框 条件条目,操作框 操作条目,(二),判定表,特点:可处理较复杂的组合条件,但不易理解,.,不易输入计算机。,通常由四部分组成。,条件框,条件定义。,操作框,操作的定义。,条件条目,各条件的取值及组合。,操作条目,在各条件取值组合下所执行的操作,。,例如,:,对商店每天的营业额所收税率,营业额,X,(,),1000X5000,5000 X,1000,元,Y,Y Y N,信誉好,Y N N -,20,年,- Y N -,优 惠,X X,正 常,X X,化简后,1 2 3 4 5 6 7 8,1000,元,Y,Y Y Y N N N N,信誉好,Y Y N N Y Y N N,20,年,Y N Y N Y N Y N,优 惠,X X X,正 常,X X X X X,Y-,满足条件,N-,不满足条件,X-,选中判定的结论,判定表,应用举例,特点,:,描述一般组合条件较清晰,易理解。不易输入计算机。,营业额,1000,元,1000,元 正常处理,好的支付信誉,优惠处理,坏的支付信誉, 20,年,优惠处理, 20,年 正常处理,如上例,(三) 判定树,1992,年由,Jacobson,提出了,Use case,的概念及可,视化的表示方法,Use case,图,并加入由他提出的,面向对象的软件工程,(OOSE),。,Use case,的概念受到了,IT,界的欢迎,被广泛应,用到了面向对象的系统分析中。基于用例的需求方,法,已成为面向对象的分析方法的主流。,用例模型被推荐为获取和识别需求的首选工具,!,基于用例的方法,3.2.2,面向对象的分析方法,(,OOA,),Use case,图,采用,“基于用例的方法”,来,识别和,获取,需求,是,从外部的角度来看系统功能,建立系统的,Use case,模型。,描述外部执行者,(Actor),所理解的系统功能。即待开发系统的功能需求。,用例,表示一个子系统,或者系统一个独立的功能。,角色,表示外部的“执行者”。,描述方法:,用例 : 角色: 连接:,用例,ATM,机验证储户身份的,Use case,图,创建用例模型的工作包括:,定义系统、确定执行者和用例、描述用例、定,义用例间的关系、确认模型。,3.2.2,面向对象的分析方法,(,OOA,),案例,3,网 上 拍 卖 系 统,随着,Internet,技术的发展和互联网的日益普及,互联网用户中约,1/4,的用户使用,Internet,进行互联网通信或经贸活动。电子商务总额每年可达到,6,万亿美元。,网上拍卖系统就是一个在互联网上模拟拍卖环境的典型的范例。可实现从展示产品、相互竞价到最后产品成交等一系列功能,;,用户可以轻松实现在线商品的拍卖和竞标 。,建立系统的,USE CASE,模型。,一、竞拍平台,1.,竞拍者资格审查,2.,竞拍规则设定,3.,竞拍过程控制,二、拍卖商品信息发布,确定发布的商品信息,对商品信息操作,三、拍卖步骤及在线帮助,四、网上支付系统,五、用户管理,用户需求,系统需求,1.,执行者,用户,系统是通过网络提供给商品的销售者和购买者一个交易平台,因此所有上网用户都是本系统的用户,具体又分为,商品购买者,和,商品销售者、系统管理员,。,考虑到一般用户既可能是商品购买者也可能是商品销售者,所以将用户分为,:,非会员用户和会员用户,.,非会员,_,未注册的用户,只能在网站上浏览商品,不能参与竞标,也不能提供物品出售。,会员,_,已注册的用户,可以直接参与拍卖或竞标,.,系统需求,2.,用例,分析系统功能,提供高效的内容丰富的,Web,拍卖商业服务,;,展示产品、相互竞价 、产品成交 。,实现拍卖商品种类的更新和消息的发布。,实现个人物品流通和网上信息发布、留言。,初步确定以下功能:,1),会员注册,2),会员天地,3),商品分类浏览,4),查找商品,5),拍卖商品,6),购买商品,7),网上支付,系统需求,进一步确定以下功能:,1),会员注册,(填写用户帐号,用户名,密码,Email,等,),2),会员天地,(查看并修改个人信息,交易记录,收邮件,信用评价等,),3),商品分类浏览,(浏览、更新、最新商品推荐等,),4),查找商品,(按关键字查找、输出打印商品信息),5),拍卖商品,(,包括商品上架:,提供商品信息,:,商品名称、类别、图片、,起拍价格、新旧程度、使用时间 等,及,编辑商品,商品下架,),6),购买商品,(,即出价参与竞标,拍卖结束时按照竟价规则获得商品,),7),网上支付,(通过银行网络系统进行交易,,设置多,种支付方式,),增加执行者“银行”,8),收藏商品,(可添加收藏,取消收藏,修改收藏),9),会员管理,(查看会员信息,封锁会员账号,激活,会员账号),10),商品类别管理,(添加商品类别,编辑商品类别,,删除商品类别),11),交易管理,(查看交易,查看交易报表,关闭交易,退款管理,申诉管理),12),公告栏管理,(添加公告,修改公告,删除公告),建立,Use Case,模型,买商品,卖商品,1.,精度要求,本系统所涉及的所有交易数据,均按实数保存,在处理时保留小数点后,2,位。,2.,时间特性要求,操作响应时间:满足普通人员的操作要求;,查询运行时间:满足普通人员的查询要求;,更新处理时间:数据库在网络无故障的情况下,,插入一条数据和更新一条数据的数据库操作响应时间,控制在,2,秒,/,条之内;,数据传输时间:数据交换过程控制在,10,秒钟内;,非功能需求,非功能需求,3.,故障处理能力要求,当出现错误时,要求以界面形式向用户说明,并,用一览表方式列出,各类可能的错误或故障出现时,,系统的处理方法和补救措施。,4.,灵活性 需求,要求当用户需求,如操作方式,运行环境,结果,精度,数据结构及其他软件接口等发生变化时,增加,新模块时,不会修改原有的模块。,5.,安全性,采用用户名及密码,对用户授权使用。支付过程,中的安全性由银行网上支付系统进行保证。,改进的,Use Case,模型,需求分析小结,软件需求工程,是软件开发人员与用户密切配合,充分交换意见,获得对需求一致意见的过程。,在开发者一方,参与工作的主要,角色,是系统分析员和系统工程师等,负责沟通用户和开发人员的认识和见解,起着桥梁作用。,需求工程阶段的最终任务是要完成目标系统的需求规格说明,确定系统的功能、非功能需求和性能,为后阶段的开发打下基础。,本阶段常用的有,SA,法,,原型法,,OOA,法,等。,
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 图纸专区 > 小学资料


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!