单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,16:48,*,单击此处编辑母版标题样式,长沙学院,计算机系,课件来源：北京大学软件工程国家工程研究中心 王立福,三、软件需求及系统,/,产品,(,需求,),规约,-,定义问题的基本要素是什么,?,-,定义问题的基本格式是什么,?,不论是自顶向上的软件开发,还是自底向上的软件开发,正确定义问题,是解决问题的前提,.,三、软件需求及系统/产品(需求)规约 不论是自顶向上的软件,1,1,定义问题的基本要素,定义问题的基本要素是”需求”,1),何谓需求,?,一个需求是一个有关“要予构造”的陈述，用以描述待开发产品（或项）功能上的能力、性能参数或者其它性质。,A requirement is a statement that has been constructed to describe a necessary functional capability,performance parameter,or other property of the intended product(or item).,1 定义问题的基本要素,2,例如：,系统必须有能力支持,100,个以上的并发用户，每个用户可,以处理附录,A,中操作任务的任选组合，平均响应时间应该,小于,1,秒，最大响应时间应小于,5,秒。,其中,:,功能,-,可以处理附录,A,中操作任务的任选组合,性能,-,有能力支持,100,个以上的并发用户,平均响应时间应小于,1,秒，最大响应时间应小于,5,秒。,必须在对话窗口的中间显示错误警告，其中使用红色的、,14,点加粗,Arial,字体。,其中,:,功能,-,能显示错误警告,设计约束,-,在对话窗口的中间显示,并使用红色的、,14,点加,粗,Arial,字体。,3,2),什么样的陈述可以作为需求,-,需求的基本性质,IEEE,标准,830-1998,要求单一需求必须具有,5,个基本性质,:,必要的,(Necessary),。是要求的吗？,无歧义的,(Unambiguous),。只能用一种方式解释吗？,可测试的,(testable),。可以对它进行测试吗？,可跟踪的,(Traceable),。可以从一个开发阶段到另一,个阶段对它进行跟踪吗？,可测量的,(Measurable),。可以对它进行测量吗？,注,:,确定一个需求是否满足以上五个性质是复杂耗时的过程,.,2)什么样的陈述可以作为需求,4,3),需求分类,功能；,性能；,外部接口；,设计约束；,质量属性。,功能需求,功能需求规约了系统或系统构件必须执行的功能。,例如：,系统应对所有已销售的应纳税商品计算销售税。,系统应提供一种方法，使系统用户可根据本地利率调整销售税比例,.,系统应能够产生月销售报表。,5,除了对要执行的功能给出一个陈述外，还应规约如下内容：,关于该功能输入的所有假定，或为了验证该功能输入，,有关检测的假定。,功能内的任一次序，这一次序是与外部有关的。,对异常条件的响应，包括所有内外部所产生的错误。,需求的时序或优先程度。,功能之间的互斥规则。,系统内部状态的假定。,为了该功能的执行，所需要的输入和输出次序。,用于转换或内部计算所需要的公式。,除了对要执行的功能给出一个陈述外，还应规约如下内容：,6,关于功能需求应考虑以下问题：,（,1,）功能源。,（,2,）功能共享的数据。,（,3,）功能与外部界面的交互。,（,4,）功能所使用的计算资源。,可见,功能需求是整个需求的主体，几乎构成了由,交谈和小组讨论所得到的所有初始需求。这意味着,:,没有功能需求,就谈不上其它需求,即,性能需求,、,外部接,口需求,、,设计约束和质量属性。,关于功能需求应考虑以下问题：,7,性能需求,性能需求,(Performance requirement),规约了一个系统或,系统构件必须具有的性能特性。例如：,系统应该在,5,分钟内计算出给定季度的总销售税。,系统应该在,1,分钟内从,100000,条记录中检索出一个销售定单。,该应用必须支持,100,个,Windows 95/NT,工作站的并行访问。,注,1,：性能需求隐含了一些满足功能需求的设计方案，经常,对设计产生一些关键的影响。例如：排序，关于花费,时间的规约将确定哪种算法是可行的。,注,2:,性能需求对功能需求而言,可以是一对多的,例如,:,性能,x,功能,功能,功能,性能需求 性能x,8,外部接口需求,外部接口需求,(External interface requirement),规约了,系统或系统构件必须与之交互的硬件、软件或数据库元素。它,也可能规约其格式、时间或其他因素。,例如：,账户接收系统必须为月财务状况系统提供更新信息，如在,“,财务系统描述,”,第,4,修订版中所描述的。,引擎控制系统必须正确处理从飞行控制系统接收来的命令，,符合接口控制文档,B2-10A4,，修订版,C,的,1,到,8,段的规定。,外部接口需求,9,-,用户接口,(User interfaces),：规约了软件产品和用户之间接口的逻辑特性。即规约 对给用户所显示的数据，对用户所要求的数据以及用户如何控制该用户接口。,-,硬件接口,(Hardware interfaces),：如果软件系统必须与硬件设备进行交互，那么就应说明所要求的支持和协议类型。,-,软件接口,(Software interfaces),：允许与其它软件产品进行交互，如，数据管理系统、操作系统或数学软件包。,-,通讯接口,(Communications interfaces),：规约待开发系统与通讯设施,(,如，局域网,),之间的交互。如果通讯需求包含了系统必须使用的网络类型（,TCP/IP,，,WindowsNT,Novell,），那么有关类型的信息就应包含在,SRS,中。,-用户接口(User interfaces)：规约了软,10,-,内存约束,(Memory constraints),：描述易失性存储和永久性存储的特性和限制，特别应描述它们是否被用于与一个系统中其它处理的通讯。,-,操作,(Operation),：规约用户如何使系统进入正常和异常的运行以及在系统正常和异常运行下如何与系统进行交互。应该描述在用户组织中的操作模式，包括交互模式和非交互模式；描述每一模式的数据处理支持功能；描述有关系统备份、恢复和升级功能方面的需求。,-,地点需求,(Site adaptation requirements),：描述系统安装以及如何调整一个地点，以适应新的系统。,-内存约束(Memory constraints)：描述,11,设计约束,设计约束限制了系统或系统构件的设计方案。就约束的本身而言，对其进行权衡或调整是相当困难的，甚至是不可能的。它们必须予以满足。这一性质，是与其它需求的最主要差别。为了满足功能、性能和其它需求，许多设计约束将对软件项目规划、所需要的附加成本和工作产生直接影响。例如：,系统必须用,C+,或其他面向对象语言编写。系统用户接口需要菜单。,任取,10,秒，一个特定应用所消耗的可用计算能力平均不超过,50%,。,必须在对话窗口的中间显示错误警告，其中使用红色的、,14,点加粗,Arial,字体。,设计约束,12,针对产品开发，为确定其相关的设计约束，一般需要考虑以下,10,个方面：,-,法规政策,(Regulatory policies),；,-,硬件限制,(Hardware limitations),，例如：处理速度、信号定序需求、存储容量、通讯速度以及可用性等；,-,与其它应用接口,(Interfaces to other applications),，如，当外部系统处于一个特定状态时，禁止新系统某些操作,-,并发操作,(Parallel operations),，例如，可能要求从,/,自一些不同的源，并发地产生或接收数据。对此，必须清晰地给出有关时间的描述。,针对产品开发，为确定其相关的设计约束，一般需要考虑以下10个,13,-,审计功能,(Audit functions),，规约软件系统 必须满足的数据记录准则或事务记录准则。如，如果用户察看或修改数据，那么就可能要求该系统为了以后复审，记录该系统的动作。,-,控制功能,(Control functions),：可以对系统的管理能力进行远程控制、可以对其他外部软件以及内部过程进行控制。,-,高级语言需求,(Higher order language requirements),：,-,握手协议,(Signal handshake protocols),：通常用于硬件和通讯控制软件，特别当给出特定的时间约束时，一般就要把,“,握手协议,”,作为一项约束。,-,应用的关键程度,(Criticality of the application),，许多生物医学、航空、军事或财务软件属于这一类。,-,安全考虑,(Safety and security considerations),。,-审计功能(Audit func,14,质量属性,质量属性,(Quality attribute),规约了软件产品必须具有,的一个性质是否达到质量方面一个所期望的水平。例如：,属性 描述,可靠性,软件系统在指定环境中没有失败而正常运行的概率,。,存活性,当系统的某一部分系统不能运行时，该软件继续运行或支,持关键功能的可能性。,可维护性,发现和改正一个软件故障或对特定的范围进行修改,所要求的平均工作。,用户友好性,学习和使用一个软件系统的容易程度。,安全性,在一个预定的时间内，使软件系统安全的可能性。,可移植性,软件系统运行的平台类型。,质量属性,15,2,定义需求的基本格式,-,需求规约（）,1),概念,一个,需求规约,是一个软件项,/,产品,/,系统所有需求陈述的正式文档,是一个软件产品系统的概念模型,。,A requirement specification is the formal documentation all requirement statements for an item/product/system.,2),基本性质,IEEE,标准还规定,SRS,必须具有以下,4,个性质：,重要性和稳定性程度,(Ranked for importance and stability),。,2 定义需求的基本格式,16,可修改的,(Modifiable),。在不过多地影响其它需求的前提下，可以容易地修改一个单一需求,.,完整的,(Complete),。没有被遗漏的需求,.,一致的,(Consistent),。不存在互斥的需求,.,注：,大型复杂项目和一些有能力的组织，在开发需求文档时，往往使用系统化的需求分析技术和工具。其中一些方法提供了系统化、自动化的功能，逐一验证单一需求所具有的五个性质，并进一步验证需求规约是否具有以上四个性质。,可修改的(Modifiable)。在不过多地影响其它需,17,系统需求规格说明书,1,引言,1,1,编写目的,说明编写本需求分析规格说明书的目的。,1,2,背景说明,(1),给出待开发的软件产品的名称；,(2),说明本项目的提出者、开发者及用户；,(3),说明该软件产品将做什么，如必要，说明不做什么。,1,3,术语定义,列出本文档中所用的专门术语的定义和外文首字母组词的原词组。,1,4,参考资料,列出本文档中所引用的全部资料，包括标题、文档编号、版本号、出版日期及出版单位等，必要时注明资料来源。,3),需求规约格式实例,系统需求规格说明书3,18,2,概述,2,1,功能概述,叙述待开发软件产品将完成的主要功能，并用方框图来表示各功能及其相互关系。,2,2,约束,叙述对系统设计产生影响的限制条件，并对下一节中所述的某些特殊需求提供理由，如管理模式、硬件限制、与其他应用的接口、安全保密的考虑等。,2概述,19,3,数据流图与数据字典,3,1,数据流图,3,1,1,数据流图,l,(1),画出该数据流图,(2),加工说明,(a)