精华内容
下载资源
问答
  • Misra-C编码规范全解读 - Dir 3 需求追溯
    千次阅读
    2020-09-26 22:03:02

    Dir 3 需求的可追溯性

    ->返回总目录<-

    Dir3.1 所有的代码都应该可追溯到需求文档

    必要性适用范围参考
    必选项 C90 C99

    3.1.1 概述

    说直白一点就是我们定了代码需求的文档,就要按需求进行开发,如果有代码不在需求文档中,那么要么改代码,要么改需求文档

    < 举个例子 >
    某公司领导飞星定了某个基于AutoSAR闪烁一颗LED灯的开发需求之后,就把码代码的工作交给程序员雪云了。雪云认认真真的写完了代码之后,为了验证一下另外一个功能,就配置了其他某个需求中没有的pin脚,利用该pin脚输出了一路多余的pwm波。那么这个pwm在需求中没有的话,按我们d3.1的要求,就不能出现在代码中,因为这样有可能造成其他使用者在不知情的情况下出问题。比如这版代码所有测试都通过了,代码也已经发布了。客户某天不小心接错线什么的,说不定这个多余的pwm波就会引起短路之类的危险情况发生,雪云的饭碗就不保了

    所以在代码开发完成后,是需要根据需求文档重审代码的,而需求文档本身又是需要项目组自己做审核的,以保证代码与实际需求的吻合

    附:返回总目录的传送门如下
    ->返回总目录<-

    更多相关内容
  • 需求工程规格说明、需求验证需求管理

    千次阅读 多人点赞 2020-04-24 18:52:14
    需求工程系列: 软件需求工程习题1(1~4章) 软件需求工程习题2(5~7章) 需求工程中的面谈和原型(8、9章) 需求获取方法之观察与文档审查(10章) 第十一章 需求规格说明 需求获取:目标是得到用户需求——收集...

    需求工程系列:

    软件需求工程习题1(1~4章)
    软件需求工程习题2(5~7章)
    需求工程中的面谈和原型(8、9章)
    需求获取方法之观察与文档审查(10章)
    需求工程规格说明、需求验证、需求管理(11~13章)


    第十一章 需求规格说明

    需求获取:目标是得到用户需求——收集需求信息
    需求分析:目标是更深刻的理解用户需求——界定能够让用户满意的解决方案准则
    需求规格说明:目标是定义用户需求——准确描述需求及其解决方案

    需求规格说明文档类型:
    在这里插入图片描述
    需求规格说明文档的描述手段:
    非形式化:自然语言、限制性文本
    半形式化:结构化文本(伪码/结构化英语)、模型语言(图、表…)
    形式化:形式化语言(数学语言:BNF,Z…)

    优秀需求规格说明文档的特性:
    完备性、一致性、根据重要性和稳定性分级、可修改、可跟踪

    习题:

    1.系统需求开发的结果最终会写入( 系统需求规格说明)。
    2.项目的前景和范围文档、用户需求文档都被视为属于( 用户文档),重点都是用户的现实世界。
    3.系统需求规格说明文档、软件需求规格说明文档、硬件需求规格说明文档、接口需求规格说明文档和人机交互文档一起被用于系统开发的目的,都被认为是(开发文档)。
    4.下列( C)不是需求规格说明文档的读者。
    A、项目管理者
    B、编程人员
    C、销售商
    D、律师
    5.编写需求规格说明文档的意义(ABCD
    A、需求规格说明文档可以成为各方人员之间有关软件系统的协议基准。
    B、需求规格说明文档可以成为项目开发活动的一个重要依据。
    C、在需求规格说明文档的编写过程 中,可以尽早的发现和减少可能的需求错误,从而减少项目的返工,降低项目的工作量。
    D、需求规格说明文档可以成为有效的智力资产。
    6.编写需求规格说明文档所使用的语言类型有(非形式化语言、半形式化语言、形式化语言)。
    7.【判断题】软件需求规格说明文档是对部分系统功能分配给软件部分的详细描述。(×
    8.【判断题】人机交互文档是对整个系统功能中需要进行人机交互部分的详细描述。(
    9.【判断题】需求规格文档化的目标是交流。(


    第十二章 需求验证

    验证(Validation)与确认(Verification)
    一方面,它要确保正确地得到需求(需求验证)得到足以作为软件创建基础的需求;
    另一方面,它要确保得到正确的需求(需求确认),得到能够准确反映用户意图的需求。

    需求验证活动的四个步骤:
    需求验证普遍存在于需求开发活动中
    1、在需求获取中:获得的用户需求是否正确和充分的支持业务需求?
    2、在需求分析中:建立的分析模型是否正确的反映了问题域特性和需求?细化的系统需求是否充分和正确的支持用户需求?
    3、需求规格说明:需求规格说明文档是否组织良好、书写正确?需求规格说明文档内的需求是否充分和正确的反映了涉众的意图?需求规格说明文档是否可以作为后续开发工作(设计、实现、测试等等)的基础?
    4、需求验证:是指在需求规格说明完成之后,对需求规格说明文档进行的验证活动。

    需求验证常见的方法;
    需求评审、原型与模拟、开发测试用例、用户手册编制、利用跟踪关系和自动化分析。

    评审过程的6个阶段:
    1.规划阶段
    2.总体部署阶段
    3.准备阶段
    4.评审会议阶段
    5.返工阶段
    6.跟踪阶段

    评审的类型:
    审查(最为严格)、小组评审(轻型审查)、走查、轮查、临时评审(最不正式)

    习题:

    1.在大多数情况下,需求都是在静态的方式下被加以验证。那么对复杂的动态行为就需要使用模拟或原型方法来加以验证。
    2.评审的检查方法有自由方法、检查清单、缺陷、功能点、视角、场景和逐步提升。
    3.【判断题】 需求验证活动同样普遍存在于需求分析过程中。( ×
    4.【判断题】需求验证是需求工程中最后一个活动。( ×
    5.需求验证并不是一个可以一次结束的活动,它可能需要多次、反复地执行验证。(
    6.在大多数情况下,需求都是在静态的方式下被加以验证。那么对复杂的动态行为就需要使用原型或模拟方法来加以验证。 ( )
    7.审查类型中最正式评审类型是轮查。(×
    8.验证是贯穿于整个软件生命周期的。(
    9.基于场景方法也是需求评审当中常用的一种检查方法。(
    10.需求验证和需求确认一样,都能确保得到正确的需求。( ×


    第十三章 需求管理

    在需求开发活动之后,需求基线应该成为后续软件系统开发的工作基础和黏合剂:

    • 项目管理者根据需求安排、监控和管理项目计划;
    • 开发者依据需求开发相应的产品功能和特性;
    • 测试人员按照需求执行系统测试和验收测试;
    • 客户和顾客依照需求验收最终产品;
    • 维护人员参考需求执行产品的演化。

    也就是说,需求的影响力贯穿于整个后续的产品生命周期,而不是单纯地存在于需求开发阶段。软件需求规格说明文档要在产品生命周期的各个阶段都扮演重要角色,发挥重要作用。软件需求说明文档的内容是开发各阶段的标准和目标来进行。

    需求管理的3个活动:
    维护需求基线、实现需求跟踪和控制变更。

    需求基线的内容:
    软件需求是需求基线的关键内容,还包括很多和软件需求相关的描述信息,它们将为软件需求在项目中的作用的有效发挥提供信息支持。

    需求基线的维护:
    1.配置管理
    2.状态维护

    需求跟踪:
    以软件需求规格说明文档为基线,在向前和向后两个方向上,描述需求以及跟踪需求变化的能力。
    1.前向跟踪
    前向跟踪是指需求被定义到软件需求规格说明文档之前的演化过程
    (1)向前跟踪到需求:说明涉众的需要和目标产生了哪些软件需求
    (2)从需求向后回溯:说明软件需求来源于哪些涉众的需要和目标
    在这里插入图片描述

    2.后向跟踪
    后向跟踪是指需求被定义到软件需求规格说明文档之后的演化过程
    (1)从需求向前跟踪:说明软件需求是如何被后续的开发物件支持和实现的
    (2)回溯到需求的跟踪:说明各种系统开发的物件是因为什么原因(软件需求)而被开发出来的
    在这里插入图片描述
    需求跟踪的实现方法:
    主要有矩阵、实体关系模型和交叉引用3种。

    习题:

    1.需求工程是所有需求处理活动的总和,它包括需求开发和需求管理两个部分。
    2需求基线的维护主要包括配置管理和状态维护
    3.从需求向后回溯(前向跟踪的两种联系之一)说明软件需求来源于哪些涉众的需要和目标
    4.后向跟踪是指 需求被定义到软件需求规格说明文档之后的演化过程。
    5.【判断题】前向跟踪是指需求在被 获取 到软件需求规格说明文档之前的演化过程。(×
    6.【判断题】后向跟踪包括两种联系:从需求向前跟踪和 回溯到需求的跟踪 。(
    7.【判断题】需求基线其实不是被明确和固定的需求集合,是项目团队需要在某一特定产品版本中实现的特征和需求集合。(×
    8.【判断题】需求跟踪是一种有效的控制手段,能够在涉众的需求变化中协调系统的演化,保持各项开发工作对需求的一致性。(
    9.【判断题】需求跟踪是以前景与范围文档为基线,在向前和向后两个方向上,描述需求以及跟踪需求变化的能力,分为前向跟踪和后向跟踪两种。(×应该是以软件需求规格说明文档为基线

    展开全文
  • 验证软件需求

    千次阅读 2019-09-04 17:35:11
    3.8 验证软件需求 3.8.1 从哪些方面验软件需求的正确 需求分析阶段的工作结果是开发件系统的重要基础,大量统计数字表明,软件系统中15%的错误...(1)一致 所有需求必须是一致的,任何一条需求不能和其他需求互相...

    3.8 验证软件需求

    3.8.1 从哪些方面验软件需求的正确性

        需求分析阶段的工作结果是开发件系统的重要基础,大量统计数字表明,软件系统中15%的错误起源于错误的需求,为了高软件质量,确保软件开发成功,降低较件开发成本,一旦对目标系统提出一组要求之后,必须严格验证这些需求的正确性,一般说来,应该从下述4个方面进行验证

    (1)一致性 所有需求必须是一致的,任何一条需求不能和其他需求互相矛。
    (2)完整性 需求必须是完整的,规格说明书应该包括用户需要的每一个功能或性能
    (3)现实性 指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测,对就件技术的进步则很难做出预测,只能从现有技术水平出发判断需求的现实性。
    (4)有效性 必须证明需求是正确有数的,确实能解决用户面对的问题

    3.8.2 验证软件需求的方法

    上一小节已经指出,至少必须从一致性、完整性、现实性和有效性这4个不同角度验证软件需求的正确性,那么,怎样验证软件需求的正确性呢?验证的角度不同,验证的方法也不同。

    1.验证需求的一致性
        
        当需求分析的结果是用自然语言书写的时候,除了靠人工技术审查验证软件系统规格说明书的正确性之外,目前还没有其他更好的“测试”方法。但是,这种非形式化的规格说明书是难于验证的,特别在目标系统规模度大、规格说明书篇幅很长的时候,人工审查的效果是没有保证的,冗余、遗楼和不一致等问题可能没被发现而继续保留下来,以致软件开发工作不能在正确的基础上顺利进行。
        为了克服上述困难,人们提出了形式化的描述软件需求的方法。当软件需求规格说明书是用形式化的需求陈述语言书写的时候,可以用软件工具验证需求的一致性(见需求分析的软件工具),从而能有效地保证软件需求的一致性。

    2,验证需求的现实性

        为了验证需求的现实性,分析员应该参照以往开发类似系统的经验,分析用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术,辅助分析件需求规格说明书的现实性。

    3,验证需求的完整性和有效性

        只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。因此,检验需求的完整性,特别是证明系统确实满足用户的实际需要(即,需求的有效性),只有在用户的密切合作下才能完成。然而许多用户并不能清楚地认识到他们的需要(特别在要开发的系统是全新的,以前没有使用类似系统的经验时,情况更是如此)不能有效地比较陈述需求的语句和实际需要的功能。只有当他们有某种工作着的软件系统可以实际使用和评价时,才能完整确切地提出他们的需要。
        理想的做法是先根据需求分析的结果开发出一个软件系统,请用户试用一段时间以使能认识到他们的实际需要是什么,在此基础上再写出正式的“正确的”规格说明书。但是,这种做法将使软件成本增加一倍,因此实际上几乎不可能采用这种方法。使用原型系是一个比较现实的替代方法,开发原型系统所需要的成本和时间可以大大少于开发实际系统所需要的,用户通过试用原型系统,也能供得许多宝贵的经验,从面可以提出更符合实际的要求。
        使用原型系统的目的,通常是显示目标系统的主要功能而不是性能,为了达到这个目的可以使用本章3.2.4小节介绍的方法快速建立原型系统,并且可以适当降低对接口、可靠性和程序质量的要求,此外还可以省掉许多文档资料方面的工作,从面可以大大降低原型系统的开发成本。

    3.8.3 用于需求分析的软件工具

        为了更有效地保证软件需求的正确性,特别是为了保证需求的一致性,需要有适当的软件工具支持需求分析工作,这类软件工具应该满足下列要求

    (1)必须有形式化的语法(或表),因此可以用计算机自动处理使用这种语法说明的内容。
    (2)使用这个软件工具能够导出详細的文档。
    (3)必须提供分析(测试)规格说明书的不一致性和冗余性的手段,并且应该能够产生一组报告指明对完整性分析的结果。
    (4)使用这个软件工具之后,应该能够改进通信状况。

        作为需求工程方法学的一部分,在1977年设计完成了RSL.(需求陈述语言),RSL.中的语句是计算机可以处理的,处理以后把从这些语句中得到的信息集中存放在一个称为ASSM(轴象系统语义模型)的数据库中,有一组软件工具处理ASSM数据库中的信息以产生出用 PASCAL语言书写的模拟程序,从而可以检验需求的一致性,完整性和现实性。
        1977年美国密执安大学开发了PSL/PSA(问题陈述语言/问题陈述分析程序)系统。这个系统是 CADSAT(计算机辅助设计和规格说明分析工具)的一部分,它的基本结构类似于RSL.其中PSL是用来描述系统的形式语言,PSA是处理PSL描述的分析程序用。用PSL描述的系统属性放在一个数据库中,一且建立起数据库之后即可增加信息、删除信息或修改信息,并且保持信息的一致性,PSA对数据库进行处理以产生各种报告,测试不一致性或遗漏,并且生成文档资料。
        PSL/PSA系统的功能主要有下述4种
    (1)描述任何应用领域的信息系统
    (2)创建一个数据库保存对该信息系统的描述符
    (3)对描述符施加增加,除和更改等操作
    (4)产生格式化的文档和关于规格说明书的各种分析报告
        PSL/PSA系统用描述符从系统信息流、系统结构、数据结构、数据导出、系统规模、系统动态、系统性质和项目管理共8个方面描述信息系统。
        用PSL对系统做了完整描述,就可以调用PSA产生一组分析报告,其中包括所有修改规格说明数据库的记录,用各种形式描述数据库信息的参照报告(包括图形形式的描述),关于项目管理信息的总结报告,以及评价数据库特性的分析报告。
        借助PSL/PSA系统可以边对目标系统进行自顶向下的逐层分解,边将需求分析过程中遇到的数据流、文件、处理等对象用PSL描述出来并输入到PSL/PSA系统中,PSA将对输人信息作一致性和完整性检查,并且保存这些描述信息。
        PSL/PSA系统的主要优点是它改进了文档质量,能保证文档具有完整性、一致性和无二义性,从面可以减少管理和维护的费用,数据存放在数据库中,便于增加、删除和更改,这也是它的一个优点。

    3.9 小结
        传统软件工程方法学使用结构化分析技术,完成分析用户需求的工作。需求分析是发现、求精、建模、规格说明和复审的过程,需求分析的第一步是进一步了解用户当前所处的情况,发现用户所画临的问题和对目标系统的基本需求接下来应该与用户深人交流,对用户的基本需求反复细化遥逐步求精,以得出对目标系统的完整、准确和具体的需求。具体地说,应该确定系统必须具有的功能、性能,可靠性和可用性,必实现的出错处理需求,接口需求和逆向需求,必须满足的约束条件以及数据需求,并且预测系统的发展前景。
        为了详细地了解并正确地理解用户的需求,必须使用适当方法与用户沟通。访谈是与用户通信的历史悠久的技术,至今仍被许多系统分析员采用。从可行性研究阶段得到的数据流图出发,在用户的协助下面向数据流自顶向下逐步求精,也是与用户沟通获取需求的一个有效的方法。为了促使用户与分析员齐心协力共同分析需求,人们研究出一种面向团队的需求收集法,称为简易的应用规格说明技术,现在这种技术已经成为信息系统领城使用的主流技术。实践表明,快速建立软件原型是最准确,最有效和最强大的需求分析技术。快速原型应该具备的基本特性是“快速”和“容易修改”,因此,必须用适当的软件工具支持快速原型技术。通常使用第四代技术、可重用的软件构件及形式化规格说明与原型环境,快速地构建和修改原型。
        为了更好地理解问题,人们常常采用建立模型的方法,结构化分析实质上就是一种建模,在需求分析阶段通常建立数据模型、功能模型和行为模型。
        除了创建分析模型之外,在需求分析阶段还应该写出软件需求规格说明书,经过严格评审并得到用户确认之后,作为这个阶段的最终成果,通常主要从一致性,完整性,现实性和有效性4个方面复审件需求规格说明书。
        多数人习惯于使用实体-联系图建立数据模型,使用数据流图建立功能模型,使用状态图建立行为模型,读者应该掌据这些图形的基本符号,并能正确地使用这些符号建立软件系统的模型。
        数据字典描述在数据模型、功能模型和行为模型中出现的数据对象及控制信息的特性,给出它们的准确定义,因此,数据字典度成为把3种分析模型粘合在一起的“粘合剂”,是分析模型的“心”,为了提高可理解性,还可以用层次方框图或 Warnier图等图形工具轴助描系统中的数据结构。为了减少冗余、简化修改步骤,往往需要规范数据的存储结构。
        算法也是重要的,分析的基本目的是确定系统必须做什么。概括地说,任何一个计算机系统的基本功能都是把输人数据转变成输出信息,算法定义了转变的规则,因此,没有对算法的了解就不能确切知道系统的功能,IPO图是描述算法的有效工具。

    展开全文
  • 控件使用的是visual studio2010开发,对TextBox进行了改写,附带了验证功能需要开发人员再次对TextBox的内容进行验证,也需要在相关的按钮里写判断语句,只需要配置下属或者根据需求自定义验证事件即可,...
  • 芯片验证全视之一:功能验证介绍

    千次阅读 2018-08-30 21:06:20
    如果你在设计一款计算器,除了加减乘除的基本功能以外,在科学计算层面上,你需要注意到三角函数、取模、阶乘、幂运算、开根号等等复杂运算。 如果你在设计一款处理器,你需要考虑将其拆分成为运算器(算术逻辑运算...

    本文转自:http://www.eetop.cn/blog/html/28/1561828-433734.html

    如果你在设计一款计算器,除了加减乘除的基本功能以外,在科学计算层面上,你需要注意到三角函数、取模、阶乘、幂运算、开根号等等复杂运算。

    如果你在设计一款处理器,你需要考虑将其拆分成为运算器(算术逻辑运算单元,ALU,Arithmetic Logic Unit)和高速缓冲存储器(Cache)及实现它们之间联系的数据(Data)、控制及状态的总线(Bus)。

    如果你在设计一款系统集成芯片(SoC, System-on-Chip),那么它可能包括的子系统包括有处理器,片上网络(NoC, Network-on-Chip),存储器,I/O控制器(多种类,例如USB,PCIe,I2C, I2S)等等。

     

    你会发现,随着系统集成度的提高,系统自身的复杂性也在随之增加,而且结合实际工程项目来看,系统复杂度的提高对于功能验证的要求是首当其冲的。由于功能验证在芯片全流程中占据关键位置,对于一名验证工程师而言,他需要充分理解系统验证的全过程,这个过程就是功能验证的生命周期。功能验证在项目的延续中(目前的芯片之所以迭代周期越来越短,就是采取剪裁以前项目来做快速的芯片设计流程),可以得到不断的提升;同时功能验证处于所在项目中时,也需要考虑如何完善验证流程和环境。

     

    那么我们本文将带大家从芯片完整开发流程进入,来检视芯片验证在整个项目中的地位和作用。

    一般来讲,新的芯片项目都是首先从市场人员与目标客户沟通开始的。这中间,市场人员会收集客户对于芯片的要求(主要包括功能、尺寸、功耗、性能),这些指标会被记录在设计结构和产品文档中去。随后,客户关心的系统层面的功能要求会被系统设计人员按照功能进一步划分为各个独立的子系统模块,这些子系统如果本身过于庞大,也会被进一步划分为功能模块,直到被划分的尺寸可以被小的设计团队进行硬件设计。

     

    在这中间,如果硬件设计人员一般会按照芯片的功能模块划分来分成不同的功能小组,同时系统设计人员的数目也会随着系统复杂程度的升高而增加。在硬件设计过程中,硬件设计工程师会将具体的功能描述文本通过逻辑翻译成为硬件描述语言(HDL,Hardware Description Language),目前使用广泛的HDL语言VHDL和Verilog均被各个大的EDA(Electornic Design Automation)公司支持。同时,由于SystemVerilog语言本身具有Verilog的语言属性和在此之上添加的硬件设计语言的额外属性,SystemVerilog的部分子集也被归纳到了可以用来综合的硬件设计语言当中。

     

    当细分的合适大小模块初步完成RTL级(寄存器级别,Register Transfer Level)的硬件描述语言文件之后,功能验证人员会在这个时候做几项工作来检查硬件设计:

    1. HDL硬件描述文件是否正确按照功能描述文档去实施了?

    2. 硬件设计人员是否有遗漏掉的额外情况(corner case)?

    3. 硬件设计是否足够稳定来处理一些错误的情况(error response)?

     

    实际项目中,硬件设计人员和功能验证人员的合作是紧密的,这具体表现在了:

    1. 当系统设计团队将功能需求翻译为功能描述以后,硬件设计团队和功能验证团队需要围绕着功能描述文档分别展开硬件设计和功能验证工作。

    2. 硬件设计团队在初步翻译出硬件描述文件以后,功能验证团队需要将硬件描述文件搭建验证环境展开各个功能点的验证。

    3. 当验证环境测试出实际结果与预期结果不符合的情况下可以分为

      1. 如果硬件设计与功能描述文档存在明显不符时,功能验证人员会报告出存在的设计缺陷,同时硬件设计人员会修复硬件描述文件,这样从验证到设计再转回到验证即完成一个缺陷检测和修正周期。

      2. 当实际结果和预期结果有模糊的边界时(例如时序问题,状态机跳转问题),验证人员和设计人员会就同一份功能描述文件的理解存在分歧,此时他们会做初步的讨论,来确定哪一方的理解有偏差。当讨论依旧无法判定理解分歧的时候,双方最终会找到系统设计人员进行“裁决”,来明确本来的系统设计思想,进而统一双方对功能描述的理解。

     

    因此,硬件设计的完成度和缺陷率会在设计人员和验证人员的迭代周期中不断得到完善,最终达到目标。关于功能验证目标的定义,我们会在以后的文章“验证的任务和目标”详细讲述。

     

    当功能验证完成以后,后端人员会将RTL文件综合生成门级网表文件(gate netlist),同时也会为了目标速度来进行布局布线,最终可以使得门级电路可以在设定的时钟频率上面工作。在后端的各种流程当中,与前端验证人员联系紧密的当属标准延时格式(SDF,Standard Delay Format)文件,该文件会包含门级网表中各个门单元之间的延时情况用来准确描述实际电路。

    所以,对于功能验证流程而言,我们所说的仿真可以根据项目的实施流程将其划分为前端仿真和后端仿真:

    1. 前端仿真指的是进行RTL仿真,在这种仿真当中是没有真实延时情况的。对于一个寄存器(register),它的输出端(Q port)相对它的时钟输入端(Clk port)的延时为零延时(delta delay)。

    2. 后端仿真指的是进行Gate仿真。在实际项目中,由于后端综合进而产生SDF文件本身需要不断迭代周期,我们进一步又将门级仿真划分为零延时仿真和SDF仿真。

      1. 零延时仿真是只有门级网表参与仿真,没有SDF文件来具体反向标注(back annotation)门级延时情况,所以门之间的延时仍然为零延时,这个时候门级零延时仿真与RTL仿真的区别仅在于前者是后者的逻辑映射,从寄存器级别到门级的逻辑转译,这一步是由后端的综合工具(synthesis tooling)完成的。

      2. 当后端随后产生出SDF文件时,我们会将门级网表反向标注上SDF文件中包含的每一条门单元之间路径的延时,最终进行有真正延时电路的仿真。

     

    从验证完整性而言,前端仿真和后端仿真均需要在项目中实施,而它们侧重的目标也有不同。前端仿真是为了检测出功能逻辑的缺陷,而后端仿真是为了检测出实际门级电路中由于延时问题可能导致采样失败进而产生的功能缺陷。也因此验证人员不能将前端仿真的功能缺陷检测任务下移到后端仿真阶段,因为就效率问题而言,前端仿真要显著高于后端仿真;同时,后端仿真之所以不能忽略是因为它可以协助后端人员来测试出实际生成电路中是否有时序不满足的问题。

     

    当完成后端仿真以后,我们会将后端生成的标准格式文件最终交付给芯片生产商进行流片(tape out)。从上面的描述来看,这是一个完整的芯片从定义、分块、设计、验证和后端的硅前(pre-silicon)流程,同时芯片在流片以后所面临的硅后流程(post-silicon)也是一个完整的周期,这其中包括了组件测试,驱动,系统固件和应用软件编写等等。由于功能验证处在硅前流程当中,我们在这里主要阐述该流程,同时,我们也将一些相对独立的部分略去(这并不代表它们不重要),例如可测试性设计(DFT,Design for Test)。

     

    至此,芯片的硅前流程就结束了。考虑到验证人员同设计人员在实际工作中的密切结合,我们举出一个生活中的例子来情景演绎出设计验证流程是如何进行的。

     

    我女儿蒙蒙三岁了,小姑娘喜欢吃糖,她妈妈每次碰到她索要糖果也是没有什么好办法。这个时候,她的工程师爸爸给出了一个流程图来应对蒙蒙要吃糖的情况。

    这张图画了出来给蒙妈看了一下,蒙妈看过以后笑着讲,你先试试看你这一套有没有用吧。

    等到小家伙过了一会儿又来要糖的时候,我问她,你是不是之前刚吃过啊?蒙蒙点了点头,说是。我接着问,可是还需要等4个小时才可以吃下一颗啊。蒙蒙这时候不懂4个小时是多久,只是她一听到“小时”两个字就大约知道应该会挺久的,要知道她可等不了那么久。于是乎,不属于下面这个决策流程中的一幕发生了,小家伙一开始央求我,后来觉着不灵就索性哭了。好吧,工程师爸爸的流程设计存在缺陷,于是,就把蒙蒙揽到怀里,给她讲了一个故事。蒙蒙听完故事,满意地又去别的地方玩儿了,仿佛忘了刚才还在因为一颗糖哭得一把眼泪。看到这招管用,于是我就把这个流程图该成后来的样子,经过亲身经历,又交给蒙妈看了看,这次蒙妈点了点头,笑着说,知道孩子不好带了吧……

    是啊,即使作为一名有经验的设计人员(Rocker),在面对新问题的时候(蒙蒙要吃糖),也不能对自己的设计太过自信,只有经过验证人员(蒙蒙)充分验证的设计才是经得起时间考验的。说到这里,看着我才修改的这张流程图,我还是自信不起来,因为晓得讲故事的套路说不定哪天就不管用了。如果到了那个时候,新的设计缺陷一旦暴露出来,那设计人员还是得再进一步完善设计,确保它的功能良好啊。

     

    所以讲,我和蒙蒙也是紧密协作的,就同设计人员和验证人员一样,当设计发生了问题,我不能生气,不能太过自信,我需要坐下来同蒙蒙交谈,找出缺陷在什么地方,再将缺陷补上,下一次再交给蒙蒙,直到蒙蒙最终可以不用哭也能开心地吃到糖,同时我也不会因为她频繁吃糖而担心她的牙齿会坏掉。所以从这个角度来看,设计人员和验证人员能够在一起,是上辈子就修来的福分啊,不就像我跟蒙蒙一样吗?

    展开全文
  • 如何分析软件安全性需求

    千次阅读 2021-02-20 14:33:31
    软件安全性需求是指系统可靠地控制、监控和审计谁能够在哪种资源上执行哪种动作的能力,以及检测安全漏洞并从中恢复的能力。
  • ATM自动取款机系统的功能需求分析

    万次阅读 2015-04-27 12:54:45
    1.今天又是一次软件工程课的演讲,要求我们对某一个系统进行需求分析,其中需求分析包括性能需求分析和功能性需求分析,这次我们小组准备没那么充分,对于性能分析上面没做太多介绍,因为我们是花了昨天一晚上的时间...
  • 用户注册信息验证功能(前端+后台)

    万次阅读 多人点赞 2018-11-10 23:36:15
    用户名:未被占用--->进行错误提示(意思就是这是可用的啦) 被占用---->进行错误提示 密码:功能需求同上,就是错误提示的内容一样 思路:说在前面,此处的错误提示默认修改2.1中相应位置的错误提示内容。...
  • 我说CMMI2.0之验证与确认(VV)

    千次阅读 2019-02-06 09:23:10
    验证verification与确认validation是两个不同的概念,在CMMI 1.3版本中是两个不同的PA,在2.0版本中合并成了一个PA,命名为VV。 验证与确认的区别,可以通过下表来描述:   验证Verification ...
  • 在excel表格中进行连接数据库服务器功能拆分,其中的二级功能其实是看到的,所以可以写二级功能 3.2 填写原始需求 将之前分析后的需求结合文档填写即可 3.3 需求整理 根据之前我们分析文档...
  • 软件需求工程复习

    千次阅读 多人点赞 2020-04-22 09:52:17
    1.软件生产中产生需求问题的最大原因在于对应用软件的(模拟)理解透彻或应用坚决。 2.需求分析的目的是保证需求的(完整和一致)。 3.系统需求开发的结果最终会写入(系统需求规格说明)。 4.传统的需求...
  • 计算机化系统CSV验证问答.doc

    千次阅读 2021-07-18 01:55:55
    由计算机系统控制部分和受控的功能和模块构成,计算机控制部分包括控制软件和硬件(如电脑、固件等) ,受控部分包括仪器设备和人员、SOP 程序、组织、培训等。在制药工厂中,计算机化系统主要有实验室仪器设备、应用...
  • 如下图所示: 由于用户模块被其他功能模块调用的可能要高于岗位模块,而且用户模块更需要进行抽象,所以一般认为用户模块应该位于岗位模块的下层(但这也一定,决定于实际场景下的需求情况)。换句话说,岗位...
  • 基于图书管理系统的需求分析 之 可行分析&安全需求分析&系统需求分析 1.可行分析 本次可行分析是按照规范步骤进行,即按复查项目目标和规模,研究本系统,导出新系统的高层逻辑模型,重新定义问题...
  • 使用 jQuery Validate 进行表单验证

    万次阅读 多人点赞 2018-06-13 21:31:18
    jQuery Validate简介jQuery Validate 插件提供了强大的表单验证功能,能够让客户端表单验证变得更简单,同时它还提供了大量的定制化选项,以满足应用程序的各种需求。该插件捆绑了一套非常有用的验证方法,包括 ...
  • 个人博客系统 --- 可行分析与需求分析文档 个人博客系统是针对希望个性化使用博客的用户的需求而设计,是可以完成个人博客用户登入、发表、浏览、修改文章以及图片视频、留言、评论甚至个性化设计博客网站页面、...
  • 重用的UVM验证结构

    千次阅读 2018-07-27 16:22:43
    路科验证官网:路科验证 - 专注于数字芯片验证的...用SystemVerilog和UVM写验证平台时,会在模块级和系统级面临的配置和可重用的问题。而从一个模块到系统级验证环境中去重用通用验证组件(Universal Verific...
  • 需求:要求在新增/修改门店名称时,不可以重复添加名称的问题 int exist = commonService.getListForTotal("existstorebyid", storeBean);... result.setMessage("门店名称不可重复"); return result;...
  • ASP.NET Core MVC 中的模型验证

    千次阅读 2018-11-27 16:01:22
    数据模型的验证被视为是数据合法的第一步,要求满足类型、长度、校验等规则,有了MVC的模型校验能够省却很多前后端代码,为代码的简洁也做出了不少贡献。 原文地址:...
  • 需求工程之需求基线

    千次阅读 2020-04-21 09:16:13
    需求基线定义:已经通过正式评审和批准的规格说明或产品,作为进一步开发的基础,而且只有通过正式的变更控制过程才能修改它。 需求基线要以一种持续、衡定和易于项目涉众访问的方式存在。 需求基线通常以文...
  • 2,条目属性字段定制。3.3节所分析的敏捷开发下的需求绝大多数是已经实现了条目化管理,产品待办列表就是Scrum进行条目化管理的载体。而条目化需求管理并不是敏捷开发的专利,当前已经有不少组织在非敏捷环境下...
  • 这是在经过断断续续学习html、css和js后,写的第一个算是比较完善,依然比较初级的小案例,用户注册界面,其中用的html以及css知识都比较少,主要是js代码中各种【验证功能】实现。 html部分:标题+form表单+table...
  • 软件工程(需求分析)

    千次阅读 2021-03-30 14:30:29
    对软件需求的深人理解是软件开发工作获得成功的前提条件,不论人们把设计和编码工作做得如何出色,能真正满足用户需求的程序只会令用户失望.给开发者带来烦恼。 需求分析是软件定义时期的最后个阶段 ,它的基本任务...
  • 软件需求与软件需求规约

    千次阅读 2018-08-15 00:15:38
    软件需求与软件需求规约 需求需求获取 不论是自顶向下的软件开发,还是自底向上的软件开发,...需求:一个需求是一个有关“要予构造”的陈述,用以描述待开发产品(或项)功能上的能力、性能参数或者其他性质 ...
  • 较全的OA系统功能需求

    万次阅读 2014-11-09 17:40:14
    近年来,很多协同OA厂商面临被淘汰的局面,正是由于它们在技术上已经跟上发展趋势,对于用户不断发展变化的需求不敏感,没有及时做出调整,没有苦练内功。所以今天我收集到一些OA模板,展示出来让大家系统的了解...
  • 软件需求分类与需求获取

    万次阅读 2021-01-05 02:07:51
    需求分类 业务需求: 客户对于系统的高层次目标要求(high-level objectives) ,定义了项目的远景和范畴(vision and scope) 业务:属于哪类业务范畴?...该系统让用户在网络上查询与浏览电子资料,改变原有借
  • 需求文档

    千次阅读 多人点赞 2019-03-29 18:10:18
    ...产品设计是一个由抽象的概念到具体形象化的处理过程,通过文字或...虽然产品需求文档没有标准的规范,但是有两项是必不可少的,那就是文件标识和修改记录。文档在撰写过程中,我们可以自行不断的...
  • 软件工程需求分析方法

    千次阅读 2019-11-28 17:12:02
    详细介绍软件工程需求分析方法,转载自别处,
  • 谁能告诉我这科的理论在哪可以实用呀?搞懂,只能收藏一下包挂科
  • 功能需求:区隔非功能需求的实现。 没错,这些规则都对,都是我们可以考虑的维度。但是,在实际中执行的又是如何呢?——实际情况是:只要看一下这些模式中提及的术语,就能体会到其中的困难。“业务规则”、...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 256,743
精华内容 102,697
关键字:

不可验证性功能需求