第二章 软件需求与软件需求规约

 

第一章 软件需求与软件需求规约

软件需求以一种技术形式，描述了一个产品/系统应该具有的功能、性能和其他性质。

2.1 需求与需求获取

2.1.1 需求定义

一个需求是有关一个“要予构造”的陈述，描述了待开发产品/系统（或项）功能上的能力、性能参数或其他性质。

对于单一一个需求，必须具有如下5个基本性质：

（1）必要的（Necessary），该需求是用户所要求的。

（2）无歧义的（Unambiguous），该需求只能用一种方式解释。

（3）可测的（Testable），该需求是可以进行测试的。

（4）可跟踪的（Traceable），该需求可从一个开发阶段跟踪到另一个阶段。

（5）可测量的（Measurable），该需求是可测量的。

2.1.2 需求分类

为了理解、认识软件需求，可以把需求分为两大类：一类是功能需求，一类是非功能需求，而非功能需求又可分为性能需求、外部接口需求、设计约束和质量性质需求。

（1）功能需求。功能需求规约了系统或系统构件必须执行的功能。

一般来说，功能需求是整个需求的主体，即没有功能需求，就没有派生其他功能需求，就没有性能、外部接口、设计约束和质量属性等非功能需求。

（2）性能需求。性能需求（Performance Requirement）规约了一个系统或系统构件在性能方面必须具有的一些特性。

（3）外部接口需求。外部接口需求（External Interface Requirements）规约了系统或系统构件必须与之交互的用户、硬件、软件或数据库元素，其中也可能规约交互格式、时间或其他因素。

接口需求可分为以下主要7类。

1）用户接口（User Interface）：描述软件系统和用户之间交互的逻辑特性，即这类接口需求应规约给定用户所显示的数据，要从用户那里得到的数据以及用户如何控制该用户接口。

2）硬件接口（Hardware Interface）：描述软件系统与硬件设备之间的交互，以实现对硬件设备的响应和控制，其中应描述所要求和支持的协议类型。

3）软件接口（software Interface）：描述与其他软件产品进行的交互。

4）通信接口（Communication Interface）：描述待开发系统与通信设施之间的交互。如果通信需求包含了系统必须使用的网络类型（TCP/IP、Microsoft Windows NT、Novell），那么有关类型的信息就应该包含在该需求描述中。

5）内存约束（Memory constraints）：描述易失性存储和永久性存储的特性和限制，特别应描述它们是否被用于与一个系统中其他处理的通信。

6）运行（Operation）：描述用户如何使系统进入正常和异常的运行，以及在系统正常和异常运行下如何与系统进行交互，其中应描述在用户组织中的运行模式，包括交互模式和非交互模式；描述每一模式的数据处理支持功能；描述有关系统备份、恢复和升级功能方面的需求。

7）地点需求（Site Adaptation Requirements）：描述系统安装以及如何调整一个地点，以适应新的物理环境。

（4）设计约束。设计约束是一种需求，它限制了软件系统或软件系统构件的设计方案的范围。

对系统/产品开发而言，为确定其相关的设计约束，需要考虑以下各方面的问题。

1）法规政策（Regulatory Policies）：通过考虑国际、国内以及各地方、组织的法律和各种不同法规政策，发现系统的设计约束。

2）硬件限制（Hardware Limitations）：通过考虑技术上和经济上的限制，发现系统的设计约束，其中技术上的限制是由当今科技发展情况确定的，包括诸如处理速度、信号定序需求、存储容量、通信速度以及可用性等。

3）与其他应用的接口（Interface to Other Application）：通过考虑与其他应用的接口，发现对新系统的设计约束。

4）并发操作（Parallel Operations）：通过考虑从/至一些不同的源，并发地产生或接收数据的要求，发现相关的设计约束，其中必须清晰地给出有关时间的描述。

5）审计功能（Audit Functions）：通过考虑数据记录或事务记录的需要。例如，对用户修改数据需要记录其执行以便复审，发现相应的设计约束。

6）控制功能（Control Functions）：通过考虑对系统进行远程控制，以及考虑对其他外部软件以及内部过程进行控制的需要，以发现相应的设计约束。

7）高级语言需求（Heigher Order Language Requirements）：通过考虑开发中需要采用一种特定的高级语言来编写系统，以发现相应的设计约束。

8）握手协议（Signal Handshake Protocols）：通过用于硬件和通信控制软件，特别当给出特定的时间约束时，一般就要把“握手协议”作为一项设计约束。

9）应用的关键程度（Criticality of The Application）：通过考虑是否存在潜在的人员损失/上海，或潜在的巨大财政损失，发现相应的设计约束。

10）安全和保密（Safety and Security）：通过考虑系统的安全要求，发现相应的设计约束，其中保密需求通常设计身份验证、授权和加密（数据保护）等。

（5）质量属性。质量属性（Quality Attribute）规约了软件产品所具有的一个性质（包括功能和其他需求）必须达到其质量方面一个所期望的水平。例如

