需求与设计写作培训PPT格式课件下载.ppt

需求与设计写作培训PPT格式课件下载.ppt

《需求与设计写作培训PPT格式课件下载.ppt》由会员分享，可在线阅读，更多相关《需求与设计写作培训PPT格式课件下载.ppt（90页珍藏版）》请在冰豆网上搜索。

不要出现“我们”、“你们”、“他们”这样的称谓，或“这个”、“那个”这样的词，应使用“本”、“该”、“其”；

表述清晰，避免引起歧义；

通篇文档细节上要保持一致；

练习,房子南北走向，房子大门在东侧中间位置。

门厅长约3米，宽2米，门厅左面是主卧室，右面是厨房。

厨房3米宽，4米长，厨房门对着门厅，厨房的顶头还有一个北阳台，与厨房同宽，长1米。

主卧室宽3米，长5米左右，房间门对着客厅。

客厅与餐厅连为一体，共7米长，4米宽，与客厅相连有一南阳台，与客厅同宽，长1.5米。

餐厅的北面是卫生间，卫生间与厨房相对，中间由1米宽，3米长的过道隔开；

卫生间门对着过道，南墙与厨房的南墙在一条直线上；

卫生间为长方形，南墙长3米，另一边长2米。

卫生间的北面是次卧，同宽，门朝着过道，次卧长4米。

过道的北端是书房门，书房南北长4米，书房有一个一米见方的门厅，书房的西墙长4米，包括1米长的门厅长度，西墙把书房和次卧分隔开。

门厅东墙北端90角折向东，长2米，把书房和厨房北阳台分隔开。

大家认为下面的描述如何？

10,练习,1.房子南北走向，房子大门在东侧中间位置。

2.门厅长3米，宽2米，门厅左面是主卧室，右面是厨房。

3.厨房3米宽，4米长，厨房门对着门厅，厨房的顶头还有一个北阳台，与厨房同宽，长1米。

4.主卧室宽3米，长5米左右，房间门对着客厅。

5.客厅与餐厅连为一体，共7米长，4米宽，与客厅相连有一南阳台，与客厅同宽，长1.5米。

6.餐厅的北面是卫生间，卫生间与厨房相对，中间由1米宽，3米长的过道隔开；

7.卫生间的北面是次卧，同宽，门朝着过道，次卧长4米。

8.过道的北端是书房门，书房南北长4米，书房有一个一米见方的门厅，书房的西墙长4米，包括1米长的门厅长度，西墙把书房和次卧分隔开。

修改成如下描述之后呢？

练习,主卧室,次卧室,厨房,餐厅,客厅,阳台,阳台,卫生间,书房,门厅,过道,北,西,再改成如下图形描述呢？

练习,LSW与CAMS配合实现认证计费的方案中，客户（禁止多人同时使用的业务帐号）登陆通过认证开始计费后，如果出现LSW重起的情况，处理方法分为两种：

1.有时间芯片的LSW（可以记录时间的），设备重起后会使用设备时间戳的特性判断出设备重起了，这时会将CAMS上的在线用户删除并按照最后一次计费更新报文来终结计费。

用户可再次正常登陆。

2.,下面的描述呢？

白话,练习,由于一台设备可以设置多个radius服务器，也就是radiusscheme。

用户可以通过命令行来配置该radius服务器是否启动设备重启防吊死功能。

由于一台设备可以设置多个radius服务器，即radiusscheme。

练习,CAMS收到该报文后会立即回应一个code=5的计费回应报文，然后根据accounting-on报文携带的NAS-IP和NAS-ID找到通过该设备认证的用户，并将他们的在线信息删除。

CAMS收到该报文后会立即回应一个code=5的计费回应报文，然后根据accounting-on报文携带的NAS-IP和NAS-ID找到通过该设备认证的用户，并将其在线信息删除。

15,练习,修改原因：

这个函数是将要发送的packet转化为buffer，系统原有函数RD_PutPacketToBuffer是针对认证用户设计的，由于本特性为设备启动后执行，没有用户信息，所以在RD_PutPacketToBuffer函数基础上做了一些修改，形成该函数。

修改原因：

该函数实现将待发送的packet转化为buffer的功能，系统原有函数RD_PutPacketToBuffer针对认证用户设计，由于本特性为设备启动后执行，没有用户信息，所以在RD_PutPacketToBuffer函数基础上做了一些修改，形成该函数。

