河北工业大学软件工程课件

内容软件工程主要的研究内容；软件工程相关的几个关键问题；职业与道德责任对软件工程的重要意义。1软件工程的研究内容几个与软件工程相关的现象（1）：几乎所有发达国家的经济发展在很大程度上都依赖软件产业的发展。越来越多的系统由软件来控制，软件在生产生活中扮演着越来越重要的角色。在发达国家中软件在GNP中占有相当的比重。软件工程要考虑专业软件开发所需要的理论、方法和工具工程技术问题软件工程的研究内容几个与软件工程相关的现象（2）：在计算机系统中软件成本通常占优—一台PC机中软件成本早已超过硬件成本。在软件生命周期中用于维护的软件成本通常会大于开发成本对于生命周期很长的软件系统，维护成本有时会达到开发成本的几倍。软件工程要考虑如何有效的在软件开发中利用有限的成本资源工程管理的问题2软件工程相关的关键问题什么是软件?什么是软件工程?什么是软件过程?什么是软件过程模型?什么是软件生命周期?谁会参与软件工程?什么是软件工程方法?软件工程相关的关键问题什么是CASE(Computer-AidedSoftwareEngineering)优良软件的属性是什么?什么是软件工程面临的主要问题?2.1什么是软件?软件的发展早期阶段（20世纪50年代初-60年代中期）

面向批处理、有限分布、自定义；第二阶段（20世纪60年代中-70年代中期）

多用户、实时、数据库、软件产品；第三阶段（20世纪70年代中-80年代中后期）

分布式系统、嵌入“智能”、硬件成本降低；第四阶段（20世纪80年代中-至今）

桌面系统、面向对象技术、专家系统、人工神经网络。

2.1什么是软件?计算机程序和相关的文档（如需求文档、设计模型和用户手册等）。软件包括：①能够提供客户所需功能与性能的计算机程序；②使程序能够适当的操作信息的数据结构；③用以描述程序开发过程及使用的文档。2.1什么是软件?软件产品可以为一个特定的用户设计开发，也可以为某一类通用的市场设计开发。软件产品可以分成：通用软件（GenericSoftware）定制软件（BespokeSoftware）一个新的软件并不一定是全新开发，可以由现有软件或可复用软件成分配置形成。模糊软件的特征软件是逻辑的而不是物理的；软件只有设计过程，不存在传统意义的制造过程；软件产品不存在“磨损”的问题；软件开发必须依赖硬件与操作系统；大多数软件是为定制全新开发的，而不是由现有组件装配完成的。软件危机软件危机指的是软件的发展过程中出现的一系列严重的问题，如开发效率低下、成本高、可维护性差。出现于20世纪60年代后期。例子：来自于IBMConsultancyGroup的数据：(Included24leadingcompanies)55%软件项目成本超预算；68%的项目不能按进度计划完成；88%不得不进行大量的返工。

是什么导致了软件项目的失败?Factors %1.不完全的需求描述 13.1%2.缺少用户参与 12.4%3.资源的短缺 10.6%4.不现实的期望 9.9%5.行政支持的缺乏 9.3%6.不断变化的需求 8.7%7.缺乏合理的规划 8.1%8.过短的生命周期 7.5%9.缺乏科学的项目管理 6.2%10.技术缺陷 4.3%11.其它 9.9%Source:StandishGroup19952.2什么是软件工程？软件工程是涉及软件生产各个方面的一门工程学科软件工程涉及软件生命周期的各个方面，从软件需求的确定到软件退役。软件工程还涉及软件开发中的人为因素，如团队组织；经济因素，如成本估算；法律因素，如版权保护。软件工程：（1）将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件；（2）研究（1）中的方法.

——IEEE[IEE93]2.2

什么是软件工程？2.2什么是软件工程？软件工程是一门旨在指导生产”无缺陷”软件的学科，既指导如何生产能够及时交付、成本不超预算并且满足用户需求的软件产品。软件工程人员应该采用系统的、有组织的工作方法，并按照所要解决的问题、开发约束和可用资源来选择适当的工具与技术。2.3什么是软件过程？软件过程是指开发或制作软件产品的一系列活动及其成果.所有的软件过程中都包括四个基本活动:描述（Specification）-系统应该提供的功能及其开发约束；开发（Development）-软件产品的生产过程；有效性验证（Validation）-检验软件产品是否满足了客户的需要；进化（Evolution）-按照用户的变更要求不断的改进软件。2.4什么是软件过程模型？软件过程模型是从一个特定的角度对软件过程的简化描述。几种软件过程模型：工作流模型-sequenceofactivities;数据流模型-informationflow;角色/动作模型-whodoeswhat.通用的软件过程模型： 瀑布模型;进化式开发模型;基于组件的软件工程（CBSE）。2.5什么是软件生命周期？软件生命周期是软件过程的另一种形象描述，包括：(1)需求定义

Identifytheneedsoftheusersbyinterviewingthem.(2)分析与描述

Describewhatthesoftwaresystemshoulddotomeettherequirements.(3)设计

Describehowthesystemshould performtherequiredtasks.2.5什么是软件生命周期？(4)实现

Programvariousmodulesofthesystem.(5)集成（测试）

Combinethemodulesandverifythatthewholesystemworkscorrectly.(6)维护

Maintaintheoperationofthesystem, removebugsastheyarediscovered.(7)退役

