软件需求工程

第1章 软件需求工程概述IEEE 关于软件需求的定义1) 用户解决问题或达到目标所需的条件或能力；（用户的角度 ）2) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。

（软件系统的角度 ）软件需求的分类1)目标需求； 2)业务需求； 3)功能需求； 4)性能需求； 5)约束与限制。

6)软件需求间的层次关系需求规格说明需求规格说明是软件所应满足的全部需求，并可以文档的方式完整和精确陈述这些需求。

一个好的需求规格说明应该具有的特征1)完整性。

2)正确性。

3)可行性。

4)必要性。

5)划分优先级。

6)无二义性。

7) 可验证性。

第2章 软件工程与需求工程软件开发过程模型1) 瀑布式模型2) 快速原型模型3) 渐增式模型4)螺旋式模型5)面向对象的开发模型所谓面向对象就是应用对象、类、继承、封装、消息、对象或类之间的关系等面向对象的概念对问题进行分析和求解的软件开发技术，或者说，是以对象（类）为数据中心、对象之间的动态行为模式作为运行机制的一种问题求解方法。

软件需求工程特点1)有一部分分析工作必须在设计之前进行，而另外一些分析工作则需与其他部分的设计与实现工作并行地进行，因而呈现出非线性的工作方式。

2)软件系统的表达形式在整个开发模型中都是相同的，即面向对象方法中把类及其结构作为系统的表达单元，无论哪一个阶段都以渐增的方式不断地进化或细化这些表达单元。

3)开发模型支持软件的重用。

需求工程对软件开发的影响如下：1)需求是制定项目计划的基础。

2)需求工程所产生的最终产物——需求规格说明——是软件设计和软件实现的基础。

3)需求规格说明也是测试工作和用户验收软件系统的依据。

4)需求规格说明也是软件维护工作的依据。

软件需求的开发和管理过程软件需求的开发和管理过程是由导出、确认和维护软件系统需求规格说明的一系列活动组成的。

根据需求工程开发和管理过程可大致划分需求开发和需求管理两个阶段。

其中需求开发主要产生正式的需求规格说明，需求管理主要是根据需求的变化对需求规格说明的内容及版本进行管理。

第3章需求获取实地收集需求信息面临的困难1)能提出软件需求的用户没有时间与开发人员进行交流和讨论。

2)有时用户不愿意花费太多的时间进行讨论。

3)用户和开发人员考虑自身利益，对需求信息的手机工作采取消极的态度。

4)用户对所面临的工作没有系统的认识和整理，使得开发人员无法整理和分析。

5)开发人员缺乏用户的业务常识，双方交流困难，收集工作难以进行。

实地调查的步骤要想获得充分的用户需求信息，就必须实地进行调查并与用户交流。

实地调查通常分为三个步骤：1)向掌握“全局”的负责人调查。

2)向部门负责人调查。

3)向业务人员调查。

2、3步骤是一个反复的过程，调查前应有提纲，调查要有记录，调查后要核实。

实地收集需求信息的方式开发人员与用户的交流可采取如下几种方式：1)座谈会的方式：参加人数不宜过多，避免拖延会议速度或偏离会议主题，应该有人主持会议，提前发给参加人员有关会议的议题和内容等材料，有助于提高会议效率。

2)书面咨询的方式：由软件开发人员将所关心的和有待澄清的问题以书面形式提交给用户，软件开发人员通过理解和分析用户的回答来收集他们的真正的需求。

3)利用用例表示方法：用例是了解用户的业务流程和澄清含糊细节的好方法。

所谓用例是用于描述软件系统与一个外部“执行者”的交互顺序，体现执行者完成一次任务的过程。

场景的定义及构成所谓场景是指用户与软件系统实现某个目标而进行交互活动过程的描述。

可视为使用系统经历的解释。

由以下几个方面的内容构成：1)执行者2)进入场景前系统状态描述3)执行者的目的4)动作和事件系列（包括正常和非正常事件流）场景的表示场景的表示出了可用自然语言表示外，也可用图形、动画等其它形式。

场景也可与快速原型方法结合使用。

场景可利用一些已有的半形式化的图形表示方法和技术。

1)非形式化的表示：自然语言、结构化语言、图形、动漫画等。

2)形式化的表示：状态图、流程图、时序图、代数描述图等。

场景技术还具有如下特点：1)可把当前系统存在的问题作为实例记录下来。

2)可成为项目相关人员间的共同语言3)由于描述了软件系统的操作，比较具体，易理解性较好4)通过场景使得提出和获得需求的双方之间能建立起相应的理解。

使用场景技术还应注意以下问题：1)场景的数量，场景数量过大，易加大分析和理解的难度。

2)场景的冗余问题，应尽量避免场景描述的内容发生重叠。

3)应防止场景描述的内容冗长。

第4章需求分析需求分析与需求获取的关系：需求分析和需求获取是密切相关的两个过程。

需求分析的基本任务就是提炼、分析和仔细审查已收到的需求信息，找出真正的和具体的需求，以确保所有项目相关人员都明白其含义。

此外，在分析过程中，通过建立软件系统的逻辑模型，发现或找出需求信息中存在的冲突、遗漏、错误或含糊问题等。

需求分析的具体工作包括：1)建立系统关联图；2)构建用户接口原型；3)分析需求可行性；4)确定需求的优先级别；5)需求建模；6)建立数据字典。

上述列举的所有工作要视具体的软件系统规模而施行。

第5章需求建模方法与技术需求建模的概念需求建模是需求分析中最重要的工作。

需求建模主要是根据待开发软件系统的需求利用某种建模方法建立该系统的逻辑模型，也称需求模型或分析模型，以帮助软件开发人员检测软件需求的一致性、完整性、二义性和错误。