练习,ARPAuthorized加强了网络安全，阻止了DHCPserver对非法ARP回应进行学习，并且通过周期的ARPping可以快速的探测到用户是否下线。

在设备的接口上使能ARPAuthorized，该接口的ARP动态学习功能被禁止。

在某个接口上禁止arp动态学习，不影响其他接口的arp学习。

在禁止了arp动态学习的接口上，只能通过手工添加静态arp，或者其他一些被允许的模块才可以添加arp，这种arp被称为ARPAuthorized，授权arp不再和其他的动态表项一样老化，而是有自己的老化机制，后面会说明。

DHCPserver就是这样的一个模块。

静态arp的优先级高于授权arp，也就是说可以覆盖授权arp。

1.ARP与arp、ARPAuthorized与授权arp，使用术语应该统一；

2.ARPAuthorized应先解释后引用；

3.“DHCPserver就是这样的一个模块”，是否相关？

课程内容,为什么要文档化文档写作基本要求需求设计文档模板需求文档写作设计文档写作,需求设计文档模板,19,课程内容,为什么要文档化文档写作基本要求需求设计文档模板需求文档写作设计文档写作,什么是好的需求,练习,2.1.1FunctionalRequirements1功能需求1修改设置smartonpassword命令1.Introduction介绍在设置smartonpassword的同时，规定密码显示形式为明文和密文。

2.Inputs输入1）密码显示形式。

2）smartonpassword。

3.Process处理1）记录密码显示形式。

2）当密码显示形式为simple时，直接设置smartonpassword为设置值；

当密码显示形式为cipher时，如果设置值是密文，先将其进行解密成明文再设置，如果是明文则直接设置。

4.output输出无5.Inherit继承性Update-需要改进,大家看看下面的需求描述如何？

1.介绍中描述的显示形式有明文和密文两种，但处理中描述的显示形式却是simple和cipher，不一致；

2.密码允许输入哪些字符，长度有无限制，均没有交待。

不完整3.输出没有吗？

不完整,练习,2.1.1配置或者取消配置系统WOL功能1.Introduction介绍在系统视图下配置或者取消配置WOL使能。

2.Inputs输入系统视图下:

wolenable或undowolenable3.Process处理在系统视图下配置或者取消WOL使能。

去系统WOL使能时，将WOL模块的MAC-ADDR表清空，释放所占内存。

初始化MAC地址表相关指针。

4.output输出WOL功能在系统中被使能或被去使能；

去系统使能时，MAC-ADDR表被清空。

5.Inherit继承性NEW-新增功能,练习,2.1.1SRS.FUNC.DHG.001IKE模块支持DH交换时使用Group5，Group141.Introduction介绍支持IKEDH组的Group5和Group14是由8040波兰提出的新需求，用户希望能提供更高安全级别的安全密钥，希望能支持DH3/4/5，但是DHGroup3/4是由椭圆曲线来实现的，与Group1/2/5有很大的区别，且需要较大的工作量，因此本次特性开发暂且实现对Group5/14的支持。

完整性：

这种术语也应该简单介绍，毕竟不是算数学题,练习,2.2.18R.FUNC.018支持XRN堆叠3.Process处理当unitdown时，处理端口删除消息，把down掉的unit端口从镜像组中删除，由此可能有相应的镜像组状态的改变。

当收到unitup消息时，本unit向其它unit发送端口镜像同步消息。

此消息包含本unit所配置的镜像组信息。

2.2.1PerformanceRequirements性能需求1.PerformanceRequirements1性能需求1通话语音要求流畅。

“可能”、“流畅”都是不清晰的，不同人理解不一样。

不清晰一般也不可验证。

25,SRS大纲,简介目的范围总体概述软件概述软件功能用户特征假设和依赖关系需求建模建模工具具体需求功能需求性能需求外部接口需求,总体设计约束标准符合性硬件约束技术限制软件质量属性可维护性可靠性依赖关系其他需求需求分级附录,简介,要点：

“目的”是针对文档，“范围”针对的是软件功能。

练习,1Introduction简介1.1Purpose目的本文用于描述DHCP增强项目中ARP相关需求的需求及设计，满足以下分配需求：

1.在接口上禁止ARP动态学习；

2.允许DHCPserver添加授权ARP；

3.ARPPING；

4.配置授权ARP老化时间；

5.如果dhcpserver删除租约则应删除相应的arp；