1）可靠性：是指软件系统在指定环境中没有失败而正常运行的概率。

2）存活性：是指当系统的某一部分不能运行时，该软件继续运行或支持关键功能的可能性。

3）可维护性：是指发现并改正一个软件故障或对特定的范围进行修改所要求的平均工作。

4）用户友好性：是指学习和使用一个软件系统的容易程度。

2.1.3 需求发现技术

初始发现需求的常用技术包括以下几个：

（1）自悟（Introspection）。需求人员把自己作为系统的最终用户，审视该系统并提出问题：“如果是我使用这一系统，则我需要……”

（2）交谈（Individual Interview）。为了确定系统应该提供的功能，需求人员通过提出问题/用户回答问题这一方式，直接询问用户需要的是一个什么样的系统。

（3）观察（Observation）。通过观察用户执行期现行任务和过程，或通过观察他们如何操作与所期望的新系统有关的现有系统，了解系统运行的环境，特别是了解要建立的新系统与现存系统、过程以及工作方法之间必须进行的交互。

（4）小组会（Group Session）。举行客户和开发人员的联席会议，与客户组织的一些代表共同开发需求。

（5）提炼（Extraction）。复审技术文档（例如，有关需要的陈诉、功能和性能目标的陈诉、系统规约接口标准、硬件设计文档等），并提取相关的信息。

通过以上对5中需求发现技术的分析，可以得出在实际应用中应注意以下3个问题。

第一个问题：依据需求工程人员的技能和产品、合同的实际情况，往往需要“组合”地使用这些技术来开发初始需求。

第二个问题：在任意特定的环境中，在实施上述任何一项技术时，还都可以辅以诸如原型构造等其他方法，例如，在举行小组会时可以使用原型，方便人员之间的交流。

第三个问题：执行需求发现这项活动的人，其技能水平对这项活动的成功具有重大的影响。

2.2 需求规约

2.2.1 需求规约定义

需求规约是一个软件项/产品/系统所有需求陈述的正式文档，它表达了一个软件产品/系统的概念模型。

需求规约一般要满足以下4个基本性质：

1）重要性和稳定性程度（Ranked for Importance and Stability）：按需求的重要性和稳定性，对需求进行分级，例如：基本需求、可选需求和期望需求。

2）可修改（Modifiable）：在不过多地影响其他需求的前提下，可以容易地修改一个单一需求。

3）完整的（Complete）：没有被遗漏的需求。

4）一致的（Consistent）：不存在互斥的需求。

2.2.2 需求规约（草案）格式

2.2.3 需求规约（规格说明书）的表达

在实际工程中，需求规约的表达主要存在3中不同的风格。

（1）非形式化的需求规约。非形式化的需求规约即以一种自然语言来表达需求规约，如同使用一种自然语言写了一篇文章。其中，可以不局限于该语言所约定的任何符号或特殊限制（例如，文法和词法），但要为那些在一个特定语境中所使用的术语提供语义定义。一般情况下，该语境与通常使用该术语的语境是有区别的。

非形式化的需求规约一般适用于规模比较小的、复杂程度不太高的小型软件项目，活在获取SRS（草案）时使用。

（2）半形式化的需求规约。半形式化的需求规约即以半形式化符号体系（包括术语表、标准化的表达格式等）来表达需求规约。因此，半形式化规约的编制应遵循一个标准的表示模板（一些约定）。其中：

1）术语表明确地标识了一些词，可以基于某一种自然语言。

2）标准化的表达格式（例如，数据流图、状态转换图、实体关系图、数据结构图以及过程结构图等）表示了一些元信息，支持以更清晰的方式系统化地来编制文档。

应用中，不论是词还是标准化的表达格式，在表达上均必须遵循一些约定，即应以一种准确和一致的方式使用之。

（3）形式化的需求规约

形式化的需求规约即以一种基于良构数学概念的符号体系来编制需求规约，一般往往伴有解释性注释的支持。其中：

1）以数学概念来定义该符号体系的词法和语义。

2）定义了一组支持逻辑推理证明规则，并支持这一符号体系的定义和引用。

3）由于形式化语言的表达能力问题，因此在实际工程中，主要针对质量（特别是安全性）要求比较高的软件产品/系统或其中某一部分，采用形式化来表达需求，其目的主要是为了程序的正确性验证。

2.2.4 需求规约的作用

需求规约的作用可概括为以下4点：

1）需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。

2）对于项目的其余大多数工作，需求规约是一个管理控制点。

3）对于产品/系统的设计，需求规约是一个正式的、受控的起始点。

4）需求规约是创建产品验收测试计划和用户指南的基础

需求规约和项目需求是两个不同的概念。需求规约是软件开发组织和用户之间一份事实上的技术合同书，即关注产品需求，回答“交付给客户的产品/系统是什么”；而项目需求是客户和开发者之间有关技术合同-产品/系统需求的理解，应记录在工作陈述（Statement of Work，SOW）中或其他某一项目文档（例如，项目管理计划）中，即关注项目工作与管理，回答“开发组要做什么”。