软件项目文档_第1页
软件项目文档_第2页
软件项目文档_第3页
软件项目文档_第4页
软件项目文档_第5页
已阅读5页,还剩6页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件项目文档文档的治理和爱护在整个软件生存期中,各种文档作为半成品或是最终成品,会不断地生成、修改或补充。为了最终得到高质量的产品,达到上节提出的质量要求,必须加强对文档的治理。以下几个方面是应注意做到的■:软件开发小组应设一位文档保管人员,负责集中保管本项目巳有文档的两套主文本。两套文本内容完全一致。其中的一套可按一定手续,办理借阅。软件开发小组的成员可依照工作需要在自己手中储存一些个人文档。这些一样都应是主文本的复制件,并注意和主文本保持一致,在作必要的修改时,也应先修改主文本。开发人员个人只储存着主文本中与他工作相关的部分文档。在新文档取代了旧文档时,治理人员应及时注销旧文档。在文档内容有更动时,治理人员应随时修订主文本,使其及时反映更新了的内容。项目开发终止时,文档治理人员应收回开发人员的个人文档。发觉个人文档与主文本有差别时,应赶忙着手解决。这常常是未及时修订主文本造成的。在软件开发过程中,可能发觉需要修改巳完成的文档,专门是规模较大的项目,主文本的修改必须专门慎重。修改往常要充分估量修改可能带来的阻碍,同时要按照:提议、评议、审核、批准和实施等步骤加以严格的操纵。文档编制的质量要求为了使软件文档能起到前节所提到的多种桥梁作用,使它有助于程序员编制程序,有助于治理人员监督和治理软件开发,有助于用户了解软件的工作和应做的操作,有助于爱护人员进行有效的修改和扩充,文档的编制必须保证一定的质量。质量差的软件文档不仅使读者难于明白得,给使用者造成许多不便,而且会削弱对软件的治理(治理人员难以确认和评判开发工作的进展),增高软件的成本(一些工作可能被迫返工),甚至造成更加有害的后果(如误操作等)。造成软件文档质量不高的缘故可能是:•缺乏实践体会,缺乏评判文档质量的标准。•不重视文档编写工作或是对文档编写工作的安排不恰当。最常见到的情形是,软件开发过程中不能按表5给出的进度,分时期及•时完成文档的编制工作,而是在开发工作接近完成时集中人力和时刻专门编写文档。另一方面,和程序工作相比,许多人对编制文档不感爱好。因此在程序工作完成以后,不得不应对一下,把要求提供的文档赶写出来。如此的做法不可能得到高质量的文档。实际上,要得到真正高质量的文档并不容易,除去应在认识上对文档工作给予足够的重视外,常常需要通过编写初稿,听取意见进行修改,甚至要通过重新改写的过程。高质量的文档应当表达在以下一些方面:针对性;文档编制往常应分清读者对象,按不同的类型、不同层次的读者,决定如何样适应他们的需要。例如,治理文档要紧是面向治理人员的,用户文档要紧是面向用户的,这两类文档不应像开发文档(面向软件开发人员)那样过多地使用软件的专业术语。精确性:文档的行文应当十分确切,不能显现多义性的描述。同一课题若干文档内容应该和谐一致,应是没矛盾的。⑧清晰性:文档编写应力求简明,如有可能,配以适当的图表,以增强其清晰性。完整性:任何一个文档都应当是完整的、独立的,它应自成体系。例如,前言部分应作一样性介绍,正文给出中心内容,必要时还有附录,列出参考资料等。同一课题的几个文档之间可能有些部分相同,这些重复是必要的。例如,同一项目的用户手册和操作手册中关于本项目功能、性能、实现环境等方面的描述是没有差别的。专门要幸免在文档中显现转引其它文档内容的情形。比如,一些段落并未具体描述,而用“见XX文档XX节”的方式,这将给读者带来许多不便。灵活性:各个不同的软件项目,其规模和复杂程度有着许多实际差别,不能一律看待。图6所列文档是针对中等规模的软件而言的。关于较小的或比较简单的项目,可做适当调整或合并。比如,可将用户手册和操作手册合并成用户操作手册;软件需求说明书可包括对数据的要求,从而去掉数据要求说明书;概要设计说明书与详细设计说明书合并成软件设计说明书等。可追溯性;由于各开发时期编制的文档与各时期完成的工作有着紧密的关系,前后两个时期生成的文档,随着开发工作的逐步扩展,具有一定的继承关系。在一个项目各开发时期之间提供的文档必定存在着可追溯的关系。例如,某一项软件需求,必定在设计说明书,测试打算以至用户手册中有所表达。必要时应能做到跟踪追查。程序文档合一与动态文档专门多企业差不多建立了许多庞大的运算机治理系统,而且将不断地推出新的系统。满足经营的需求须不断爱护、改造运算机系统,但同时又要不阻碍现行生产,因此必须建立一整套机制来评判、操纵和完成对系统的爱护。在软件爱护过程中,提出程序与文档合一的概念在软件开发的同时建立动态文档。程序与文档合一概念的提出一、目前软件的状况程序与文档的形式分离,不仅是用各自独立的形式存放,而且使用不同的工具在不同的时刻里书写和检索。爱护程序时不能方便地得到文档的关心,不能同步修改文档。程序与文档的内容分离,由于程序与文档采纳不同的描述,既有运算机语言也有自然语言。爱护过程中不能及时、一致地更新文档或程序,使文档不能准确地描述程序而几乎成为废纸甚至带来负面价值。软件开发与爱护的分离,绝大多数软件在设计、开发时不太考虑以后可能的修改,加大了软件爱护的难度,而且使爱护容易引入新的错误。这些分离也表现在设计、开发的不同时期的文档之间的不相容性,例如:需求分析说明书是纸上的东西,在概要设计时期不能专门好地继承、利用需求分析说明书,设计、编制概要设计时必须从零开始,需要重新分析、明白得需求分析,这种思维上的脱节,不仅延缓开发进度、加重设计人员的负担,而且由于明白得上的不同导致不同时期描述的对象有许多不相容情形。这些分离使得文档在系统的设计、开发、爱护中的作用下降,这也是专门多软件人员不情愿编写文档的要紧缘故。二、程序与文档合一的概念提出如何样才是好的文档系统呢?应当具备以下属性:能够准确地描述软件、同时简单易明白;能够迅速错误定位、阻碍分析、修正设计;能够提高软件爱护质量;能够方便程序修改时明白得程序。为此提出了程序与文档合一的概念。这概念使软件成为真正意义上的软件:程序+文档,程序确实是文档,文档集成在程序中。它要求在选择开发环境时不仅要考虑环境对设计、开发的完美支持,而且要考虑对爱护、文档的支持;它要求软件人员在设计、开发过程中要考虑爱护问题、文档问题;它要求程序与文档储备在同一位置、同一系统中;它要求使用相同工具进行程序与文档的书写、检索;它要求在编写和爱护程序的同时形成文档,在书写文档时编写、爱护程序。程序与文档合一的概念不仅存在于系统的设计、开发时期而且存在于系统的爱护时期,它贯穿软件的生命周期。动态文档系统是建立在程序与文档合一的概念基础上的、文档与程序一致的、简单易明白的联机文档系统。它包括构件说明与数据描述、对构件与构件之间、构件与数据之间的关系进行的描述。动态文档系统是提高了文档的可用性、易用性和连贯性,使文档更加有效,是解决爱护问题的有效途径。动态文档系统问题分析需要解决的问题是:软件文档的内容划分与猎取、文档的储备与爱护、文档的检索、软件文档的生成打印。一、软件文档的内容划分成:语义文档、结构文档、过程文档语义文档是对软件的功能、概念、总体设计、流程、规约等用自然语言的描述,是软件人员依照规范在使用CASE工具编写并填入程序的文档,它也是为更全面的说明文档而灵活加入的额外信息。结构文档是在软件设计工具、开发环境中对象的属性、构件间接口、构件间引用关系、软件的结构等的描述。利用词法、语法分析程序对整个系统的对象、构件进行识别、分析,猎取上述描述并形成表格文件。过程文档是对软件的设计、编码、爱护过程中形成的过程描述和程序注释,如设计目的、设计人、时刻等说明,利用开发环境对软件人员在设计、开发、爱护过程中操作的记录形成操作跟踪。二、 程序与文档的统一储备与爱护依照程序与文档合一的概念和文档从程序中提取的要求,文档必须存放在程序中,甚至文档固有的源代码中。结构如此的程序源代码的储备必须采纳一种新技术一对象仓储(Repository)技术,而不能采纳流式文件,如此才能使程序与文档既结合又分离。程序与文档结合在一个对象仓储中,结合在统一的开发环境中;结合在修改代码时能够同时修改文档、修改文档时能够同时人工检查和修改程序,并在多次文档生成而可不能丢失手工输入的文档。程序与文档应当分别存放在对象仓储中的不同表或不同的字段中,在编译与运行时分离。三、 文档的检索对单个对象、构件文档的检索方式是若于文档存放在一个对象仓储中,它能够随源代码一起检索和爱护。这种检索给分析和爱护单个构件、对象提供文档支持。建立多种视图、编写程序对整个系统进行文档的检索和猎取,完成对整个系统的分析,对整个系统进行实时文档支持。这将在例子中较详细的描述。四、 软件文档的生成打印编写程序检索和猎取整个系统的文档,按照国家软件标准的文档式样建立文档模板并将按模板生成文档和利用文字处理软件强大的功能进行创建、编辑文档并打印。依照上述分析,文档分布和猎取对开发环境提出了要求:开发环境应该是设计工具、开发工具的集成,应该基于CASE技术、对象仓储技术、构件技术、OLE技术。基于CASE技术的开发环境;设计、开发、爱护过程中形成的文档并植入程序代码中,使文档成为程序的一部分。基于对象仓储技术的开发环境,将文档与程序统一储备在对象仓储中方便检索。基于构件技术的开发环境,便于识别、猎取构件,分析、形成结构文档和过程文档。基于OLE等技术使文档能够专门好地利用Word等文档处理软件。动态文档系统的一个应用实例广州电信科技开发自行设计、开发的名为九七系统的庞大的电信治理运算机系统自1997年投产验收后,将长期用于生产,爱护工作专门重要和紧迫。这为动态文档系统提供了需求和试验场所。在长期爱护的过程中,体会到好文档的重要性并提出了程序文档合一的概念,这为动态文档系统提供了理论基础。九七系统是使用Uniface开发环境。这种开发环境采纳了CASE技术、对象仓储技术、构件技术,这为动态文档系统提供了技术支撑。一、广州电信动态文档系统的建立步骤明白得Uniface、Oracle工具的开发环境,规划语义文档在各级对象中存放的表与字段,并依照工具的特性制定填写的规则。查找结构文档、过程文档在Uniface、Oracle工具中存放的表与字段。在设计、开发和爱护软件的过程中对这些表或字段按照规则进行填写。建立一整套模板使文档结构与信息源建立映像,包括:数据字典模板、设计文档模板、结构文档模板、开发过程文档模板等。将这些模板组装成文档系统,并使它独立于开发目标系统。广州电信动态文档系统的组成能够分为文档查询、爱护记录查询、文档生成。文档查询不仅包括构件说明与数据描述,而且包括对构件与数据之间的关系的描述,是实时的联机文档查询系统。爱护记录查询是对软件爱护过程中的各个环节进程进行记录与追踪,用于规范爱护工作。它包括问题报告、问题分析、错误定位、爱护设计、爱护执行、确认测试、爱护评审、爱护提交、问题跟踪等。文档生成则是依照需要实时生成软件设计说明书。二、程序与文档合一概念与动态文档系统的意义广州电信动态文档系统的差不多任务是辅助错误定位、爱护阻碍分析、记录爱护进程、生成文档。使用Uniface的开发环境开发的,能够安装在用Uniface开发的不同的应用系统中。该系统差不多在九七计费系统的爱护中发挥重要作用。它推崇的程序与文档合一的概念,提出文档确实是程序,程序确实是文档的思路,文档融合在程序中的构思并巳实现,这一概念指导了软件人员进行有效地工作。合一的概念贯穿了设计、开发、爱护整个软件周期,保证了文档之间的继承性和一致性,在设计、开发每一时期是继承前时期的程序和文档的结果。如此极大地排除了程序与文档、文档与文档之间的不一致性,加快了软件设计进度,提高了软件开发、爱护的质量。它是软件工程在具体应用中的一种尝试,它从程序文档合一的角度动身,进一步规范软件设计、开发、爱护。程序文档合一的概念为软件开发环境进展提供了一种思路;设计更好的对象仓储来满足开发、爱护人员对程序文档合一的概念的需求。动态文档系统的局限与进展广州电信动态文档系统有专门大的局限性,只能用于Uniface或Oracle开发的系统中。目前的广州电信动态文档系统的构件的识别与猎取要紧依靠开发工具提供的构件和构件的特点进行识别的。这种动态文档系统难以在一些3GL工具一未使用对象仓储技术、构件技术开发的软件一中实现程序与文档的合一与分离。大型软件系统的环境是复杂的,往往采纳了多种开发环境,如何对其他开发环境进行支持还要进行技术探讨和实践上的摸索。另一个局限问题是目前的动态文档系统描述的是程序文档,其要紧在编码、爱护的过程中进行建设,系统进入爱护时期使用。如何使动态文档系统不仅对软件爱护时期进行支持,而且对软件的设计、开发时期进行更多的支持?一种可能的解决途径是将软件复用技术拓宽到包括文档复用,包括程序复用、程序文档复用和设计文档复用,而且将动态文档系统建立在基于这种软件复用系统之上。如何编写高质量“软件需求说明书”你的工程应该有个好的起点。一个小组要带领客户进入需求启发时期而且你要写软件需求说明书。这份说明有些大,但客户会专门重视,因此说明必须得到赞同。现在你正在设计其中的一个特性,差不多发觉了需求的一些问题。你能够用多种不同的方式说明需求15;需求9的说明正好与需求21相反,你因该相信哪一个?需求24专门模糊,你全然不明白它的意思;你不得不花上一个小时与2位开发人员讨论需求30,只因为你们对其各有各的明白得;同时,唯独能够澄清这些问题的客户没有给你们答复。你被迫破解众多需求的含义,同时你能预料到,假如你错了,你要做大量的重复工作。许多软件需求说明书(SRS)写得专门糟糕。任何产品的质量需要其原始材料的质量保证,糟糕的软件需求说明书不可能产出优秀的软件。不幸的是,几乎没有开发人员受过与需求的抽象、分析、文档、质检有关的教育。而且,没有专门多的好需求能够借鉴学习,部分缘故是专门少有工程能够找到一个好的借鉴,其他缘故是公司不情愿将其产品说明书放在公共区域。这篇文章描述了高质量需求叙述和说明的几个特性(特点)。我们将用这些观点检查一些有缺陷的需求,带着痛楚重新编写。而且我会谈一些如何编写好的需求的提示。你也许想通过这些质量标准评估你的工程需求。关于修订,也许迟了,但你会学到一些有用的东西,并关心你的小组在下次编写出更好的需求。不要期望能够编写出一份能表达需求应具备的所有特性的SRS。不管你如何细化、分析、评论和优化需求,都不可能达到完美。然而,假如你牢记这些特性,你就会编写出更好的需求,生产出更好的产品。高质量需求叙述的特性我们如何从一些有问题的需求中辨论出好的软件需求?这一节将分别介绍需求叙述应表达的6个特性,下一节将从整体上介绍SRS文档应具备的特性。判定每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金治理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试例子能够明确显现在需求中描述的产品行为(特性),能够显现缺陷、冗余和模糊之处。正确:每个需求必须精确描述要交付的功能。正确性依据于需求的来源,如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的(因此,系统需求说明书本身可能不正确)。只有用户的代表能够决定用户需求的正确性,这确实是什么缘故在检查需求时,要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的:“这是没意义的”,“这可能是他们的意思”等众所周知的推测。可行性:在巳知的能力、有限的系统及其环境中每个需求必须是可实现的。为了幸免需求的不可行性,在需求分析时期应该有一个开发人员参与,在抽象时期应该有市场人员参与。那个开发人员应能检查在技术上什么能做什么不能做,哪些需要需要额外的付出或者和其他的权衡。必要性:每个需求应载明什么是客户确实需要的,什么要顺应于外部的需求,接口或标准。每个需求源于你认可、具有权说明需求的原始资料,这是考虑必需的另外情形(译注,此句翻译不顺,请参照原文:Anotherwaytothinkof“necessary”isthateachrequirementoriginatedfromasourceyourecognizeashavingtheauthoritytospecifyrequirements)。跟踪每个需求回溯到出处,如用例,系统需求,规章,或来自其他用户的意见。假如你不能标识出处,可能需求只是个镀金的例子,没有真正的必须。优先权:为了说明在一个详细的产品版本中应包含哪些要点,需要为每个需求,特点,或用例分配实现的优先权。客户或其代理都应有强烈的责任建立优先权。假如所有的需求都被视为同等重要,那么由于在开发中,预算削减,打算超时或组员的离开导致新的需求时,项目经理将不能起到作用。优先权的作用是提供给客户的价值,实现的相关费用,实现相关联的有关技术风险。我是用3种级别的优先权:高优先权说明需求必须表达在下一个产品版本中,中优先权说明需求是必须的,然而假如需要能够推迟到晚一些的产品版本中,低优先权说明有它专门好,但我们必须认识到假如没有充足的时刻或资源,它能够被舍弃掉。明确:需求叙述的读者应只能从其得到唯独的说明说明,同样,一个需求的多个读者也应达成共识。自然语言极易导致模糊。要幸免使用一些关于SRS作者专门清晰但关于读者不清晰的主观词汇,如:用户友好性,容易,简单,快速,有效,几个,艺术级,改善的,最大,最小等等。每写一个需要都应简洁,简单,直观的采纳用户熟知的语言,不要采纳运算机术语。检查需求模糊的有效方式包括需求说明书的正规检查,依照需求写测试,建立用户的假想来说明产品某个特定部分预期的特性。可证实:看你是否能够做出测试打算或其他验证方式,如检查和实证,来决定在产品中每个需求是否正确的实现。假如需求是不可验证的,决定需求是不是正确的实现就成了判定的事。需求之间不一致,不可行,不明确也能导致不可证实。任何需求假如说产品将要支持什么也是不可证实的。高质量需求说明的特点一个完整的SRS不仅是包括长长的功能性需求列表,还包括外部接口描述和一些诸如质量属性,期望性能的非功能性需求。下面描述了高质量的SRS的一些特性。完整:不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。发觉缺少的信息专门难,因为全然不存在。在SRS中将需求以分层名目方式组织,将关心评审人员明白得功能性描述的结构,使他们专门容易指出遗失的东西。在需求抽象时,相关于系统功能,你过多的注意用户的业务,将导致在需求的全局观和引进不是真正必需的需求上显得不足。在需求抽象上,应用用例方法会发挥专门好的作用。能够从不同角度观看需求的图形分析模型也能够检查出不完整性。假如你明白巳缺少一些信息,使用TBD(tobedetermined)标准标志能够突出这些缺陷,当你在构建产品的相关部分时,就能够从一个给定的需求集中解决所有的缺陷。一致性:一致性需求确实是不要于其他的软件需求或高级别的系统(商业)需求发生冲突。需求中的不一致必须在开发开始前得到解决。只有通过调研才能确定哪些是正确的。修改需求时一定要慎重,假如只审定修改的部分,没有审定于修改相关的部分,就可能导致不一致性。可修改性:当每个需求的要求修改了或爱护其历史更换时,你必须能够审定SRS。也确实是说每个需求必须相关于其他需求有其单独的标示和分开的说明,便于清晰的查阅。通过良好的组织能够使需求易于修改,如:将相关的需求分组,建立名目表,索引,以及前后参考(照)。可追踪:你应能将一个软件与其原始材料相对应,如高级系统需求,用例,用户的提议等。也能够将软件需求与设计元素,源代码,用于构造实现和验证需求的测试相对应。可追踪的需求应该具有独立标示,细密和结构化的编写,不应过大,不应是叙述性的文字和公告式的列表。需求质量的评审这些有关需求质量的特性的描述在理论上差不多上专门好的,但一个好的需求到底是个什么模样的呢?为了表达得更切合实际,我们做个小练习。下面有几个从实际的工程选出的需求,依据上面的质量标准,评估每个需求,看看有什么问题,然后用更好的方式重写。我将对每个例子都提出自己的分析和改进的建议。也欢迎你提出不同的见解。我所占优的只是我明白每个需求的出处。因为你我都不是真正的客户,我们只能推测每个需求的意图。例1.“产品应在许多于每60秒的正常周期内提供状态信息”那个需求是不完整的:状态信息是什么,如何显示给用户。那个需求有几处模糊。我们在谈论产品的哪部分?状态信息间隔确实假定为许多于60秒?,甚者每10年显示一条新的状态信息也能够?也许它的意图是消息间隔不应超过60秒,那么1毫秒是不是太短?“每”那个词导致了不确定性。问题的后果,确实是需求的不可证实。补偿缺陷,重写需求的一种方法:1、状态信息1.1后台任务治理器因该以误差上下不超过10秒的60秒间隔,在用户界面的指定位置显示状态信息1.2假如后台进程处理正常,那么应该显示任务巳完成的百分数/比1.3任务完成时,应显示相关的信息1.4后台任务出错应该显示错误信息为了分别测试和追踪,我将其分成了多个需求。假如将几个需求串接在一节中,在构造和测试时就专门容易漏掉一个。例2.“产品应瞬时在显示和隐藏不可打印字符间切换”运算机在瞬时不能做任何事,因此那个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更换自己?或者用户为了仿照更换要做一些动作?而且,在文档中改变显示的范畴是多大:选中的文本,整个的文档,或其他的?这也是个模糊的问题。不可打印字符合隐藏字符一样吗?或者是一些属性标志或一些操纵字符?问题的后果,确实是需求的不可证实。象如此编写需求也许更好一些:“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就专门清晰,不可打印字符是HTML标记。由于没有定义触发条件,需求对设计没有约束力。只有设计人员选定了触发条件后,你才能编写测试验证触发的正确操作。例3.“HTML分析器能够产生HTML标记错误报告,关心HTML入门者快速解决错误”。单词“快速”使其模糊,没 有加进错误报告的定义也是其部完整。我不明白,你如何验证那个需求。找一个自称为HTML的入门者,看看能不能依照错误报告快速解决错误?试试那个:“HTML分析器能够产生一个错误报告,错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。假如没有错误,就可不能产生错误报告”。现在我们明白了,什么会被加到出错报告中,然而出错报告是个什么模样,则留由设计人员决定。我们还指定了一个例外:假如没有发觉错误,不产生错误报告。例4.“假如可能,主管号码应通过联机校验,而不是通过主全体主管号码列表校验”。真感到失望,什么是“假如可能”:假如技术上可行?假如主全体主管号码列表能够联机获得?要幸免象“应该”的这类不确切的词。客户是需要那个功能性依旧不需要。我曾看过一些需求说明书,采纳诸如:应,将,应该/将要等一些词描述优先级的细微差别。但我更喜爱用“应,,清晰的说明需求的意图,指明优先级。这是修改后的:系统应校验输入的主管号码而不通过联机的主全体主官号码列表。假如在列表中没有发觉主管号码,将会显示一条错误信息,也不同意指令。在明白得各个巳完成的糟糕需求上,开发人员将会遇到的难题是:开发人员与客户将会在审核需求,未达成共识前发生猛烈的争辩。详细检查大的需求文档不是一件轻松的情况。我清晰有人做过,而且他们花在检查上的每一分钟差不多上值得的。相关于开发时期和用户的埋怨,在那个时期修补缺陷是廉价的,编写质量需求的方针编写优秀的需求是没有公式化的方法的。这需要大量的体会,要从你在过去的文档中发觉的问题学习。请在组织软件需求文档时,严格遵从这些方针。句子和段落要短。采纳主动语气。使用正确的语法,拼写,标点。使用术语,要保持一致性,并在术语表或数据字典中定义它们要看需求是否被有效的定义,能够以开发人员的观点看看。在内心将“当你们做完了找我”这句加到文档尾部,看看能不能是你紧张起来。换句话说,你是否需要SRS的编写者的额外说明关心开发人员专门好的明白得需求,以便于设计和实现?假如是的话,在连续工作前,需求还需要细化。需求编写者还要努力正确地把握细化程度。要幸免包含多个需求的长的叙述段落。有关心的提示是编写独立的可测试的需求。假如你认为一小部分测试能够验证一个需求的正确,那么它差不多正确的细化了。假如你预想到多种不同类的测试,几个需求可能巳挤到了一起,需要拆分开。紧密关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中使用“和”/“或”。通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如:“关于红色合法的颜色代码应是R”及“关于绿色合法的颜色代码应是G”就有能够以分散的需求分离开,而“产品应能对来自语音编辑指示做出反应”应作为一个子系统,不应作为单个的功能性需求。幸免在SRS中过多的申述需求。在多处包含相同的需求能够使文档更易于阅读,但也会给文档的爱护

增加困难。文档的多份文本要在同一时刻内全部更新,幸免不一致性。假如你遵从了这些方针,你能够尽早地经常正式或非正式的审查需求,这些需求关于产品的构造,系统测试以及最后的客户中意,都会成为好的奠基石。同时要记住,没有高质量的需求,软件就象一盒巧克力,你永久不明白你会得到什么。国家标准局

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论