Migratetoanewsystem.相对成本软件生命周期各阶段的相对成本[Grady1994]Maintenanceissoexpensive—amajoraspectofsoftwaredevelopmentconsistsoftechniques,tools,andpracticesthatleadtoareductioninmaintenancecost2.6谁是软件工程的参与者?2.7什么是软件工程方法？软件工程方法是软件生命周期中使用的一整套技术方法的集合，包括系统模型描述、约束规则、设计建议和过程指南等组成元素。普遍采用的软件过程方法：结构化方法面向对象方法2.8什么是CASE(Computer-AidedSoftwareEngineering)？CASE是一些用于支持软件过程活动的自动化、半自动化的软件系统CASE通常分为两个层次：高层（高端）CASE，用于支持软件过程早期的分析与设计，如报告生成器、符号编辑器；低层（低端）CASE，用于支持后期的实现与测试，如代码生成器、调试器、测试用例生成器。2.9什么是优良软件的属性？优良的软件应能交付相应的功能与性能，而且应具有良好的可维护性、可依赖性、有效性和可用性：可维护性（Maintainability）可依赖性（Dependability）有效性（Efficiency）可接受性（Acceptability）2.10什么是软件工程面临的主要问题21世纪软件工程面临三大挑战：异构：如何使软件在异构的平台与执行环境下构建与移植；交付：如何快速有效的交付软件产品；信任：如何提高软件的可信任程度。

——IanSommerville3职业与道德责任软件工程所涉及的不仅仅是技术应用，还包括许多职业与道德责任。软件工程师必须坚持正直诚实的行为准则。道德行为不仅仅是通过遵守法律来约束。职业与道德责任保密工作能力知识产权计算机滥用要点软件工程是一门工程学科，涉及软件生产的各个方面.软件产品包括所开发的程序和相关的文档，软件产品的基本属性是可维护性、可依赖性、有效性和可用性。软件过程包括开发软件产品的一系列活动。基本的活动包括软件描述、开发、有效性验证和进化。软件方法是软件生产的组织方式，包括对软件过程的建议、使用的标记、进行系统描述的规则和设计指南。要点CASE工具是一些能够支持软件过程活动的软件系统，如编辑设计图表、检查程序的一致性和追踪已运行的程序测试。软件工程师对软件工程这一职业和社会负有责任，不应该只关心技术问题。思考1、软件工程是一门工程学科，它把工程理论与技术应用于软件开发，规范软件的开发过程，提高软件的开发质量。请思考：传统工程学科如机械工程、电子工程中的工程理论能否直接应用于软件工程？只依靠工程理论与技术能否解决软件开发中的所有问题？2、了解了软件工程的一些基本概念，你对软件的理解有了哪些不同？思考第二讲软件过程

（SoftwareProcesses）WelcometoSoftwareEngineeringLecture2目标了解软件过程与软件过程模型的概念；掌握四种一般的过程模型及它们的适用情况；掌握软件需求工程、软件开发、软件测试及软件进化所涉及的主要活动；了解软件复用的思想和基于构件的软件开发的一般过程了解Rational统一过程模型的基本特点。内容1.软件过程模型2.过程活动3.基于构件的软件工程4.Rational统一过程软件工程——一种层次化技术SoftwareEngineeringSoftwareEngineering“quality”focusprocessmethodstools过程、方法和工具软件过程与软件过程模型

软件过程指包括了软件生产设计的一系列活动，基本活动包括：Specification;Development(DesignandImplementation);Validation;Evolution.一个软件过程模型是软件过程的一种抽象表示，它通常是对软件过程某一特定方面的抽象描述。1软件过程模型介绍几种常见的一般过程模型：瀑布模型（Thewaterfallmodel）进化式开发（Evolutionarydevelopment）增量式开发螺旋式开发1.1瀑布模型（顺序模型）1.1瀑布模型（顺序模型）A.k.a.:ClassicLifeCycle1.1瀑布模型（顺序模型）瀑布模型各阶段需求定义与分析系统和软件设计实现和单元测试集成与系统测试运行和维护反馈表示在软件开发过程中要针对一些具体情况做一些适应性调整。瀑布模型的缺点和适用情况这种模型生硬的把一个软件过程划分成几个界限清晰的阶段，而且这些阶段前后有严格的顺序，这导致它很难对用户的需求变更做出及时的调整；因此，瀑布模型只适合需求非常清楚和需求变更被严格限制的情况下。

实际的软件开发过程中，几乎没有多少业务系统具有稳定的需求。瀑布模型反映了工程设计的基本思想。

1.2进化式开发模型基本思想：通过开发系统原型和用户反复交互，以明确需求，使系统在不断调整与修改中得以进化成熟。又叫做原型式开发方法。两种基本类型：探索式开发;抛弃式原型法.1.2进化式开发模型框架描述描述开发有效性验证初始版本最终版本中间版本中间版本中间版本并行活动问题缺乏过程可见性;系统结构通常会很差;需要一些特别的技术（如原型快速开发技术），通常与主流技术不兼容.适用情况适合中小规模的交互系统;可用于大型系统的局部开发（如系统界面），可以和瀑布模型混合使用；生命周期较短的系统。1.2进化式开发模型1.3基于过程反复的过程模型对于大型项目而言，系统需求的变更是无法避免的，因此开发过程的反复是软件开发的必要手段；过程反复可以和任何一种一般过程模型结合使用。两种支持过程反复的过程模型：增量式开发；螺旋式开发。增量式开发这种开发方式不把系统作为一个整体交付，而是把系统分解成为若干个增量，每个增量交付系统部分功能；用户需求按优先级进行排序，优先级最高的需求有最早交付的增量来完成；一旦增量进入开发阶段，其需求的变更便被“冻结”，而同时后续的增量的需求分析可以同步进行。增量式开发增量式开发的特点分析分析分析分析设计设计设计设计编码编码编码编码测试测试测试测试增量1增量2

增量3增量4

软件功能项目时间增量1发布增量3发布增量2发布增量4发布增量式开发的特点分析分析设计设计编码测试编码测试测试增量1增量2

分析设计编码增量3分析设计编码测试增量4

