华为需求设计需求分析写作培训市公开课一等奖省赛课微课金奖课件.pptx

,谢 谢 !,需求设计写作培训,质量管理部,SQA小组,.06,1/90,课程范围,仅关注怎样写作文档,不包括详细需求分析和设计方法,2/90,课程内容,为何要文档化,文档写作基本要求,需求设计文档模板,需求文档写作,设计文档写作,3/90,为何要文档化,开发人员经过文档化过程查错补遗；,便于评审，在早期发觉技术上问题；,后续阶段开发任务可能由他人负担，输出文档便于他们开展工作；,维护人员开展维护工作需要；,文档是必要交付件；,可读性就尤为关键,4/90,为何要文档化,“全部过程分析都要形成文档。我们现在有一个严重问题是，,大家好像不喜欢写文档，对于需要实现方案，通常都是一个责任人在脑袋里想想该怎么实现，然后邮件或电话找几个相关人员讨论一下就算能够了，,可能连个会议材料或会议纪要都没有。,而老外可不是这么，他们非常非常重视文档，他们认为,一个人在脑袋里想东西是不清楚也不全方面，有时候心里想认为很正确方案实际上可能存在致命缺点。他们要求必须把心里想法形成文档才能有效防止这种问题。,写文档过程中，能够愈加有效、更深入去整理您原来心里思绪，很多问题在您写过文档过程中您就能发觉；另外，文档写作多使用图表，浪费口水文字尽可能少用，和我们一起工作系统工程师在系统架构分析中就画了五六十张图，,就算看不懂他写英文，从图中我们就能够很清楚指导整个产品系统架构,。”,摘自一位华为员工瑞典出差汇报,5,5/90,课程内容,为何要文档化,文档写作基本要求,需求设计文档模板,需求文档写作,设计文档写作,6/90,文档写作基本要求,下面文档出自于我们开发人员手笔，大家以为怎样？,7/90,文档写作基本要求,应使用标准模板写作；,文档封页、页眉页脚、修订统计、附录、参考文件应完善；,关键词、摘要、缩略语应完整；,目录要及时更新；,通篇文档标题、文字格式、间距应协调美观；,全部文档模板中章节，只可增加，不可删除；,编写提议是用来指导文档写作，在利用完后要及时删除；,图号置于图形之下，表号置于表格之上；,8/90,文档写作基本要求,应追求图文并茂效果；,句子和段落要短；,使用语言应严谨，不要使用白话；,采取主动语气；,不要出现“我们”、“你们”、“他们”这么称谓，或“这个”、“那个”这么词，应使用“本”、“该”、“其”；,表述清楚，防止引发歧义；,通篇文档细节上要保持一致；,9/90,练习,房子南北走向，房子大门在东侧中间位置。门厅长约3米，宽2米，门厅左面是主卧室，右面是厨房。厨房3米宽，4米长，厨房门对着门厅，厨房顶头还有一个北阳台，与厨房同宽，长1米。主卧室宽3米，长5米左右，房间门对着客厅。客厅与餐厅连为一体，共7米长，4米宽，与客厅相连有一南阳台，与客厅同宽，长1.5米。餐厅北面是卫生间，卫生间与厨房相对，中间由1米宽，3米长过道隔开；卫生间门对着过道，南墙与厨房南墙在一条直线上；卫生间为长方形，南墙长3米，另一边长2米。卫生间北面是次卧，同宽，门朝着过道，次卧长4米。过道北端是书房门，书房南北长4米，书房有一个一米见方门厅，书房西墙长4米，包含1米长门厅长度，西墙把书房和次卧分隔开。门厅东墙北端90角折向东，长2米，把书房和厨房北阳台分隔开。,大家认为下面描述怎样？,终究长多少？?,是左？,还是右？,大段叙述，不利于了解！,10,10/90,练习,1.房子南北走向，房子大门在东侧中间位置。,2.,门厅,长3米，宽2米，门厅左面是主卧室，右面是厨房。,3.,厨房,3米宽，4米长，厨房门对着门厅，厨房顶头还有一个北阳台，与厨房同宽，长1米。,4.,主卧室,宽3米，长5米左右，房间门对着客厅。,5.,客厅,与餐厅连为一体，共7米长，4米宽，与客厅相连有一南阳台，与客厅同宽，长1.5米。,6.餐厅北面是,卫生间,，卫生间与厨房相对，中间由1米宽，3米长过道隔开；卫生间门对着过道，南墙与厨房南墙在一条直线上；卫生间为长方形，南墙长3米，另一边长2米。,7.卫生间北面是,次卧,，同宽，门朝着过道，次卧长4米。,8.过道北端是,书房,门，书房南北长4米，书房有一个一米见方门厅，书房西墙长4米，包含1米长门厅长度，西墙把书房和次卧分隔开。门厅东墙北端90角折向东，长2米，把书房和厨房北阳台分隔开。,修改成以下描述之后呢？,11/90,练习,主卧室,次卧室,厨房,餐厅,客厅,阳台,阳台,卫生间,书房,门厅,过道,北,西,再改成以下列图形描述呢？,12/90,练习,LSW与CAMS配合实现认证计费方案中，客户（禁止多人同时使用业务帐号）登陆经过认证开始计费后，假如出现LSW重起情况，处理方法分为两种：,1.有时间芯片LSW（能够统计时间），设备重起后会使用设备时间戳特征判断出设备重起了，这时会将CAMS上在线用户删除并按照最终一次计费更新报文来终止计费。用户可再次正常登陆。,2.,下面描述呢？,白话,修改成以下描述呢？,1.使用时间芯片LSW（,支持统计时间功效,），利用设备时间戳特征能够检测出设备,是否重启,，,设备重启时,将CAMS上在线用户删除，并依据最终一次计费更新报文终止计费。用户可再次正常登陆。,13/90,练习,因为一台设备能够设置多个radius服务器，也就是radius scheme。用户能够经过命令行来配置该radius服务器是否开启设备重启防吊死功效。,因为一台设备能够设置多个radius服务器，即radius scheme。用户能够经过命令行来配置该radius服务器是否开启设备重启防吊死功效。,14/90,练习,CAMS收到该报文后会马上回应一个code=5计费回应报文，然后依据accounting-on报文携带NAS-IP和NAS-ID找到经过该设备认证用户，并将他们在线信息删除。,CAMS收到该报文后会马上回应一个code=5计费回应报文，然后依据accounting-on报文携带NAS-IP和NAS-ID找到经过该设备认证用户，并将,其,在线信息删除。,15,15/90,练习,修改原因：,这个函数是将要发送packet转化为buffer，系统原有函数RD_PutPacketToBuffer是针对认证用户设计，因为本特征为设备开启后执行，没有用户信息，所以在RD_PutPacketToBuffer函数基础上做了一些修改，形成该函数。,修改原因：,该函数实现将待发送packet转化为buffer功效，系统原有函数RD_PutPacketToBuffer针对认证用户设计，因为本特征为设备开启后执行，没有用户信息，所以在RD_PutPacketToBuffer函数基础上做了一些修改，形成该函数。,16/90,练习,ARP Authorized加强了网络安全，阻止了DHCP server对非法ARP回应进行学习，而且经过周期ARP ping能够快速探测到用户是否下线。,在设备接口上使能ARP Authorized，该接口ARP动态学习功效被禁止。在某个接口上禁止arp动态学习，不影响其它接口arp学习。,在禁止了arp动态学习接口上，只能经过手工添加静态arp，或者其它一些被允许模块才能够添加arp，这种arp被称为ARP Authorized，授权arp不再和其它动态表项一样老化，而是有自己老化机制，后面会说明。DHCP server就是这么一个模块。,静态arp优先级高于授权arp，也就是说能够覆盖授权arp。,1.ARP与arp、ARP Authorized与授权arp，使用术语应该统一；,2.ARP Authorized应先解释后引用；,3.“DHCP server就是这么一个模块”，是否相关？,17/90,课程内容,为何要文档化,文档写作基本要求,需求设计文档模板,需求文档写作,设计文档写作,18/90,模板,何处获取,需求,SRS文档：REP01T01,jvpal,接口文档：REP01T03,jvpal,设计,概要设计：DVP05T01,jvpal,详细设计：DVP05T03,jvpal,软件设计：DVP05T04,jvpal,移植设计：DVP05T05,jvpal,需求设计合一,来自华为北研所,h3crnd01-fs软件部规范小特征开发规范模板需求设计,需求设计文档模板,19,19/90,课程内容,为何要文档化,文档写作基本要求,需求设计文档模板,需求文档写作,设计文档写作,20/90,什么是好需求,什么样需求是好需求,完整性,清楚性,可行性,一致性,可验证性,21/90,练习,2.1.1Functional Requirements1 功效需求1修改设置smarton password命令,1.Introduction介绍,在设置smarton password同时，要求密码显示形式为明文和密文。,2.Inputs 输入,1)密码显示形式。2)smarton password。,3.Process 处理,1)统计密码显示形式。,2)当密码显示形式为simple时，直接设置smarton password为设置值；当密码显示形式为cipher时，假如设置值是密文，先将其进行解密成明文再设置，假如是明文则直接设置。,4.output输出,无,5.Inherit继承性,Update-需要改进,大家看看下面需求描述怎样？,1.介绍中描述显示形式有明文和密文两种，但处理中描述显示形式却是simple和cipher，不一致；,2.密码允许输入哪些字符，长度有没有限制，均没有交待。不完整,3.输出没有吗？不完整,22/90,练习,2.1.1配置或者取消配置系统WOL功效,1.Introduction介绍,在系统视图下配置或者取消配置WOL使能。,2.Inputs 输入,系统视图下:,wol enable 或 undo wol enable,3.Process 处理,在系统视图下配置或者取消WOL使能。去系统WOL使能时，将WOL模块MAC-ADDR表清空，释放所占内存。初始化MAC地址表相关指针。,4.output输出,WOL功效在系统中被使能或被去使能；去系统使能时，MAC-ADDR表被清空。,5.Inherit继承性,NEW-新增功效,在前面没有介绍情况下，这里应对缩略语进行详细解释，不然不完整,23/90,练习,2.1.1SRS.FUNC.DHG.001 IKE模块支持DH交换时使用Group5，Group14,1.Introduction介绍,支持IKE DH组Group5和Group14是由8040波兰提出新需求，用户希望能提供更高安全级别安全密钥，希望能支持DH 3/4/5，不过DH Group3/4是由椭圆曲线来实现，与Group1/2/5有很大区分，且需要较大工作量，所以此次特征开发暂且实现对Group5/14支持。,完整性：这种术语也应该简单介绍，毕竟不是算数学题,24/90,练习,2.2.18R.FUNC.018支持XRN堆叠,3.Process 处理,当unit down时，处理端口删除消息，把down掉unit端口从镜像组中删除，由此可能有对应镜像组状态改变。,当收到unit up消息时，本unit向其它unit发送端口镜像同时消息。此消息包含本unit所配置镜像组信息。,2.2.1Performance Requirements 性能需求,1.Performance Requirements1 性能需求1,通话语音要求流畅。,“可能”、“流畅”都是不清楚，不一样人了解不一样。,不清楚普通也不可验证。,25,25/90,SRS纲领,介绍,目标,范围,总体概述,软件概述,软件功效,用户特征,假设和依赖关系,需求建模,建模工具,详细需求,功效需求,性能需求,外部接口需求,总体设计约束,标准符合性,硬件约束,技术限制,软件质量属性,可维护性,可靠性,依赖关系,其它需求,需求分级,附录,26/90,介绍,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,目标,范围,描述文档目标,指明文档读者,软件命名,软件要做什么，不做什么,软件应用,关键点：“目标”是针对文档，“范围”针正确是软件功效。,27/90,练习,1Introduction 介绍,1.1Purpose 目标,本文用于描述DHCP增强项目中ARP相关需求需求及设计，满足以下分配需求：,1.在接口上禁止ARP动态学习；,2.允许DHCP server添加授权ARP；,3.ARP PING；,4.配置授权ARP老化时间；,5.假如dhcp server删除租约则应删除对应arp；,6.删除授权ARP表项后删除租约；,本文适合用于相关开发及维护人员，本文档描述了COMWAREV300R002产品软件需求。,1.2Scope 范围,本文包含DHCP增强项目中ARP相关需求需求规格分析及软件设计说明。,本文不包含相关实当代码、用户指导及测试计划。,应在范围中描述,范围不是用来描述本文包含什么、不包含什么,28/90,总体概述,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,假设和依赖关系,总体概述,软件功效,用户特征,软件概述,本节不对需求作详细描述，只是为了使那些需求更易于了解,29/90,总体概述软件概述,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,描述软件与其它产品或项目所组成整体环境,本软件模块1,外部模块3,系统外部模块1,系统外部模块2,外部模块4,本节是概要性描述，最好使用图形描述系统或项目标组件、互联性及外部接口,30,30/90,总体概述软件功效,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,提供软件所实现功效一个概要描述,能够从更高层规格文档直接引用,清楚易懂,显示不一样功效及其相互关系,不描述详细需求,功效3,功效1,功效2,。,31/90,总体概述用户特征,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,描述影响特定需求最终用户普通特征,最终用户：操作人员、维护人员、系统管理人员等,考虑方面：受教育程度、经验、专业技术知识等,32/90,总体概述假设和依赖,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,假设,尚不确定但又必须要情况下，所设定一个参考结果，与已知事实相对。,依赖,对外部条件依赖，二者之间存在明确需求关系。,33/90,练习,1.本项目基于PPPoFR和MPoFR应用，是针对虚模板上QoS应用增强型项目，要求原有PPPoFR模块、QoS模块、MP模块稳定可靠。,2.本项目依赖ACL模块稳定性，包含ACL规则维护、匹配等。,3.本项目依赖VRP提供VOS底层平台，如内存管理、定时器、消息和队列等。,4.本性能优化项目基于前提是，当前系统转发性能瓶颈在转发流程，而非硬件限制。,下面描述是假设还是依赖？,假设,依赖,依赖,假设,34/90,需求建模,需求建模,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,总体概述,DFD样例,在DOS环境下模拟实现ATM柜员机功效,需求分析方法更多培训资料参见,h3crnd01-fs软件部规范小特征开发规范培训需求设计,35,35/90,详细需求,功效需求,详细需求,性能需求,接口需求,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,逐条定义详细需求,包含需求规格全部细节,一条需求必须有一个编号,36/90,详细需求功效需求,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,处理,功效需求,描述每一个需求输入怎样被转换成输出，描述软件必须执行基本动作，同时给出该规格优先级。,输入,输出,37/90,详细需求功效需求,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,功效需求描述,介绍,处理,该功效目标、使用方法和技巧，及相关背景介绍,全部输出数据详细描述,从输入数据和中间参数取得输出全部操作,全部输入数据详细描述,输入,输出,38/90,详细需求功效需求,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,输入数据描述：,输入起源,数量,度量单位,时序,允许输入偏差范围,39/90,详细需求功效需求,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,处理操作：,输入数据正当性检测,操作次序,异常情况响应,操作影响到参数,用于把系统输入转换到对应输出全部方法，诸如方程式，数学算法，逻辑操作,对输出数据正当性检测,溢出,通信失败,错误处理,40,40/90,详细需求功效需求,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,输出数据描述,输出到何处（如打印机、文件等）,数量,度量单位,时序,允许输出偏差范围,对非法值处理,错误消息,41/90,详细需求功效需求,功效需求写作关键点：,每个功效需求分配唯一编号，且给出一有意义标题，便于检索。标题通常是动宾词组，不要使用“功效需求一/二”这么描述。,是描述What to do，而不是How to do；,介绍部分描述“做什么”没有意义，因为后面IPO会详细介绍。应描述有利于了解后续IPO内容：,Why，为何会有此需求,When/Where，什么时候/什么场所使用,How，怎样使用,对IPO描述中将使用到特殊术语解释,与其它功效需求联络等,42/90,详细需求功效需求,功效需求写作关键点(续)：,处理部分能够,采取C语言中关键词如if、else、while等辅助描述，这么在时序、逻辑上更清楚；,IPO缺一不可,有些情况下，输入输出可能不直观，如：定时器超时事件、接口up/down事件等，但并不是没有，不然处理什么。若认为实在没有，那最可能是功效需求分解不合理，所描述功效根本就不成为需求。,不要将命令行作为功效需求描述,单纯命令行不能提供任何功效，只是用户界面而已；,每一命令行之后都承载着一详细功效；,命令行形式我们能够自行定义，但其后功效我们无法自行定义；,用户真正需要是命令行承载功效。命令行形式，甚至是命令行是否必要，这些用户并不会关心。,43/90,练习,2.1.1.取拨号口属性函数,1.Introduction介绍,取以下配置：链路空闲挂断时间：dialer timer idle；呼叫间隔时间：dialer timer enable；链路建立等候时间：dialer timer wait-carrier；竞争等候时间：dialer timer compete；缓冲区报文数：dialer queue-length,2.Inputs 输入,NULL。,3.Process 处理,遍历全部全局DDR控制块链表,是Dialer接口和物理接口,取DDRifnet,取全部拨号口属性,返回链表头指针,4.Output 输出,拨号口属性链表头指针。,1.在描述实现，按照这么IPO描述无法对其进行验证；,2.更应该作为一个接口需求，而不是功效需求；,44/90,详细需求性能需求,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,描述软件或人机交互静态和动态量化需求。,静态量化需求,支持终端数目,支持并发用户数目,需处理文件和统计数目,表和文件大小,动态量化需求,可包含正常和满负荷业务量条件下，某时间段（如一小时）内处理事务和任务数目以及数据量。,45,45/90,详细需求性能需求,举例：,性能需求写作关键点：,每条性能需求必须以可测量术语进行描述，即应给出明确量化指标，包含度量单位；,对于动态性能指标，除性能指标外，还应包含必要前置条件；,前置,条件,交易能很快完成，操作员无须等候。,95%事务应在1秒内被处理。,电梯由静止状态进入正常匀速(2m/s)状态时间限定在22.5s秒内。,46/90,详细需求接口需求,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,接口需求,硬件接口,软件接口,用户接口,通信接口,软件人机交互特征,与系统硬件之间接口,与其它软件产品或应用系统之间接口,消息、回调函数等系统内部通信接口,47/90,详细需求接口需求,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,用户接口示例：系统用户经过一个显示终端进行操作，需要描述：,要求屏幕格式,页面布局以及汇报或菜单内容,输入和输出相关时序,是否支持可编辑功效键,48/90,详细需求接口需求,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,软件接口,描述怎样使用其它软件，针对每个所需软件描述：,名字,助记符,版本号,起源,描述与其它软件接口，针对每个接口描述：,接口目标,经过消息和格式定义接口,49/90,详细需求接口需求,接口需求写作关键点：,用户接口若是命令行，写作需遵照操作手册格式进行；,软件接口小节，应只描述本软件/系统对外提供软件接口，,不包含外部提供给本软件/系统接口,，后者应在依赖中给予描述；,软件接口若为函数，写作能够按照代码中函数头格式进行，这么在后续阶段能很方便地重用。如：,1.R.INTF.SOFT.001 认证接口,/*,*函数名称:ATMLoginInProc,*功效描述:读取输入用户账号名及密码，保留到当前用户信息全局变量中，,*并到账务处理系统进行认证。,*输 入:无,*输 出:无,*返 回 值:VOS_OK：表示登录成功；VOS_ERR：表示登录失败。,*调用关系:略,*其 它:无,*/,50,50/90,总体设计约束,描述由标准、硬件、技术限制等造成对设计限制,标准顺从：描述来自现有标准和规则需求,汇报格式,数据命名,协议,硬件约束：描述支持软件运行硬件条件，如内存限制,技术限制：描述对使用特定技术限制，如数据库、并行操作等,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,51/90,软件质量属性,可维护性,可靠性,安全性,可移植性,易用性,.,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,52/90,软件质量属性,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,可维护性,描述支持软件可维护详细需求,比如：,跟踪调试功效,告警提醒功效,对软件模块之间耦合度进行考虑,53/90,软件质量属性,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,可靠性,容错性,在出现软件故障时候依然能够维持某种层次性能能力。,可恢复性,在出现故障时恢复能力和重新建立某种层次性能能力。,比如：,主备板热备份,通信链路中止重连,54/90,软件质量属性,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,安全性,在此描述预防软件遭到意外或恶意侵入、使用、修改、破坏或泄密原因。,比如：,使用特定加密技术,保留详细日志或历史数据,对不一样模块分配特定功效,限制程序一些区域间进行通信,对主要数据计算校验和,55,55/90,软件质量属性,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,可移植性,描述把软件从一个环境转换到另一个环境时，所需要用户程序、用户接口兼容性限制等需求。,56/90,软件质量属性,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,易用性,易懂性：用户通晓逻辑概念花费人力和软件适用性,易学性：用户学习应用程序花费人力,易操作性：用户操作应用程序所花费人力,57/90,依赖关系,依赖关系,解释每一条需求内部和外部依赖关系,说明：依赖关系也能够在前面详细介绍每一条需求时进行描述,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,58/90,其它需求,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,数据库,操作,当地化需求,其它需求,59/90,附录,附录,I/O 格式示例，成本分析研究描述，用户调查结果,有利于用户阅读SRS支持或背景信息,软件将处理问题描述,被支持组织历史，背景，经验和操作特征,软件需求与项目里程碑交叉参考表，指明哪些软件需求将在哪些里程碑阶段里完成,为了符合安全、出口、安装或其它需求，对代码和介质特殊包装要求,说明：,附录不是必须要求内容,SRS中包含附录时，应明确申明附录是否是需求一部分。,总体概述,详细需求,设计约束,质量属性,介绍,附录,依赖关系,其它需求,60,60/90,需求文档写作关键点,仅关注“What to do”，即系统需提供什么功效。不要描述“How to do”，,那是设计关注事情。,1.功效需求部分不要出现“函数”、“数据结构”、“指针”、buildrun之类表述；,2.站在客户立场上来写需求，而不是站在开发人员立场上。,61/90,需求文档写作关键点,功效需求划分应合理,3.1Functional Requirements 功效需求,3.1.1配置要求经过PPP协商从对端得到协商DNS地址,1.Introduction介绍,在接口视图下经过以下命令来配置要求经过PPP主动协商从对端得到DNS地址：,ppp ipcp dns request,2.Inputs 输入,用户在某一封装了PPP协议接口视图下，输入：ppp ipcp dns request,3.Process 处理,路由器解析此命令输入正确后，将修改PPP协议中协商参数，使路由器在进行PPP协商时候会要求对端分配协商DNS地址。,4.Output 输出,操作成功后，能够经过在当前视图下输入 display this 命令来查看配置是否成功。不然显示犯错提醒。,3.1.2配置取消要求经过PPP协商从对端得到协商DNS地址,1.Introduction介绍,在接口视图下经过以下命令来配置取消要求经过PPP主动协商从对端得到DNS地址：undo ppp ipcp dns request,下一页,62/90,需求文档写作关键点,2.Inputs 输入,用户在某一封装了PPP协议接口视图下，输入：undo ppp ipcp dns request,3.Process 处理,路由器解析此命令输入正确后，将修改PPP协议中协商参数，使路由器在进行PPP协商时候不会要求对端分配协商DNS地址。,4.Output 输出,操作成功后，能够经过在当前视图下输入 display this 命令来查看先前配置是否被取消。不然显示犯错提醒。,3.1.3配置保留协商得到DNS地址，并可经过命令display interface查看,1.Introduction介绍,保留从对端协商得到DNS地址，并可经过查看接口信息display interface命令将得到DNS地址显示出来。,2.Inputs 输入,取出协商得到DNS地址,3.Process 处理,路由器保留协商得到DNS地址，并将其添加到接口信息中,4.Output 输出,操作成功后，协商得到DNS地址保留GotOptions里，并被添加到接口信息中，不然显示犯错提醒，不会显示在接口信息中。,分析：,前两个功效点是在描述一条命令行，而后一功效点描述是另一条相关命令行。,用户需求是什么？是这两条命令行吗？,命令行只是我们提供用户界面，隐藏其后功效需求是什么？,“支持经过PPP协商获取DNS地址”，就这一条。,拆成三条，需求分解不合理，怎样修正？,一条功效需求（支持经过PPP协商获取DNS地址）,display命令修改能够在功效需求输出中提及。,一条接口需求（undo ppp ipcp dns request,）,63/90,需求文档写作关键点,唐僧：唉唉唉！大家不要生气，生气会犯了嗔戒！悟空你也太调皮了，我跟你说过，叫你不要乱扔东西。乱扔东西这么多你看我还没说完呢，你把棍子又给扔掉了！月光宝盒是宝物，你把它扔掉会污染环境。唉，要是砸到儿童呢，怎么办？就算没有砸到儿童，砸到那些花花草草也是不正确呀！,保持语句和段落简短。,64/90,需求文档写作关键点,需求陈说应该含有一致样式。比如“系统必须”或者“用户必须”，并紧跟一个行为动作和,可观察,结果。,举例：,计算过程中出现除零错误时，系统必须马上弹出对话框显示该错误，并进行声音提醒。,举例：,计算过程中出现除零错误时，系统必须给出提醒信息。,65,65/90,需求文档写作关键点,必须防止含糊、主观术语，降低不确定性。,比如：可能、大约、可能、界面友好、轻易、简单、美观、快速、有效、支持、许多、最新技术、优越、可接收和健壮。,.,美女,.,.,!,66/90,需求文档写作关键点,防止使用比较性词汇，比如：提升、最大化、最小化和最正确化。定量地说明所需要提升程度或者说清一些参数可接收最大值和最小值。,提升文件柜高度。,伙计2,伙计3,伙计1,伙计1,67/90,需求文档写作关键点,不应该把多个需求集中在一个冗长叙述段落中。务必记住：不要在需求说明中使用“和/或”，“等等”之类连词。,C&C08交换机应该提供呼叫等候和三方通话等新业务。,C&C08交换机应该提供呼叫等候功效。,C&C08交换机应该提供三方通话功效。,C&C08交换机应该提供呼叫转移功效。,C&C08交换机应该提供闹钟服务功效。,这个“等”包含哪些内容？怎么测试？,测试人员,68/90,需求范例,69,69/90,课程内容,为何要文档化,文档写作基本要求,需求设计文档模板,需求文档写作,设计文档写作,70/90,设计文档纲领(开发项目),零层设计,一层设计,二层设计,配置和,控制,介绍,模块,1,详设,数据库,模块,n,详设,HLD,LLD,上下文定义,设计思绪,分解描述,依赖性描述,接口描述,分解描述,依赖性描述,接口描述,数据描述,函数描述,开发项目：,系统总体设计,子系统设计,系统对外关系,71/90,HLD分解层次普通不超出3层（0层、1层、2层），每层模块数以2到4个为宜，最多不要超出7个。,单元模块函数总数也不超出7个；,HLD阶段将全部函数全部分解出来，LLD阶段不再关注模块分解；,HLD使用,结构图,描述函数调用关系；,函数分解规模以3050行(非空非注释)为宜，最大不超出200行。每个函数复杂度控制在10以内，即：一个函数中不能有太多if，else，for,switchcase等逻辑；,LLD阶段写,伪码,，推荐在source insight中写，完成后嵌入LLD中。伪码粗细程度以适宜作注释为标准；,设计文档写作关键点,72/90,结构图(structure chart),描述了一个系统模块划分，表达了模块之间层次、组织和通信关系,示例：,结构图,73/90,伪码,又叫PDL(Program Design Language)，是一个混合语言，用自然语言（如英语、汉语等）描述程序处理逻辑，用一定关键字语法（如if、else等）定义控制结构和数据结构。,优点：,维护方便,轻易评审,作为代码注释,缺点：,不轻易掌握粗细,轻易写成代码,伪码,伪码=关键字语法+自然语言描述,74/90,伪码,使用C语言语法书写伪代码，使用标准符号，如：if,else,while等；,用描述性语言来描述；,if（接口是以太网接口）,if（InterfaceType=ETHERNET),详略得当。用概括性语句来描述详细处理，要求在每个逻辑处理分支用简练、概括性语言描述处理，而不要局限于处理细节。,封装IP报文头内容;,用收到报文源地址来设置发送报文目标地址;,用发送报文接口地址来设置发送报文源地址;,伪码写作说明：,75,75/90,设计样例,76/90,设计文档纲领(增强、移植项目),移植或增强项目：,修改分类1,修改原因,影响分析,修改描述,修改点1,修改点n,修改分类N,77/90,增强、移植设计,修改分类：,对全部需要修改点进行分类，一个修改分类包含一个或多个修改点，实现一相对独立功效；,每个修改分类都应使用有明确含义标题，如：“关于XXX修改”。,修改分类一,关于将MQC策略应用到ATM PVC接口下修改,修改点：,一个修改点描述一处修改，如一个数据结构修改，一个宏定义修改，一个函数修改等；,修改点也应使用有意义标题，不要使用“修改点1”等。,78/90,增强、移植设计,修改原因：,针对每个修改点，详细阐述为何需要修改，如因为某某处理流程改变，功效扩展，界面改变，性能优化等；,不应该描述修改什么，这是修改描述部分应详细介绍内容；,修改原因中描述应有利于对修改描述了解。,修改,原因,影响分析,修改描述,79/90,增强、移植设计,影响分析：,应评定修改对原模块有没有冲击，从功效、性能、接口等多方面进行评定；,应评定修改对系统资源消耗情况；,应描述为了配合此修改点还需要作哪些修改，即将各修改点关联起来。,还应考虑对测试影响，即怎样充分地验证这些修改。,影响,分析,修改原因,修改描述,80,80/90,增强、移植设计,修改描述：,使用适当,标注方式,描述修改，修改前后对比要显著；,修改,描述,影响分析,修改原因,新增代码：用红色表示,修改代码：用蓝色表示,删除代码：用删除线表示,continue,81/90,增强、移植设计,修改描述:(续),对原代码修改一定要将修改详细位置表达出来,将,适当代码,加在,适当位置,；,新增函数应采取伪码描述，与原有函数调用关系应该用函数调用关系图方式表示出来，便于了解；,对于修改函数，若改动量很小或很分散，能够直接用代码描述；对于大段集中修改，提议还是采取伪码描述。,修改,描述,影响分析,修改原因,82/90,练习,2.修改点struct crypto_xf transforms,1）修改原因,crypto_xf transforms结构增加AES；,2）影响分析,无,3）修改描述,struct crypto_xf transforms=,AES_CBC,AES(CBC-Mode),16,32,2*BLOCKSIZE,NULL,IKE_AesInit,IKE_AesEncrypt,IKE_AesDecrypt,修改原因还是在描述怎样修改，为何修改却没有阐述。,影响分析“无”，是无影响，还是没有分析？,修改描述中没有表达出修改在原代码中详细位置。,83/90,练习,2.修改点2 数据结构修改：ETHARP_ARPRTENTRY_S,1）修改原因,需要在ARP表项节点纪录授权表项标志位。,2）影响分析,修改原有数据结构，对其它模块无影响。,3）修改描述,typedef struct tagARPRTENTRY,。,#if(VRP_MODULE_LINK_ARP_AUTHORIZED=VRP_YES),ULONG ulArpAuthTag;/*授权表项标志位,*0 x1-授权ARP;,*0 x0-其它;,*/,#endif,ETHARP_ARPRTENTRY_S;,修改原因还是在描述怎样修改，没有介绍增加该标志是为了什么。,影响分析“对其它模块无影响”，结构体变大，有没有评定对系统内存资源消耗？,84/90,增强、移植设计范例,85,85/90,思索,对于开发项目，在详细设计阶段，我们提倡在C文件中写伪码，这么较之在word文档中写伪码好处有：,1.可读性更加好。伪码在形式上很靠近于代码，而大家更习惯在source insight中阅读代码；,2.利于评审，原因同上；,3.编码阶段可直接重用。,对于增强、移植项目，当前大家都是在word文档中写设计，是因为word文档中能够使用特殊标注，这么能将修改前后对比表达出来。,移植设计能否也在C文件中写呢？,请大家思索这个问题，假如有好想法，能够提出来讨论。,86/90,内容回顾,为何要文档化,文档写作基本要求,需求设计文档模板,需求文档写作,设计文档写作,87/90,答疑,Any question?,88/90,89/90,90/90,