软件工程 软件需求工程 Software Requirements Engineering
通过对问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段。\r\n 软件需求作为软件生命周期的一个阶段，其重要性越来越突出，到20世纪80年代中期，逐步形成了软件工程的子领域——需求工程。\r\n 90年代后，需求工程成为软件界研究的重点之一。从1993年起，每两年举办一次需求工程国际研讨会（ISRE），1994年起，每两年举办一次需求工程国际会议（ICRE）。一些关于需求工程的工作小组相继成立，使需求工程的研究得到了迅速进展。
内容摘要
1.什么是需求工程？\r\n2.什么是软件需求工程？\r\n3.软件需求的重要性\r\n4.软件需求的困难\r\n5.软件需求内容\r\n6.需求工程的活动
1 )需求的基本概念 \r\n宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。 \r\n2)需求工程(RE)的概念 \r\n是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。\r\n需求分析专家 Alan Davis 把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动” \r\nRE通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。
1 什么是需求工程
2.什么是软件需求工程？
需求工程RE可分为系统需求工程（如果是针对由软硬件共同组成的整个系统）和软件需求工程（如果仅是专门针对纯软件部分）。\r\n软件需求——是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。\r\n软件需求工程——是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。
软件需求无疑是当前软件工程中的关键问题，没有需求就没有软件。\r\n需求的重要性\r\nFrederick Brooks在他1987年经典文章“No Silver Bullet”中阐述了需求的重要性：\r\n开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。 \r\n需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。 \r\n国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。
3.软件需求的重要性
3. 软件需求的重要性
美国于1995年开始对全国范围内的8000个软件项目进行跟踪调查。
分析失败的原因发现，与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。
未完成
完成未实施
完成
4. 软件需求的困难
软件需求是软件工程中最复杂的过程之一：\r\n应用领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。\r\n非功能性需求建模技术的缺乏及其与功能性需求有着错综复杂的联系，大大增加了需求工程的复杂性。\r\n沟通上的困难，由于系统需求分析各方面人员有不同的着眼点和不同的知识背景，给需求工程的实施增加了人为的难度。
4. 软件需求的困难
客户说不清楚需求；\r\n需求自身经常变动；\r\n分析人员或客户理解有误。
真正的软件需求获取如此困难（漫画）
需求工程是系统工程和软件工程的一个交叉分支，涉\r\n及到软件系统的目标、软件系统提供的服务、软件系统的\r\n约束和软件系统运行的环境。它还涉及这些因素和系统的\r\n精确规格说明以及系统进化之间的关系。它也提供现实需\r\n求和软件能力之间的桥梁。
需求工程
5. 软件需求内容
软 件需 求
软件需求的内容
5. 软件需求内容
功能需求\r\n 它是对系统应该提供的服务、功能以及系统\r\n在特定条件下的行为的描述。它与软件系统的类\r\n型、使用系统的用户等相关，有时需要详细描述\r\n系统的功能、输入/输出、异常等，有时还需要申\r\n明系统不应该做什么。
领域需求\r\n 是由软件系统的应用领域所决定的特有的功\r\n能需求，或是对功能的约束。
需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。
6. 需求工程的活动
Herb Krasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理 \r\n Matthias Jarke和Klaus Pohl提出了三阶段周期的说法：获取、表示和验证 \r\n 本书将软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段。\r\n… …
6. 需求工程的活动
一、 需求开发
需求开发的任务是准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用《需求规格说明书》规范的形式准确地表达用户的需求。\r\n需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。\r\n需求获取的目的是深入实际，通过各种途径,在充分理解用户需求的基础上，获取用户的需求信息。\r\n需求分析、协商与建模的目的是对各种需求信息进行分析，消除错误，刻画细节等。\r\n需求规格说明目的是根据需求获取和需求分析的结果，进一步定义准确无误的产品需求，产生《需求规格说明书》。系统设计人员将依据《需求规格说明书》开展系统设计工作。\r\n需求验证是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。确保需求说明准确、完整地表达系统的主要特性。
需求获取是需求工程的主体,非常困难，主要原因有：\r\n●缺乏领域知识,应用领域的问题常常是模糊的、不精确的；\r\n● 存在默认的知识,如难以描述的常识问题；\r\n● 存在多个知识源,且多知识源之间可能有冲突；\r\n● 客户可能的偏见，如不能提供或不想告知你所需要了解的事情。
一)、需求获取(requiremente licitation)
需求获取技术
1.面谈法 重要而直接，简单的需求获取技术。\r\n2. 问卷法调查法 是对面谈法的补充。 \r\n3.需求专题讨论会 最有力的需求获取技术。有利 于 培养高效团队。\r\n4. 观察用户的工作流程 适用于用户无法准确表达需求的情况。\r\n5. 原型化方法\r\n6. 基于用例的方法
还有知识工程方法等如：场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。
面谈的对象主要有用户和领域专家：\r\n1） 面谈前的准备要充分；\r\n2） 面谈后注意认真分析总结；\r\n3） 注意掌握面谈的人际交流技能。
需求获取技术
1.面谈法 重要而直接，简单的需求获取技术。\r\n2. 问卷法调查法 是对面谈法的补充。 \r\n3.需求专题讨论会 最有力的需求获取技术。有利 于 培养高效团队。\r\n4. 观察用户的工作流程 适用于用户无法准确表达需求的情况。\r\n5. 原型化方法\r\n6. 基于用例的方法
是从多个用户中收集需求信息的有效方式 ，一般问卷设计形式：\r\n1）多项选择问题 ；\r\n2）评分问题 ；\r\n3）排序问题 。
需求获取技术
1.面谈法 重要而直接，简单的需求获取技术。\r\n2. 问卷法调查法 是对面谈法的补充。 \r\n3.需求专题讨论会 最有力的需求获取技术。有利 于 培养高效团队。\r\n4. 观察用户的工作流程 适用于用户无法准确表达需求的情况。\r\n5. 原型化方法\r\n6. 基于用例的方法
由开发方和用户方共同召开,操作步骤：\r\n① 开发方根据双方制定的《需求调研计划》召开相关需求主题沟通会；\r\n② 会后开发方整理出《需求调研记录》提交给用户方确认；\r\n③ 如果此主题还有未明确的问题则再次沟通,否则开始下一主题；\r\n④ 所有需求都沟通清楚后，开发方根据历次《需求调研记录》整理出《用户需求说明书》，提交给用户方确认签字。
因此系统应该具备以下功能：\r\n ⑴ 基本数据维护功能\r\n ⑵ 基本业务功能\r\n ⑶ 数据库管理功能\r\n ⑷ 信息查询功能
例1：有一个大学图书管理系统，该系统除了一般的图书管理功能外，还能够为学生和教工从其他图书馆借阅图书和文献资料提供服务。
1. 功能需求\r\n⑴基本数据维护功能：\r\n 提供使用者录入，修改并进行维护基本数据的途径。基本数据包括读者的信息、图书资料的相关信息，可以对这些信息进行修改，更新。\r\n⑵基本业务功能：\r\n 读者借、还书籍的登记管理功能，随时根据读者借、还书籍的情况更新数据库系统，可以进行书籍的编目、入库、更新等操作。
⑶数据库管理功能：\r\n 对所有图书信息及读者信息进行统一管理维护的功能，对书籍的借还也要进行详细的登记，以便协调整个图书馆的运作。\r\n⑷信息查询功能：\r\n 提供对各类信息的查询功能，如对本图书馆的用户借书信息，还书的信息，书籍源信息等进行查询，对其他图书馆的书籍、资料源信息的查询功能。
2.非功能需求\r\n ① 系统安全性需求：为保证系统安全性，对本图书馆的各项功能进行分级、分权限操作，对各类用户进行确认。对其它图书馆借阅图书和文献资料服务控制访问范围：如限IP、限用户等。\r\n ② 对系统可用性的需求：为了方便使用者，要求对所有交互操作提供在线帮助功能。\r\n ③ 对系统查询速度的需求：要求系统在20S之内响应查询服务请求。\r\n ④ 对系统可靠性的需求：要求系统失败发生率小于1%。
3. 领域需求\r\n例如：对“大学图书管理系统”，提出一些与图书管理的业务相关的需求：\r\n ⑴ 图书编目要求按照《中国图书馆分类法》进行；\r\n ⑵ 由于版权限制，某些文献资料只能在图书馆规定的阅览室阅读，并限制复制和打印。\r\n 第一条需求是对遵循我国图书管理的规定，执行对图书的分类管理的标准。而第二条需求则是版权法对图书馆文献资料的保护的需要，描述了对一类文献资料有限制的使用和服务。
\r\n 需求分析阶段主要对收集到的需求进行提炼、分析和认真审查，进行需求建模、对模型或原型进行分析。确保所有参加人员取得一致共识。找出错误、遗漏和不足，建立完整的分析模型。
二)、需求分析、协商与建模
1、确定系统的综合要求\r\n 系统功能要求—这是最主要的需求，确定系统必须完成的所有功能。 \r\n 系统性能要求—应就具体系统而定，例如可靠性、联机系统的响应时\r\n间、存储容量、安全性能等。\r\n 系统运行要求—主要是对系统运行时的环境要求，如系统软件、数据\r\n库管理系统、外存和数据通信接口等。 \r\n 将来可能提出的要求—对将来可能提出的扩充及修改作预准备。\r\n2、分析系统的数据要求\r\n 软件系统本质上是信息处理系统，因此，必须考虑：\r\n 数据 （需要哪些数据、数据间联系、数据性质、结构）\r\n 数据处理 （处理的类型、处理的逻辑功能）\r\n3、导出系统的逻辑模型。\r\n4、修正系统的开发计划—通过需求对系统的成本及进度有了更精确的估算，可进一步修改开发计划。
需求分析、协商与建模的具体任务
需求分析的一般步骤
1．必须能够表示和理解问题的信息域\r\n2．必须能够定义软件将完成的功能\r\n3．必须能够表示软件的行为(作为外部事件的结果)\r\n4．必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节\r\n5．分析过程应该从要素信息移向细节信息
需求分析操作原则
信息域
信息域：包括信息内容、信息流、以及信息结构。\r\n信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成。 \r\n例如，数据对象“工资”是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、扣除额等等 \r\n信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息(数据和/或控制)，然后进一步被变换为输出\r\n\r\n信息结构表示了各种数据和控制项的内部组织 \r\n数据或控制项将被组织为n维表还是树形结构？\r\n在结构的语境内，什么信息是和其他信息相关的？\r\n信息包含在单个结构中，还是使用不同的结构？\r\n在某信息结构中的信息如何和在另一个结构中的信息相关？
需求工程的指导性原则
除了上面提到的操作性分析原则，Davis提出了一组针对需求工程的指导性原则： \r\n在开始建立分析模型前，先充分理解问题。\r\n开发原型，使得用户能够了解如何进行人机交互。\r\n记录每个需求的起源及原因。\r\n使用多个需求视图。建立数据、功能和行为模型，为软件工程师提供三种不同的视图。\r\n给需求赋予优先级。\r\n努力删除歧义性。
常用的需求分析方法：
功能分解方法\r\n面向数据流的结构化分析方法 (SA)\r\n面向数据结构的分析方法 \r\n信息建模法\r\n面向对象的分析方法 (OOA)
需求分析方法
功能分解方法 \r\n 将系统看作若干功能模块的集合，每个功能又可以分解为子功能,子功能还可继续分解,分解的结果即是系统的雏形。
问 题\r\n1. 需要人工完成\r\n2. 无法对描述的准确度进行验证。\r\n3. 难以适应需求的变化。
1．客房预定系统 2．前台接待系统 \r\n 3．前台收银系统 4．帐务系统 5．管家系统 6．电话系统 7．客历系统 8．合约系统 9．经理系统 10．总经理系统 11．密码管理系统 12．报表系统 13．帐务报表
酒店管理系统
例：
按照功能分解为以下子系统：
例：盘存/销售系统，用户提出,系统应具有以下功能:\r\n ① 计算买主订单 ② 准备销售报表 \r\n ③ 建立买主文件和应收帐发票 ④ 运行更新的盘存文件\r\n ⑤ 产生托运单和包装单 ⑥ 保证库存及时订货
计算销售\r\n记录 \r\n 1.1.1
产生销售\r\n报表\r\n 1.1.2
核对买主\r\n贷方金额\r\n 1.1.3
需求分析方法
结构化分析方法\r\n 结构化分析方法是面向数据流的需求分析方法，是20世纪70年代末由Yourdon,Constaintine及DeMarco等人提出和发展，并得到广泛的应用。它适合于分析大型的数据处理系统，特别是企事业管理系统。\r\n SA法也是一种建模的活动，主要是根据软件内部的数据传递、变换关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。
需求分析方法
面向对象的分析方法 \r\n面向对象的分析方法(OOA)的关键是识别问题域内的对象,分析它们之间的关系,并建立起三类模型。
信息建模法 \r\n是从数据的角度对现实世界建立系统的信息模型,基本工具是ER图。是由实体、属性和关系组成的网络图。 E-实体，是一个或一组对象；\r\n R-关系，实体之间联系或交互作用。
需求协商
协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案 \r\n协商不是简单的逻辑或技术上的争论 \r\n要注意组织和行政方面的因素 \r\n①不一致的目标 \r\n②责任的丧失或转移 \r\n③组织文化 \r\n④组织管理态度和士气 \r\n⑤部门差异
通常会议是解决冲突最快的方式 \r\n参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员 \r\n会议应该讨论那些非正式讨论不能解决的问题 \r\n通常会议分为三个阶段：\r\n叙述阶段\r\n讨论阶段\r\n决策阶段
需求建模
在软件需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做\r\n目标软件的模型不应涉及软件实现细节
典型分析建模方法\r\n结构化分析(传统建模方法)\r\n面向对象分析
模型的作用
结构化分析模型的元素
数据字典(DD)：模型核心(中心库)\r\n数据流图(DFD) \r\n指明数据在系统中移动时如何被变换;\r\n描述对数据流进行变换的功能;\r\nDFD中每个功能的描述包含在加工规约(小说明)。\r\nE-R图(ERD)\r\n状态变迁图(STD)\r\n 指明作为外部事件的结果,系统将如何\r\n 动作。
三)需求规格说明(需求规约)
采用原始模板在你的组织中要为编写软件需求文档定义一种标准模板 \r\n指明需求的来源 \r\n为每项需求注上标号制定一种惯例来为每项需求提供一个独立的可识别的标号或记号 \r\n记录业务规范
需求规约的原则
1．从现实中分离功能，即描述要“做什么”而不是“怎样实现”。\r\n2．要求使用面向处理的规约语言（或称系统定义语言），讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规约。\r\n3．如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。\r\n4．规约必须包括系统运行环境。
需求规约的原则 (续)
5．规约必须是一个认识模型，而不是设计或实现的模型。\r\n6．规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，已提出的解决方案是否都能满足规约。\r\n7．规约必须允许不完备性并允许扩充。\r\n8．规约必须局部化和松散耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规约应被松散地构造（即松耦合），以便能够很容易地加入和删去一些段落。
需求规约IEEE/ANSI830-1993 简化大纲
引言：陈述软件目标，在基于计算机的系统语境内进行描述。\r\n信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。\r\n功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。\r\n行为描述：描述作为外部事件和内部产生的控制特征的软件操作。\r\n检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。\r\n参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。\r\n附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。
四)、需求的有效性验证
需求验证目的是要检验需求是否能够反映用户的意愿\r\n(一) 需求验证的重要性\r\n １. 由于需求分析是软件开发的第一阶段，直接影响后面各阶段的开发。\r\n ２. 需求的可变性必须进行验证。
(二) 需求验证的内容\r\n 1.有效性检查—指功能需求是否符合用户所提出的需求。\r\n 2.一致性检查—系统功能描述及约束是否一致。\r\n 3.完备性检查—是否包含所有系统用户的需求和约束。\r\n 4.可检验性检查—是否能设计出一组验证方法。
52
需求开发过程
53
二、需求管理
需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动 \r\n需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。 \r\n 需求管理贯穿需求分析全过程，包括:
需求管理的所有活动中，最重要的是需求变更管理，包括:
问题分析和变更描述
变更分析和成本计算
变更实现
需求管理过程需要CASE (Computer Aided Software Engineering) 工具支持。
二、需求管理
系统分析员的主要能力
在整个系统分析活动中，系统分析员起着关键的作用，其本人应该具备以下能力：\r\n熟悉计算机技术；\r\n了解用户业务领域的相关知识；\r\n能在用户和开发人员之间借助于数据概念进行交流。\r\n同时从个人素质上，分析师应善于从原始材料中抽象出逻辑概念，将其重新整理之后成为各种逻辑成分，并根据各种逻辑成分综合出问题的解决办法，并善于用模型说话；\r\n能从冲突或者混淆中吸取恰当事实的能力；\r\n能弄清用户环境的能力；\r\n能为用户系统恰当配置软硬件的能力\r\n能较好地用书面和口头形式进行沟通的能力\r\n有“从树木见森林”的能力。
需求工程小结
软件需求工程,是软件开发人员与用户密切配合，充分交换意见，获得对需求一致意见的过程。\r\n在开发者一方，参与工作的主要角色是系统分析员和系统工程师等，负责沟通用户和开发人员的认识和见解，起着桥梁作用。\r\n需求工程阶段的最终任务是要完成目标系统的需求规格说明，确定系统的功能、非功能需求和性能，为后阶段的开发打下基础。本阶段常用的有SA法，OOA法等。