需求规格化

　　需求规格化

　　面向开发人员：规格化需求

　　需求经过客户确认之后，系统分析人员应该开始对需求进一步细化。即使用更加形式化的描述方式为需求建立更加详细的模型，并生成面向开发人员的需求说明书，或者说真正意义上的软件需求分析规格说明书。

　　为了保持良好的同步，建议在文档结构上不做太大的改动。

　　(1)去除图2-1中的第4节，将这部分的内容转到正式的《软件项目计划》中。

　　(2)对“系统功能需求”和“系统数据需求”两个小节进行细化及扩展，以严格的UML模型细化说明。

　　1.用例建模

　　在前一段工作中，我们已经完成了系统用例模型，并且也对每个用例都做了一些简要的说明，并且已经列出关键的事件流。因此在规格化的阶段的主要工作就是对用例进行细化，通过UML的活动图、序列图将用例行为规格化地表示出来。

　　在此，我们以用例“发送通知”为例，说明如何对其进一步规格化，如图2-6所示。

　　用文字描述的事件流，往往阅读起来比较困难，而且容易产生理解上的差异。因此建议读者对于一些相对比较复杂的事件流用UML的活动图建模，如图2-7所示。

　　活动图能够清晰地表现出整个用例的处理过程，其作用与流程图相类似。而在面向对象的分析中，我们需要找到参与的类，以及它们之间所传递的消息，这方面即可采用UML中的序列图。不过实践经验告诉笔者，绘制序列图时一定会引入一些与业务无关的对象，通常会将其放在系统设计阶段来完成。因此笔者认为除非必要，在分析阶段可以不做这方面的细化。

　　2.类建模

　　在前一阶段，我们找到了与业务相关的实体类。接下来应该进一步地细化每个类的主要属性，以及类与类之间的关联关系。而对于类的操作则更多的是系统设计的内容，当然也可以标识出一些重要的操作，如图2-8所示。

　　图2-6 发送通知用例的规格化

　　图2-7 活动图示例

　　图2-8 类模型

　　总而言之，软件需求文档的编写一定要能够有效地解决问题。如果是一个束之高阁的文档，则毫无意义，是浪费开发团队时间之举。本文结合了自己的实践经验，提出了一些想法与思考。希望能够对读者有一些帮助，也欢迎读者与笔者交流。

　　(《中国系统分析员》2004年第1期 徐锋)