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