您好,欢迎访问三七文档
软件工程导论2019/11/151软件工程第4章需求工程目标了解用户需求和系统需求的概念以及这些需求要使用不同的方法表达的原因;了解功能需求和非功能需求之间的不同;需求如何组织在软件需求文档中。了解导出、分析和有效性验证等主要的需求工程活动,以及这些活动之间的关系了解需求管理的必要性,以及它是如何支持需求工程活动的22019/11/15内容功能需求和非功能需求用户需求系统需求软件需求文档需求描述需求工程过程需求导出与分析需求有效性验证需求管理32019/11/1542019/11/15需求工程对系统应提供的服务和所受到的约束的描述就是系统需求的内容对服务和约束的发现、分析、建立文档、检验的过程叫做需求工程。52019/11/15什么是需求?需求被视为对系统应该提供的服务或对系统的约束的一个高层抽象的描述,而在另一些较极端的情形下,它又被定义为是对系统功能的详细的,用数学方法的形式化描述。62019/11/15需求类型用户需求是用自然语言加图表的形式给出的关于系统需要提供哪些服务以及系统操作受到哪些约束的声明。系统需求详细地给出系统将要提供的服务以及系统所受到的约束。系统需求文档有时也称为功能描述,应该是精确的。72019/11/15用户需求和系统需求82019/11/15不同类型的需求描述的读者对象92019/11/15用户需求客户管理者系统最终用户客户工程师承包商管理者系统体系结构工程师系统需求系统最终用户客户工程师系统体系结构工程师软件开发人员4.1功能需求与非功能需求功能需求包括对系统应该提供的服务,如何对输入做出反应以及系统在特定条件下的行为的描述。在某些情况下,功能需求可能还需明确声明系统不应该做什么。非功能需求对系统提供的服务或功能给出的约束。包括时间约束,开发过程的约束,标准等。非功能需求常用于整个系统。通常不用在单个系统或服务中。领域需求这是来自系统的应用领域的需求,反映了该领域的特点。它们也可能是功能需求或非功能需求。102019/11/154.1.1功能需求功能需求描述系统所预期提供的功能或服务。它取决于开发的软件类型,软件未来的用户以及开发的系统类型。如果是用户需求,就用可以被系统用户理解的一种抽象方法来描述。若是功能性的系统需求,则需要详细地描述系统功能,输入和输出,异常等。112019/11/15MHC-PMS的功能性需求用户能够搜索到所有诊所的预约挂号单。系统每天能够为每个诊所生成一份想预约的那天就诊的病人名单。每位使用该系统的职员都可以通过他的八位雇员号码被唯一识别。122019/11/15需求的模糊性软件工程中的许多问题都源自对需求描述的不严密。系统开发者自然想把需求描述得含糊一点,这样可以简化对它的实现。考虑前面系统需求中的第一个例子“搜索”。用户意图---在所有诊所的预约单中搜索病人姓名。开发者的理解---在单个的诊所搜索病人姓名,用户先选择诊所再开始搜索。132019/11/15需求的全面与一致性理论上,系统的功能需求描述应该既全面又具有一致性。全面意味着用户所需的所有服务都应该给出描述。一致性意味需求描述不能前后矛盾。在实际过程中,对大型而又复杂的系统而言,要做到需求描述既全面又一致几乎是不可能的。142019/11/154.1.2非功能需求所谓非功能需求,是指那些不直接与系统具体功能相关的一类需求。它们与系统的总体特性相关,如可靠性,反应时间和存储空间等。换言之,它们定义了系统的约束。过程需求的例子包括在对过程中一定要用的质量标准的描述,对设计中必须使用的CASE工具集的描述以及过程所必须遵循的原则等。非功能需求可能比功能需求对系统更关键,如果一个非功能系统需求没有满足则可能使整个系统无法使用。152019/11/15非功能需求类型162019/11/15非功能性需求的实现非功能性需求会影响整个系统的体系结构,而不是个别的组件为保证系统的性能需求,就必须合理组织系统使得组件之间的通信量达到最小单个的非功能性需求,如一个信息安全性需求,会产生整个相关的功能性需求,这些功能性需求定义了新系统所要求的服务也约束现有的需求172019/11/15非功能性需求分类产品需求是叙述产品行为的需求,包括系统运行速度和内存消耗等性能需求,包括反映系统可以接受的出错率等系统的可靠性需求,包括可移植性和可用性需求。机构需求这个需求起源于客户所在的机构和开发者所在的机构中的政策和规定。包括过程标准,实现要求,交付需求等。外部需求其范围较广,包括所有系统外部因素和开发过程,包括互操作需求,法律需求,道德需求等。182019/11/15MHC-PMS中非功能性需求实例ProductrequirementTheMHC-PMSshallbeavailabletoallclinicsduringnormalworkinghours(Mon–Fri,0830–17.30).Downtimewithinnormalworkinghoursshallnotexceedfivesecondsinanyoneday.OrganizationalrequirementUsersoftheMHC-PMSsystemshallauthenticatethemselvesusingtheirhealthauthorityidentitycard.ExternalrequirementThesystemshallimplementpatientprivacyprovisionsassetoutinHStan-03-2006-priv.192019/11/15目标与需求非功能需求的常见问题是检验起来非常困难。非功能需求可能是对系统的易用性,系统的可恢复性和对用户输入的快速反应性能的要求。需求描述得不详细和不确定,会给开发者带来许多问题,在系统交付之际会在客户和开发者之间引发争议。提出了系统可用性目标和对该目标的一个可行的验证方法。202019/11/15需求可用性系统目标系统应该很好用,即使对一个没有经验的用户,而且应该使得用户错误降到最少。可检验的非功能需求对一个没有经验的用户来说,经过两个小时的培训就应该能使用系统的所有功能。在这样的培训之后,一个有经验的用户每天的出错平均数不应该超过两次。212019/11/15定义非功能需求的度量222019/11/15领域需求领域需求起源于系统的应用领域而不是系统用户的需要。它本身可能就是一个新的特有的功能需求,对已存在的功能需求的约束或者是需要实现的一个特别计算。如果领域需求不被满足,系统就不太可能让人满意地运转。232019/11/15领域需求存在的问题可理解性需求的表达使用的是一种应用领域专门的语言;对于软件工程人员来说,理解这些领域知识不是件轻松的事情。详细性领域专家可能在需求描述中对有些信息未详尽列出,他们可能认为这些内容是显而易见的,但对于系统开发人员来说却未必这样,结果就是对这些需求的实现就变得不确定了。242019/11/154.2软件需求文档软件需求文档是对系统开发者应当实现的内容的正式陈述。应该包括系统的用户需求和一个详细的系统需求描述。它不是一个设计文档.,是描述系统应该做些什么,而不是应该怎么做。252019/11/15敏捷方法和需求敏捷方法认为写需求文档是浪费时间,因为需求变化很快。因此,文档常常是过时的。XP方法是增量式的收集用户需求,并把它们作为用户故事情境写在卡片上。这种方法适合需求不稳定的业务系统,但不适合需要交付大量分析文档(关键系统)或由多个团队开发的系统。262019/11/15需求文档的用户272019/11/15需求文档内容需求文档中内容的详细程度,取决于所要开发系统的类型以及所使用的开发过程。增量式开发的系统,需求文档的细节较少。需求文档有标准的结构,如IEEE标准,适合大多数大型工程项目。282019/11/15需求文档结构2019/11/1529IEEE标准需求文档提出的结构如下:引言一般描述专门需求附录索引302019/11/154.3需求描述需求描述是在需求文档中写下用户需求和系统需求。用户需求是从用户角度来描述系统的功能和非功能需求,以便让不具备专业技术背景知识的用户能看懂。系统需求包括更多的需求细节和更多的技术信息。需求是系统开发合同的一个部分因此,需求尽可能完整是很重要的312019/11/15,系统需求描述的书写方法322019/11/15需求与设计原则上,系统需求应该仅仅描述系统的外部行为和对它的操作上的限制,而不应该包括系统应该如何设计和如何实现。实际上,需求与设计是不可分的:首先要给出系统的初始的体系结构,借助这个框架来构造需求描述。大部分情况下,系统和其他已存在的系统存在互操作。使用特别的设计是系统的一个外部需求。332019/11/154.3.1自然语言描述需求用自然语言来描述并配以相应的图表自然语言被用来表达需求,因为,它易于表达、直观且普遍使用,客户可以比较好的理解需求342019/11/15书写需求的原则设计一个标准的格式,保证所有的需求定义都按照该格式书写。使用一致的语言,来区分强制性需求和可选性需求。对文本加亮来突出显示关键性的需求。尽量避免计算机专业术语。解释需求产生的原因352019/11/15自然语言存在的问题描述不够清楚使用自然语言描述,既要精确无二义,又要保证叙述不至于晦涩难懂,这往往不容易做到。需求混乱功能需求,非功能需求,系统目标和设计信息无法清晰的区分。需求混合多个不同的需求可能被搅在了一起,以一个需求的形式给出。362019/11/15胰岛素泵软件系统中的需求实例3.2Thesystemshallmeasurethebloodsugaranddeliverinsulin,ifrequired,every10minutes.(Changesinbloodsugararerelativelyslowsomorefrequentmeasurementisunnecessary;lessfrequentmeasurementcouldleadtounnecessarilyhighsugarlevels.)3.6Thesystemshallrunaself-testroutineeveryminutewiththeconditionstobetestedandtheassociatedactionsdefinedinTable1.(Aself-testroutinecandiscoverhardwareandsoftwareproblemsandalerttheusertothefactthenormaloperationmaybeimpossible.)37Chapter4Requirementsengineering4.3.2结构化描述结构化自然语言是书写系统需求时的一种方法,需求的作者的自由受到限制,所有的需求都要以一种标准方式来书写。这个方法的好处是它保持了自然语言中的绝大部分好的性质,包括表现能力和易懂性,同时又在不同程度上对描述做了一致性的约束。对某些类型的需求是比较适合的,比如嵌入式控制系统的需求,但,某些业务系统需求这样的规定太严格了。382019/11/15格式化的描述包括定义功能或实体的描述输入及输入来源的描述输出及输出去向的描述计算所需要的信息以及系统中所使用的其他实体的信息采取的行动的描述前置和后置条件操作的副作用,如果有的话392019/11/15胰岛素泵软件的结构化需求描述402019/11/15图表描述用来补充自然语言描述。当需要表示状态的变化或需要描述行为序列的时候使用图形模型是非常有效的。例如,胰岛素泵系统根据用户胰岛素需求进行计算的,二用户胰岛素需求是根据自身血糖水平变化速率得到的。412019/11/15胰岛素
本文标题:04需求工程
链接地址:https://www.777doc.com/doc-1814308 .html