我习惯于规划复杂性在于用户交互的软件。我学到的敏捷软件工程原理非常适合这种场景。当大部分计划都围绕用户交互进行时，用户故事很容易写出来。
我现在正在开发一个系统，用户唯一的干预就是点击开始按钮并在发生错误时读取错误。
该系统的所有其他工作都在数据处理和非常繁重的数据处理中。在这个处理工作流程中，我有大约 5 种不同的数据转换要计划。
这些流程本质上是松散耦合的，因此它们应该易于规划为不同的流程，然后进入工作流程。即便如此，规划数据驱动流程的问题仍然存在，但规模较小。
我该如何规划这样的数据驱动流程？此类软件是否有任何已知的设计流程？
相同！
规划和迭代开发的敏捷原则可用于任何类型的项目。这仍然可以是用户驱动的，但您可能必须扩展“用户”的概念。谁将最终使用您正在构建的软件？你自己？技术团队？其他流程？“真实”用户？无论他们是谁，您都需要将他们包括在设计中，并让他们与您讨论规格。
首先优先考虑用户想要什么。他们希望看到的“核心”特性集是什么，和/或你的新流程中最重要的、定义架构的特性是什么？计划对它们的前几次迭代。（在您设置开发环境的迭代 0 之后）。在这些结束时，您的系统将不会做它应该做的所有事情，但这将是一个开始。此外，专注于端到端的故事。最好尽早产生一个输出，即使它不是所需的输出，然后回来重构它以改进它。
继续按照你习惯的方式编写用户故事，也许在每个故事的开头添加一句话：“作为 XXX，我想……为了……”。这样每个故事都与该故事的原始请求者紧密相关。（XXX 可能是您自己、另一个系统或真实用户）。
很早就将注意力集中在一套全面的验收测试上。（也许使用JBehave或FITnesse 之类的自动化框架（如果您使用 Java，但我认为每种语言都有替代方案）。对于数据驱动的项目，这些是最重要的：它们将充当您系统的文档，并将其你应该这样构建你的验收测试：从一个“空”（或“给定”系统）开始，当你添加 XX 和 YY 和 ZZ 作为数据时，结果应该是 AA、BB 和 CC。不要犹豫，在你的验收测试中进行修改和削减，只要它们一直被用户看到和认可。（不要对它们做任何假设，验证一切）
然后一次又一次地迭代，增加复杂性层，直到达到所需的一组规范。
我参与了几个基于数据管理和处理（存储库，包括从不同来源合并、维护“黄金来源”、双时态数据库、提供其他外部系统等）的大中型项目，基本上，团队越敏捷，项目就越成功。到目前为止。
使用某种形式的验收测试（BDD 近来受到很多关注）会有所帮助。生成的 PDF 肯定有不同的“功能”，您会希望确保它们存在，不是吗？我建议尝试使用 BDD 验收测试将验证（提供反馈）这些功能的责任转移给最终用户。