Incremental Requirements With Requs

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

需求工程是软件开发中最重要的学科之一。甚至比架构、设计或编码本身还要重要。Joy Beatty和Karl Wiegers在《软件需求》一书中指出,需求规范中的错误成本要远高于源代码中的错误。我完全同意这一观点。

在XDSD项目中,我们使用Requs来指定需求,这是一种听起来像英语的受控自然语言,同时也可以被计算机解析。在Requs中,一个简单的需求文档可能看起来类似于:

这个软件需求规范(SRS)定义了两种类型(DepartmentEmployee)和一种方法UC(也称为“用例”)。

Requs的语法在这里有详细解释。

在任何XDSD项目中,需求工程的主要目标是创建一个完整且不含歧义的SRS文档。负责执行这项任务的人被称为“系统分析师”。本文解释了他或她的主要任务,并讨论了可能遇到的问题。

我们以增量方式修改SRS,而且我们的增量非常小。例如,假设我们有上述提到的示例文档,我是项目中的系统分析师。我的任务都会类似于“SRS中有一个错误,让我们修复它”。

即使是一个建议,它仍然会以对SRS不完整性的抱怨开始。例如:

  • 一个员工的薪水有限制吗?它可以是负数吗?

  • 一个部门可以有多少员工?它可以是零吗?

  • 一个员工可以接受薪水减少吗?

所有这些错误都是针对我提出的。我需要通过改进SRS来修复它们。我的工作流程在每个任务中都是相同的:

  1. Change the SRS

  2. Close the task

让我们逐步尝试一下。

作为一名系统分析师,我的工作是理解产品所有者(也称为“需求提供者”)的需求并记录他们的愿望。在大多数情况下,他们的需求和愿望非常模糊和混乱。我的工作是使它们变得完整和明确。这就是为什么第一步是了解所需内容。

首先,我必须确定产品所有者是谁,然后才能开始工作。产品所有者签署SRS,因此我应该完全关注他的意见。然而,我的工作不仅仅是倾听,还要提出建议。一个优秀的系统分析师可以通过问合适的问题来激发产品所有者的创造性思维。

好的,现在我知道了产品所有者的身份,我需要与他交谈。在XDSD中,我们不会进行任何会议、电话或其他任何形式的非正式交流。因此,我获得所需信息的唯一机制就是通过他的工单。

我将提交新的工单,将其地址指向产品所有者。由于项目中可能有许多产品所有者,我必须提交清楚说明工单是针对特定所有者问题的第一句的工单。接收工单的人将确定最适合回答的人。

因此,在处理单个任务时,我将提出许多问题并获得许多有趣的答案。我将做所有这些工作,以提高我对产品所有者正在开发的产品的理解。

当我理解如何修复SRS时,就是修改Requs文件的时候了。

SRS文档在每个持续集成的构建周期中自动生成。它是从称为.req文件的片段编译而来,这些文件通常位于项目存储库的src/main/requs目录中。

作为系统分析师,我的工作是对其中一些文件进行更改并提交拉取请求以供审查。

GitHub指南解释了如何使用GitHub。然而,简而言之,我需要:

  • 请将以下Markdown段落从英文翻译成中文,不要翻译技术术语和专有名词: “Check out its copy to my computer;”

  • Make changes;

  • 提交我的更改;

  • 将它们推送到我的远程分支;

  • 提交一个拉取请求

无论我编辑哪个文件都无关紧要,因为Requs会自动将所有以 .req 扩展名的文件组合在一起。我甚至可以向目录中添加新文件——它们也会被捕捉到。同样地,我还可以添加带有文件的子目录。

在提交拉取请求之前,我会尝试验证我的更改在语法和语法上是否有效。我将使用与我们的持续集成服务器编译Requs文件到SRS文档的相同方法来编译它们。

但在我编译之前,我需要安装JDK7Maven

之后,我在项目目录中执行以下命令行调用:

输入命令后,我期望看到“BUILD SUCCESS”消息。如果没有看到该消息,说明存在一些错误,我需要修复它们。如果Requs无法编译文件,我的拉取请求将不会被合并,也无法关闭任务。

一旦编译完成,我可以在Firefox中打开SRS。它位于target/requs/index.xml。尽管它是一个XML文件,但Firefox可以将其作为网页进行打开。其他浏览器则无法使用。嗯,Google Chrome可以使用,但只需使用这个小技巧

一旦所有的更改完成,我将提交一个拉取请求。然后,项目经理会指派某人来审查我的拉取请求,并给予反馈。

在大多数情况下,审查者通常会提出至少几个修改建议。一般来说,我的请求会由其他系统分析师审查。因此,我必须回应所有的评论,并确保我的更改能够满足审查者的要求。

我将在本地对同一分支进行额外的更改,并将它们推送到GitHub。拉取请求将自动更新,因此我不需要创建新的请求。

一旦拉取请求对审查者来说足够干净,他将把它合并到“master”分支中。

最后,我的拉取请求被合并了,我回到了任务的所有者那里。我告诉他SRS已经修复,并请求他进行审核。他原来的问题现在应该已经解决了——SRS应该提供所需的信息。

然后,他关闭了任务,项目经理在几小时内付款给我。

附注:还可以查看这篇关于我为Jekyll创建的自定义词法分析器的文章,我为了在这篇博客文章中突出显示Requs语法而创建了它。

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 16:37

sixnines availability badge   GitHub stars