功能规范

系统工程规范和开发水平的模型。在系统开发过程中,生成了一系列规格来描述系统的不同细节级别。这些程序独特的规格构成了配置基线的核心。如下所示,除指系统层次结构中的不同级别外,这些基线还在设计过程的不同阶段定义。 SI&T是“系统集成和测试”不是“系统集成和文本”。

系统工程软件开发中的功能规范(还包括功能规格规格功能规格文档(FSD)功能需求规范)是一个文档,它指定了系统或组件必须执行的功能(通常是需求规范的一部分) (ISO/IEC/IEEE 24765-2010)。

该文档通常描述系统用户所需的内容以及输入和输出的请求属性(例如软件系统的)。功能规范是对匹配要求文档的技术响应越多,例如产品需求文档“ PRD”。因此,它取得了需求分析阶段的结果。在更复杂的系统上,多个级别的功能规范通常会相互嵌套,例如在系统级别,模块级别和技术细节级别上。

概述

功能规范不能定义所提出系统的内部工作。它不包括如何实现系统函数的规范。

功能规范中的功能要求可能如下所示:

当用户单击“确定”按钮时,对话框已关闭,并且将焦点返回到显示此对话框之前所在状态的主窗口。

这样的要求描述了外部代理(用户)和软件系统之间的相互作用。当用户通过单击“确定”按钮为系统提供输入时,程序会通过关闭包含“确定”按钮的对话框窗口来响应(或应该响应)。

功能规范主题

目的

功能规格有许多目的。团队项目的主要目的之一是,在制定更耗时的撰写源代码测试案例的努力之前,就该计划要实现的目标达成了某种形式的共识,然后进行了一段时间的调试。通常,在谈判了一种成本效益的方式来满足软件需要满足的要求之后,在项目上的利益相关者进行了一项或多项评论之后,就达成了共识。

  1. 开发人员知道要构建什么。
  2. 让测试人员知道要进行哪些测试。
  3. 利益相关者知道他们得到了什么。

过程

在有序的工业软件工程生命周期(瀑布模型)中,功能规范描述了必须实施的内容。接下来,系统体系结构文档描述了如何使用所选软件环境来实现这些功能。在非工业,典型系统开发中,通常在需求分析的一部分之后或作为一部分之后编写功能规范。

当团队同意达成功能规范共识时,功能规范通常会声明为“完整”或“签名”。之后,通常使用功能规范作为参考的软件开发和测试团队编写源代码和测试用例。在进行测试时,将程序的行为与功能规范中定义的预期行为进行比较。

方法

编写功能规范文档的一种流行方法是绘制或渲染简单的电线框架或精确的,图形设计的UI屏幕截图。完成此操作后,所有利益相关者都可以批准屏幕示例,可以编号图形元素,并在屏幕示例中为每个编号添加书面说明。例如,登录屏幕可以具有标记为“ 1”的用户名字段,并标记为“ 2”的密码字段,然后可以以书面形式声明每个数字故意的。这种方法的好处是,可以将无数的其他细节附加到屏幕示例上。

功能规格的示例

软件开发规格的类型

也可以看看