软件工程需求分析

第四章需求分析,4.1需求分析概述,需求分析的目标与任务目标：弄清用户对系统的细节要求，完整、准确、清晰、具体地回答目标系统“做什么”。任务：是对用户提出的软件功能、性能等应用问题及其环境进行分析与理解，采用一系列的分析方法和技术，把系统分析阶段产生的系统规格说明和项目规划逐步精确化、完全化、一致化，借助于当前系统的逻辑模型导出目标系统逻辑模型，最终形成需求规格说明文档的过程。具体过程：需求的获取、建模、文档、验证；,4.1需求分析概述,需求开发是技术范畴，需求管理是管理范畴。在软件工程课里通常讲述需求分析是指需求工程当中的需求开发部分需求分析=需求开发,4.1需求分析概述,需求分析的必要性软件开发是用户与开发者共同参与的过程，项目涉众人员之间必须经过充分交流；用户与开发者的知识领域不同，缺乏共同语言，存在对问题理解的歧义；软件开发失败的原因大约超过50%是需求不合理而急于编程引起的；在需求分析阶段的错误会引起错误的放大，后期发现错误时要花费更大的精力修改；,4.1需求分析概述,需求分析是RUP生命周期的“细化”阶段,产品目标,业务建模,初始阶段,细化阶段,层面：面向决策层（商务层面）活动：问题定义；可行性研究人员：领域决策人+领域专家IT决策人+IT专家,层面：面向终端用户层（应用层面）面向设计层面（技术层面）活动：获取；建模；描述；验证人员：领域专家+终端用户IT专家（分析师、架构师、设计师）,需求建模,软件结构,4.1需求分析概述,从问题定义到需求分析是个逐步细化的过程，到需求分析阶段把需求的细节搞清楚,问题定义,可行性研究,需求分析,软件规模、性质、约束,在约束条件下客户提出的软件的功能能否实现,软件功能的细节要求,对软件的要实现的功能逐步细化的过程，前者是后者的子集,4.1需求分析概述,需求分析的参与者,开发方,用户方,分析师,需求分析,设计师,架构师,部门负责,领域专家,终端用户,4.1需求分析概述,需求工程：也称需求过程或需求阶段。包括了需求开发和需求管理，所涉及到的具体工作如下图所示,4.1需求分析概述,任务讲究目标，过程要讲究方法：需求获取（需求提出）Gatheringdetailedrequirementsisthefirstpartoftheprojectlifecycle问题分析（分析建模）Theanalysisphase:Understandingwhatthecustomerwants需求说明（需求文档）Capturetherightuserrequirementswiththesebestpracticesforwritingsoftwarespecifications需求验证（需求评审）Determineuserrequirementsnowtoavoidproblemslater,4.1需求分析概述,需求获取：调查软件需求，弄清用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。手段：通过现场调查、核实、归纳，用自然语言描述。需求建模：是对现实世界进行抽象的过程。通过符号和文字说明描述系统模型使用户和开发者间建立共同语言基础，消除理解上的歧义；从原始模型分析找寻目标模型，从物理模型过渡到逻辑模型，作为设计阶段的依据；手段：采用建模语言和工具,4.1需求分析概述,需求说明：需求说明书是需求分析阶段的最终成果，也是需求分析阶段复审的依据；是用户领域专家、软件分析师、软件设计师共同交流的途径和媒介；是交付给用户文档的一部份；手段：编写文档需求评审：根据需求说明书，对需求的正确性、一致性、完整性、无二义行进行评审、确认。手段：分析师、设计师、客户会审文档,4.1需求分析概述,需求分析的步骤需求分析过程：是一个从模糊概念出发，经过分析、综合评价，到概念逐步清晰的过程。需求分析过程就是四项任务的工作流程，一般分四个步骤。需求分析四个步骤并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。,需求获取,分析建模,需求描述,需求验证,4.2需求获取,需求获取的内容分为：功能性需求:搞清系统做什么；非功能性需求:定义了系统工作时的特性(环境、性能、可靠性、安全保密性、成本消耗、资源利用、用户接口等)；需求获取的特性需求获取不是一次完成，不仅仅在分析阶段，在问题定义、可行性研究阶段都需要，是逐步深化的结果。需求获取是有层次的，不同层面的需求内容取自不同的对象，不同层面的需求写在不同的文档及章节里。需求获取的内容经过整理要写进“需求规格说明书”的“用户里，,4.2需求获取,软件需求的层次,4.2需求获取,软件需求包括三个不同的层次：业务需求；用户需求；功能需求-也包括非功能需求。业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明，通常就是“问题定义”或在SRS中的项目背景、系统目标所指（调查谁？）。用户需求(userrequirement)描述了用户使用产品必须要完成的任务，采用业务领域的术语，使用用户与开发者都能理解的语言和图形表达。如结构化的DFD图+加工说明，面向对象的用例（usecase）图+用例脚本（scenario）。它是经过调查、归纳后双方认同的结果（调查谁？）。功能需求(functionalrequirement)定义了开发人员必须实现的软件功能，用软件行业术语，通常是需求建模的结果即目标系统的逻辑模型，如结构化的功能模型、数据模型、行为模型，面向对象的类模型等（写在哪？）。特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求（非功能需求）。例子（P76）,4.2需求获取,需求获取方法需求获取是调查研究的结果，获取方法以采访、观察、座谈、对先前的系统版本的测试等。必要时采用快速原型法。先集中在使用者对系统的观点上，以收集用户原始资料，数据、工作方式、工作流程、使用要求等为工作起点，深入到部门、车间、班组，做好原始纪录；然后根据对问题及其环境的理解与软件开发经验，改正用户需求的模糊性、歧义性和不一致性，排除由于用户的片面性和短期行为所导致的不合理要求、挖掘用户尚未提出但具有价值的潜在需求，并在用户的帮助下对相互冲突的要求进行折衷，使用户需求逐步精确化、一致化和完全化；需求获取不是一次完成，不仅仅在分析阶段，在问题定义、可行性研究阶段都需要，是往复进行、逐步深化的结果。需求获取的内容经过整理形成“用户需求”最终要写进“需求规格说明书”，结果由客户确认。三步法（P77）,4.3需求建模,需求建模的意义建模就是把客观世界的领域问题模型化，通过逐步细化模型最终映射到计算机世界里。需求建模是模型化的开始。需求模型就是根据用户需求建立的目标软件的逻辑模型。需求模型起到承上启下的作用。承上：面向用户，指与领域专家的沟通，反映用户的需求。通过建立需求模型进一步清除用户需求的模糊性、歧义性和不一致性，也就是对需求获取的校验。如果需求获取不完整、不清楚，建立模型就会有所反应，甚至无法进行。这就要重新调研，完善需求获取。启下：面向设计，指需求模型作为设计阶段的输入，反映系统要实现的功能。模型细化的下一步就是设计，设计的依据就是这里的需求模型。,4.3需求建模,建模的过程建模的一般过程获得当前系统的物理模型抽象出当前系统的逻辑模型。建立目标系统的逻辑模型。,4.3需求建模,建模的方法形式化的方法，采用严格的数学模型，这种方法目前常见的是Z语言和petri网。非形式化的方法，如用自然语言、半形式化语言、图形符号、表格等方式对需求规格进行描述。形式化方法得到的需求模型更加严密和精确，容易过渡到编码，但往往难以掌握，特别是不易与用户沟通。非形式化方法的需求模型更加直观和易于理解，要通过逐步细化（映射）到编码。目前普遍应用以非形式化为主。无论采用形式化还是非形式化的、是传统的还是现代的分析方法，所遵循的原则是一样的。,4.3需求建模,非形式化的两种建模技术结构化分析建模SA（StructuredAnalysis），又分面向数据建模和面向数据流建模。主要应用技术：数据流图（DFD）；数据字典（DD）；加工说明（PESPEC）；实体关系图（E-R）；状态变迁图（STD）等。,4.3需求建模,结构化分析模型的组织结构,数据流图(DFD),E-R图,状态变迁图(STD图),加,工,说,明,控制说明,数,据,对象,说明,数据字典（DD）,4.3需求建模,非形式化的两种建模技术面型对象分析建模OOA（Object-OrientedAnalysis）主要应用视图：用例图（UseCase）；时序图（Sequence）；状态图（Statechart）；类图（Class）；构件图（Component）；部署图（Deployment）等。,4.3需求建模,面向对象分析模型的组织结构,4.3需求建模,建模过程举例通过对现实环境的调查，获得当前系统的物理模型,教务科审批2#楼D座304王老师,4.3需求建模,去掉具体模型中的非本质因素，抽取现实系统的实质，抽象出当前系统的逻辑模型。,4.3需求建模,分析当前系统与目标系统的差别，建立目标系统的逻辑模型（结构化的DFD）,4.3需求建模,面向对象的目标系统的逻辑模型（UML用例图）,4.3需求建模,建模原则必须能够表达和理解问题的数据域和功能域按自顶向下、逐层分解问题要给出系统的逻辑视图,4.4需求说明,需求说明的作用SRS(SoftwareRrquirementSpecification)是需求分析的最终结果。SRS是软件项目的一个关键性文档，主要用来描述待开发系统所要实现的功能和目标，清楚地阐述一个软件系统必须提供的功能性需求和非功能性需求以及所要考虑的限制条件。SRS是用户、分析人员和设计人员之间进行理解和交流的手段；SRS是开发者与用户间事实上的技术合同书，是制定目标系统测试和项目验收计划的依据；SRS是下一步设计和编码的基础，指导着整个系统的开发过程，如果对评审过的SRS进行任何改动就需要进行变更控制；SRS是制定初步测试计划的基础。SRS是编写初步用户手册的基础。,4.4需求说明,需求说明的质量要求SRS要达到质量要求，也是需求分析要达到明确(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable)、可跟踪（Traceability）、可修改（modifiability）等标准。正确性；无歧义性；完整性；一致性；重要性/稳定性分级；可验证性；可修改性；可追踪性；,4.4需求说明,SRS的编写在软件项目中，开发组织应该采用一种标准的软件需求规格说明的模板。现在有许多推荐的软件需求规格说明模板可以使用，这里介绍一种由IEEE标准830-1998改写并扩充的模板。国家标准委员会于2008年在第6号公告中又发布了GB/T9385-2008计算机软件需求规格说明规范，是最新的SRS文档编制指南，见本书的电子资料附录。引言综合描述（任务概述、项目概述)功能需求(需求模型)外部接口非功能需求（性能需求）其它需求,4.4需求说明,引言1.1编写目的:说明编写需求规格说明书的目的.1.2背景说明:软件产品的名称,项目的提出者、开发者及用户，软件产品能做什么。1.3预期读者：列举本说明所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。描述了文档中剩余部分的内容及其组织结构，建议每一类型读者最适合的阅读文档章节。1.4术语定义:列出文档中所用的专门术语的定义、缩写、略语等.1.5参考资料:列出文档所引用的全部资料.,4.4需求说明,综合描述这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。2.1产品描述：描述了软件需求规格说明中所定义的产品的背景和起源。考虑的问题有：系列产品；改进产品；替代品；新型的；子系统。2.2产品功能：概述了产品所具有的主要功能。其详细内容将在3中描述，所以在此只需要概略地总结，例如用列表的方法给出。很好地组织产品的功能，使每个读者都易于理解。用图形表示主要的需求分组以及它们之间的联系，例如总体框图、顶层数据流图或类关系图。,4.4需求说明,2.3用户特征：对用户的受教育程度、行业工作经验、计算机知识水平等因素对用户进行分类，即什么样的操作需要什么样的水平。以免用户对产品感到失望。2.4运行环境：描述了软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。2.5限制说明：叙述对系统设计产生影响的限制条件或特殊需求的理由,如管理模式、硬件限制、与其它应用系统的接口、安全保密等。2.6假设和依赖：列举出在对软件需求规格说明中影响需求陈述的假设因素，以及项目对外部因素存在的依赖。,4.4需求说明,功能需求该部分是SRS的灵魂。需求分析核心工作由此体现3.1功能描述（功能模型）：详列出系统的详细功能需求。这也是必须提交给用户的软件功能。注意：与2.2（产品功能）的区别，2.2是罗列而展示全貌，这里是具体详实的操作功能。3.2数据描述(数据模型)：实体关系图（ER），数据的逻辑模型。3.3状态描述（行为模型、动态模型）：对于实时系统是必须的。,4.4需求说明,外部接口4.1用户接口:（用户界面）描述屏幕格式、报表或菜单的页面格式及内容、功能键等；对于用户界面的细节，例如特定对话框的布局，应该写入一个独立的用户界面规格说明中，而不能写入软件需求规格说明中。4.2硬件接口:描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。4.3软件接口:该软件与其它软件之间的接口。描述该产品与其它外部组件（由名字和版本识别）的连接，包括数据库、操作系统、工具、库和集成的商业组件。明确并描述在软件组件之间交换数据或消息的目的。描述所需要的服务以及内部组件通信的性质，确定将在组件之间共享的数据。4.4通信接口：描述与产品所使用的通信功能相关的需求，包括电子邮件、Web浏览器、网络通信标准或协议及电子表格等等。定义了相关的消息格式，规定通信安全或加密问题、数据传输速率和同步通信机制。,4.4需求说明,非功能需求5.1性能需求阐述了不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员作出合理的设计选择。确定相互合作的用户数或者所支持的操作、响应时间以及与实时系统的时间关系。5.2安全设施需求详尽陈述与产品使用过程中可能发生的损失、破坏或危害相关的需求。定义必须采取的安全保护或动作，还有那些预防的潜在的危险动作。明确产品必须遵从的安全标准、策略或规则。5.3安全性需求详尽陈述与系统安全性、完整性或与私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。定义用户身份确认或授权需求，明确产品必须满足的安全性或保密性策略。5.4软件质量属性详尽陈述与客户或开发人员至关重要的产品质量其它特性，这些特性必须是确定、定量的并在可能时是可验证的。如产品的易用程度、执行速度、可靠性、当发生异常情况时，系统如何处理。这些被称为软件质量属性(或质量因素)的特性，是系统非功能（也叫非行为）部分的需求。5.5业务规则列举出有关产品的所有操作规则，例如什么人在特定环境下可以进行何种操作。这些本身不是功能需求，但它们可以暗示某些功能需求执行这些规则。5.6用户文档列举出将与软件一同发行的用户文档部分，例如用户手册、在线帮助和教程，明确所有已知的用户文档的交付格式或标准。,4.4需求说明,SRS是说明由软件获得的结果，而不是获得这些结果的手段。避免将需求与项目、与设计的界限混淆。表述具体需求功能可以用若干种方法来表达可参考的模板有多种，不管使用哪个模板，SRS文档结构中要反映出业务需求、用户需求、功能需求的三个层次。,4.4需求说明,SRS与需求层次,需求模型的细化,非功能能需求,综合描述（任务概述项目概述项目背景系统目标）,SRS主要章节：综合描述功能需求非功能需求其它需求,4.4需求说明,一个字处理程序为例说明需求层次业务需求：“能有效地纠正文档中的拼写错误”；用户需求：“用户检查拼写错误时，提示文档中拼写错误的单词并通过一个提供的替换项列表来供选择替换拼错的词”。功能需求：找出拼写错误单词；定位并高亮提示错词；显示提供替换词的对话框以及实现整个文档范围的替换。所有的用户需求必须与业务需求一致，功能需求必须满足用户需求，而开发人员则根据功能需求来设计软件以实现必须的功能。,4.4需求说明,书写规格说明的困惑先进行开发然后再写需求规格说明；规格说明往往写的过于简单；不知道如何反映需求的三个层次，写在规格说明书什么章节。对逐步求精理解不够，认为许多内容是重复。软件需求规格说明的模板不统一，不知采用哪个为好。如需求分析的核心内容是建立需求模型，也是教材和教学的重点内容，但建模的结果写在SRS哪个章节里？不同的SRS模板说法不同，有的模板甚至无处表述。很难找到公开的、可以参照的范文。IT企业有自己的模板但不公开，也未必规范，但内部使用没有问题。,4.5需求评审,需求评审的作用需求说明书描述几乎都是自然语言，这种非形式化的语言容易出现不准确、冗余、遗漏和理解不一致等问题。对规格说明书的审查是必须的，确保需求说明准确、完整地、清晰、无二义地表达产品的功能和质量要求。需求评审是为了及早消除隐藏的错误，经验和研究表明，在需求开发阶段纠正这个错误会节省相当多的时间和金钱。评审是需求分析的最后一步，通过评审后的需求文档才可以生效。,4.5需求评审,评审标准需求规格说明的质量特性作为评审的标准正确性完整性一致性无二义性可修改性可跟踪性可验证性,4.5需求评审,正确性：对系统功能、行为、性能等的描述必须与用户的期望相吻合，代表了用户的真正需求。完整性：需求规格说明应该包括软件要完成的全部任务，不能遗漏任何必要的需求信息，注重用户的任务而不是系统的功能将有助于你避免不完整性一致性：需求规格说明对各种需求的描述不能存在矛盾，如术语使用冲突、功能和行为特性方面的矛盾以及时序上的不一致等可修改性：格式和组织方式应保证后续的修改能够比较容易和协调一致。我们可以使用软件工具，或者使用目录表、索引和相互参照列表等方法使软件需求规格说明更容易修改。可跟踪性：可跟踪性意味着每项需求都能与其对应的来源、设计、源代码和测试用例联系起来。可验证性：描述的需求都可以运用一些可行的手段对其进行验证和确认。,4.5需求评审,需求评审方法规格说明书评审：分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核。可以有：用户评审和同行评审：用户验收的标准则是依据需求规格说明书中的内容来制订，所以用户评审是第一位的；而同行评审是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。正式与非正式：非正式评审多少有些同行切磋的性质，根据个人爱好的方式，不拘时间，不拘形式；正式评审除软件开发人员外，还邀请用户代表和领域专家参加，通常采用答辩形式，与会者有备而来(即提前审阅了文档)，分析人员在做详细说明后，答复与会者的问题并记下各种重要的评审意见。这种评审方式应对事不对人，防止把评审变为质询或辩论。评审规格说明时配合演示原型是个重要的辅助方式，通过对模型的运行，评审人员可以了解系统是否满足需求，模型的运行也可揭示出需求文档中的错误和遗漏。,4.5需求评审,编写辅助文档也属需求验证初始测试用例：根据用户需求所要求的产品特性写出黑盒功能测试用例。通过使用测试用例以确认是否达到了期望的要求，从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。初始用户手册：在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析。,4.5需求评审,评审规格说明需要考虑的问题是否所有的分配需求都在SRS中体现?在SRS中定义需求时,是否避免使用那些引起歧义的术语,诸如也许,可能,每条需求都清晰无歧义?是否在SRS中清楚地描述了软件要做什么及不做什么?是否在SRS中描述了软件使用的目标环境,指明并简短描述了目标环境中其他相关软件产品/子系统/模块?是否每个需求有唯一的编号?每个需求是否切实可行,可测试,前后一致,彼此不冲突?是否在SRS中说明了对每个输入的验证措施,并描述了每个输入的属性如:度量单位,边界值,时序要求等等?是否在SRS中说明了对每个输入的处理?是否在SRS中说明了每个输入项是如何输出的,并描述每个输出的属性如:度量单位,边界值,时序要求?,4.5需求评审,是否在SRS中描述了软件的所有的性能要求?是否性能需求的描述能通过测试来验证?是否在SRS中说明了所有对系统的可能的约束?质量属性是否以可测量或可验证的术语进行描述?是否在SRS中描述了系统中与子系统,模块或硬件设备的相关的接口?是否对每个接口的描述足够清楚,实现时不需要多于的解释?是否在SRS中描述了与操作系统的接口?是否在SRS的附录中记录了分配需求可行性的分析结果?是否项目SOW文档所对应的分配需求都在RTM中体现?RequirementsTraceabilityMatrix（需求跟踪矩阵）StatementofWork(工作说明),4.5需求评审,需求举例需求文档陈述与改进举例-1,产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不得小于60秒。,改进,后台任务管理器(BTM)应该在用户界面的指定区域显示状态消息。a.在后台任务进程启动之后，消息必须每隔60(10)秒更新一次，并且保持连续的可见性。b.如果正在正常处理后台任务进程，那么后台任务管理器(BTM)必须显示后台任务进程已完成的百分比。c.当完成后台任务时，后台任务管理器(BTM)必须显示一个“已完成”的消息。d.如果后台任务中止执行，那么后台任务管理器(BTM)必须显示一个出错