6.删除授权ARP表项后删除租约；

本文适用于相关开发及维护人员，本文档描述了COMWAREV300R002产品的软件需求。

1.2Scope范围本文包括DHCP增强项目中ARP相关需求的需求规格分析及软件设计说明。

本文不包括相关实现代码、用户指导及测试计划。

应在范围中描述,范围不是用来描述本文包括什么、不包括什么,总体概述,总体概述软件概述,描述软件与其它产品或项目所组成的整体环境,本节是概要性描述，最好使用图形描述系统或项目的组件、互联性及外部接口,30,总体概述软件功能,提供软件所实现功能的一个概要描述可以从更高层规格文档直接引用清楚易懂显示不同功能及其相互关系不描述具体需求,总体概述用户特征,描述影响特定需求的最终用户的一般特征,总体概述假设和依赖,假设尚不确定但又必须要的情况下，所设定的一个参考结果，与已知事实相对。

依赖对外部条件的依赖，两者之间存在明确的需求关系。

练习,1.本项目基于PPPoFR和MPoFR应用，是针对虚模板上的QoS应用的增强型项目，要求原有的PPPoFR模块、QoS模块、MP模块稳定可靠。

2.本项目依赖ACL模块的稳定性，包括ACL规则的维护、匹配等。

3.本项目依赖VRP提供的VOS底层平台，如内存管理、定时器、消息和队列等。

4.本性能优化项目基于的前提是，目前系统转发性能的瓶颈在转发流程，而非硬件限制。

下面的描述是假设还是依赖？

假设,依赖,依赖,假设,需求建模,DFD样例在DOS环境下模拟实现ATM柜员机的功能,需求分析方法更多的培训资料参见h3crnd01-fs软件部规范小特性开发规范培训需求设计,35,具体需求,具体需求功能需求,功能需求描述每一个需求的输入怎样被转换成输出，描述软件必须执行的基本动作，同时给出该规格的优先级。

具体需求功能需求,具体需求功能需求,输入数据的描述：

输入来源数量度量单位时序允许的输入偏差范围,具体需求功能需求,处理操作：

输入数据合法性检测操作次序异常情况的响应操作影响到的参数用于把系统输入转换到相应输出的所有方法，诸如方程式，数学算法，逻辑操作对输出数据的合法性检测,40,具体需求功能需求,输出数据的描述输出到何处（如打印机、文件等）数量度量单位时序允许的输出偏差范围对非法值的处理错误消息,具体需求功能需求,功能需求写作要点：

每个功能需求分配唯一编号，且给出一有意义的标题，便于检索。

标题通常是动宾词组，不要使用“功能需求一/二”这样的描述。

是描述Whattodo，而不是Howtodo；

介绍部分描述“做什么”没有意义，因为后面IPO会详细介绍。

应描述有利于理解后续IPO的内容：

Why，为什么会有此需求When/Where，什么时候/什么场合使用How，如何使用对IPO描述中将使用到的特殊术语的解释与其它功能需求的联系等,具体需求功能需求,功能需求写作要点（续）：

处理部分可以采用C语言中关键词如if、else、while等辅助描述，这样在时序、逻辑上更清晰；

IPO缺一不可有些情况下，输入输出可能不直观，如：

定时器超时事件、接口up/down事件等，但并不是没有，否则处理什么。

若认为实在没有，那最可能是功能需求分解不合理，所描述的功能根本就不成为需求。

不要将命令行作为功能需求描述单纯的命令行不能提供任何功能，只是用户界面而已；

每一命令行之后都承载着一具体功能；

命令行的形式我们可以自行定义，但其后的功能我们无法自行定义；

用户真正需要的是命令行承载的功能。

命令行形式，甚至是命令行是否必要，这些用户并不会关心。

练习,2.1.1.取拨号口属性函数1.Introduction介绍取以下配置：

链路空闲挂断时间：

dialertimeridle；

呼叫间隔时间：

dialertimerenable；

链路建立等待时间：

dialertimerwait-carrier；

竞争等待时间：

dialertimercompete；

缓冲区报文数：

dialerqueue-length2.Inputs输入NULL。

3.Process处理遍历所有的全局DDR控制块链表是Dialer接口和物理接口取DDR的ifnet取所有的拨号口属性返回链表头指针4.Output输出拨号口属性链表头指针。

