第一讲
1. 什么是需求分层？为什么要进行需求分层？【P6~P9】
一些基本术语和概念，需求，软件需求工程，需求分析
（1）软件需求包括三个不同的层次—业务需求、用户需求和功能需求，除此之外，每个系统还有各种非功能需求。
业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在前景和范围文档中予以说明。
用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。
功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。
（2）需求具有多个视图，从不同的角度定义不同项目涉众所关注的相同问题。软件需求的层次划分可以满足需求的多视图需要。
具体而言，管理人员或市场营销人员负责定义软件的业务需求，以提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言）。
所有的用户需求都必须符合业务需求，需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。
开发人员则根据功能需求和非功能需求设计解决方案，在约束条件的限制范围内实现必需的功能，并达到规定的质量和性能指标。
2. 需求开发和需求管理是按照什么来划分的？它们各自包含哪些活动？【P9~P10】
按照需求基线来划分的，即：按照某一时刻，对特定版本中已达成一致的需求内容为界限。
它们各自包含的活动有：【参见课本】 3. 好的需求是什么样的？【P15~P16】
单条需求（即需求声明）的特点：【P15】 SRS作为整体应具备的特点：【P16】
4. 如何去理解需求签约以及如何认识？【P25】
客户和开发人员之间合作伙伴关系的核心是就产品的需求达成一致，很多组织把在需求文档上签字作为客户认可需求的标志。
“签字”的核心在于建立需求协议的基线，即某一时刻需求的瞬态图。在需求规格说明书上签字表示，同意这份文档所描述的系统能够满足客户的需求，进一步的变更将在此基础上，依照项目定义的变更过程进行。
在实务操作中，“签字”常出现如下问题：一是客户代表把在需求文档上签字当做毫无意义的仪式；二是开发经理把签字当做冻结需求的方法。这些都是需要规避的，即不能把“签字”当做武器，而应该将之视为项目的一个里程碑，对于签字之前应进行哪些活动，以及签字对将来变更的影响，各方应形成明确一致的理解。
第二讲
要求：弄清楚软件开发过程（书上给了供大家参考的图） 如果让你接收一个软件项目，如何规划开发过程？
1、Understand good practices for requirements engineering
最佳方法是一个有争议的说法：谁能决定什么是“最佳”，他有什么依据？一种决定方法是召集一群行业专家或研究人员来分析来自不同组织的项目。这些专家在其中寻找一些方法，他们的有效性能是和成功的项目联系在一起的，而失败的项目则往往没有很好地时间这些方法，或者根本就没有实践。通过这些这些手段，专家们就那些一直产生良好结果的活动达成一致。这些活动就被称为最佳方法。对于专业软件人员来说，这些活动代表了十分高效的方法，能够提高特定类型或特定条件下项目的成功几率。-P28
软件需求工程推荐方法：-P28 （1） 知识
a) 培训需求分析人员
b) 对用户代表和管理者进行需求培训 c) 对开发者进行应用领域相关的培训 d) 创建术语表 （2） 需求管理
a) 定义需求变更控制进程 b) 成立变更控制委员会 c) 分析需求变更的影响
d) 控制需求版本并为其建立基线 e) 维护需求变更的历史记录 f) 跟踪每项需求的状态 g) 衡量需求稳定性 h) 使用需求管理工具 i) 创建需求跟踪矩阵 （3） 项目管理
a) 选着合适的开发周期 b) 根据需求制订项目计划 c) 重新协商权利或义务 d) 管理需求风险
e) 跟踪需求耗费的人力物力 f) 回顾以往的教训 （4） 获取需求
a) 定义需求开发过程 b) 定义项目前景和范围 c) 确定用户群 d) 选择用户代言人 e) 建立核心队伍 f) 确定用例
g) 确定系统事件和响应
h) 距离进一步需求获取的讨论
i) 观察用户如何工作 j) 检查问题报告 k) 重用需求 （5） 需求分析
a) 绘制关联图 b) 创建原理 c) 分析可行性 d) 确定需求优先级 e) 为需求建模 f) 创建数据字典
g) 将需求分配至各子系统 h) 应用质量功能调度 （6） 编写规格说明
a) 采用SRS模板 b) 确定需求来源 c) 唯一标识每项需求 d) 记录业务规范 e) 定义质量属性 （7） 需求验证
a) 审查需求文档 b) 测试需求 c) 确定合格标准
2、Learn project management
软件项目管理方法和项目的需求过程紧密相关。应根据需求实践的需求来规划项目资源、进度和承诺。需求变更会影响到这些项目计划，因此项目计划应该预先为需求变更和范围过大作一些准备。-P36
3、Follow requirements development process （1）不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。实际上，这些活动是交叉的、递增的和反复的，如图1。-P39
图1
（2）由于软件开发项目和公司文化的多样性，需求开发没有一种单一的、公式化的方法。图2给出了一个可用于很多项目的需求开发过程框架。-P39
图2
其中，前7个步骤主要在项目的前期执行一次。其他步骤在每次版本增补或迭代时都要执行。 注：其中的英文名可以与软件需求工程推荐方法相对应。 4、Be a good analyst 需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者。如图3所示，需求分析员是用户群体与软件开发团队间进行需求沟通的主要渠道。-P41
图3
（1） 需求分析员的工作–P42
a) b) c) d) e) f) g) h) i) （2）
a) b) c) d) e) f) g) h) i) j) （3）
（4）
a) b) c) （5）
a) b) c)
定义业务需求
确定项目涉众和用户类型 获取需求 分析需求
编写需求规格说明书 为需求建模
主持对需求的验证
引导对需求的优先级划分 管理需求
需求分析人员必备的技能–P44 倾听的技巧
交谈和提问的技巧 分析能力 协调能力 观察能力 写作能力 组织能力 建模能力 人机交往能力 创造力
需求分析员必备的知识–P45 a） 除了前面提到的专门技能以及性格特点，需求分析员还需具备从实验
经验中积累的广博知识。其中最基础的是对当代需求管理技术的深刻理解，以及在各种不同的软件开发生命周期环境中应用这些技术的能力。
b） 如果需求分析员能够充分理解项目管理、风险管理和质量工程，则有
助于避免因需求问题导致项目失败。
c） 对于优秀的需求分析员而言，掌握应用领域的知识也是一项重要的能
力。
谁能成为程序员–P47 用户
开发人与那
主题专家（SME）
营造合作的气氛，要达到的目的-P48 客户对产品感到满意
开发组织因产品在商业上去的成就而兴奋
开发团队成员在具有挑战性和高回报的项目中去的的成果而骄傲。
第三、四讲 需求的获取（考试弱化该部分）
视图和范围文档
第五、六讲 需求的分析
1. 什么是原型？为什么用原型？如何看待原型？【P162~P171】
（1）软件原型是所提议的新产品的部分实现或可能的实现。它是软件系统的最初版本，以最少的费用，最短的时间开发出的、以反映最后软件的主要特征的系统。是一个可实地运行的模型，有正式产品的主要特征，但不是全部特征。
（2）使用原型的原因：产品开发初期很难确定用户的需求规格，为了解决用户与开发者之间的鸿沟，以原型(软件产品的样品)为共同语言，实现用户与开发者双向沟通。原型直观、易于理解与沟通，此外，还是解决需求二义性和不完整性的有效方法。具体而言，使用原型的目的有三：【P163】
（3）对原型的理解 原型的好处：
1） 保证产品有较好的可维护性。
2） 改善用户与开发人员的信息交流和思想沟通，给用户修改的机会。 3） 减少或消灭下游返工的可能，改进了瀑布模型的弊病。 4） 原型系统可作为培训环境,有利于用户培训和开发同步。 5） 开发成本降低，周期缩短。
但是创建原型也同时带来了风险：
1） 最大的风险是涉众看到一个正在运行的原型，从而得出产品几乎已经完成的结论。 2） 用户容易陷入重点关注系统的“how（如何）”诸如外观、界面等浮于表面的因素，而忽
略掉在需求阶段本应当重点关注的“what（什么）”方面的问题。 3） 用户容易根据原型的性能来推断最终产品的期望性能。
最后，注意原型不适合做如下开发：嵌入式软件、实时控制软件和科学数值计算软件。 2. 为什么要设定需求的优先级？如何设定优先级？
第七讲 需求Specification
数据字典
1、业务规则是什么？包含哪些内容？
定义：业务规则是对业务的某个方面进行定义或约束的语句。业务规则用于声明业务结构，
或者控制、影响业务的行为。P105
包含内容：事实、约束、动作触发规则、计算、推论、术语表六部分（P105图）
（书上只画了五部分，老师上课讲时补充了“术语表”部分）。
（1）事实：是对业务的真实陈述，常常描述重要业务术语见的关联。事实也称为不变量——关于数据实体及其属性的不可改变的真实情况。
（2）约束：限制了系统或它的用户可以执行哪些操作。有些词和短语可暗示说话人正在描述一项约束，包括：必须、不可以、可以不和只有。项目级的约束应归入软件项目的管理计划中；很多业务规则都会对业务的实施方式施加限制，每当这些约束反映在软件功能性需求中时，必须把相关规则作为这种派生需求的来源进行说明。
（3）动作触发规则：在特定条件下触发某个动作的规则。形如“如果，则”的语句暗示
说话人正在描述一个动作触发规则。
（4）推论：是根据某个条件的真实性得出某些新事实的规则，也称为“推导出的知识”。推论可根据其他事实或从计算中推导出新的事实，常用“如果/则”的句式来表达。
（5）计算：使用特定数学公式或算法进行。
（6）术语表：定义了对业务重要的词汇、短语和缩写。
2、质量属性有哪些？哪些是对用户的质量属性，哪些是对开发人员的质量属性？
用户对产品的工作性能有期望，用户衡量这种性能的特性包括：产品的易用性、运行速度、出错频率，以及处理异常情况的能力。这些特性合起来称为软件质量属性或这两因素，是系统非功能性需求的一部分。P149-150
主要对用户重要的属性
可用性 有效性 灵活性 完整性 互操作性 可靠性 健壮性 易用性
主要对开发人员重要的属性
可维护性 可移植性 可重用性 可测试性
第九讲 需求验证
1、V字模型的概念及思想
V字模型表明测试活动应该与相应的开发活动同时开始。这个模型表明，验收测试以用户需求为基础，系统测试以功能性需求为基础，集成测试以系统的体系结构为基础。
该模型基于“需求驱动”的思想，认为在相应的开发阶段，必须规划测试活动并着手开发初步的测试用例。虽然不可能在需求开发阶段就进行任何测试，因为还没有可以执行的软件，但可以早在开发团队编写代码之前，以需求为基础建立概念性测试用例，以便发现软件需求规格说明和分析模型中的错误、二义性和遗漏之处。P182
以下内容来自百度百科
简介
V模型是在快速应用开发 (RAD，Rap Application Development)模型基础上演变而来，由于将整个开发过程构造成一个V字形而得名。V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。
开发特点
下面介绍v字形开发软件开发和测试的关系，理解V模型具有面向客户、效率高、质量预防意识等特点，能帮助我们建立一套更有效的、更具有可操作性的软件开发过程。
2.1横向特点
左边是设计和分析，是软件设计实现的过程，同时伴随着质量保证活动——审核的过程，也就是静态的测试过程；右边是对左边结果的验证，是动态测试的过程，即对设计和分析的结果进行测试，以确认是否满足用户的需求。如：
1、需求分析和功能设计对应验收测试，说明在做需求分析、产品功能设计的同时，测试人员就可以阅读、审查需求分析的结果，从而了解产品的设计特性、用户的真正需求，确定测试目标，可以准备用例(Use Case)并策划测试活动。
2、当系统设计人员在做系统设计时，测试人员可以了解系统是如何实现的，基于什么样的平台，这样可以设计系统的测试方案和测试计划，并事先准备系统的测试环境，包括硬件和第三方软件的采购。因为这些准备工作，实际上是要花去很多时间。
3、当设计人员在做在做详细设计时，测试人员可以参与设计，对设计进行评审，找出设计的缺陷，同时设计功能、新特性等各方面的测试用例，完善测试计划，并基于这些测试用例以开发测试脚本。
4、在编程的同时，进行单元测试，是一种很有效的办法，可以尽快找出程序中的错误，充分的单元测试可以大幅度提高程序质量、减少成本。
从中可以看出，V模型使我们能清楚地看到质量保证活动和项目同时展开, 项目一启动，软件测试的工作也就启动了,避免了瀑布模型所带来的误区——软件测试是在代码完成之后进行。
2.2纵向特点
水平虚线上部表明，其需求分析、定义和验收测试等主要工作是面向用户，要和用户进行充分的沟通和交流，或者是和用户一起完成。水平虚线下部的大部分工作，相对来说，都是技术工作，在开发组织内部进行，主要是由工程师、技术人员完成。
从垂直方向看，越在下面，白盒测试方法使用越多，到了集成、系统测试，更多是将白盒测试方法和黑盒测试方法结合起来使用，形成灰盒测试方法。而在验收测试过程中，由于用户一般要参与，使用黑盒测试方法。
2、需求验证的方法
（1）需求评审：包括非正式评审和正式评审。分正式评审方法包括同级桌面检查、轮查、走查。正式评审遵循一个固定合理的过程，生成一份报告，主要提交对发现的错误和提出的问题的总结。P184，审查过程和困难见P184-191
（2）测试需求：以功能性需求为基础或者从用户需求推导出来的测试用例，有助于是项目参与者了解系统的预期行为。P192-194
（3）制定验收标准：让用户来设计验收测试，验收标准应评估产品是否满足其文档需求，也应评估铲平是否适用于预期的运行环境。验收测试的中鼎应该是测试预期的使用场景，测试用例的主干过程。P196
3、对需求验证的理解：为什么进行需求验证？验证哪些？如何验证？
验证原因：需求确认活动可以确保需求复合优秀需求陈述的特征（完整、正确、可行、必要、具有优先级、无二义性和可验证），并且符合好的需求规格说明的特征（完整、一致、易修改和可跟踪）。P182
验证内容：P182“注释1”上方的五点 验证方法：见上一题
第十、十一讲 需求管理
1、需求管理的思想和内容
内容：变更控制、版本控制、需求状态跟踪、需求跟踪（P221图）。具体见图上方五点 2、变更控制过程及影响分析
项目负责人通过变更控制过程，可以做出周全的业务决策，这些决策在控制产品生命周期成本的同时，可以提供最高的客户价值和业务价值。P232
客户和其他涉众常常不喜欢遵循一个新的过程，但变更控制过程并不是作出必要修改的障碍，而是一个漏斗和过滤机制，可以确保项目将最合适的需求包含进来。P233
影响分析：是需求管理的一个关键方面，通过对影响进行分析，可以准确地理解提议的变更所涉及到的问题，有助于项目团队就批准哪些提议作出周全合理的业务决策。P242
影响分析分为三个方面P243 3、需求跟踪方法及评估
需求跟踪机制将单个需求和其他系统元素之间的依赖关系和逻辑联系编写成文档，这些元素爆孔各种类型的其他需求、业务规则、系统体系结构等。可跟踪信息为分析提供了便利，可以帮助我们确定如果要实现某一提议的需求变更，必须修改哪些工作产品。P247
需求跟踪方法：联系链、需求跟踪矩阵P252-253 需求跟踪过程P255 4、使用需求管理工具的好处
管理版本和变更、存储需求属性、进行影响分析、跟踪需求状态、访问控制、与涉众沟通、重用需求P259-260
因篇幅问题不能全部显示，请点此查看更多更全内容