我的一位客户向我发送了一份要求文件，在阅读该文件时，脑子里浮现出一丝闪光。我开始重写类似下面的大文档。您是否认为，自动化工具可以通过此操作生成数据模型和规则。比如说，如果任何客户通过这种方式传达他们的要求，它将使每个人更好地理解域。
我明白，因为我知道什么是博客，评论和帖子我能够在这里轻松地联系起来。但是，如果以这种方式削减其业务的所有技术条款，那么将每个人放在同一页面上会不容易吗？
修改
我真正想要的是 - 一旦你得到了一份需求文档，如果你创建了一个这里提到的文档，你将能够弄清楚客户正在寻找什么。
另一个优点是您可以使用此文档进一步增强和开发项目。甚至客户也可以直接手工编辑这份文件，因为他现在已经了解了我们如何看待他的要求（我的意思是我们的语言）。
现在，在某种程度上，这些陈述可以用不同的方式解释。
例如，我可以使用一些工具来分析语句并提供信息，例如任何模型更改，规则更改都会进入本文档。
修改
我目前正在尝试在像Order Management这样的复杂模型中遵循这种方法，我将在这里更新我学到的东西。同时，如果你们有兴趣在这里，他们也可以和我一起参与。
答案 0 :(得分：1)
对于像这样的简单案例，也许。
总的来说，我会说不。如果它真的如此简单，它现在就已经完成了，作为一个专业的编程将会结束。执行管理员和中小企业将开发企业系统。
我认为代码生成可以提升，只要您自己编写代码生成器并彻底理解它。但总的来说，我持怀疑态度。我认为难题比你的例子复杂得多。
您所描述的案例似乎是Grails或Ruby on Rails的最佳位置或类似于Microsoft的东西。
答案 1 :(得分：0)
例如，Ruby on Rails提供了这种特定于域的语言。请参阅迁移和ActiveRecord验证。
它提供了系统的一些简单部分，但任何复杂的部分都必须“手动”编码。
答案 2 :(得分：0)
鉴于所有情况都很简单，因为可以使用更高级别的编程语言将内容定义为内部DSL，例如： ruby或scala，或者使用代码生成器作为外部dsl，例如Xtext，MPS，或yacc和野牛。
然而，当结果应该是通用的，同意duffymo时，生成器或抽象可能变得非常复杂。
答案 3 :(得分：0)
现在你采取了错误的做法。两个组（开发人员和客户端）的要求应该是可以理解的，并且应该有一个实例。因此，当需求只改变一个时，您必须只更改一个宫殿/ pice /信息。不是几个文档。此外，任何开发者都可能不会向客户提出问题，因此他必须显示规范（如果应用程序很复杂），这必须是客户端规范。 （我说不，如果）。
也许敏捷方法适合。使用小故事而不是文档。故事应该涵盖一个功能。好处是程序员和客户端使用相同的语言（storys应该使用客户端域语言），客户可以为每个语言指定重要级别。
PS我很害羞这个规格会改变:) 博客20天后无法发表评论PSPS业务逻辑（您的规则）很复杂，远远超出您的简单示例，因此随时与客户联系的可能性（没有邮件！电话或VoIP）非常重要
PSPSPS你知道ORM吗？ http://en.wikipedia.org/wiki/Object-relational_mapping
答案 4 :(得分：0)
请参阅行为驱动开发，可能会为您提供有关规格的DSL的一些想法。 实际上，我正在研究我的硕士论文，它将结合DDD，DSL，BDD和MDSD来实现你的目标。
答案 5 :(得分：0)
我理解您希望采用更加自动化的方法来保持需求与代码同步。 UML是用于建模系统的成熟工具，并且存在许多用于此类和类似语言的代码生成工具。然而，从使用过它们的人那里，我只听过恐怖故事。
需求文档的问题一般是大多数利益相关者并不认为系统是一套精确的，正式的规则。我总是不得不将高级需求转换为较低级别的需求，以使它们对我们的程序员有任何用处，这需要花费大量时间，研究，会议和一些假设。我认为我们无法以自动化的方式弥合这一差距。也许我们注定要失败，应该对任何传递给我们的模糊设计文件感到高兴。