精华内容
下载资源
问答
  • 软件需求分析——非功能性需求

    万次阅读 多人点赞 2019-05-07 18:28:24
    前言:需求分为功能需求和非功能性需求,常常会因为注重功能需求而忽略了非功能性需求,以下是对常见几类非功能性需求的小小总结,以后再慢慢补充。 非功能性需求 1、定义:软件产品为满足用户业务需求而必须具有...

     前言:需求分为功能需求和非功能性需求,常常会因为注重功能需求而忽略了非功能性需求,以下是对常见几类非功能性需求的小小总结,以后再慢慢补充。

    非功能性需求

    1、定义:软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。

    2、影响:影响着产品是否能够持续稳定并高效的提供服务。

    3、常见类别:

    • 性能需求:响应时间、吞吐量、资源利用率;
    • 安全性:保密性、防泄漏、权限控制、防攻击;
    • 可维护性与可扩展性:模块性、可复用性、易分析性;
    • 可靠性:易恢复性、容错性、成熟性;
    • 易用性:易学习性、易操作性、用户错误防御机制、用户界面美观;
    非功能性需求1.0

     

    展开全文
  • 功能性需求和非功能性需求

    万次阅读 2016-10-10 12:07:35
    需求定义:需求(requirement)就是系统(更广义的说法是项目)必须提供的能力和必须遵从的条件。 需求分类: (1) 在一般使用中,需求... 非功能性需求是指软件产品为满足用户业务需求而必须具有且除功能需求以外的

     

    需求定义:需求(requirement)就是系统(更广义的说法是项目)必须提供的能力和必须遵从的条件。

    需求分类:

    (1) 在一般使用中,需求按照功能性(行为的)和非功能性(其它所有的行为)来分类。

      功能性需求是说有具体的完成内容的需求。

      例如:比如客户登录、邮箱网站的收发收发邮件、论坛网站的发帖留言等。

      非功能性需求是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性,包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。

      例如:性能要求:要求系统能满足100个人同时使用,页面反应时间不能超过6秒;

         可靠性: 系统能7×24小时连续运行,年非计划宕机时间不能高于8小时。要求能快速的部署,特别是在系统出现故障时,能够快速的切换到备用机。  

    (2) 在统一过程(UP)中,需求按照“FURPS+”模型进行分类。

      • 功能性(Functional):特性、功能、安全性;
      • 可用性(Usability):人性化因素、帮助、文档;
      • 可靠性(Reliability):故障频率、可恢复性、可预测性;
      • 性能(Performance):响应时间、吞吐量、准确性、有效性、资源利用率;
      • 可支持性(Supportability):适应性、可维护性、国际化、可配置性。

     

    “FURPS+”中的“+”是指一些辅助性的和次要的因素,比如:

     

      • 实现(Implementation):资源限制、语言和工具、硬件等;
      • 接口(Interface);强加于外部系统接口之上的约束;
      • 操作(Operation):对其操作设置的系统管理;
      • 包装(Packaging)例如物理的包装盒;
      • 授权(Legal):许可证或其他方式。

    使用“FURPS+”分类方案(或其他分类方案)作为需求范围的检查列表是有效的,可以避免遗漏系统某些重要方面。

    其中某些需求可以统称为质量属性(quality attribute)、质量需求(quality requirement)或系统的“某属性”。这些需求包括:可用性、可靠性、性能和可支持性

    展开全文
  • 什么是功能性需求和非功能性需求

    万次阅读 2011-11-02 17:04:08
    需求定义: 需求(requirement)就是系统(更广义的说法是项目)必须提供的能力和必须遵从的条件。 需求分类: (1) 在一般使用中,需求... 非功能性需求是指软件产品为满足用户业务需求而必须具有且除功能需求以

    需求定义:

    需求(requirement)就是系统(更广义的说法是项目)必须提供的能力和必须遵从的条件。

    需求分类:

    (1) 在一般使用中,需求按照功能性(行为的)和非功能性其它所有的行为)来分类。

      功能性需求是说有具体的完成内容的需求

      例如:比如客户登录、邮箱网站的收发收发邮件、论坛网站的发帖留言等。

      非功能性需求是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性,包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。

      例如:性能要求:要求系统能满足100个人同时使用,页面反应时间不能超过6秒;

         可靠性: 系统能7×24小时连续运行,年非计划宕机时间不能高于8小时。要求能快速的部署,特别是在系统出现故障时,能够快速的切换到备用机。

    (2) 在统一过程(UP)中,需求按照“FURPS+”模型进行分类。

    • 功能性(Functional):特性、功能、安全性;

    • 可用性(Usability):人性化因素、帮助、文档;

    • 可靠性(Reliability):故障频率、可恢复性、可预测性;

    • 性能(Performance):响应时间、吞吐量、准确性、有效性、资源利用率;

    • 可支持性(Supportability):适应性、可维护性、国际化、可配置性。

    “FURPS+”中的“+”是指一些辅助性的和次要的因素,比如:

    • 实现(Implementation):资源限制、语言和工具、硬件等;

    • 接口(Interface);强加于外部系统接口之上的约束;

    • 操作(Operation):对其操作设置的系统管理;

    • 包装(Packaging)例如物理的包装盒;

    • 授权(Legal):许可证或其他方式。

    使用“FURPS+”分类方案(或其他分类方案)作为需求范围的检查列表是有效的,可以避免遗漏系统某些重要方面。

    其中某些需求可以统称为质量属性(quality attribute)、质量需求(quality requirement)或系统的“某属性”。这些需求包括:可用性、可靠性、性能和可支持性。

    展开全文
  • 功能安全学习笔记002-功能安全的定义

    万次阅读 多人点赞 2018-04-07 21:52:59
    1,功能安全的定义1.1 本质安全与功能安全为了了解功能安全的概念,先得熟悉下 和“本质安全”和“功能安全”的概念。假如以铁道的路口为例,比较一下基于两种安全概念的避免路口事故的方法。这里避免路口事故就是...
    1,功能安全的定义

    1.1 本质安全与功能安全

    为了了解功能安全的概念,先得熟悉下 和“本质安全”和“功能安全”的概念。

    假如以铁道的路口为例,比较一下基于两种安全概念的避免路口事故的方法。这里避免路口事故就是安全目标,为了实现这个目标,可进行如下操作:

    首先,如果把铁道路口撤掉,直接改造成立交桥的形式,让火车和汽车都走各自的路,这样就不会发生人或者车辆横穿铁道口的事故了。像这样,根据系统的特性把危险源直接除掉的方法是「本质安全」。

                                                                               

    其次,假如我们在铁道路口设置信号灯和道口自动栏杆,当火车来临时前闪红灯,同时将栏杆放下,避免行人或者车辆通过。像这样通过栏杆的拦截功能及预警灯来抑制事故风险的技术叫做「功能安全」。在这里信号灯和自动栏杆一种安全机制(Safety Mechanism)。理想的情况是不管什么场合都采用 「本质安全」,但事实上,在很多场合里,由于系统自身的原因,不可能把危险源除掉。特别是像车载电控系统这样非常复杂的电子化系统,以上所述的本质安全很难被实现和应用。因此我们只能采用功能安全,它的目的就是在本质安全无法达到时,尽可能的通过增加安全机制去提高安全等级,实现安全目标。

    1.2 电子控制器的功能安全

    对于汽车而言,可将汽车看成一个“机器人”,驾驶员给这个“机器人”发送信号,比如踩踏板加油,汽车收到命令然后执行:电喷系统增加喷油,发动机输出扭矩增加,实现车辆加速。

    对于传统汽车而言,它的结构简单,且大多数命令都是通过机械方式来实现的,如老式汽车的机械式节气门等,其失效的可预见性大;而现在汽车,其电子电气化增强,驾驶员的指令会先转换成相关信号,然后这些信号传递给控制器的处理芯片,然后最终驱动相关的执行器来执行,其失效的可预见性大大降低。


       

    正因为现代汽车随着电子电气化的程度越来越高,其整车的安全性很大程度就取决于电子控制器的安全性,比如发动机控制器ECU,变速箱控制器TCU,车辆稳定性控制器ESP等等。而且电子控制器失效的可预见性非常低,比如芯片/电路受外界干扰等,这很难预料什么情况会出问题。  因此必须考虑电子控制器失效了会怎么办的问题。

    1.3 功能安全考虑的角度

    针对电子控制器失效了怎么办这个问题,首先得确定一个角度。比如极端高温情况下的ECU自燃,爆炸等这种系统本身带来的风险,这种风险不在功能安全的考虑范围内。

    从产品安全的角度来说,可将其安全分为传统安全以及由电子/电气功能安全,传统安全包括:与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害,除非危害是直接由电子电气安全相关系统的故障行为而引起的。传统安全不在功能安全的考虑范围之内。

      

    根据国际上知名的安全协会的定义,比如英国的MISARA(The Motor Industry Software Reliability Association 汽车工业软件可靠性协会),比如德国的德国VDA协会(VDA(Verband der Automobilindutrie)德国汽车工业协会)他们是从车辆可控性的角度对功能安全提出要求。而IEC-61508强调从人身安全(还可以考虑设备安全)角度提出需求。

    因此从车辆可控性和人身安全两个层面上考虑功能安全就有了着陆点。比如考虑是不是有非驾驶员期望的加速等,而非驾驶员期望的减速其实是降低了安全边界,但车辆扔被驾驶员控制着。这就是为什么ECU不对相关控制器的减扭做监控的原因。

    1.4 ISO26262中对功能安全的定义

    ISO 26262是专门用作提升汽车电子电气产品功能安全的国际标准,它派生于电子、电气及可编程器件功能安全基本标准IEC61508。那26262是如下定义功能安全这个概念的:

    English definition:absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems;

    没有由电子、电气系统故障行为导致的危险所引起的不合理风险。

    我们来分解下这段话:

    A.没有风险:absence of risk

    B.没有不合理风险 unreasonable

    C.没有由电子、电气系统故障行为导致的危险所引起的不合理风险

    其中的关键词是不合理风险,什么是不合理风险呢,比如车辆行驶时安全气囊蹦出来了,这是不合理风险,这是功能安全需要避免的问题。

                                                    

    总体来说,功能安全是指避免由系统功能性故障导致的不可接受的风险。它关注的是系统发生故障之后的行为,而不是系统的原有功能或性能。因此功能安全的目的就是当系统发生故障后,将系统进入安全的可控模式,避免对人身、财产造成伤害。

    2,ASIL汽车安全完整性等级

    2.1 危险事件的确定

    对电子控制器ECU来说,引起失效主要是两个方面:软件和硬件。

    软件失效:比如没有考虑分母可能为0;变量公式定义错误,导致精度丢失;

    硬件失效:如下图所示可以分为传感器失效;ECU硬件失效(比如CPU或者RAM/ROM失效);执行器失效;

            

    依据ISO 26262标准进行功能安全设计时,首先识别系统的功能,并分析其所有可能的功能故障(Malfunction)或失效,可采用的分析方法有HAZOP,FMEA、头脑风暴等。

    功能故障在特定的驾驶场景下才会造成伤亡事件,比如近光灯系统,其中一个功能故障就是灯非预期熄灭,如果在漆黑的夜晚行驶在山路上,驾驶员看不清道路状况,可能会掉入悬崖,造成车毁人亡;如果此功能故障发生在白天就不会产生任何的影响。

    所以进行功能故障分析后,要进行情景分析,识别与此故障相关的驾驶情景,比如:高速公路超车、车库停车等。分析驾驶情景建议从公路类型(国道,高速),路面情况,(湿滑、冰雪);车辆状态(转向、 超车、制动、加速等),环境条件(风雪雨尘、夜晚、隧道灯),人员情况(乘客、路人)等几个方面去考虑。功能故障和驾驶场景的组合叫做危害事件(hazard event)。

    危害事件确定后,根据三个因子——严重度(Severity)、暴露率(Exposure)和可控性(Controllability)评估危害事件的风险级别——也就是ASIL等级。

    2.2 ASIL等级

    ASIL等级的定义是为了对失效后带来的风险进行评估和量化以达到安全目标,其全称是Automotive Safety Integration Level--汽车安全完整性等级。这个概念来源于IEC61508,其通过失效概率的方式定义了安全完整性等级(SIL)。但是在汽车界只有硬件随机失效可以通过统计数字评估失效概率,软件失效却难以量化,因此26262根据汽车的特点定义了ASIL。

    如上节所述ASIL的评定,一般是在产品概念设计阶段对系统进行危害分析和风险评估,识别出系统的危害,如果系统的安全风险越大,对应的安全要求级别就越高,其具有的ASIL的等级也越高。ASIL分为QM,A、B、C、D五个等级,ASIL D是最高的汽车安全完整性等级,对功能安全的要求最高。

    2.3 危险分析和风险评定

    对于汽车系统,特定危险的风险决定于以下三个因素:

    A.危险事件所导致伤害或损失的潜在严重性 (Severity of failure, S) 

    B.指人员暴露在系统失效能够造成危害的场景中的概率OR理解为危险事件可能发生的驾驶工况的可能性 (probability of exposure, 简称E) 

    C.危险所涉及的驾驶员和其它交通人员通过及时的反应避免特定伤害或损失的能力 (controllability, 简称C)

       

    然后分别将严重性S、可能性E和可控性C分成4个等级,如下表所示,其中QM代表与安全无关:

     


    按照以上的划分并进行组合相加得到5个ASIL等级(QM,A,B,C,D),原则是:

    A. 基本可控C0的组合不考虑;

    B. 无伤害S0的组合不考虑;

    C. 其余组合相加等于7分为ASIL A,等于8分为ASIL B,等于9分为ASIL C,等于10分为最高等级ASIL D;ASIL A、B、C、D都是与功能安全相关的(Safety Relevant Function)

    D. 其余的得分安全评定为QM,代表与安全无关的功能(Non Safety Relevant Function)

       


    下面举几个例子进行说明:

    1,EPB(Electrical Park Brake)电子手刹

    以电子手刹的驻车功能为例,当驻车时,驾驶员通过按钮或者其他方式触发制动请求,EPB在汽车的后轮上施加制动力,以防止车非期望的滑行。该系统的危害有非期望的制动失效,非期望的制动启动。相同的危害在不同场景下风险也是不一样的,因此也要对不同场景进行分析。分析如下表所示:

      

    得出了EPB系统的安全目标为:防止非期望的制动,ASIL等级为D

    根据上面的分析,不难得出其它例子的ASIL 等级,比如:

     


    2.4 功能安全目标的分解

    通过上危害分析和风险评估,我们得出系统或功能的安全目标和相应的ASIL等级,当ASIL等级确定之后,就需要对每个评定的风险确定安全目标,安全目标是最高级别的安全需求。安全目标确定以后就需要在系统设计,硬件,软件等方面进行设计和实施,验证。

    从安全目标可以推导出开发阶段的安全需求,安全需求继承安全目标的ASIL等级。如果一个安全需求分解为两个冗余的安全需求,那么原来的安全需求的ASIL等级可以分解到两个冗余的安全需求上。因为只有当两个安全需求同时不满足时,才导致系统的失效,所以冗余安全需求的ASIL等级可以比原始的安全需求的ASIL等级低。ISO 26262标准的第9章给出了ASIL分解的原则。ISO 26262中提出了在满足安全目标的前提下降低ASIL等级的方法——ASIL分解,这样可以解决上述开发中的难点。

    ASIL 分解的一个最重要的要求就是独立性,如果不能满足独立性要求的话,冗余单元要按照原来的ASIL等级开发。所谓的独立性就冗余单元之间不应发生从属失效(Dependent Failure),从属失效分为共因失效(Common Cause Failure)和级联失效(Cascading Failure) 两种。共因失效是指两个单元因为共同的原因失效,比如软件复制冗余,冗余单元会因为同一个软件bug导致两者都失效,为了避免该共因失效,我们采用多种软件设计方法。级联失效是指一个单元失效导致另一个单元的失效,比如一个软件组件的功能出现故障,写入另一个软件组件RAM中,导致另一个软件组件的功能失效。

    具体降解的方法如下所示,比如应按照下列之一对一个 ASIL D 的要求进行分解: 

    1)   一个ASIL C(D)的要求和一个ASIL A(D)的要求;或 

    2)   一个ASIL B(D)的要求和一个ASIL B(D)的要求;或 

    3)  一个ASIL D(D)的要求和一个QM(D)的要求,


         

    其它ASIL等级分解可如下图所示:



          

    以上简单的介绍了下功能安全的定义,以及ASIL等级的评定和分解。所学有限,如有失误,还请指正,感激不尽。




     






















    展开全文
  • 功能性需求,一般是我们显性易见的,就是一般实现了什么功能,提供了什么服务,大体我认为问题中提到,或者我们日常所说的:“看起来复杂不复杂”,基本上都会是针对功能性需求而言的。如果拿google的搜索服务举
  • 如何定义需求的优先级也是挺能看出产品经理的能力水平的,在上一节已经详细阐述了评估哪些需求该做,哪些需求不该做,对于已经决定要做的需求,这样的需求数量很多,是现在做,还是以后做,不可能在同一时间内全部...
  • 软件需求的定义

    千次阅读 2008-03-13 08:49:00
    对同一项需求,不同的人会有不同的描述,称其为用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。客户对需求的定义,在开发人员看来可能只是高级别的产品概念;而开发人员的需求概念对用户来...
  • 软件测试的定义

    万次阅读 2017-12-11 23:10:56
    首先要明确测试的定义,所谓测试,就是以检验产品是否满足需求为目标。 而软件测试,自然是为了发现软件(产品)的缺陷而运行软件(产品) 比较标准的软件测试的定义是:在规定的条件下对程序进行操作,以发现错误,对软件...
  • python中函数的定义以及如何编写一个函数

    万次阅读 多人点赞 2019-06-30 18:06:52
    1.函数的定义 ...定义一个函数,你可以定义一个由自己想要功能的函数,以下是简单的规则: 函数代码块以 def 关键词开头,后接函数标识符名称和圆括号()。 任何传入参数和自变量必须放在圆括号...
  • 从“概念“到“最小可行...在产品开发中,最小可行性产品(MVP)是一种具有刚好可以满足早期用户需求的功能,并为未来开发提供反馈的产品。 构建“最小可行性产品” 假设你有了一个很棒的想法,你需要开始构建一个...
  • 多态的定义和作用

    千次阅读 2018-03-25 00:08:40
    1多态(polymorphism)的定义 多态是面向对象的必备特性,指的是同一接口的不同实现方式,多态允许基类的指针指向子类方法。... 2父类引用可以调用不同子类的功能,提高了代码的扩充和可维护...
  • 缺陷分类和级别定义

    千次阅读 2019-03-23 10:14:05
    功能问题(FunctionError):对产品、项目质量有影响,但尚难以确定是否是错误,暂时无法解决 功能缺陷(FunctionDefect):不满足用户需求等bug的总称 设计缺陷(UIDefect):页面美观、协调、错别字等 用户...
  • java中的函数定义及其使用

    万次阅读 多人点赞 2017-07-16 11:25:11
    函数是具备特定功能的一段代码块,解决了重复代码的问题。 为什么要定函数呢? 目的是为了提高程序的复用和可读性。 函数的格式 修饰符 返回值类型 函数名(形式参数类型1 参数名1,形式参数类型2 参数名2,形式...
  • 文章目录系统测试概述功能测试性能测试负载测试压力测试性能测试、压力测试、负载测试的关系兼容测试安全测试健壮测试配置测试可用测试文档测试 系统测试概述 系统测试的定义 将已经集成好的软件系统,作为...
  • Bug的严重程度、优先级如何定义

    万次阅读 2015-10-18 19:54:57
    Bug的严重程度、优先级如何定义【转】 Priority()和Severity(严重程度)是的两个重要属性。很多新人经常混淆这两个概念。通常,人员在提交Bug时,只定义Bug的Severity, 即该Bug的严重程度,而将Priority交给Project ...
  • 什么是功能安全

    万次阅读 2018-07-06 09:15:33
    什么是功能安全(FS)?在现代工业控制领域中,可编程电子硬件、软件...为此,世界各国历来对石化过程安全控制系统、电厂安全控制系统、核电安全控制系全领域的产品安全设计技术非常重视,并且将电子、电气及可编...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,774,701
精华内容 709,880
关键字:

定义产品的功能性需要