1.在描述实现，按照这样的IPO描述无法对其进行验证；

2.更应该作为一个接口需求，而不是功能需求；

具体需求性能需求,描述软件或人机交互的静态和动态量化需求。

45,具体需求性能需求,举例：

性能需求写作要点：

每条性能需求必须以可测量的术语进行描述，即应给出明确的量化指标，包括度量单位；

对于动态性能指标，除性能指标外，还应包含必要的的前置条件；

交易能很快完成，操作员不必等待。

95%的事务应在1秒内被处理。

电梯由静止状态进入正常匀速（2m/s）状态时间限定在22.5s秒内。

具体需求接口需求,具体需求接口需求,用户接口示例：

系统用户通过一个显示终端进行操作，需要描述：

要求的屏幕格式页面布局以及报告或菜单的内容输入和输出的相关时序是否支持可编辑功能键,具体需求接口需求,软件接口描述如何使用其他软件，针对每个所需软件描述：

名字助记符版本号来源描述与其他软件的接口，针对每个接口描述：

接口的目的通过消息和格式定义接口,具体需求接口需求,接口需求写作要点：

用户接口若是命令行，写作需遵照操作手册的格式进行；

软件接口小节，应只描述本软件/系统对外提供的软件接口，不包括外部提供给本软件/系统的接口，后者应在依赖中予以描述；

软件接口若为函数，写作可以按照代码中函数头的格式进行，这样在后续阶段能很方便地重用。

如：

1.R.INTF.SOFT.001认证接口/*函数名称:

ATMLoginInProc*功能描述:

读取输入的用户的账号名及密码，保存到当前用户信息全局变量中，*并到账务处理系统进行认证。

*输入:

无*输出:

无*返回值:

VOS_OK：

表示登录成功；

VOS_ERR：

表示登录失败。

*调用关系:

略*其它:

无*/,50,总体设计约束,描述由标准、硬件、技术限制等造成的对设计的限制标准顺从：

描述来自现有标准和规则的需求报告格式数据命名协议硬件约束：

描述支持软件运行的硬件条件，如内存限制技术限制：

描述对使用的特定技术的限制，如数据库、并行操作等,软件质量属性,可维护性可靠性安全性可移植性易用性.,软件质量属性,可维护性描述支持软件可维护的具体需求例如：

跟踪调试功能告警提示功能对软件模块之间的耦合度进行考虑,软件质量属性,可靠性容错性在出现软件故障的时候仍然能够维持某种层次性能的能力。

可恢复性在出现故障时的恢复能力和重新建立某种层次性能的能力。

例如：

主备板热备份通信链路中断重连,软件质量属性,安全性在此描述防止软件遭到意外或恶意的侵入、使用、修改、破坏或泄密的因素。

使用特定的加密技术保存详细的日志或历史数据对不同模块分配特定的功能限制程序某些区域间进行通信对重要的数据计算校验和,55,软件质量属性,可移植性描述把软件从一个环境转换到另一个环境时，所需要的用户程序、用户接口兼容性限制等需求。

软件质量属性,易用性易懂性：

用户通晓逻辑概念花费的人力和软件的适用性易学性：

用户学习应用程序花费的人力易操作性：

用户操作应用程序所花费的人力,依赖关系,依赖关系解释每一条需求的内部和外部依赖关系说明：

依赖关系也可以在前面具体介绍每一条需求时进行描述,其它需求,附录,附录I/O格式的示例，成本分析研究的描述，用户调查的结果有助于用户阅读SRS的支持或背景信息软件将解决的问题的描述被支持组织的历史，背景，经验和操作特征软件需求与项目里程碑的交叉参考表，指明哪些软件需求将在哪些里程碑阶段里完成为了符合安全、出口、安装或其它需求，对代码和介质的特殊包装要求说明：

附录不是必须要求的内容SRS中包含附录时，应明确声明附录是否是需求的一部分。

60,需求文档写作要点,仅关注“Whattodo”，即系统需提供什么功能。

不要描述“Howtodo”，那是设计关注的事情。

1.功能需求部分不要出现“函数”、“数据结构”、“指针”、buildrun之类的表述；

2.站在客户的立场上来写需求，而不是站在开发人员的立场上。

需求文档写作要点,功能需求划分应合理,3.1FunctionalRequirements功能需求3.1.1配置要求通过PPP协商从对端得到协商的DNS地址1.Introduction介绍在接口视图下通过以下命令来配置要求通过PPP主动协商从对端得到DNS地址：