软件功能项目时间增量1发布增量3发布增量2发布增量4发布增量式开发的特点由于每个增量可以交付部分系统功能，因此软件可以较早的交付用户使用（部分功能）；早期交付的增量可以作为后期增量的原型帮助后期需求的确定；项目总体的失败率较低；优先级最高的系统功能得到最多的测试。螺旋式开发这种模型用螺旋线表示软件过程，而不是采用一系列活动及活动间的反馈；螺旋中的每个回路表示软件过程中的一个阶段；这种模型充分考虑了软件开发所面临的风险，并贯穿软件过程始终。螺旋模型螺旋模型螺旋线划分成四部分目标设置风险评估和规避开发与有效性验证规划2.过程活动软件描述（SoftwareSpecification）软件设计和实现（SoftwareDesignandImplementation）软件有效性验证（SoftwareValidation）软件进化（SoftwareEvolution）2.1软件描述软件描述（需求工程）要确定软件系统要实现的功能及系统开发与运行过程中要遵循的一些约束。需求工程过程包括：可行性研究；需求导出与分析；需求描述；需求有效性验证。需求工程过程2.2软件设计与实现这个阶段要把需求工程得到的系统描述转换成可执行的系统。软件设计设计符合软件描述的系统架构和细节构成，形成完整的系统解决方案。实现把“设计蓝图”翻译成可执行程序。设计与实现的活动常常是紧密联系在一起的，很多时候是交替进行的。设计过程活动体系结构设计抽象描述接口设计组件设计数据结构设计算法设计软件设计过程程序设计与调试程序设计与调试是把设计翻译成程序并且在程序中排除错误的过程；程序设计因人而异，通常没有统一的设计模式；程序员通常要负责对自己编写的程序进行检验（单元测试），从程序中定位错误并改正（调试）。调试过程2.3软件有效性验证检验（Verification）和有效性验证（validation）是要检验系统是否符合它的规约描述的符合程度以及系统是否符合客户的预期目标。包括检查、评审和系统测试的过程。系统测试主要是采用测试用例来执行程序，测试用例是按照系统规约描述设计的系统可能处理的实际数据及预期结果。测试过程测试过程中的阶段组件（或单元）测试Individualcomponentsaretestedindependently;Componentsmaybefunctionsorobjectsorcoherentgroupingsoftheseentities.集成测试Testingofthesystemasawhole.Testingofemergentpropertiesisparticularlyimportant.验收测试Testingwithcustomerdatatocheckthatthesystemmeetsthecustomer’sneeds.测试阶段2.4软件进化软件的特点使得软件具有灵活性和易变性；由于需求会随着业务环境发生变化，用于支持业务活动的软件系统必须进行进化与变更。软件过程通常会把软件开发与软件维护划分为两个阶段，但完全从头开发的系统已经越来越少，所以把系统的开发与维护开成一个连续的过程更有意义即软件进化。系统进化Exercise3基于构件的软件工程基于组件的软件工程是一种面向软件复用的软件开发方式，这种方式中，软件产品是由现有软件组件或COTS(Commercial-off-the-shelf)系统组装而成.过程阶段组件分析;需求修订;应用复用的系统设计;开发与集成。Thisapproachisbecomingincreasinglyusedascomponentstandardshaveemerged.3.1

软件复用与软构件的基本思想软件复用的定义软构件的概念软件复用的意义1）软件复用的定义正式提出：1968年，D.Mcllroy在国际上首次讨论软件工程的国际会议上建议建立生产软组件的工厂，用产品目录上的软组件构成复杂系统，以作为解决软件危机的一种的一种可能技术途径。软件复用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素（通常称为可复用构件、组件或软部件）的过程。软件复用通常指复用“为了复用目的而设计的软件”的过程。2）软构件的基本概念软构件的类比软件IC!?软件标准零部件!?2）构件的基本概念构件是为组装服务的！软件构件是指可以独立生产、获取和部署的、可以被组装到一个功能性系统中去的可执行单元。软构件是标准的、可以互换的、经过装配可随时使用的软件模块。3）软件复用的意义软件复用的出发点是使软件系统的开发不再“一切从零开始”，能够充分利用已有的知识和经验。软件复用是在软件开发中避免重复劳动的解决方案。通过软件复用，能够充分利用已有的开发成果，消除软件开发个阶段的重复劳动，可以提高开发效率，见地开发成本。软件复用还可以避免全新开发可能引入的错误，从而提高软件的开发质量。4）软件复用技术的发展历史1968年的NATO软件工程会议上，Mcllroy在提交会议的论文《大量生产的软件构件》中，提出了“软件组装生产线”的思想。70年代中：软件工厂研究实验80年代后期:构件库系统与构件分类技术的研究取得进展的方面：可复用构件的创建与分发、复用支持环境、公司级复用计划。问题：复用范围太狭窄，没有达到预期的在软件生产力和质量上的重大提高。提出对软件复用的广义理解。90年代：系统化复用对软件体系结构的认识对过程的改进复用业务组织90年代，基于构件的软件开发方法的研究和应用开始兴起。“构件化开发方法的兴起是源于面向对象开发方法在软件复用方面的受到的挫折。”

