软工课程笔记（二）：软件需求管理概要与开发过程（基础）_软件开发 srs生成软件

一、软件需求管理概要

         需求分析是软件工程中的重要步骤，是决定软件项目成败的关键影响因素之一。需求阶段的错误在后期的纠错成本远远高于软件设计和实现阶段的错误的纠错成本。因此，需求工程成为软件工程和系统工程重要的分支领域之一，在需求工程中，我们主要关注的是软件和系统需求的获取、建模、分析、验证和管理。

1.1 需求工程师的职责

需要具备以下能力：

• 分析问题和解决问题的能力（建模和求解）如找出对环境以及系统的错误的假设
• 人际沟通及交流能力（以交流为工具获得用户需求）如提高支持速度和效率
• 软件工程知识和技能（面向开发内部的工作职能需要）如对标准和规范的依从性、减少组织和个人间的误解
• 应用领域有关知识（了解软件功能所解决的问题）如提升客户满意度
• 书面语言组织和表达能力（将需求高效展现出来）如确保描述的一致性、撰写优质的需求文档

1.2 软件需求的定义

• 对外可见的系统特征，有三项主要任务：学习-需求获取、剪枝-需求优选、文档化-撰写需求规格说明书
• 需求作为系统开发，测试，验收，提交的正式文档依据
• 每个“人造物”对于其周遭和作用环境与外部环境的“接口“，该接口即是需求

定义涵盖内容

•  为什么要设计该系统
• 系统由谁使用
• 系统要做什么
• 系统涉及哪些信息
• 对解决方案有何额外限制
• 如何使用该系统
• 质量需达到何种程度

1.3 获取软件需求的主要途径

• 访谈

访谈是需求获取的主要方式，通过当面交流和引导，获取有效信息，例如用户的痛点、用户希望解决的问题、达到什么目的等。

访谈对象的选择很重要，将直接决定需求的有效性，通常会约客户领导、客户接口人、用户进行访谈。不同的角色对软件的期望不一样，收集到的需求点应进行筛选分析再做参考。

• 问卷调查

问卷调查适用于大范围的目标人员调查，可以收集到用户对软件的意见和建议，根据收集到的信息进行统计分析，有助于软件需求的挖掘。

优秀的问卷设计有助于获取高质量的信息，信息收集后可以做多维度的统计分析。

• 现场考察

现场考察是最直接最有效的需求获取方式，深入现场，观察用户的使用场景和遇到的问题，挖掘潜在需求、分析用户的真正所需，必要时可录像或记录，以便后续深入分析。

• 资料查阅

资料查阅是指获取业务相关的资料文献，通过阅读资料挖掘相关的需求点，例如业务流程、SOP、操作手册等。

• 市场调研或竞品分析

市场调研和竞品分析有助于扩展需求、升级需求，学习市场上更好的产品和想法，在原需求的范围内进一步做优化和升级，获得客户的认可。

1.4 软件需求文档的框架

① SRS（软件需求文档）规格说明

• 是具有一定法律效力地合同文档
• 清楚地描述软件在什么情况下，需要做什么，以及不能做什么
• 以输入/输出、输入到输出之间的转换方式来描述功能性需求
• 描述经过干系人磋商达成共识的非功能性需求
• 一般参考需求定义模板，覆盖标准模板中定义的所有条目
• 作为后续的软件评估依据和变更的基准

② SRS的 组织形式

• 文档需要有逻辑组织结构
• 按照待设计的系统它本身的需要合理的有逻辑的方式来组织

③ SRS的风格

• 描述性的自然语言文本
• 从用例模型产生、从需求数据库中产生、从混合模型中生成

 作为用户手册的SRS

• 介绍->开始->操作模式->高级特性->命令语法和系统选项

④ SRS的用户

• 对于市场人员和销售要按需定义优质产品特征应对产品发布
• 对于产品开发人员要按需了解系统具体项目并且开发系统
• 对于测试人员需要按需系统验证，通过测试和用户征询的方式
• 对于不同的国家和地区需要基于产品核心部分，补充本地运行所需的特性

⑤ 高质量SRS及其评价标准

