《软件工程》学习笔记（二）

8.1 需求工程师

  软件工程师的思维方式是做出尽可能简化问题复杂度的假设。计算机科学家的思维方式是将眼前的问题看成是更具一般性问题的特例，数学家更注重精确性。

当代工程师的要求

    1.分析问题和解决问题的能力

    2.人际沟通及交流能力

    3.软件工程知识和技能

    4.应用领域有关知识

    5.书面语言组织和表达能力

优秀需求工程师的目标

     · 识别错误假设

     · 确保一致性

     · 提升依从性

     · 减少彼此误解

     · 提高支持速度和效率

     · 提升客户满意度

     · 撰写优质需求文档

需求工程师要避免的

     · 干扰

     · 沉默

     · 过度规约

     · 矛盾

     · 含糊

     · 向前引用

     · 不切实际与一厢情愿

8.2 需求的定义

什么是需求

  需求，是人们要解决的某个问题或达到某种目的的需要。是系统或其组成部分为满足某种书面规定（合同，标准，规范等）所需要具备的能力。需求将作为系统开发，测试，验收，提交的正式文档依据。

需求的内容

   · 需求是系统为满足客户期望的目标而完成的行为

   · 需求要体现出对问题领域的清晰理解

   · 给出系统的使用场景和上下文

 需求：由系统的存在而使能的应用领域性质。

存在问题的需求描述实例

需求规约

  好的需求是可以度量的，能给出项目成功的必要条件。

· 评估单个需求项的质量：

  准确、正确、明确、可行、可证

· 评估整个需求集合的质量：

  现实、精确、全面、一致

8.7 撰写需求文档

需求文档规格说明

  · 是具有一定法律效力的合同文档

  · 清楚地描述软件在什么情况下，需要做什么，以及不能做什么

  · 以输入/输出、输入到输出之间的转换方式来描述功能性需求

  · 描述经过干系人磋商达成共识的非功能性需求

  · 一般参考需求定义模板，覆盖标准模板中定义的所有条目

  · 作为后续的软件评估依据和变更的基准

需求文档的组织形式

  · 文档需要有逻辑组织结构

    例如：参照IEEE的模板

  · 典型的组织形式包括

    · 按系统能够响应的各种外部环境情况来组织

    · 按系统特征来组织

    · 按系统的响应方式来组织

    · 按所管理的外部数据对象来组织

    · 按用户类型来组织

    · 按软件的工作模式来组织

    · 按子系统的划分来组织

不同风格的SRS的方法总览

用户手册大纲

   · 介绍

     · 产品总览和基本原理

     · 术语和基本特征

     · 展示格式与报表格式的总结

     · 手册的大纲

   · 开始

     · 开始指令

     · 帮助模式

     · 样例运行

   · 操作模式

     · 命令行/对话框/报告

   · 高级特征

   · 命令语法和系统选项

需求规格说明的用户

高质量的需求规格说明的评价标准

     · 正确性 = 经过验证的

     · 无歧义

     · 完整的

     · 可测试 = 可以证明的

     · 可修改的

     · 可跟踪的

     · 易理解

     · 一致的

     · 有序的

     · 项目或产品特定的其他特征

需求规格说明生成过程

   · 创建任何类型的需求规格说明最优先的方式是通过需求数据库生成它

   · 不直接修改规格说明，修改数据库中的需求并且重新生成规格说明

需求规格说明的结构

IEEE-830 SRS模板大纲

IEEE-830 SRS模板第三部分

  在（20：50）模板中，第三部分是最关键的内容，也就是对系统需求的详细的描述。

SRS模板优缺点

总结

 · 尽快开始写需求

 · 确定哪些属性将被用于分类和细化需求

 · 产生一个初始版本来刺激反馈

 · 询问用户往往比咨询专家更有用

 · 撰写需求时需要遵循的法则：

   · 使用简单、直接的语言

   · 撰写可测试的需求

   · 使用定义好的并达成共识的术语

   · 一次只写一项需求

4.1 软件过程

过程的含义

  过程是一组将输入转化为是输出的相互关联或相互作用的活动。

过程方法

  过程方法是系统地识别和管理组织内所使用的过程，保证更有效地获得期望的结果。

软件过程

问题定义：人们通过开展技术探索和市场调查等活动，研究系统的可行性和可能的 解决方案，确定待开发系统的总体目标和范围。

需求开发：在可行性研究之后，分析、整理和提炼所收集到的用户需求，建立完整的 需求分析模型，编写软件需求规格说明。

软件设计：根据需求规格说明，确定软件体系结构，进一步设计每个系统部件的实现 算法、数据结构及其接口等。

软件构造：概括地说是将软件设计转换成程序代码，这是一个复杂而迭代的过程，要求 根据设计模型进行程序设计以及正确而高效地编写和测试代码。

软件测试：检查和验证所开发的系统是否符合客户期望，主要包括单元测试、子系统 测试、集成测试和验收测试等活动。

软件维护：系统投入使用后对其进行改进，以适应不断变化的需求。完全从头开发的 系统很少，将软件系统的开发和维护看成是一个连续过程更有意义。

软件开发管理

  软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、 人员、进度、质量和风险进行控制和管理的活动。

  软件配置管理是通过执行版本控制、变更控制的规程，并且使用合适的配置管理软件， 来保证所有产品配置项的完整性和可跟踪性。

4.2 软件过程模型

软件过程模型的定义

  软件过程模型是对软件过程的抽象描述，是定义任务之间关系和规程和方法。

  常见的软件过程模型：瀑布模型、原型化模型、迭代式开发模型、可转换模型。

瀑布模型

  将基本的开发活动看成是一系列界限分明的独立阶段，这是一种计划驱动的软件过程，有利于规范软件开发活动。

原型化模型

  原型是一个部分开发的产品，用于加强对系统的理解，有助于明确需求和选择可行的设计策略。（看似美丽，实则不现实）

迭代式开发模型

  将描述、开发和验证等不同活动交织在一起，在开发过程中建立一系列版本，将系统一部分一部分地逐步交付。

适用特点：

  更快速地发布产品、追求产品创新、需求不确定性高、需要快速响应用户的变化、关注用户行为。

增量模型：在每一个新的发布中逐步增加功能直到构造全部功能。

迭代模型：一开始提交一个完整系统，在后续发布中补充完善各子系统功能。

可转换模型

  利用自动化的手段，通过一系列转换将需求规格说明转化为 一个可交付使用的系统。

  由于数学方法具有严密性和准确性，形式化方法所交付 的系统具有较少的缺陷和较高的安全性。 • 特别适合于那些对安全性、可靠性和保密性要求极高的 软件系统，这些系统需要在投入运行前进行验证。