IanSommerville3.2基于构件的软件开发技术1）软构件技术的产生2）软构件的基本形式构件是可被用来构造其他软件的软件成分，基本形式可以是：被封装的对象类类树功能模块软件框架（framwork）软件架构（或体系结构Architecture）文档分析件设计模式等3）基于构件的软件工程（CBSE）由两部分组成：制造软件构件的技术(属于领域工程)。使用软件构件的技术,也称“基于构件的软件开发”。(ComponentBasedSoftwareDevelopment,CBSD）基于构件的软件工程需求描述组件分析需求修订基于复用的系统设计开发与集成系统验证VSCBSE过程模型构件生产线系统生产线

构件开发分析设计编程测试

领域分析系统测试构架细化

构件提交领域知识领域专家经验现有系统资料领域构件需求构件/构架库领域构架领域构件系统开发系统专用构件应用系统领域构架领域构件问题域用户需求

专用构件开发分析设计编程测试系统组装

分析设计编程4.Rational统一过程（RUP）RUP是Rational在提出UML后开发的统一过程模型，是基于UML及相关过程的一种现代过程模型。RUP一般从三个视角来描述过程：动态视角；静态视角；实践视角。RUP阶段模型RUP阶段模型RUP各阶段初始Establishthebusinesscaseforthesystem.细化Developanunderstandingoftheproblemdomainandthesystemarchitecture.构造Systemdesign,programmingandtesting.转换Deploythesysteminitsoperatingenvironment.RUP的好的实践反复地开发软件管理需求使用基于组件的体系结构可视化模型软件验证软件质量控制软件变更要点软件过程指软件系统生产与进化的一系列活动；软件过程模型是软件过程的抽象表示；软件过程基本的过程活动包括软件描述、软件开发、软件有效性验证和软件进化；四种一般过程模型：瀑布模型、进化式软件开发、增量式开发和螺旋模型；需求过程是开发软件描述的过程；设计与实现把软件描述转换成一个可执行程序；要点有效性验证要检查系统是否符合规格描述和用户需求；进化考虑如何在软件投付使用后修改完善软件的问题；软件复用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素（通常称为可复用构件、组件或软部件）的过程。基于构件的开发方式是采用大量可复用构件组装系统的开发方法。RUP是一个现代的一般过程模型；Exercise查找资料，了解敏捷开发与极限编程的基本思想及其与传统软件开发过程的区别，下节课讨论！

第三讲需求工程

（RequirementsEngineering）WelcometoSoftwareEngineeringLecture3目标了解需求工程的主要活动及它们之间的关系；掌握有关需求的基本知识；掌握需求导出和分析的一些技术；了解结构化分析的基础知识和基本方法；重点掌握基于UML建模的面向对象分析方法了解需求有效性验证及如何进行需求评审；了解需求管理的必要性以及它如何支持其它需求工程活动。内容可行性研究需求分析基础需求导出与分析结构化分析基础UML与面向对象分析方法需求有效性验证需求文档需求管理恐怖的噩梦一个棘手的项目终于接近了尾声，作为项目经理的你坐在办公室舒展着紧张了几个月的身躯，头脑中盘算着如何让客户痛快的付清合同款。这时，客户走进你的办公室，坐下，直视着你的眼睛说道：“我知道你认为你理解我说的是什么，但你并不理解我所说的并不是我想要的。”需求工程过程需求工程过程并不具有唯一的模型，按照不同的应用领域、不同的客户与开发团队，需求工程的过程有很大的差异。然而，在所有的过程中都会涉及一些共同的活动，它们是：可行性研究(feasibilitystudy)；需求导出与分析(elicitationandanalysis)；需求描述(specification)；需求有效性验证(validation)；需求管理(management)。需求工程过程需求工程1.可行性研究可行性研究要决定被提议的系统是否值得去做。可行性研究过程较短，焦点集中在以下几个问题：系统的开发是否符合组织的总体目标？系统是否可能在现有的技术和预算限制内完成？系统能否与已存在的其它系统相兼容？进行可行性研究进行可行性研究包括信息评估、信息汇总和书写报告三部分工作。信息的评估与汇总需要分析人员与Stakeholders相沟通，通过提出问题汇总信息，可能提出的问题包括：如果系统没有实现，机构将如何应对？当前处理过程存在哪些问题？新系统将如何处理？系统将对业务目标有什么直接的贡献？系统需要和哪些系统相集成？需要使用新技术吗？使用那些技术？对待开发系统感兴趣和直接或间接从系统中获益的人2.需求分析基础2.1什么是需求？定义不一致需求具有双重功能：IanSommerville可以作为竞标、签约的基础一种开放的、易于交流的系统功能及约束的高层概要描述；签约之后，为了完成合同约定，开发者给出的对系统的详尽、准确的描述。两种描述都叫做需求文档，分别对应于用户需求和系统需求。2.2需求的类型用户需求从客户的角度，采用自然语言配合以图表对目标系统应提供的服务以及系统操作要受到的约束进行的声明。系统需求系统需求是一种结构化文档，要运用一些专业的模型详细的描述系统的功能及其约束。系统需求文档有时也称为功能描述，应该是精确的，它可以成为双方之间合同的重要内容，同时作为开发工作的依据。需求定义与描述用户需求定义1.LIBSYS应该能够管理全国及其他地区的版权代理商所要求的全部数据。系统需求描述1.1向LIBSYS申请建立一个档案的时候，系统应该用一个表格来记录申请者及他所提出的申请的详细情况；1.2LIBSYS申请表格应该从提交的日子开始在系统中保存5年；1.3LIBSYS申请表格必须能够由用户根据请求材料的名称和申请人来进行索引；1.4LIBSYS应该能够维护一个已经被系统处理的所有申请的日志；1.5对于作者提供出借权的材料，系统应该按月向已经在系统注册的版权代理商提供详细的出借信息。2.3功能需求与非功能需求功能需求对系统应提供的功能，系统在特定的输入下做出的反应及特定条件下的行为的描述。某些情况下还要包括系统不应做什么。非功能需求对系统提供服务或功能时收到的约束进行描述。如时间约束、开发过程约束和标准等。领域需求这种需求来自于系统的应用领域，反映领域特征。可能是功能需求也可能是非功能需求。2.3.1功能需求功能需求描述系统所应提供的功能或服务。取决于待开发软件的类型、未来的用户以及开发的系统类型。功能性的用户需求只需要对系统应提供的服务进行高层一般描述，对于系统需求，则应该详细的描述系统功能、输入输出及异常。功能需求描述例：图书馆系统（

LIBSYS）

该图书馆系统要提供一个界面，使顾客能够访问多个图书馆不同的文献数据库中的资料。允许用户出于个人学习的目的对文献资料进行搜索、下载和打印。功能需求描述用户可以从总的数据库中进行查询，也可以从其中一个子集中查询；系统应提供一个适当的浏览器供用户阅读馆藏资料；每次借阅应该对应一个唯一标识符(ORDER_ID)。通过这个标识，可以允许用户把文献拷贝到常备存储区。不严密问题当需求被不严密的表述时，会产生很多问题。一些不明确、不准确的表述可能会使用户与开发者有不同的理解。思考上例中的短语“适当的浏览器”，如何理解？用户的理解

开发者的理解需求的全面性和一致性原则上，功能性需求描述应该具备全面性和一致性。全面性包括了所有用户要求的服务。一致性在系统服务的描述中没有冲突和矛盾Inpractice,itisimpossibletoproduceacompleteandconsistentrequirementsdocument.2.3.2非功能性需求非功能需求不直接和功能相关，但定义了实现系统功能受到的约束与系统特性。如可靠性、响应时间、存储空间、I/O设备能力等。非功能需求还常与系统的开发过程有关，表现为过程需求。如设计必须实用的特定CASE工具集、设计语言和开发方法。Whichoneismorecritical?俺当上白领儿了？也该买辆车了！先生，我们的汽车配置齐全，自动巡航、四气囊、真皮座椅、电动天窗、自动空调一应俱全，才八万多，性价比相当高！嗯，功能不错，价格也便宜，安全性怎麽样？……,呵呵，说实话，是有点小毛病，偶尔刹车会失灵，不过问题不大，多踩几下就行了！非功能需求分类产品需求Requirementswhichspecifythatthedeliveredproductmustbehaveinaparticularwaye.g.executionspeed,reliability,etc.机构需求Rcessstandardsused,implementationrequirements,etc.外部需求Reroperabilityrequirements,legislativerequirements,etc.非功能需求的类型非功能需求案例（仍以LIBSYS为例）产品需求

LIBSYS的用户界面应该能够正确处理错误操作，并给出提示和帮助信息。组织需求系统的开发过程和可交付文档应遵照XYZCo-SP-STAN-95中的相关定义。外部需求

系统不应对系统操作人员公开客户除名字与索引代码之外的任何个人信息。目标与验证非功能需求的常见问题是检验困难，可以通过设定目标来定义可检验的非功能需求。目标明确说明用户的意图，如可用性；可检验的非功能需求用可测试的度量标准来描述需求。可能的情况下，应量化非功能需求，从而使其检验更客观。案例：系统目标Thesystemshouldbeeasytouseeventoexperiencelesscontrollersandshouldbeorganisedinsuchawaythatusererrorsareminimised.可检验的非功能需求Experiencelesscontrollersshallbeabletouseallthesystemfunctionsafteratotaloftwohourstraining.Afterthistraining,theaveragenumberoferrorsmadebyexperiencelessusersshallnotexceedtwoperday.非功能需求的度量需求冲突一些复杂的系统中，功能需求与非功能需求常会出现冲突。例：SpacecraftsystemTominimiseweight,thenumberofseparatechipsinthesystemshouldbeminimised.Tominimisepowerconsumption,lowerpowerchipsshouldbeused.However,usinglowpowerchipsmaymeanthatmorechipshavetobeused.Whichisthemostcriticalrequirement?2.3.3领域需求领域需求来自于应用领域，描述的是反映领域特点的系统特性与特征。领域需求可能是新的功能需求，也可能是对现有需求的约束或定义一个特别的计算。领域需求非常重要，如果领域需求不能满足，可能会使整个系统无法运转。图书馆系统的领域需求ThereshallbeastandarduserinterfacetoalldatabaseswhichshallbebasedontheZ39.50standard.Becauseofcopyrightrestrictions,somedocumentsmustbedeletedimmediatelyonarrival.Dependingontheuser’srequirements,thesedocumentswilleitherbeprintedlocallyonthesystemserverformanuallyforwardingtotheuserorroutedtoanetworkprinter.领域需求表述的问题不易理解Requirementsareexpressedinthelanguageoftheapplicationdomain;Thisisoftennotunderstoodbysoftwareengineersdevelopingthesystem.表述模糊Domainspecialistsunderstandtheareasowellthattheydonotthinkofmakingthedomainrequirementsexplicit.2.4用户需求用户需求是从用户角度来描述的系统功能需求与非功能需求，这样的描述可以使不具备专业技术知识的用户能够看明白。用户需求使用任何人都看得懂的自然语言、图表和直观的图形来描述。自然语言的缺陷描述不够清楚

存在二义性，不易准确理解；需求混乱功能需求、非功能需求无法清晰区分；需求混合多个不同的需求可能被混合在一起表述；书写用户需求的准则设计一个标准格式，以帮助减少遗漏，避免不必要的细节描述；使用一致的语言，尤其强调区别强制性需求与希望性需求。如使用“必须

”定义强制性需求，使用“应该

”定义希望性需求；使用文本加亮来突出关键性需求；尽量避免使用计算机专用术语。2.5系统需求相对于用户需求，系统需求是对系统功能、服务及约束的更详尽的描述。系统需求是系统实现的基本依据，会被写入合同中。因此系统需求是一个完全的、一致的系统描述，是设计的起点。系统需求可以用系统模型来定义与说明。使用自然语言描述系统需求的问题不明确Thereadersandwritersoftherequirementmustinterpretthesamewordsinthesameway.NLisnaturallyambiguoussothisisverydifficult.描述随意性太大Thesamethingmaybesaidinanumberofdifferentwaysinthespecification.不能进行模块化描述NLstructuresareinadequatetostructuresystemrequirements.代替NL的描述方法结构化的自然语言这种方式保持了自然语言的表达能力和易懂等特点，同时用预先定义的模版限制了书写需求使得自由度：所有的需求都用一致的标准方法来书写；对使用的词汇进行了限制，并用模板来约束。基于标准格式的描述方法对功能或实体的定义；对输入及输入来源的描述；对输出及输出去向的描述；其它被引用实体的索引；前条件与后条件；对操作的副作用（如果有）的描绘。例：添加节点的格式化描绘应用表格进行描述这种方法常用做自然语言描述的补充。适用于对于多种不同条件有多种可选动作（结果）的情况。例：表格描述图形模型图形模型在需要描述系统的状态变化或动作序列时最为有用。有关图形模型的应用是这门课程的实践重点！例：ATM取款序列图3.需求导出与分析这个阶段在可行性研究之后进行。系统分析人员要和客户及最终用户一同调查应用领域，找出系统应提供的服务及其约束，即找出系统的功能需求与非功能需求。这个阶段通常与需求描述交叉进行。这个阶段的活动会涉及到机构中方方面面的人，如终端用户、工程人员、业务经理领域专家，甚至工会代表，他们都是对系统需求产生直接或间接影响的人，被称作stakeholders。需求分析可能遇到的问题Stakeholdersdon’tknowwhattheyreallywant.Stakeholdersexpressrequirementsintheirownterms.Differentstakeholdersmayhaveconflictingrequirements.Organisationalandpoliticalfactorsmayinfluencethesystemrequirements.Therequirementschangeduringtheanalysisprocess.Newstakeholdersmayemergeandthebusinessenvironmentchange.需求螺旋过程活动需求发现Interactingwithstakeholderstodiscovertheirrequirements.Domainrequirementsarealsodiscoveredatthisstage.需求的分类与组织Groupsrelatedrequirementsandorganisesthemintocoherentclusters.优先排序和冲突解决Prioritisingrequirementsandresolvingrequirementsconflicts.需求文档Requirementsaredocumentedandinputintothenextroundofthespiral.需求的发现与识别这是整个过程中最为关键的活动，负责收集目标系统级现存系统的相关信息并从这些信息中提炼出用户需求和系统需求。信息的来源包括已有的文件，系统的信息持有者（stakeholders）以及相近系统的规约描述。ATMstakeholdersBankcustomersRepresentativesofotherbanksBankmanagersCounterstaffDatabaseadministratorsSecuritymanagersMarketingdepartmentHardwareandsoftwaremaintenanceengineersBankingregulators3.1多视点（viewpoint）需求定义视点用来表述不同角度的需求来源（信息持有者、其它相关系统及领域）。每一个视点代表系统需求的一个子集。从多视点对系统进行分析是十分重要的，因为没有那一种单一的途径能够诠释整个系统需求。视点的类型交互者视点Peopleorothersystemsthatinteractdirectlywiththesystem.InanATM,thecustomer’sandtheaccountdatabaseareinteractorVPs.间接视点Stakeholderswhodonotusethesystemthemselvesbutwhoinfluencetherequirements.InanATM,managementandsecuritystaffareindirectviewpoints.领域视点Domaincharacteristicsandconstraintsthatinfluencetherequirements.InanATM,anexamplewouldbestandardsforinter-bankcommunications.视点的识别以下的几个方面可以帮助识别视点：Providersandreceiversofsystemservices;Systemsthatinteractdirectlywiththesystembeingspecified;Regulationsandstandards;Sourcesofbusinessandnon-functionalrequirements.Engineerswhohavetodevelopandmaintainthesystem;Marketingandotherbusinessviewpoints.LIBSYS的视点3.2访谈对stakeholders进行正式的和非正式的访谈对于需求工程是非常重要的工作。有两种类型的访谈：封闭式访谈，预先定义所要提问的问题，又叫做限定式访谈；开放式访谈，不预先设定访谈内容，给定一个范围，与stakeholders自由交流以更好的把握他们的要求。访谈实践通常是采用两种方式相混合，以封闭式访谈开始，以开放式结束。访谈对于全面了解系统需求是一种很好的方法，在访谈中可以了解stakeholders的要求，他们是如何与系统交互的，对当前系统面临的问题等。访谈方式对于获取领域需求并不是很奏效Requirementsengineerscannotunderstandspecificdomainterminology;Somedomainknowledgeissofamiliarthatpeoplefindithardtoarticulateorthinkthatitisn’twortharticulating.对访谈者的要求有能力的访谈者应该是思维开阔的，愿意聆听他人的想法，并且不会对问题有先入为主的看法。他们善于用问题和建议去启发访问者的思维，或使用原型与被访问者讨论，而不是仅用‘whatdoyouwant’进行简单的提问。

3.3场景场景描述法是采用把系统交互放到一个真实的生活片段中，这样比采用抽象的形式描述要容易理解，容易导出目标系统的使用细节。场景的描述方式很多，一般包括：场景开始时系统初始状态的描述；一个标准事件流的描述；对可能出现的错误及解决方法的描述；其它并行事件流的描述；场景结束状态的描述。常用的方法，自然语言和用例。例：酒店预定场景描述开始：

MedocaSansumi,是theSantaCruzB&B的酒店前台，一边看着theHotelAppMain的银幕一边等着电话。电话从Ms.JaneGoogol打来，一个来自纽约的客户。Ms.Googol拿起电话说“你好，我是JaneGoogol，我想要为新年的前夜预定一间房间”。Medoca在HotelApp的主银幕上选择了“创建预定”。屏幕上显示出一个空预定。中间过程：

Medoca问到“你什么时候到达这里？”。Jane回答到“12月31日到，我想要住到1月5日。”Medoca输入了开始日期，并且问到“你想要预定什么类型的房子呢？”，“我将和我的丈夫一起到那，所以需要一个单独的并且有足够空间的，那个Blue房子有空的吗？”Jane问到。Medoca选择“single”在预定的表格中，完成了查找。系统给予了三种空房间的回应：Victoria,Blue和Queen。“是的，有空的”Medoca回答。Medoca选择了Bule房间，系统把它填入预定的表格中，然后做出“held”的预约记号。例：酒店预定场景描述更多的中间过程：

Medoca向系统中输入Jane的全名。Ms.Googol是一个现有的客户，所以系统通过客户表单的数据在预约的表格中给出回应。“你想要今天就把这个预定确定下来吗？”Medoca问道。“是的”Jane说，“用我的VISA卡，卡号是：1111-2222-3333-4444。”Jane在Medoca把卡号输入进去以后暂停了。“截至日期是2007年7月。”Medoca输入这些信息，并且在系统上选择了“VerifyPayment（确认付款）”。五分钟后，系统给出了银行存款验证的回应。系统把预定的状态改成了“confirmed.”例：酒店预定场景描述例：酒店预定场景描述结束：

Medoca告诉Jane预约号（系统产生的），并且问道“我还能为您做什么？”，Jane回答没什么了，Medoca向Jane道谢并且再见。Medoca关闭了预约表格的窗口，系统返回到MainHotelApp的主屏幕上。用例（UseCase）用例是一种基于UML的场景描述技术，用来识别在一个系统交互中的参与者并描述这个交互过程。用例的集合应该可以描述系统中的所有的交互。UML中的序列图可以用来配合用例图描述系统的交互细节。例1：文献打印用例图例2：

LIBSYS用例模型例3：文献打印序列图3.4

导出工作产品对于大多数系统而言，工作产品包括：Astatementofneedandfeasibility.Aboundedstatementofscopeforthesystemorproduct.Alistofcustomers,users,andotherstakeholderswhoparticipatedinrequirementselicitationAdescriptionofthesystem’stechnicalenvironment.Alistofrequirements(preferablyorganizedbyfunction)andthedomainconstraintsthatapplytoeach.Asetofusagescenariosthatprovideinsightintotheuseofthesystemorproductunderdifferentoperatingconditions.Anyprototypes

developedtobetterdefinerequirements.4结构化分析（SA）建模结构化分析方法是一种面向数据流的系统建模技术；SA帮助分析者理解系统的功能，并采用模型与用户进行交流；不同的模型从不同的角度对系统进行描述。结构化分析建模结构化分析方法建立的分析模型结构如下图：实体—关系图

数据词典状态—迁移图数据流图数据对象描述控制规格说明加工规格说明结构化分析模型的核心是数据词典，它描述了所有的在目标系统中使用的和生成的数据对象。围绕着这个核心的有三种图：实体—关系图(ERD)描述数据对象及数据对象之间的关系；数据流图(DFD)描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能（子功能）；状态—迁移图(STD)描述系统对外部事件如何响应，如何动作。因此，ERD用于数据建模，DFD用于功能建模，STD用于行为建模。

结构化分析建模4.1数据建模与实体—关系图(ERD)数据模型包括三种互相关联的信息：数据对象描述对象的属性描述对象间相互连接的关系（具体绘制方法同数据库原理ER模型画法）4.2功能建模和数据流图

功能建模的思想就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。数据流图可以表示任何一个系统（人工的、自动的、或混合的）中的数据流程；每个表示加工的圆圈可能需要进一步分解以求得对问题的全面理解；着重强调的是数据流程而不是控制流程。4.2.1数据流图的画法数据流图中的常用图元有以下四种：表示外部实体，代表数据源和数据池（终点）。表示加工，代表接收输入，经过变换，继而产生输出的处理过程。表示数据流，代表数据的流向和路径。表示数据存储，代表系统加工的数据所存储的地方。

例：教材采购与销售管理系统数据流图

F1教材存量表

1

销售

2采购

书库保管员

学

生领书单购书通知进书通知

购书单

缺书单

F2缺书登记表

缺书汇总表多个数据流与加工之间关系的符号

4.2.2分层数据流图复杂的实际问题，在数据流图上常常出现十几个甚至几十个加工。画数据流图的基本步骤概括地说，就是自外向内，自顶向下，逐层细化，完善求精。按照系统的层次结构进行逐步分解，并以分层的数据流图反映复杂的结构关系，能清楚地表达和容易理解整个系统。4.2.2分层数据流图画分层数据流图的注意事项数据流图要具有可读性、一致性、正确性。①数据流图上所有图形符号只限于前述四种基本图形元素。②顶层数据流图上的数据流必须封闭在外部实体之间。③数据应通过加工流动，避免从一个数据存储直接流向另一个数据存储。④每个加工至少有一个输入数据流和一个输出数据流，且输入与输出数据流要平衡。有输入，无使用及输出为“黑洞”，无输入和产生而有输出为“奇迹”。⑤在数据流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的父图与子图的对应关系。⑥规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。画分层数据流图的注意事项⑦图上每个元素都必须有名字。数据流和数据文件的名字应当是“名词”或“名词性短语”，表明流动的数据是什么。加工的名字应当是“名词＋宾语”，表明做什么事情。⑧可以在数据流图中加入物质流，帮助用户理解数据流图。⑨数据流图中不可夹带控制流。⑩初画时可以忽略琐碎的细节，以集中精力于主要数据流。例：教材采购与销售管理系统零层数据流图L0教材购销系统领书单

进书通知

学生书库保管员

购书单缺书单

教材采购与销售管理系统一层数据流图L1F1教材存量表

1

销售

2采购

书库保管员

学

生领书单购书通知进书通知

购书单

缺书单

F2缺书登记表

缺书汇总表教材采购与销售管理系统二层数据流图L2.11.1查库存1.2售书1.3申请采购

学生

购书单领书单缺书列表F1教材存量表F2缺书登记表到货书单进书通知缺书汇总表教材采购与销售管理系统二层数据流图L2.22.3进货进书通知F1教材库存量表2.1询价2.2订货订货价格F2缺书登记表缺书单

书库管理员进书通知进货单缺书汇总表4.2.3数据词典数据词典用于精确、严格地定义每一个与系统相关的数据元素（包括数据流、数据存储和数据项），并以字典式顺序将它们组织起来，使得用户和分析员有共同的理解。在数据词典的每一个词条中应包含以下信息：①名称：数据对象或控制项、数据存储或外部实体的名字。②别名或编号。③分类：数据对象？加工？数据流？数据文件？外部实体？控制项（事件∕状态）？④描述：描述内容或数据结构等。⑤何处使用：使用该词条（数据或控制项）的加工。⑥注释：数据量，峰值，限制，组织方式等

数据词典中的符号

符号

含义

解释

＝＋[...,...][...|...]{...}m{...}n(...)“...”..

被定义为与或或重复重复可选基本数据元素连结符例如，x=a＋b，表示x由a和b组成。例如，x=[a,b]，x=[a|b]，表示x由a或由b组成。例如，x={a}，表示x由0个或多个a组成。例如，x=3{a}8，表示x中a出现3到8次。例如，x=(a)，表示a可在x中出现,也可不出现。例如，x=“a”，表示x为取值为a的数据元素。例如，x=1..9，表示x可取1到9之中的任一值。例如：类型：数据流条目名字：购书列表别名：购书单列表描述：对学生提供的购书单通过查库存将有库存的购书信息汇总形成的列表定义：购书列表={需书单位+书名+（刊号）+数量+（时限）+[学生用书|教师用书|图书馆用书]}类型：数据项条目名字：需书单位别名：购书单位描述：提供购书单的单位名称定义：20个汉字例如：类型：数据存储条目编号：F1名字：教材库存量表别名：描述：记录每种库存教材的库存数量定义：教材库存量表={书名+（刊号）+（版本）+数量}数据组织方式：按书名拼音顺序排列例如：4.2.4加工规格说明

加工规格说明用来说明DFD中的数据加工的加工细节，数据加工的输入，实现加工的算法以及产生的输出。另外，加工规格说明指明了加工（功能）的约束和限制，与加工相关的性能要求，以及影响加工的实现方式的设计约束。目前用于写加工规格说明的工具有结构化语言、判定表和判定树。结构化语言：类型：加工说明条目编号：2.1名字：询价别名：加工逻辑：首先根据购书通知逐个进行多方询价然后比较各种报价比较其他情况（有无现货，付款方式，是否送货等）综合评定供应商，确定订货价格输入数据：购书通知输出数据：订货价格触发条件：每当书库管理员发出购书通知执行发生频度：一般每周一次，最多每天一次判定树和判定表

判定树和判定表适于描述多个逻辑条件的组合描述。判定树根据判定条件的关系构造，内部节点为判定条件，叶子节点为判定结果。判定表的基本结构为：基本条件条件项基本动作动作项判定树和判定表

判定树和判定表

5UML与面向对象分析方法较早的软件开发，用结构程序设计方法。这种方法中程序的定律是：程序=（算法）+（数据结构）即过程（函数）是一个独立的整体，数据结构（包含数据类型与数据）也是一个独立的整体。两者分开设计，以算法（函数或过程）为主。

voidmain(){inta=1,b=2,c;c=max(a,b);}5.1结构化与面向对象结构化程序设计是一种面向过程的自顶向下的程序设计方法。BuildACarBuildChassisBuildEngineBuildDriveSystemAssemble…………结构化与面向对象结构化设计中模块和模块之间的关系，被紧紧局限于信息流，试图通过信息流及其转换来认识系统，这限制了对模块之间众多关系的表达和体现，如继承、依赖。main()buildD()buildE()buildC()assemble()…………结构化与面向对象流水线式的过程处理与人们日常处理问题的方式不一致。随着时间流逝，软件工程师越来越注重系统整体关系的表示和数据模型技术（把数据结构与过程看作一个独立功能模块）。程序定律被重新认识：

程序=（过程+数据结构）这样的思想符合现实世界中的事物特征，我们区分事务主要依靠就是事物各式各样的特征，包括事物不同的属性和特定的行为。集成化的软件开发方法--面向对象方法产生。结构化与面向对象在面向对象中，过程与数据结构被捆绑成一个对象，这样就不用为如何实现通盘的程序功能而费尽心机了。这时侯，程序定义变为：

对象=（过程+数据结构）程序=（对象+对象+...）也就是说，程序就是许多对象在计算机中相继表现自己。而对象又是一个个程序实体。结构化与面向对象

思考：请描述你到饭店就餐的情景！

结构化与面向对象5.2.1UML是什么统一建模语言UnifiedModelingLanguageUML是一个通用的可视化建模语言UnifiedModelingLanguage（统一建模语言）是对象管理组织（OMG）制定的一个通用的、可视化的建模语言标准，可以用来可视化（visualize）、描述（specify）、构造（construct）和文档化（document）软件密集型系统的各种工件（artifacts，又译制品）

5.2UML基础UML的历史BoochmethodOMTUnifiedMethod0.8OOSEOthermethodsUML0.9UML1.01989-1994期间，OO方法从不足10种增加到50多种UML1.1OOPSLA´95Web-June´96UMLpartnerspublicfeedback

2004FinalsubmissiontoOMG,Nov‘97FirstsubmissiontoOMG,Jan´97OMGAcceptance,Nov1997

Fall1998UML1.3UML2.0UML的创始人UML是由世界著名的面向对象技术专家G.Booch、J.Rumbaugh和I.Jacobson发起，在Booch方法、OMT方法和OOSE方法的基础上，广泛征求意见，集众家之长，几经修改而完成的。ThreeamigosBoochRumbaughJacobsonUML的特点统一了面向对象方法的表示表示能力强大，可用于各种软件系统建模，以及其它系统建模，如商业系统与开发过程无关允许扩展本身不设计特点语言的语法及规则，但可对应到各种OOP语言框架UML和OOA、OODUML既不是方法论，也不是一种开发过程，而是面向对象系统分析与设计的建模语言，是一种语言工具。如同英语充当国际交流的工具一样OOA&OOD是方法论，该方法论的实践过程中需要使用UML的图符，使用时还必须遵循一定的原则及步骤。5.2.2

UML结构UMLStructure构造块buildingblocks公共机制commonmechanisms构架architecture基本UML建模元素、关系和图达到特定目标的公共UML方法系统架构的UML视图UML模型元素模型元素是构成图片的最基本单位，一种模型元素通常有它主要出现的图类型，但同时可以用在不同的图中，但不论出现在哪里，一般表示相同的含义。通用机制一般用来表示注释、语义、约束等含义，不隶属于任何一种图，是所有图中通用的一些特殊模型元素。

UML模型元素依赖实现UML图形图diagrams类图classdiagrams对象图objectdiagrams构件图componentdiagrams部署图deploymentdiagrams用例图usecasediagrams顺序图sequence`diagrams协