说明：

• 是所有需求的集合
• 描述产品要提供的所有功能
• 是软件系统解决方案的商业合同的基础
• 是测试计划的基础
• 定义产品需求的度量标准
• 是产品需求的跟踪的先决条件
• 影响开发产品的项目计划

评价标准：

• 是所有需求的集合
• 描述产品要提供的所有功能
• 是软件系统解决方案的商业合同的基础
• 是测试计划的基础
• 定义产品需求的度量标准
• 是产品需求的跟踪的先决条件
• 影响开发产品的项目计划

⑥SRS生成过程

• 创建任何类型的需求规格说明最优先的方式是通过需求数据库生成它
• 不直接修改规格说明，修改数据中的需求并且重新重新生成规格说明

⑦ SRS结构

 ⑧ SRS模板

• SRS需要根据预先定义的标准章节模式来组织，即根据模板来撰写
• SRS的模板是的撰写统一的SRS变得简单
• 对于QA人员来说定义SRS指标变得简单
• 模板也适用于业务需求和系统需求
• 模块可以被用于半自动地从需求数据库或者用例模型生成SRS

 

二、软件开发过程

2.1 软件过程概念及其组成

软件过程概念

软件过程是为了获得高质量软件而实施的一系列活动，它包括问题定义、需求开发、软件设计、软件构造和软件测试等一系列软件开发的实现活动。而每一项活动都会产生相应的中间制品。为了保证软件开发过程能够按照预定的成本、进度、质量顺利完成，还需要诸如项目管理、配置管理、质量保证等一系列开发管理活动。通过建立整个组织的质量管理体系，实现对软件开发实现活动的有效控制和质量保证。

软件过程组成

• 问题定义：人们通过开展技术探索和时长调查等活动，研究系统的可行性和可能的解决方案，确定待开发系统的总体目标和范围。
• 需求开发：在可行性研究之后，分析、整理和提炼所收集到的用户需求，建立完整的需求分析模型，编写软件需求规格说明
• 软件设计： 跟据需求规格说明，确定软件体系结构，进一步设计每个系统部件的实现算法、数据结构及其接口等
• 软件构造：概括地说是将软件转换成程序代码，这是一个复杂而迭代地过程，要求根据设计模型进行程序设计以及正确而高效地编写和测试代码
• 软件测试：检查和验证所开发地系统是否符合用户期望，主要包括单元测试、子系统测试、集成测试和验收测试等活动。
• 软件维护：系统投入使用后对其进行改进，以适应不断变化地需求。完全从头开发地系统很少，将软件系统的开发和维护看成是一个连续过程更有意义。

2.2 传统软件工程模型的特点及其使用场合

瀑布模型

        瀑布模型将基本的开发活动看成是一系列界限分明的独立阶段，这是一种计划驱动的软件过程，  有利于规范软件开发活动。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

 特点：

• 1、阶段间具有顺序性和依赖性

• 必须等前一阶段的工作完成后，才能开始后一阶段的工作；前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果

• 2、推迟实现的观点

• 对于规模较大的软件项目来说，往往编码开始的越早，最终完成开发所需时间越长。因为前面阶段的工作没做或做的不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题

  瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现

  清楚的区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想

• 3、质量保证的观点

为了保证所开发的软件的质量，在瀑布模型的每一个阶段都应坚持两个重要做法：每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务；每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
传统的瀑布模型过于理想化，实际的瀑布模型是带"反馈环"的。

优缺点
优点：

• 为项目提供了按阶段划分的检查点
• 当前一阶段完成后，您只需要去关注后续阶段
• 可在迭代模型中应用瀑布模型
• 不适合需求模糊或需求经常变动的系统
• 由于开销的逐步升级问题，它不希望存在早期阶段的反馈
• 在一个系统完成以前，它无法预测一个新系统引入一个机构的影响
• 在用户可能需要较长等待时间来获得一个可供使用的系统，也许会给用户的信任程度带来影响和打击
• 最终产品往往反映用户的初始需求而不是最终需求

原始化模型

        原型是一个部分开发的产品，用于加强对系统的理解，有助于明确需求和选择可行的设计策略。原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。