pppipcpdnsrequest2.Inputs输入用户在某一封装了PPP协议的接口视图下，输入：

pppipcpdnsrequest3.Process处理路由器解析此命令输入正确后，将修改PPP协议中的协商参数，使的路由器在进行PPP协商的时候会要求对端分配协商的DNS地址。

4.Output输出操作成功后，可以通过在当前视图下输入displaythis命令来查看配置是否成功。

否则显示出错提示。

3.1.2配置取消要求通过PPP协商从对端得到协商的DNS地址1.Introduction介绍在接口视图下通过以下命令来配置取消要求通过PPP主动协商从对端得到DNS地址：

undopppipcpdnsrequest,下一页,需求文档写作要点,2.Inputs输入用户在某一封装了PPP协议的接口视图下，输入：

undopppipcpdnsrequest3.Process处理路由器解析此命令输入正确后，将修改PPP协议中的协商参数，使的路由器在进行PPP协商的时候不会要求对端分配协商的DNS地址。

4.Output输出操作成功后，可以通过在当前视图下输入displaythis命令来查看先前配置是否被取消。

3.1.3配置保存协商得到的DNS地址，并可通过命令displayinterface查看1.Introduction介绍保存从对端协商得到的DNS地址，并可通过查看接口信息的displayinterface命令将得到的DNS地址显示出来。

2.Inputs输入取出协商得到的DNS地址3.Process处理路由器保存协商得到的DNS地址，并将其添加到接口信息中4.Output输出操作成功后，协商得到的DNS地址保存GotOptions里，并被添加到接口信息中，否则显示出错提示，不会显示在接口信息中。

分析：

前两个功能点是在描述一条命令行，而后一功能点描述的是另一条相关的命令行。

用户的需求是什么？

是这两条命令行吗？

命令行只是我们提供的用户界面，隐藏其后的功能需求是什么？

“支持通过PPP协商获取DNS地址”，就这一条。

拆成三条，需求分解不合理，如何修正？

一条功能需求（支持通过PPP协商获取DNS地址）display命令的修改可以在功能需求的输出中提及。

一条接口需求（undopppipcpdnsrequest）,需求文档写作要点,保持语句和段落的简短。

需求文档写作要点,需求陈述应该具有一致的样式。

例如“系统必须”或者“用户必须”，并紧跟一个行为动作和可观察的结果。

65,需求文档写作要点,必须避免模糊的、主观的术语，减少不确定性。

也许、大概、可能、界面友好、容易、简单、美观、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的。

!

需求文档写作要点,避免使用比较性的词汇，例如：

提高、最大化、最小化和最佳化。

定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。

伙计2,伙计3,需求文档写作要点,不应该把多个需求集中在一个冗长的叙述段落中。

务必记住：

不要在需求说明中使用“和/或”，“等等”之类的连词。

需求范例,69,课程内容,为什么要文档化文档写作基本要求需求设计文档模板需求文档写作设计文档写作,设计文档大纲（开发项目）,HLD,LLD,开发项目：

系统总体设计,子系统设计,系统对外关系,HLD分解层次一般不超过3层（0层、1层、2层），每层的模块数以2到4个为宜，最多不要超过7个。

单元模块函数总数也不超过7个；

HLD阶段将所有函数全部分解出来，LLD阶段不再关注模块分解；

HLD使用结构图描述函数的调用关系；

函数分解规模以3050行（非空非注释）为宜，最大不超过200行。

每个函数的复杂度控制在10以内，即：

一个函数中不能有太多的if，else，for,switchcase等逻辑；

LLD阶段写伪码，推荐在sourceinsight中写，完成后嵌入LLD中。

伪码的粗细程度以适宜作注释为标准；

设计文档写作要点,结构图（structurechart）描述了一个系统的模块划分，体现了模块之间的层次、组织和通信关系示例：

结构图,伪码又叫PDL（ProgramDesignLanguage），是一种混合语言，用自然语言（如英语、汉语等）描述程序的处理逻辑，用一定的关键字语法（如if、else等）定义控制结构和数据结构。

优点：

维护方便容易评审作为代码注释缺点：

不容易掌握粗细容易写成代码,伪码,伪码=关键字语法+自然语言描述,伪码,使用C语言的语法书写伪代码，使用标准符号，如：

if,