一、学习目的与要求
- 目的：认识软件需求是一个项目的开端，是软件设计及实现的基础
- 要求：
- 了解软件需求的概念
- 理解需求开发的步骤和活动
- 初步具备编写需求规格说明书的能力
- 掌握需求管理的目标、原则和策略
二、学习内容
1. 需求工程
1. 软件需求概念（次重点）：
（1）用户解决问题或达到目标所需的条件或能力；
（2）系统或系统部件要满足合同、标准、规范或其他正式文档所需具有的条件或能力；
（3）一种反映上面所描述的条件或能力的文档说明。
2.软件需求层次（4个）
- 原始问题描述：对要解决的问题的叙述，是软件基础；
- 用户需求
1. 概念：从用户的角度描述系统需求，它只描述系统外部行为，尽量避免设计系统内部的设计特性；
2. 编写文档原则：标准的格式、使用一致的语言、使用特殊的文本、尽量避免专业术语。 - 系统需求
1. 概念：比用户需求更为详细和专业的需求描述，是系统实现的依据；
2. 一般分为功能需求（描述系统所应提供的功能和服务，具有全面性和一致性）、非功能需求（只那些不直接与系统的具体功能相关的一类需求）和领域需求（来自系统应用领域） - 软件设计描述：在系统需求的基础上加入更详细的内容构成，它作为软件详细设计和实现的基础，是对软件设计活动的概要描述。
3.软件需求质量评价（度量的9个元素）（一般）
- 正确性：需求集 是正确的当且仅当其中每条需求都代办了构建软件系统所要完成的事；
- 无歧义：当且仅当需求只有一种解释；
- 完备性：当且仅当需求集描述了用户关心的所有有意义的需求；
- 一致性：当且仅当任意两个需求的子集之间没有矛盾；
- 根据重要性和稳定性分级：根据级别的高低决定实现的先后；
- 可验证性：当且仅当它所包含的每条需求都是可验证的；
- 可修改性：当且仅当其中每一项需求都能独立地、一致地进行变更；
- 可跟踪性：当且仅当它的每条需求都是可溯源的；
- 可理解性：指用户和开发人员都完全理解未来系统的整体行为。
4. 需求工程发展历程
- 需求工程概念： 是一个包括创建和维护需求文档所必需的所有活动的过程，是将用户非形式化的软件需求转变形式化的需求规格说明的过程。
- 发展历程：
（1）20世纪80年代中期，需求工程（RE）渐渐形成；
（2）20世纪90年代后，成为学术界研究热点； - 发展趋势
（1）对象化；
（2）形式化：需求规格描述方法有形式化方法（准确、无二义性）、非形式化方法（易于理解和使用）和半形式化方法；
（3）自动化；
5.需求工程研究内容
- 需求开发：关注需求的生成，分为4个阶段：
（1）需求获取：确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档；
（2）需求分析：绘制关联图、创建开发原型、分析可行性、确定需求优先级、为需求建立模型、编写数据字典、应用质量功能调配；
（3）规格说明：编写规格说明书，项目试图和范围文档包含了业务需求，使用实例文档包含了用户需求；
（4）需求验证：审查需求文档、依据需求编写测试用例、用户手册，确定系统合格的验收标准。 - 需求管理：关注需求变更的控制，包括变更控制、版本控制、需求跟踪及需求状态更新4个方面。
2.需求开发（重点）
1.需求开发活动
- 确定产品所期望的用户类；
- 获取每个用户类的需求；
- 了解实际用户任务和目标以及这些任务所支持的业务需求；
- 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息；
- 将系统级的需求分为几个子系统；
- 了解相关质量属性的重要性；
- 商讨实施优先级的划分；
- 将所发现的用户需求编写成规格说明和用例模型；
- 平生用例和需求规格说明，确保对用户需求达到共同的理解和认识。
- 需求开发矩阵
| 需求获取 | 需求分析 | 规格说明 | 需求验证 |
|---|
| 编写前景 | 绘制关联图 | 采用软件需求规格说明模板 | 审查需求文档 |
| 确定需求开发过程 | 创建开发原型 | 指明需求来源 | 依据需求编写测试用例 |
| 用户群分类 | 分析可行性 | 未每项需求注上标号 | 确定系统合格的验收标准 |
| 选择产品代表 | 确定需求优先级 | 记录业务范围 | |
| 确定用例 | 为需求建立模型 | 创建需求跟踪能力矩阵 | |
| 联系会议 | 编写数据字典 | | |
| 分析用户工作流程 | 应用质量功能调配 | | |
| 确定质量属性 | | | |
| 检查问题报告 | | | |
| 需求重用 | | | |
2.需求获取（活动和结果如下）
- 确定需求开发过程：确定如何组织需求的收集、分析、细化并核实的步骤；
- 编写项目试图和范围文档：包括高层的产品业务目标；项目试图和范围文档模板如下：
| 1 | 2 | 3 | 4 | 5 | 6 |
|---|
| A业务需求 | 背景 | 业务机遇 | 业务目标 | 客户或市场需求 | 提供给客户的价值 | 业务风险 |
| B项目视图的解决方案 | 项目视图陈述 | 主要特性 | 假设和依赖环境 | | | |
| C范围和局限性 | 首次发行的范围 | 随后发行的范围 | 局限性和专用性 | | | |
| D业务环境 | 客户概貌 | 项目优先级 | | | | |
| E产品成功的因素 | | | | | | |
- 用户群分类：明确客户是谁，最终用户是谁；根据差异性把不同的用户分成用户类；
- 选择产品代表：能真正代表需求并能做出决策的人；
- 建立核心队伍：收集目前产品的功能需求和非功能需求；
- 确定使用实例：收集使用软件完成所需任务的描述；
- 召开应用程序开发联系会议；
- 分析用户工作流程：观察用户执行业务任务的过程；
- 确定质量属性；
- 检查问题报告：进一步完善需求客户的问题报告及补充需求；
- 需求重（chong）用；
3. 需求分析（提炼、分析和仔细审查需求）
- 绘制关联图；
- 创建用户接口原型；
- 分析可行性；
- 确定需求优先级；
- 建立需求模型；
- 编写数据字典；
- 应用质量功能调配。
4. 编写需求文档
- 需求文档的作用
| 使用对象 | 作用 |
|---|
| 客户 | 了解软件项目能够提供软件产品，检查软件需求是否满足需要 |
| 项目管理人员 | 根据需求文档指定项目的开发计划和软件过程，初步预测资源的使用 |
| 软件开发人员 | 理解要开发的产品及具体要开发的内容 |
| 软件测试人员 | 验证软件系统是否满足预期的要求 |
| 软件维护人员 | 使用需求文档帮助理解软件系统内在的逻辑关系 |
| 软件发布人员 | 在需求文档的基础上编写用户文档 |
| 软件培训人员 | 在需求文档的基础上编写培训资料 |
- 软件需求规格说明的基本含义：软件需求规格（SRS）也被成为功能规格说明、需求协议或系统规格说明，精确地阐述了一个软件系统必须提供的功能和性能以及他所要考虑的限制条件，是对外部行为和系统环境接口的描述性文档；
- IEEE标准830-1998：需求说明的标准
5. 需求验证：为了确保需求规格说明准确、完整地表达了必要的质量特点
- 需求验证过程：
（1）审查需求文档；
（2）依据需求文档编写测试用例；
（3）编写用户手册；
（4）确定产品验收合格标准。 - 需求验证内容：
（1）有效性检查；
（2）一致性检查；
（3）完备性检查；
（4）现实性检查；
（5）可校验性检查；
（6）可跟踪性检查；
（7）可调节性检查；
（8）可读性检查。
3. 需求管理（重点）
1. 需求管理的必要性
- 对于软件缺陷，发现和修复的越早，则成本越低，需求阶段出现的错误往往很难发现，所以做好需求管理、减少需求错误的出现对于降低软件项目成本是至关重要的。
2.需求管理的困难性
- 不总是显而易见的，它可来自各个方面；
- 不总是能容易用文字明白无误地表达；
- 存在不同种类需求，其详细程度各不相同；
- 如果不加以控制，需求本身的数量都将难以管理；
- 需求之前相互关联，而且需求也和软件工程流程种的其他交付工作相关；
- 需求有唯一的特征或特征值；
- 需求设计众多相关方面；
- 需求会有变更；
- 需求可能对时间敏感。
3.需求管理的目标和原则
- 目标
（1）使软件需求受控，并建立供软件工程和管理使用的需求基线；
（2）使软件计划、产品和活动与软件需求保持一致。 - 原则
（1）需求一定要分类管理；
（2）需求必须分优先级；
（3）需求必须文档化；
（4）需求一旦变化，就必须对需求变更的影响进行评估；
（5）需求管理必须与 需求工程的其他活动紧密整合。 - 需求管理策略
（1）需求一定要与投入有必然的联系；
（2）需求的变更要经过出资者的认可；
（3）小的需求变更也要经过正规的需求管理流程；
（4）精确的需求与范围定义并不会阻止需求的变更。
4. 需求管理活动
- 建立需求管理规划
（1）需求识别，给需求唯一的标识，以便在上下文中引用；
（2）变更管理过程，确定一个选择、分析和抉择需求变更的过程，所以需求变更都要遵循此过程；
（3）需求跟踪，定义需求之间的关系及需求和设计之间的关系，记录并维护这些关系；
（4）自动化工具，对使用的CASE工具做出选择。 - 需求管理活动（表）
| 需求管理活动 | 活动的任务 |
|---|
| 变更控制 | 建议需求变更并分析其影响，作出是否变更的决策 |
| 版本控制 | 确定单个需求和SRS的版本 |
| 需求跟踪 | 定义对其他需求及系统元素的联系链 |
| 需求状态 | 定义并跟踪需求的状态 |
- 活动内容
（1）确定需求变控制过程；
（2）建立变更控制委员会；
（3）进行需求变更影响分析；
（4）跟踪所有受需求变更影响的工作产品；
（5）建立需求基准版本和需求控制版本文档；
（6）维护需求变革历史记录来记录变更需求文档版本的日期依据所做的变更及原因，还包括由谁负责更新和更新的版本号等；
（7）跟踪每项需求的状态；
（8）衡量需求的稳定性，记录基准需求的数量和每周或每月的变更数量；
（9）使用需求管理工具。
5.需求变更管理
- 需求变革的原因：
（1）在项目早前某些问题不能完全被定义，软件需求是不完备的；
（2）软件开发人员对问题的理解会发生变化；
（3）每类用户可能会有不同的需求和优先次序；
（4）系统客户和系统最终用户很少是同一个人。 - 变革管理过程：
（1）变更描述：始于一个被识别的需求问题或是一份明确的变更提议；
（2）变更分析：对被提议的变更产生的影响进行评估；
（3）变更实现。 - 变更影响分析：一旦发生需求变更，项目的进度、文档代码资源和项目成本都会收到负面影响；
- 变更控制流程
6. 需求状态
- 需求的属性：创建时间、版本、创建者、批准者、状态、原因或根据、涉及的子系统、涉及的产品版本、优先级、稳定性；
- 需求的状态：已建议、已批准、已拒绝、已设计、已实现、已验证、已交付、已删除
7. 需求文档版本控制
- 做好需求文档版本控制，必须注意：
（1）统一确定需求文档的每一个版本，保证每个曾于都能得到当前最新的需求文档版本；
（2）清楚地将变更写入文档，并及时通知到项目干系人；
（3）为尽量减少困惑、冲突、误传，应只允许指定负责人来更新需求文档。
8. 需求跟踪
- 需求跟踪的必要性：有利于确认和评估实现某个建议的需求变更所必需的工作；
- 可追溯性信息：源可追溯性信息、需求可追溯性信息、设计可追溯性信息；
- 需求跟踪的实现：正向跟踪、逆向跟踪；
- 需求跟踪的作用：
（1）在需求验证中，需求跟踪信息便于确保所有需求被应用；
（2）有助于需求变更影响分析；
（3）便于需求的维护；
（4）便于测试时找出问题所在；
（5）便于项目跟踪；
（6）减小项目的风险；
（7）简化了系统的再设计；
（8）易于软件重用。 - 需求评审：
（1）评审方式：正式技术评审（同行评审）、非正式技术评审；
（2）需求评审注意事项：严格控制每一次评审的文档规模及持续时间；评审工作要分段进行；对讨论的问题进行控制；避免无谓的争吵。
4. 需求开发和需求管理的注意事项
1. 需求开发的注意事项
- 项目前景认识一致；
- 需求获取完整和正确；
- 需求分析过程中要注意划分需求优先级；
- 需求规格得到双方一致理解和认可；
2. 需求管理的注意事项
- 需求变更；
- 需求变更过程；
- 未实现的需求；
- 扩充项目范围。
三、小结
- 软件需求是软件设计及实现的基础，对于整个软件项目来说至关重要；
- 软件项目需求管理是对需求的获取、组织及记录过程进行的管理，保证客户与项目开发团队对不断变更的软件需求达成并保持一致；
1852
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