它允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。

优缺点
优点：

• 克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险
• 适合预先不能确切定义需求的软件系统的开发

缺点：

• 所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下
• 使用前提是要有一个展示性的产品原型，一定程度上可能会限制开发人员的创新

迭代式开发

        软件开发具有迭代性，需要不断地反复尝试，通过比较和选择不同的设计，最终确定令人满意的问题的解决方案。

        迭代式开发是将描述、开发和验证等不同活动交织在一起，在开发过程中建立一系列版本，将系统一部分一部分地逐步交付。迭代式的开发使得软件系统能够逐步的进行交付，开发人员在完成一部分功能之后形成一个产品版本，然后将其发布给用户使用，当用户使用第一个版本的时候开发人员继续开发下一个版本，如此迭代循环。这样做，不仅可以缩短产品的开发周期，还可以更好的获得用户对产品的反馈。

        增量模型和迭代模型是迭代式开发的两种形式。在增量模型中，首先定义一个小的功能系统，然后在每一个新的发布中逐步增加功能，指导构造出全部的功能；在迭代模型中，一开始就提交一个完整的系统，但是每个功能并不完善，然后在后续的发布中，再对其补充完善，下图说明了增量模型和迭代式模型的区别。

增量模型

        增量模型也称渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能

使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。

把软件产品分解成增量构件时，唯一必须遵守的约束条件是，当把新构件集成到现有构件中时，所形成的产品必须是可测试的。

瀑布模型或快速原型模型目标是一次就把一个满足所有需求的产品提交给用户

增量模型把整个软件产品分解成许多个增量构件，分批地逐步向用户提交产品

特点
       增增量模型把瀑布模型的顺序特征与快速原型法的迭代特征相结合，将软件看作一系列相互联系的增量，在开发过程的各次迭代中，每次完成其中的一个增量。

风险更大的增量模型

确定用户需求后就着手拟定第一个构件的规格说明文档，完成后规格说明组转向第二个构件的规格说明文档，同时设计组开始涉及第一个构件

使用该方法将不同的构件并行构建，可能加快工程进度，但将冒构建无法集成到一起的风险

增量模型也称渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能

使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。

把软件产品分解成增量构件时，唯一必须遵守的约束条件是，当把新构件集成到现有构件中时，所形成的产品必须是可测试的。

瀑布模型或快速原型模型目标是一次就把一个满足所有需求的产品提交给用户

增量模型把整个软件产品分解成许多个增量构件，分批地逐步向用户提交产品

特点
增增量模型把瀑布模型的顺序特征与快速原型法的迭代特征相结合，将软件看作一系列相互联系的增量，在开发过程的各次迭代中，每次完成其中的一个增量。

风险更大的增量模型

确定用户需求后就着手拟定第一个构件的规格说明文档，完成后规格说明组转向第二个构件的规格说明文档，同时设计组开始涉及第一个构件

使用该方法将不同的构件并行构建，可能加快工程进度，但将冒构建无法集成到一起的风险

可转换模型

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

可转换模型是采用形式化的数学方法描述系统，并利用自动化手段通过一系列转换，将形式化的需求规格说明变为可交付使用的系统。

2.3 迭代模型特点及其使用场合

        迭代模型是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。即所有功能一起开发，从粗到细，逐步求精。迭代模型适用于需求不甚明确、难度比较大的软件开发。

迭代模型的选择使用条件

• 1、在项目开发早期需求可能有所变化。
• 2、分析设计人员对应用领域很熟悉。
• 3、高风险项目。
• 4、用户可不同程度地参与整个项目的开发过程。
• 5、使用面向对象的语言或统一建模语言（Unified Modeling Language，UML）。
• 6、使用CASE（Computer Aided Software Engineering，计算机辅助软件工程）工具，如Rose（Rose是非常受欢迎的物件软体开发工具。）。
• 7、具有高素质的项目管理者和软件研发团队。

迭代模型的优点

与传统的瀑布模型相比较，迭代过程具有以下优点：

• 1）降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
• 2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
• 3）加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
• 4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。