软件项目需求管理
2.1软件需求\r\n2.1.1软件需求概念\r\n1.定义\r\n 软件需求是系统或软件必须达到的目标和能力。是指用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。\r\n1997年版IEEE软件工程标准词汇表需求定义如下：\r\n用户解决问题或达到目标所需的条件和能力。\r\n系统或系统部件要满足合同、标准、规范或其他正式文档所需具有的条件或能力\r\n一种反映上面第一点或第二点所描述的条件或能力的文档说明\r\n以下五项内容确定一组完整的软件需求：\r\n（1）系统的输入\r\n（2）系统的输出\r\n（3）系统的功能\r\n（4）系统的属性\r\n（5）系统环境的属性
2.软件需求在软件项目中的作用
2.1.2软件需求分类\r\n1.软件需求的抽象层次
原始问题描述
用户需求
系统需求
软件设计描述
原始问题空间
解决方案空间
2.用户需求\r\n从用户的角度描述系统的需求，对系统的原始问题的描述。\r\n是用自然语言和图表描述的关于系统需要提供的服务及系统的操作约束。\r\n\r\n\r\n3.系统需求\r\n比用户需求更为详细和专业的需求描述。\r\n是系统功能描述的基础，可成为用户和软件开发组织之间协议的基础。
4.系统需求的分类\r\n（1）功能需求\r\n 功能需求描述系统所应提供的功能和服务，包括系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述。\r\n 理论上，功能需求应具备全面性和一致性。\r\n（2）非功能需求\r\n 非功能需求是指不直接与系统的具体功能相关的一类需求，但与系统的总体特性相关，如可靠性、响应时间、存储空间、知识产权等。\r\n 非功能需求分为三类：产品需求、机构需求、外部需求；\r\n 功能需求得不到满足会降低系统的能力，但非功能需求得不到满足则有可能使系统无法运行。\r\n（3）领域需求\r\n 领域需求的来源不是系统的用户，而是系统应用的领域，反应了该领域的特点。
2.1.3 软件需求文档\r\n1.需求文档的编制与作用\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软件开发人员 理解开发的产品和内容\r\n软件测试人员 验证系统是否满足要求\r\n软件维护人员 理解软件系统内在逻辑关系\r\n软件发布人员 编写用户文档\r\n软件培训人员 编写培训材料
2.软件需求说明书\r\n（1）基本含义\r\n 软件需求规格SRS（Software Requirement Specification）也称为功能规格说明、需求协议或系统规格说明。\r\n 是精确阐述一个软件系统必须提供的功能和性能以及所要考虑的限制条件， 是对外部行为和系统环境（软件、硬件、通信端口和人）接口的简洁完整的描述性文档。\r\n 是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。为软件项目管理者提供项目规划和管理的依据。\r\n 被作为是用户的使用手册或帮助用户理解系统的文档。实现用户、分析员和设计人员之间的通信。\r\n SRS 的基础内容：功能需求和非功能需求。\r\n（2）IEEE标准830-1998 需求规格说明结构：\r\na.引言\r\n a.1需求规格的目的\r\n a.2软件产品范围\r\n a.3定义、首字母缩写词与缩略语
a.4参考文献\r\n a.5文档概要\r\nb.一般描述\r\n b.1产品透视\r\n b.2产品功能\r\n b.3用户特征\r\n b.4一般约束\r\n b.5假设和依赖性\r\nc.专门需求\r\n c.1包括功能需求、非功能需求和领域需求\r\nd.附录\r\ne.索引
（3）SRS大纲\r\n\r\na.软件项目概述\r\n\r\nb.一般限制\r\n\r\nc.假设与相关性\r\n\r\nd.用户界面\r\n\r\ne.具体要求\r\n\r\nf.附录
例:需求规格说明书主要内容
1、引言\r\n1）文档的范围和目的\r\n2）概述 （1）目标 （2）约束\r\n2、功能和数据描述\r\n1）系统结构 （1）系统结构关系图 （2）系统结构关系图的描述\r\n3、子系统描述\r\n1）子系统N的规格说明 （1）结构流图 （2）系统模型说明 （3）性能说明 （4）设计约束条件 （5）分配系统部件\r\n2）结构字典\r\n3）结构互连图及说明\r\n4、系统建模和模拟\r\n1）用于模拟的系统模型\r\n2）模拟结果\r\n3）特殊性能\r\n5、项目问题\r\n1）开发成本\r\n2）进度安排\r\n6、附录
2.1.4软件需求度量\r\n 度量的时机：在软件需求规格说明书建立后，需对软件需求进行度量。\r\n 软件需求质量度量的九元素：\r\n1.正确性\r\n 每条需求都代表了构建软件系统所要完成的事情。\r\n 问题：列出的需求与用户需求没有交集；没有完全理解用户的需求；添加了用户没有要求的需求。\r\n2.无歧义\r\n 用户和开发人员对需求的描述和解释没有歧义（只有一种解释）。\r\n3.完备性\r\n 需求描述了用户关心的所有有意义的需求（软件系统对实现中所有情况下所有有实际输入的响应）。\r\n 包括：功能、性能、设计约束、属性及外部接口需求，图、表、名词等定义提供完整的引用和标记。
4.一致性\r\n 任意两个需求的子集之间没有矛盾。\r\n5.根据重要性和稳定性分级\r\n 避免资源不足等环境需求不足。\r\n6.可验证性\r\n 在以后的过程中，存在一个有限的、经济的方法可以测试它是否得到满足。\r\n7.可修改性\r\n 每一需求易于完整、一致的进行变更，且不改变需求集的结构和风格。\r\n8.可跟踪性\r\n 每条需求都是可溯源的（来历清楚）。在对需求变更时，便于评估其影响的范围和程度。\r\n9.可理解性\r\n 用户和开发人员都能完全理解它的整体行为、所提供的功能及其中每条需求的含义。
2.2需求工程\r\n2.2.1需求工程产生与发展\r\n1.产生\r\n 软件需求不再仅限于软件开发的最初阶段，而是贯穿于软件项目开发的整个生命周期。是软件工程的子领域。\r\n 定义：需求工程是一个包括创建和维护需求文档所必需的所有活动的过程，是将用户非形式化的软件需求转变为形式化的需求规格说明的过程。\r\n 另一个定义：需求工程是应用已证实有效的技术、方法确定用户需求，进行需求分析，帮助分析人员理解问题并定义目标系统的所有外部特征的一门科学。\r\n2.发展\r\n（1）对象化\r\n 是指需求模型及其构造方法的对象化。\r\n（2）形式化\r\n 是具有严格数学基础的描述系统特征的方法，具有准确、无二义性的特点，有助于验证有效性和完整性。\r\n（3）自动化\r\n 随着软件工程的自动化程度的提高， 需求工程逐渐进入自动化。
2.2.2需求工程研究内容\r\n1.需求工程的目标\r\n 两个主要任务：\r\n（1）通过对问题及其环境的理解、分析和综合，建立分析（系统）模型；\r\n（2）在完全弄清用户对软件系统的确切要求的基础上，用SRS(Software Requirement Specification)把用户的需求表达出来。\r\n2.需求工程的层次分解\r\n 需求工程分为需求开发和需求管理（之间有界限）。
需求工程过程:\r\n需求获取及分析、需求记录、需求验证、基准需求规格；\r\n需求变更、版本控制、需求状态及跟踪。
2.3需求管理\r\n2.3.1需求管理的必要性\r\n1.需求供求双方固有的矛盾\r\n 软件专业人员的技术性导致需求供求双方达成共识困难。\r\n2.需求具有易变性难以表达性\r\n 软件项目中40%-60%的问题都是在需求分析阶段埋下的祸根。
3.需求错误出现的高频性和修复的高昂成本\r\n 需求的错误，如果在软件项目进行到后期才发现，修复费用是非常可怕\r\n的，甚至会超出项目本身的费用。在维护阶段修复的成本是需求阶段修复成\r\n本的100-200倍。
需求阶段
设计阶段
编码阶段
单元测试阶段
集成测试阶段
维护阶段
软件缺陷修复成本
200倍
2.3.2 需求管理的目标和原则\r\n1.需求管理的目标\r\n（1）使软件需求受控，并建立供软件工程和管理使用的需求基线。\r\n（2）使软件计划、产品和活动与软件需求保持一致。\r\n2.需求管理的原则\r\n 需求管理遵循的五条原则：\r\n（1）需求一定要分类管理\r\n（2）需求必须分优先级\r\n（3）需求必须文档化\r\n（4）需求一旦变化，就必须对需求变更的影响进行评估\r\n（5）需求管理必须与需求工程的其他活动紧密整合
2.3.3需求管理活动\r\n 需求管理的活动贯穿于整个软件项目过程，需求管理规划内容：\r\n（1）需求识别\r\n（2）变更管理过程\r\n（3）需求跟踪\r\n（4）自动化工具\r\n 需求管理是一个对系统需求变更了解和控制的过程。\r\n 初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的草稿版本，需求管理活动就开始了。\r\n 需求管理活动\r\n需求管理活动 活动的任务\r\n变更控制 建议需求变更并分析其影响，做出是否变更的决策\r\n版本控制 确定单个需求和SRS的版本\r\n需求跟踪 定义对于其他需求及系统元素的联系链\r\n需求状态 定义并跟踪需求的状态
2.3.4需求变更管理\r\n1.需求变更的原因\r\n（1）在项目的早期所有的问题不可能被完全定义；\r\n（2）随着软件项目的进行，软件开发人员对问题的理解会发生变化。\r\n2.变更管理过程\r\n 需求变更的管理和裁决机构：\r\n 变更委员会：由软件项目风险承担者组成，负责需求变更的管理工作。\r\n 变更管理过程分为三个阶段：\r\n（1）变更描述\r\n 要对问题或变更提议进行分析以检查它的有效性，进而产生一个更明确的需求变更提议。\r\n（2）变更分析\r\n 对被提议的变更产生的影响进行评估。\r\n（3）变更实现\r\n 执行变更。
3.变更影响分析\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被影响的其他需求\r\n被影响的其他任务\r\n要变更的计划及文档
2.3.5 需求文档版本\r\n 需求文档版本控制就是保证人人得到的是最新的需求文档版本和记录需求的历史版本。\r\n 需求文档版本控制必须保证如下三点：\r\n 统一确定需求文档的每一个版本,保证每个成员都能得到当前的需求版本；\r\n 清楚地将变更写成文档，并及时通知到项目开发所涉及的人员；\r\n 为尽量减少困惑、冲突、误传、应只允许指定的人来更新需求文档。\r\n2.3.6 需求状态\r\n1.需求的属性\r\n 除描述需求要实现功能的文本属性以外，还需要为需求提供背景资料和上下文关系的信息，即需求的属性。\r\n2.需求状态\r\n 需求状态是指某时间点需求的一种情况反映。\r\n（1）已建议（2）已批准（3）已拒绝（4）已删除\r\n（5）已设计（6）已实现（7）已验证 （8）已交付\r\n 在整个软件开发过程中，跟踪每个需求的状态是需求管理的一个重要方面。
2.3.7需求跟踪\r\n1.需求跟踪的必要性\r\n 需求跟踪的目的是建立和维护从用户需求开始到测试之间的一致性和完整性。\r\n2.可追溯性信息\r\n 进行需求跟踪，就要对需求和需求之间以及需求和系统设计之间的许多关系进行追溯。需求维护的可追溯性信息有三类：\r\n（1）源可追溯性信息（提出需求的原因和项目相关人员）\r\n（2）需求可追溯性信息（需求文档中彼此依赖的需求）\r\n（3）设计可追溯性信息（需求对实现的设计模块的关系）\r\n3.需求跟踪的实现\r\n 良好的需求跟踪能力可以减少软件生存期的费用，但在短期之内会造成开发成本的上升。需求跟踪有两种方式：正向跟踪和逆向跟踪。\r\n 常用方法：需求链和需求跟踪距阵。\r\n4.需求跟踪的作用\r\n 需求跟踪提供了一个表明与合同或说明一致的方法。其作用表现如下：\r\n（1）在需求验证中的作用
（2）有助于需求变更影响分析\r\n（3）便于需求的维护\r\n（4）便于测试时找出问题所在\r\n（5）便于项目跟踪\r\n（6）减小项目的风险\r\n（7）简化了系统的再设计\r\n（8）易于软件重用\r\n2.4 需求管理质量保证\r\n2.4.1 需求验证\r\n1.需求验证过程\r\n 需求验证分析需求规格说明的正确性和可行性，检验需求能否反映客户的意愿。\r\n 需求验证可按如下四个步骤进行：\r\n（1）审查需求文档\r\n（2）依据需求编写测试用例\r\n（3）编写用户手册
（4）确定合格的标准\r\n2.验证的内容\r\n 对需求文档中定义的需求执行多种类型的检查。\r\n（1）有效性检查\r\n（2）一致性检查\r\n（3）完整性检查\r\n（4）现实性检查\r\n（5）可检验性检查\r\n（6）可跟踪性检查\r\n（7）可调节性检查\r\n（8）可读性检查\r\n2.4.2 需求评审\r\n1.评审方式\r\n（1）正式需求评审\r\n（2）非正式需求评审
需求评审是在需求分析完成后，由用户和系统分析员对需求规格说明书和相关文档，共同进行需求评审。\r\n2.评审注意事项\r\n（1）严格控制每一次评审的文档规模及持续时间\r\n（2）评审工作要分段进行\r\n（3）对讨论的问题进行控制\r\n（4）避免无谓的争吵