需求开发在软件开发流程中的地位与日俱增，本文的编写目的在于介绍一种用于需求开发的子过程——需求分析的“伪形式化”方法。
本文内容在需求开发中所处的位置：
需求开发
——需求获取
——需求分析
——需求验证

需求分析阶段中，往往需要确定系统边界、接口模型、信息流等内容，需要开发系统原型 ( Prototype ) ，需要建立一个总体模型。在目前广泛应用的方法中，这些内容往往采用了自然语言描述和一些图来表示，如 Data Flow Diagram, Context Diagram 等。这样的方法有一定的模糊性，并且其后的 Design 可能与 Requirements 发生不一致。下面两张图给出了使用“伪形式化”方法的工作流程以及模型组成。

在“伪形式化”的方法中，一个完整的需求分为两大块，其一是 Initial Requirements ，其二是 Functional Spec。在 Initial Requirements 中的基本任务是：将客户需要及约束文档化，使用 Informal Goal Hierarchy 表达客户的需要，使用非形式化的语句描述约束（包含资源，性能，环境等等），对相关系统属性进行建模，通过 Formal Environment Model 标准化需求等等。而 Functional Spec 则提供一个精确的目标系统行为的黑箱模型。Initial Requirements 与 Functional Spec 的区别如下：
Initial Requirements 是针对项目发起组织的产物，它使用客户域的词汇描述客户需要，它被当作 RFP (Request for Proposal) 使用。
Functional Spec 是针对项目开发组织的产物，它使用问题域 (Problem Domain) 与软件域 (Software Domain) 的词汇描述客户的问题（包含一些目标及约束），它被当作 RFP 的回应。

这里有必要阐明几个概念。
第一个概念是 Logic 及其表达。这里的 Logic 表达牵涉到了一种逻辑符号。之所以使用逻辑符号而非自然语言，就在于逻辑符号可以更加精确的表达需求，带来更加少的逻辑错误，并且提供了一种比编程语言更加原始的表达方式。举一个例子：在一个电梯控制系统中，客户要求：

这句话往往就是作为规范写入我们的文档中的。而如果采用 Logic 的形式，那么就可能是类似于以下的样子：

这种描述很类似于离散数学中的逻辑表达，比起前一种各人有各人理解的自然语言描述来，这是极为精确的，没有二义性可言的。以下是三种表达的例子，分别是自然语言，逻辑表达以及我们这里所用到的表达方式。

第二个概念是 Environment Model。顾名思义，这个 Model 定义的是目标系统与参与者和系统环境之间的关系，其最终也可通过 Context Diagram 反映出来。以下是一个例子：
一个航空售票系统的 Initial Environment Model

经过精化 (Refine) 之后的一个 Environment Model

DEFINITION flight_view
INHERIT time
INHERIT location
IMPORT Subtype FROM type
IMPORT One_to_one FROM function (flight, flight_id)

CONCEPT flight: type
    - -The passenger will choose a flight based on origin,
    - -destination, departure, arrival, and price.
WHERE Subtype (flight, activity)

  CONCEPT origin (f: flight) VALUE (a: airport)
CONCEPT destination (f: flight) VALUE (a: airport)
CONCEPT departure (f: flight) VALUE (t: time_of_day)
CONCEPT arrival (f: flight) VALUE (t: time_of_day)
CONCEPT price (f: flight) VALUE (m: money)
CONCEPT id (f: flight) VALUE (i: flight_id)
   - - The flight id is used by the passenger to find
   - - the flight.
   WHERE One_to_one (id)   - - The id uniquely identifies
                           - - a flight.

CONCEPT airport: type
   WHERE Subtype (airport, location)

CONCEPT flight_id: type

CONCEPT airline: type 
   WHERE Subtype (airline, supplier),
      ALL (f: flight :: SOME (a: airline :: supplies (a, f) ) )
        - - Every flight is associated with an airline.
        - -We are only concerned with commercial flights.
END

第三个概念是 Functional Spec 中的 FUNCTION、MACHINE、TYPE。这些东西用于定义系统中的各个模块。FUNCTION 表示变量域与值域存在的映射关系；MACHINE 表示一个状态机；TYPE 表示一种可有多个实例的类型。它们的定义语法如下：

FUNCTION function_name
--inherit , import , export section
--message definitions
--concept definitions
END

MACHINE machine_name
--inherit , import , export section
--state model definition
--message definitions
--concept definitions
END

TYPE type_name
--inherit , import , export section
--instance model definition
--message definitions
--concept definitions
END

以下是一个 FUNCTION 的例子：

FUNCTION square_root {precision:real SUCH THAT precision > 0.0}
    MESSAGE(x:real) - - anonymous message
        WHEN x >= 0.0 - -  precondition
            REPLY(y:real) - - return value
            WHERE Y >= 0.0 AND                         approximate(y*y,x)
            OTHERWISE REPLY EXCEPTION
                imaginary_square_root
CONCEPT approximate(r1,r2:real)
    - - true if r1 is a sufficiently accurate approximation of r2, based on the value of the precision specified by the user
    VALUE(b: boolean )
        WHERE
            babs(r1-r2)<=abs(r2*precision)
END

可以看到，通过这种方式精确定义了一个功能模块的“黑箱”行为。

第四个概念 Stimulus-Response Diagram。这个 Diagram 用于显示以上三种 Spec Language 的输入、输出流。对于上面的实例 FUNCTION ，有下面的图：

限于篇幅以及个人的理解，目前就写这些。给出一个 Case Study ，供有兴趣的朋友学习。