前言
软件需求这门课我基本上没怎么听，但是老师课上完后就考试真的是很怕，给了一些重点范围，我整理了一下，虽然不一定全，但至少应该掌握这些。
软件危机及其表现
软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。
表现：
1) 软件需求增长得不到满足
2) 软件生产高成本、价格昂贵
3) 软件生产进度无法控制
4) 软件需求定义不准确
5) 软件质量不易保证
6) 软件可维护性差
软件过程模型的概念
软件过程模型又称为软件开发模型，它是软件开发全部过程，活动和任务的结构框架。
了解瀑布模型（优缺点），原型模型，up模型，敏捷过程
瀑布模型
瀑布模型的优点：
简单易用，将复杂的软件开发过程明确分解为几个顺序的步骤，降低开发软件的复杂性。有利于大型软件开发过程中人员组织、管理。有利于软件开发方法和工具的研究，从而提高了大型项目开发的质量和效率。
严格，第一是每个步骤的严格，每个步骤都有明确的标准和技术审查，尽量减少每个步骤的错误，同时减少对下个阶段的影响。第二是对文档的严格要求，每个阶段都有各自的规格说明书。
瀑布模型的缺点：
开发过程一般不能逆转，否则代价太大；很难严格按该模型进行；（很难清楚地给出所有的需求。
一次性：单向开发，开发期间没有迭代过程，无法适应用户不明确的需求或需求出现变动，难以适应现代软件开发模式的问题。
用户的风险：瀑布模型顺序严格，用户到软件开发结束才能看到最终结果，可能离用户预期的需求有很大差距，开发风险大。
瀑布模型的使用范围：用户的需求非常清楚全面，且在开发过程中没有或很少变化,对软件的应用领域很熟悉；用户的使用环境非常稳定；开发工作对用户参与的要求很低。
快速原型模型
快速原型模型的优点：可以得到比较良好的需求定义，容易适应需求的变化；有利于开发与培训的同步；费用低、开发周期短且对用户更友好。
快速原型模型的缺点：客户与开发者对原型理解不同； 准确的原型设计比较困难； 不利于开发人员的创新。
快速原型模型的使用范围：对所开发的领域比较熟悉而且有快速的原型开发工具；项目招投标时，可以以原型模型作为软件的开发模型；进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型是非常适合的。
UP模型（统一过程模型）
（过程框架：初始，细化，构造，移交）
统一过程模型：是风险驱动的，基于用例技术，以架构为中心的，迭代的，可配置的软件开发流程
五个核心工作流程：需求 分析 设计 实现 测试
敏捷过程（agile process）
是一种以人为核心、迭代、循序渐进的开发方法。它是由17个工程师为了解决日益庞大的开发团队和繁琐的开发过程、大量的文档中解脱开发人员的工作量达成的一项共识。在敏捷过程中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷过程是全一个全新的新理论。他不同于原来的6Sigma，ISO9000和CMM。细心的人们可以发现，敏捷过程也借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子，也许还有更多。
改善，而非创新。敏捷过程可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷过程继承了不少原有方法的优势。“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，”Fowler介绍，“这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”
敏捷过程的价值观:
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 循环计划
鼓励和侧重左侧的内容，不是完全的支持。她强调人的作用，希望在开发团队中有优秀的开发人员。
需求分类(描述角度，需求有哪几种）
1）功能需求： 和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。
功能需求三个不同抽象层次之间有紧密的联系
l 业务需求：反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
l 用户需求：文档描述了用户使用产品必须要完成的任务，这在使用实例（use-case）文档或方案脚本(scenario)说明中予以说明。
l 功能需求：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示。
软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节。
2）性能需求：系统整体或其组成部分应该拥有的性能特征，如CPU使用率和内存使用率等。
3）质量属性：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，如可靠性程度和可维护性程度等。
4）对外接口：系统和环境中其他系统之间需要建立的接口，包括硬件接口，软件接口和数据库接口等。
5)约束：进行系统构造时需要遵守的约束，如编译语言和硬件设施等。
除了上述5中明确的软件需求类别以外，还指出项目中也可能出现逻辑数据需求等其他特殊类型的需求。
在非功能需求中质量属性对系统成败的影响极大，因此在某些情况下，非功能需求又被用来特指质量属性。
需求工程及过程
需求工程是软件工程的核心组成部分，是指应用有效技术、方法进行需求分析，确定客户需求，帮助分析和设计人员理解问题，并定义目标系统的一门学科。
它把整个软件需求工程研究领域划分为需求开发和需求管理两部分。
需求管理和开发
需求获取：需求获取是从人、文档、或环境中获取需求的过程，必须用各种方法和技术来发现需求，需求开发的过程包含学习和认知的两个过程，学习和认知是递进的。具体有：1收集背景资料2、获取问题与目标，定义项目前景和范围3、识别涉众，选择信息的来源4、选择获取方法，执行获取、获取功能与非功能需求5、记录获取结果
需求分析：1、背景资料2、问题分析、目标分析、业务分析、确定系统边界3、软件需求建模4、细化需求5、确定优先级6、需求协商
需求规格说明： 1、定制文档模板2、编写文档
需求验证：1、执行验证2、问题修正
需求管理：1、建立和维护需求基线集2、建立需求和跟踪信息3、进行变更控制、
需求开发过程是迭代和并发的。
需求开发过程与软件工程过程的相互影响：
需求获取和需求分析是相互交织的，需求获取与需求分析是需求开发过程的两个主要活动
需求获取的难点
1) 用户和开发人员的背景不同，立场不同
2) 普通用户缺乏概括性、综合的表述能力
3) 用户存在认知困境
4) 用户越俎代庖
5) 缺乏用户参与
2，需求获取的活动
1) 研究应用背景，建立初始的知识框架
2) 根据获取的需要，采用必要的获取方法和技巧
3) 现行确定获取的内容和主题，设定场景
4) 分析用户的高（深）层目标，理解用户的意图
5) 进行涉众分析，针对涉众的特点展开工作
需求获取的方法
1) 传统方法:
常见的有问卷调查、面谈、文档分析、文档检查和需求剥离等
2) 集体获取方法：
该类方法将很多涉众集中在一起，通过与涉众的讨论发现需求，并在讨论中达成需求的一致，同时它还可以有效利用时间。常见的优头脑风暴、专题讨论会、JAD（联合应用开发）和JRP（联合需求计划等）
3) 原型：
原型方法在软件系统的很多开发阶段都起着十分重要的作用，其中就包括需求获取。在需求模糊和不确定性较大的情况下，原型方法尤其有效。
4) 模型驱动方法
该类方法都有一个定义明确的模型，模型的定义方式确定了所要收集的的信息类型，模型建立和完善的过程就是进行需求获取的过程。常见的有面向目标的方法、基于场景的方法和基于用例的方法。
5) 认知方法
该类方法起源于知识系统中的知识获取方法，以认知的方式获取用户无法表达的潜在知识。常见的优任务分析和协议分析等。
6) 基于上下文的方法
前面5种方法基本都以用户的语言表达为主要关注点，相比之下基于上下文的方法更加注重用户在一定环境下表现出来的行为，通过分析用户的行为得到信息。常见的有观察、民族志和话语分析。
需求获取的来源
1) 涉众：包括用户、客户、领域专家以及市场人员、销售人员等其他用户替代源。
2) 硬数据：包括登记表格、单据、报表等定量文档，以及备忘录、日志等定性文档。
3) 相关产品：包括原有系统、竞争产品及协作产品（和解系统存在接口的其他软件系统）。
4) 重要文档：包括原有系统的规格说明、竞争产品的规格说明、协作产品的规格说明及客户的需求文档（委托开发的规格说明、招标书）。
5) 相关技术标准和法规：包括相关法律、法规及规章制度，行业规范、行业标准及领域参考模型。
什么是涉众
所有对软件系统开发和应用具有发言权和决定权的人统称为涉众。
定义：所有能够影响软件系统的实现，或者会被实现后的软件系统所影响的个体和团体。
涉众的分类
客户、用户、领域专家、开发者、管理者、市场、法律、法规、政策、标准、规范。
涉众的分析过程
一个典型的涉众分析过程，它从比较容易发现的初始涉众出发，先后执行涉众识别、涉众描述、涉众评估和涉众代表选择4个步骤，最终完成涉众分析的各项任务。
对涉众的深入理解：涉众特征描述，不仅有利于进行项目前景与范围的确定，而且对整个软件开发而言都是重要的参考信息，所有涉众特征描述信息需要记录下来，在项目的各个开发阶段共享使用。
面谈的问题的类型及其优缺点
开放式问题
优点：让被会见者感到自在；会见者可以收集被会见者使用的词汇，这能反应他的教育、价值标准、态度和信念；提供丰富的细节。
缺点：提此类问题可能会产生太多不相干的细节；面谈可能失控；开放式回答会花费大量的时间才能获得有用的信息。
封闭式问题
优点：节省时间；切中要点；保持对面谈的控制；快速探讨大规范问题；得到贴切的数据。
缺点：使被会见者厌烦；得不到丰富的细节；出于上述原因。失去主要思想；不能和面谈者建立友好关系。
面谈的类别及其适用场景
结构化面谈：通常被用来获取一些比较确定或者选择空间比较有限的信息，一些统计性倾向信息的获取也可以使用结构化面谈
半结构化面谈：通常用来在一个基础框架下处理探索性的问题。即会见者对面谈主提有一定的了解，能够建立一个基础框架，并据此制定面谈问题和面谈结构，然后根据探索性需要进行策略的使用和调整。半结构化是在需求中应用最多的一种面谈类型，能够处理大部分需求获取任务。
非结构化面谈：
非结构化面谈较多使用开放式问题。
原型的分类及其用法
水平和垂直的原型
水平原型也叫做“行为原型” (behavioral prototype)，这是我们和业务人员经常谈到的原型 。探索预期系统的一些特定行为，并达到细化需求的目的。当用户在考虑原型中所提出的功能可否使他们完成各自的业务任务时，原型使用户所探讨的问题更加具体化。它更多从业务需求着手，应用在需求阶段。
垂直原型（vertical prototype），也叫做结构化原型或概念的证明，实现了一部分应用功能。当预期实现阶段可能存在技术风险时，可以开发一个垂直原型。比起在软件的需求开发阶段，垂直原型更常用于软件的设计阶段以减少风险。
抛弃型原型或进化型原型
从原型存在生命时机考虑分为抛弃型原型和进行型原型，抛弃型原型不作为最终产品的一部分，只是作为探索性的回答一些需求问题，细化需求并提高需求质量。由于在开发阶段最终将抛弃这些原型，因此不需要花太大力气去建立该原型。
进化型原型是在已经清楚地定义了需求的情况下，为开发渐进式产品提供了坚实的开发基础，作为产品的部分实现。与抛弃型原型的快速、粗略的特点相 比，进化式模型一开始就必须具有健壮性和产品质量级的代码。因此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。一个进化型原型必须设计为易于升级和优化的，因此，你必须重视软件系统性和完整性的设计原则。要达到进化型原型的质量要求并没有捷径。进化型原型一般在处理架构时会采用。
原型的优缺点
要点
准备原型
决定原型方法：抛弃型还是进化型原型？水平还是垂直型原型？
标识需要建模的功能点
制作原型
构建原型是一个迭代的过程，开始先勾画出整个系统的轮廓，例如子系统、模块，然后再是具体模块逻辑、功能、规则等
使用一致的界面样式
评估原型
从流程、数据和业务规则来验证原型是否捕获了用户的需要
使用时需要考虑的地方
好处
1) 使用图形化表现，方便沟通，可以更有效地确认和发现需求
2) 原型允许用户早期交互和反馈
3) 抛弃型原型是一种快速发现和确认不同需求的方法
4) 垂直型原型能够表示现有技术的可行性
坏处
1) 如果业务更关注“怎么做”而不是“做什么”时，使用原型会花费较多时间
2) 原型会误导用户对未来系统有不切实际的期望，例如性能、完整数据、可靠性等
需求分析的方法
1) 传统分析
2) 结构化分析
3) 信息工程
4) 面向对象分析
建模的方法和手段
UML（统一建模语言）是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示。
用例建模：用例图和用例说明描述用户需求。
静态建模：通过类图/对象图描述系统中的对象如何组成系统。
动态建模：描述系统动态行为和控制结构。主要有顺序图、协作图、状态图、活动图。
实现模型：描述了系统现实时的特性，即物理架构，包括组件图和部署图。
预定酒店的例子
1）用例模型
2）用例描述
3）根据用例描述画出类图和交互图
