第一部分 软件需求的基本概念
*好需求的特征：无歧义、完整、一致、可检验、确定、可跟踪的，正确的，可行的和必要的。
软件开发的目标，简单而言，就是满足用户的需要 。
三种最经常使项目“遇到困难”的因素是：
缺乏用户介入：占所有项目的13%
不完整的需求和规格说明：占所有项目的12% 不断改变的需求和规格说明：占所有项目的12%
三种项目最主要的“成功因素”是：
用户介入：占所有成功项目的16%
高层管理的支持：占所有成功项目的14% 需求陈述清晰：占所有成功项目的12%
高质量的需求过程带来的好处：在开发后期和整个维护阶段的重做的工作大大减少了 。
IEEE软件工程标准词汇表定义需求为：
1. 用户解决问题或达到目标所需的条件或能力。
2. 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条
件或能力。
3. 一种反映上面(1)或(2)所描述的条件或能力的文档说明。
第二章 需求的层次
*需求是多层次的，包括业务需求、用户需求、功能需求和非功能需求。
业务需求反映了组织机构或客户对系统、产品高层次的目标要求，位于需求链中的最顶层，在项目视图和范围文档中予以说明。
用户需求描述了用户使用产品必须要完成的任务，这在实例文档或方案脚本予以说明。 功能需求定义了开发人员必须实现的软件功能，使得用户完成他们的任务，从而满足了业务需求。和非功能需求在SRS中说明。
非功能性的需求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
需求路线图：涉众需要 —〉系统的特性—〉建立软件需求
软件的6个质量特征（非功能性需求）:可靠性,可用性,有效性,可维护性,可移植性,约束。 有效性(Efficiency)
是在规定的条件下，软件性能水平与所使用资源量之间关系有关的一组属性。
可靠性(Reliability)
是与在规定的一段时间和条件下，软件维持其性能水平的能力有 关的一组属性
可维护性(Maintainability)
是与进行指定的修改所需的努力有关的一组属性
约束定义为：对开发人员在软件产品设计和构造上的限制。
第二部分 需求工程与需求工程过程 第3章 主要软件生命周期模型 瀑布模型
快速应用开发模型（RAD） 螺旋模型 RUP
迭代式模型
瀑布模型的优点
客户很容易熟悉该模型。
以有序的方式解决复杂的问题，易于理解，目标简单—完成所需要的活动。 可以严格控制项目进程，使项目管理易于实施。 方便按阶段设置里程碑，便于项目跟踪。
定义了质量控制过程。运用该过程来确定系统的质量。
采用瀑布模型需要具备的项目特征
在系统开发前要对需求有完整、全面、清晰的了解。 上述需求不存在隐含的不可克服的风险。 需求变更不能过于频繁。
不同涉众的需求互相兼容，不存在明显的冲突。 开发团队掌握了解决需求问题的有效方法。 开发期限允许分阶段地串行工作。 RAD模型的优点
采用高效率的开发工具，从而减少了整个产品的开发周期。提高了生产率，降低了
成本。
用户能够持续地参与开发，提高了用户参与程度，从而使用户的满意度上升，保证
了系统能够满足用户的需要。
工作重点从文档转为构建，所见即所得 。
RAD方法包含三个阶段：需求计划阶段，用户描述，构建阶段 采用RAD模型的项目特征
系统可模块化（基于组件的结构）和可缩放。 用户能参与到整个生命周期中。 项目开发周期很短通常约60天。
项目团队熟悉问题领域，能熟练使用开发工具
螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。 螺旋模型的优点
能够及时找到项目存在的风险，避免因为克服不了的困难而造成大的损失。
使用户能够尽早将信息经常反馈给开发人员，保证了产品的正确性和高质量。 可以方便地评估和验证每次迭代的成果；实现从开发到维护的无缝连接。 采用螺旋模型的项目特征
适用于大型项目；更适用于内部开发（指没有外包的开发内容）。 用于新功能、新产品或需要采用新技术时。 收益不确定，项目不能确保成功时。 用户不能确定其需求或需求很复杂时。
Rational统一过程是一种软件工程过程。提供了如何在开发组织中严格分配任务和职责的方法。 目标：按照预先制定的时间计划和经费预算，开发高质量的软件产品以满足最终用户的需求。
*RUP6个核心过程工作流 ：业务建模，需求，分析和设计，实现，测试，部署 *3个核心支持工作流 ：配置和变更管理，项目管理，环境
RUP的优点
降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一
个开发有误的迭代的花费。
降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以
尽早来解决而不至于在开发后期匆匆忙忙。
加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更
有效率。
由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断
细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。
迭代模型与瀑布模型的差别在于风险的暴露时间上
敏捷方法的价值观包括了沟通，简单，反馈，勇气，谦逊
敏捷方法分为三个部分：敏捷项目管理，敏捷需求分析和敏捷软件开发 敏捷思想的核心是人与交流
第4章 需求工程
需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。
*完整的软件需求工程包括需求开发和需求管理两个部分，需求开发的一般过程分为需求获取、需求建模、需求规格说明、需求验证四个阶段，需求管理则主要包括需求基线的建立、需求变更控制以及需求跟踪等活动。
需求工程方法大致分为四类：面向过程、面向数据、面向控制、面向对象。
面向对象的需求工作流包括：问题分析，理解涉众需要，定义系统，管理项目规模，改进系统定义。
软件需求过程的改进具有以下两个主要目标：解决在以前项目或目前项目中遇到的问题；防止和避免你可能在将来的项目中要遇到的问题
面向对象的开发方法强调从问题域的概念到软件程序和界面的直接映射 面向对象的需求工程方法基本步骤：
与用户广泛接触，收集和查看相关资料，对问题域有一个大致的了解。在此基础上，
提炼和标识对象。
描述对象（类）的属性。
描述对象之间的关系，如整体关系和从属关系等。
描述问题域的“场景”，即描述问题域中完成每个任务需要的对象间的协作关系。
第五章 需求获取的方法
获取需求是一个确定和理解不同涉众的需要和约束的过程。
获取需求的方法：面向目标，基于场景，面向方面，面向视点，基于知识。 需求描述语言可分为三种：非形式化、半形式化和形式化语言。
第六章 寻找客户的需求
鱼骨图也称为因果鱼骨图，它是一种以直观的图形找出问题或现象的所有潜在原因
的方法，它有利于追踪出问题的根源。 具有三个典型的优点：
它允许探讨各种类别的原因 它鼓励通过自由讨论发挥创造性 它提供问题与各类原因的直观图
帕累托图的作用：
为80%的问题找到关键的20%的原因；
一目了然地显示出每个原因的相对重要程度；
有助于预防在解决了一些问题后，却使另外一些问题变得更糟的情况。
第7章 理解用户的需要 用户访谈优缺点和使用时机
优点是直接有效、形式灵活、交流深入的宽带通信形式（有文字、有声音、
有图像）。 缺点：
占用时间长：通常要访谈的人比较多，语言交流会占用大量时间。 信息存在片面性：用户代表经常各执一词，导致收集的信息无法代
表所有用户的想法，从而导致偏差的出现。
用户访谈是需求获取中的主要技术，只要有可能，就应该尽可能多地进行用户访谈。
*情节串联板是通常就是一系列图片，通过这些图片讲故事。一种很生动的技术，它经常被称为原型法。（强调借助原型来加速需求获取过程）
情节串联板就是使用工具向用户（主角）说明（有时是动画演示）系统如何适应组织的需要，并表明系统将如何运转。
类型：被动式、主动式和交互式。
其复杂度依次递增
被动式通常由草图、图片、屏幕截图、幻灯片等组成。 主动式试图使用户能够看到类似“电影样片”。可以自动播放的，描述系统在
典型用法和典型场景中的行为方式。 交互式让用户能体验系统的行为。系统需要用户的参与才能继续运行。可以
是仿真器、实物模型甚至是抛弃式原型。
静态工具：纸和铅笔、白板、即时贴、powerpoint等。 动态工具：Flash、Macromedia Director和其他动画工具。
第8章定义系统
项目范围涉及三个要素：项目所要提交的功能，项目可用资源，实现项目可用的时间。 第9章 管理客户
在你与客户协商时，要遵循这样的原则：少承诺，多提交。 第11章 结构化分析建模
分析模型必须达到三个主要目标：描述客户的需要；建立创建软件设计的基础；定
义在软件完成后可以被确认的一组需求。
在分析模型的核心是“数据字典”，包含了软件使用或生产的所有数据对象描述的中
心库。围绕着这个核心有三个层次的子模型，数据模型、功能模型和行为模型。
数据流图服务于两个目的：
指明数据在系统中移动时如何被变换； 描述对数据流进行变换的功能(和子功能)。
数据模型
数据建模回答与任何数据处理应用相关的一组特定问题 数据模型包含三种互相关联的信息：数据对象、描述数据对象的属性和数据对象相互连接的关系。
用于对复杂数据数据分析和建模：E-R图
*商业建模的步骤
第一步，从涉众中找出用户。并定义这些用户之间的关系。 第二步，找出每个用户要做的事，即业务用例。 第三步，利用业务场景图帮助分析业务流程。 第四步，绘制用例场景图。
第五步，从第三步或第四步中绘制的活动图中找到每一步活动将使用到的或产生的
结果。
第六步，在上述过程中，随时补充词汇表。它包括所有业务词汇，专业词汇等一切
在建模过程中使用到的需要解释的名词。
第七步，根据涉众的期望评审建立好的模型，确定业务范围，决定哪些业务用例在
系统建设范围内 。
上述的步骤 是可以迭代的
业务角色是实现业务用例的人，业务主角是和业务有关的人
用例驱动是RUP的特征。各种类型的开发活动包括项目管理、分析设计、测试、实
现等都是以系统用例为主要输入工件，用例模型奠定了整个系统软件开发的基础 用例图使我们对系统的功能有了一个整体的认知，我们可以知道有哪些参与者会与
系统发生交互，每一个参与者需要系统为它提供什么样的服务。
用例方法完全是站在用户的角度上（从系统的外部）来描述系统的功能的。 使用用例的方法来描述系统的功能需求的过程就是用例建模。 用例模型是由用例图和用例规约所组成的。
对用例模型进行检查，可以从几个方面进行：功能需求的完备性；模型是否易于理解；是否存在不一致性；避免二义性语义。
用例模型主要用于描述系统的功能性需求，对于其他的非功能性需要用其他文档来记录。
用例的粒度不但决定了用例模型级的复杂度，而且也决定了每一个用例内部的复杂度。
用例间的关系 ：关联关系,包含关系,扩展关系,泛化关系 第15章 原型开发
候选原型方法的因素：软件应用领域、软件应用复杂性、客户特征、以及项目特征。 为了导出快速原型，可采用第四代技术、可复用软件构件、形式化规约和原型环境。
抛弃式原型。将开发原型看做是沟通工具，永远也不会将一次式原型引入正式运行环境中。主要解决需求的不确定性，二义性，不完整性等。 进化式原型。会在未来的系统中包含的原型。这种方法能够将最大量的工作投入到正式系统中。
水平原型也称为行为原型，用来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通常只是功能导航，并未真实实现功能。主要用在用户界面上。
垂直原型也称为结构化原型，实现了一部分功能。主要用在复杂的算法实现上。
软件原型的典型应用 抛弃型 进化型 水平 澄清并细化用例和功能需求 实现核心的用例 查明遗漏的功能 根据优先级，实现附加的用例 探索用户界面 开发并细化Web应用 垂直 证明技术的可行性 实现并优化核心算法 需求文档的编写原则
句子和段落要短 。
要检查需求是否被有效地定义 。
需求编写者还要努力正确地把握细化程度 。 密切关注合成了多个需求的单个需求。 通篇文档细节上要保持一致 。
*高质量的SRS的一些特性
完整性 一致性 可修改性 可追踪
第17章 需求验证
需求验证所包括的活动是为了确定以下几方面的内容：
软件需求规格说明正确描述了预期的系统行为和特征。 从系统需求或其它来源中得到软件需求。 需求是完整的和高质量的。 所有对需求的看法是一致的。
需求为继续进行产品设计、构造和测试提供了足够的基础。
需求验证确保了需求符合良好特征并且符合需求规格说明的良好特性。
需求评审为涉众们提供了在特定问题上达成共识的方法。 评审类型：评审、检察、走查。
进行成功的评审有几个关键要素：理解评审流程；确保评审员理解自己的角色；指
定协调员；使评审保持简短，严格按照议程进行；确定问题，而不要解决问题。
分层次评审
目标性需求：企业的高层管理人员所关注
定义了整个系统需要达到的目标
功能性需求：企业的中层管理人员所关注
定义了整个系统必须完成的任务
操作性需求：企业的具体操作人员所关注
定义了完成每个任务的具体的人机交互
*能力成熟度模型CMM
第21章 管理变更
需求的变化是永恒的。因而，对于需求变更应该正确对待，尽量将其负面影响降低。 需求变更可能来自解决方案提供商、客户或产品供应商等外部因素，也可能来源于
项目组内部。
需求变更的因素
对需求的理解存在分歧，系统实施时间过长，用户业务需求改变，系统正常升级
*需求变更管理实践中的对策
优先排序，分批实现 相互协作，充分交流 合同约束，区别对待 选用适当的开发模型 用户参与需求评审
需求跟踪提供了一个表明与合同或说明一致的方法。更进一步，需求跟踪可以改善
产品质量，降低维护成本，而且很容易实现重用。 需求跟踪链使你能跟踪一个需求使用期限的全过程。
通用的跟踪模型显示了我们要在软件开发的不同层面全面地跟踪需求。 分析建模： 案例：销售软件
从用户调查中了解到某高校向学生销售教材的手续是：先由系办公室的张秘书开一购书证明，学生凭证明找教材科的王会计开购书发票，向李出纳员交付书款，然后到书库找赵保管员领书。现欲将上述手工操作改为计算机处理，按照需求分析的步骤对销售软件做需求分析。 1.通过对现实环境的调查研究，获取当前系统的具体模型；
2.去掉具体模型中的非本质因素，提炼出当前系统的逻辑模型。
3分析当前系统与目标系统的差别，建立目标系统的逻辑模型。
4.通过目标系统的人-机界面，和用户一起确认目标系统功能；确定哪些功能交给计算机去做，哪些功能由人工完成。 5.复审需求说明，补充迄今尚未考虑过的细节，例如确定系统的响应时间，增加出错处理等。
把案例改画成DFD图
现有2个加工（审查并开发票，开领书单），4个数据流（购书单，发票，领书单，
无效书单），数据的源点和终点都是“学生”。但没有数据文件。实际上在审查购书单和开出发票之前，至少要查阅两个文件：①各班学生用书表，用以核对学生是否需用这些教材；②教材存量表，了解有没有该生要买的教材。把这两个文件加进图二
中，并给加工添上编号，就得到计算机售书系统的完整的DFD
DFD的绘制步骤
1. 找出外部实体，确定系统边界
2. 从数据源出发，按系统的逻辑需求，逐步画出加工框，直至数据终点 3. 为了控制系统复杂度，DFD分层，自顶向下，逐步求精 4. 对DFD进行复审
行为模型——状态转换图（STD）
大多数商业系统是数据驱动的，所以，适合于使用数据流模型。但是，实时控制系
统却主要是事件驱动的，因此，行为模型是最有效的系统行为描述方式。 状态转换图(STD)指明作为外部事件的结果，系统将如何动作，它表示了系统的各种
行为模式(称为“状态”)以及在状态间进行变迁的方式，STD 是行为建模的基础。
因篇幅问题不能全部显示，请点此查看更多更全内容