怎样进行软件需求分析[7]

怎样进行软件需求分析[7]

关键字：软件 需求分析

　　由于形式化规格说明具有很强的严密性和精确度，因此，所使用的形式化语言只有极少数软件开发人员才熟悉，更不用说客户了。虽然结构化的自然语言具有许多缺点，但在大多数软件工程中，它仍是编写需求文档最现实的方法。包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受。图形化分析模型通过提供另一种需求视图，增强了软件需求规格说明。

　　软件需求规格说明不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。许多读者使用软件需求　　规格说明来达到不同的目的：

　　客户和营销部门依赖它来了解他们所能提供的产品。

　　项目经理根据包含在软件需求规格说明中描述的产品来制定规划并预测进度安排、工作量和资源。

　　软件开发小组依赖它来理解他们将要开发的产品。

　　测试小组使用软件需求规格说明中对产品行为的描述制定测试计划、测试用例和测试过程。测试用例模板

　　软件维护和支持人员根据需求规格说明了解产品的某部分是做什么的。

　　产品发布组在需求规格说明和用户界面设计的基础上编写客户文档，如用户手册和帮助屏幕等。

　　培训人员根据需求规格说明和用户文档编写培训材料。

　　软件需求规格说明作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明，那么它将不能作为协议的一部分并且不能在产品中出现。

　　我见过有一个项目突然接到测试人员发出的错误灾难的报告。结果是他们测试的是老版本的软件需求规格说明，而他们觉得错误的地方正是产品所独有的特性。他们的测试工作是徒劳的，因为他们一直在老版本的软件需求规格说明中寻找错误的系统行为。

　　在编写软件需求规格说明，希望读者牢记以下的建议：

　　对节、小节和单个需求的号码编排必须一致。

　　在右边部分留下文本注释区。

　　允许不加限制地使用空格。

　　正确使用各种可视化强调标志(例如，黑体、下划线、斜体和其它不同字体)。

　　创建目录表和索引表有助于读者寻找所需的信息。

　　对所有图和表指定号码和标识号，并且可按号码进行查阅。

　　使用字处理程序中交叉引用的功能来查阅文档中其它项或位置，而不是通过页码或节号。

原文转自：http://www.ltesting.net