需求建模方法的特点1)提供描述手段：描述形式对人员间的交流和继续进行下一步的工作非常重要。

2)提供基本步骤：将问题按先后次序进行分解，每一步集中精力解决某个问题，直至解决所有问题。

需求建模的方法在目前的需求建模方法中，主要使用的描述手段和技术是自然语言、图形符号语言和形式语言等。

SA方法采用分解策略，把大型和复杂的软件系统分解成若干个易于理解和易于分析的子系统。

在分解过程中，被分解的上层是下层的抽象，下层为上层的具体细节。

SA方法的基本思想是按照由抽象到具体、逐层分解的方法，确定软件系统内部的数据流、变换或加工的关系，并用数据流图表示。

复杂的软件系统的描述方法⏹当前系统：已经存在的人工系统⏹目标系统：待开发的计算机系统SA方法的分析步骤如下：1)理解和分析当前的现实环境，以获得当前系统的具体模型。

具体模型必须忠实地反映人工系统的实际情况，软件开发人员在获得需求信息的基础上，利用DFD将现实环境中的人工系统表达出来。

2)建立当前系统的逻辑模型。

从系统的具体模型中抽象出当前系统的逻辑模型，当前系统的逻辑模型应反映当前系统必须满足的性质。

3)建立目标系统的逻辑模型。

主要是分析目标系统与当前系统在逻辑系统的差别，并建立目标系统的逻辑模型。

4)进一步完善目标系统的逻辑模型，完善的工作大致为：①至今尚未说明的处理细节，如出错处理②某些需要的输入/输出格式或用户界面的说明③增加性能需求和其它一些约束限制等状态转换图P60-图5-18、P61-图5-19第6章需求定义需求规格说明的作用需求规格说明的作用主要体现在：1)需求规格说明是软件设计和实现的基础2)需求规格说明是测试和用户验收软件系统的重要依据3)需求规格说明能为软件维护提供重要的信息一个软件系统能否满足用户需求，主要是用户的需求能否全部反映在需求规格说明中。

因此，需求规格说明作为需求工程的最终成果必须具有综合性，必须包括所有的需求，开发人员与客户不能做任何假设。

除了设计和实现的限制，需求规格说明不应包括假设、构造或维护阶段的细节；需求规格说明=技术合同，是软件开发方与用户达成的一致性文档，是基准的规格说明。

需求规格说明的特性软件的开发是以说明为基础的，如果需求规格说明中出现错误或需求不可能实现等都将导致软件开发工作的返工或失败，因此，需求规格说明必须满足各种各样的特性。

1)正确性：需求规格说明中对每一项需求必须准确地陈述。

2)无含糊性：对所有需求规格说明只能有一种明确和统一的解释。

避免自然语言容易导致的含糊性。

3)完整性：每一项需求都必须将所要实现的功能描述清楚，以便软件开发人员获得设计和实现这些功能所需的必要信息。

4)一致性：需求规格说明内部要一致，与其它的规格说明不发生矛盾。

5)可验证性：当需求规格说明中所有的需求都可检测时，则该需求规格说明是可验证的。

6)可行性：每一项需求都必须在已知系统和环境的限制范围内是可以实施的。

7)必要性：每一项需求都会把用户真正所需要的和最终系统所需遵从的标准记录下来。

即每一项需求都是用来授权编写文档的“根据”，要使每项需求都能回溯到某个或某些需求来源。

第8章需求验证需求验证的目的和任务需求验证所包括的活动是为了确认以下几个方面的内容：1)软件需求规格说明是否正确描述了目标系统的行为和特征；2)从其它来源中（包括硬件的系统需求规格说明书）得到软件需求；3)需求是完整的和高质量的；4)需求为进一步的软件开发和测试提供了足够的基础。

上述内容使得需求验证的目的就是要确保需求规格说明具有良好的特性（如完整性与正确性）。

需求验证的任务1)需求认证的任务就是要求各方人员从不同的技术角度对需求规格说明文档做出综合性评价。

2)在收集需求并且编写成需求规格说明文档后进行需求验证并不仅是一个独立的阶段，某些验证活动（如对渐增式软件需求规格说明的初审工作）将在需求获取、需求分析和定义需求规格说明的整个过程中反复进行。

3)大部分需求验证只能通过人工进行检测，以表明需求规格说明将是用户实际需要的系统。

需求验证的内容一般包括：1)一致性：所有需求必须是一致的，任何一条需求不能与其它需求相矛盾；2)完整性：需求必须是完整的，软件需求规格说明应包括用户需要的每一个功能和性能；3)现实性：指定的需求应该在现有的硬件基础或软件技术的基础上是可行的；4)有效性：必须验证需求是正确有效的，确实能解决用户需求间的矛盾。

5)一般可根据软件系统的特点和用户的要求增加一些检验内容，如软件的安全性、可靠性、正确性等。

需求验证方法：主要靠人工技术审查和验证软件需求规格说明、形式化验证方法。

第9章需求管理需求变更的内容主要涉及两个方面一方面是需求变更只对软件系统内部产生影响，而不影响其它需求；另一方面是在原有软件需求的基础上提出扩充软件系统功能的需求，亦即扩展需求。

扩展需求是指在基准的需求规格说明已确定后，又要增添新的功能或进行较大的功能扩充。

控制变更范围扩展的方法：1)把扩充系统的视图、范围和限制等文档化，作业务需求或功能需求的一部分，对新增的每个功能进行评估。

2)利用原型化方法实现扩充部分的预览，以帮助用户与开发人员进行交流和沟通，准确把握用户需求。

3)应充分考虑需求变更的难度，不能一味应和用户需求。

变更控制策略变更控制策略与变更的过程和标准相关。

这些策略描述了变更以何种形式提出、分析和处理。