假设我们正在创建 Acme CMS。此 CMS Web 应用程序将允许您创建无限数量的具有子类别（无限深度）的类别，并且每个类别可以有 0+ 个与之关联的内容页面。
所以这个项目，在高层次上将有：
前端 1. 索引页面 2. 带有内容页面列表的类别页面 3. 内容页面
管理控制面板 1. 类别（添加/更新/删除） 2. 页面（添加/更新/删除/）
架构设计 1. 表 2. 存储过程 3. 数据访问层
问题：我正在使用错误跟踪器和 Wiki，那么我应该如何分解这个项目？
我正在考虑将每个部分（前端/管理面板）分解为单独的页面，然后为每个页面（或主题）编写简单的用户故事。
当我完成用户故事后，我将在我的错误跟踪器中创建一个案例列表，代表我必须开发的功能，以及对每个案例的估计。
我是否正确地分解了这个项目？计划中的任何重大差距都会导致该项目失败（理论上无论如何！）
请提供详细的答案，也许是我应该做什么的大致想法，并附有详细的示例来解释它以及原因等。
“我正在考虑将每个部分（前端/管理面板）分解为单独的页面，然后为每个页面（或主题）编写简单的用户故事。”
页面没有故事。用户有故事。页面是您为实现用户故事而构建的东西。
主题——如果有这么小的东西的话——是“管理内容”。也许有两个主题：关于写作/编辑的故事集和围绕浏览/阅读的故事。
一些用户（'编辑'？）想要创建、组织、更新和删除内容，以便他们可以做一些事情[问题没有说]。你强迫他们使用网页，因为它比 5x8 卡片和记号笔更好——更便宜——更快。
一些用户（“读者”？）想要检查内容并进行导航，以便他们能够——谁知道呢？——在某事上更快乐、更有成效。你强迫他们使用网页，因为它比用磁铁固定在白板上的 5x8 卡片要好。
您有关于创建和管理内容主题的故事。
“然后在我的错误跟踪器中创建一个案例列表，代表我必须开发的功能，以及每个案例的估计”
正确的。并且功能必须首先从数据模型开始，然后以某种有用的形式呈现。也许在页面上。确实，一旦您拥有一个广泛满足用例的模型，您就可以微调演示文稿以使模型更可用。
“业务层和表示是我需要详细说明的”
模型 == 业务层。他们是一样的。
页面 == 演示文稿。笔记。这是最后一次。一旦你有了用例和支持这些用例的模型，你就可以向人们展示你的东西，这样他们就可以与模型进行交互。
据我所见，您的设计中有一些明显的差距，部分功能是隐含的（类别和页面的链接），有些则完全被遗漏了（管理员登录、用户管理、预览等）。这些将占您小型应用程序的大约一半，您最好将它们包含在初始大纲中。也许您可能希望采用更系统的方法来设计 CMS。您可以采取至少三种一般路线：
首先设计领域模型，然后设计业务层，然后是 UI 和数据模型。
从数据模型开始，在其之上构建业务层和 UI。
首先对 UI 建模，然后是其他一切。
无论您更愿意采取（或组合）哪条道路，都有一些一般准则：
从您想要自动化的工作的大图开始。这称为“工作范围”。这里的“大图”可以按字面意思表示，虽然它可能只是一个描述过程的故事，但最好使用包含动作、人工制品、其他应用程序、用户等的丰富图片来可视化。至于“大”图片需要包含比预期产品更多的部分，大于您想要自动化的工作部分。
然后概述您希望您的产品处理的具体工作。这通常被称为“产品范围”。
为您的应用程序制作用户角色（或配置文件）列表、输入和输出列表、外部接口列表。
现在您可能想开始编写一些用户故事。每个用户配置文件至少需要一个，因为您需要提供所有用户视角的说明。
在这一点上，您可以使用足够的信息来开始使用领域模型、UI 模型或数据模型对问题进行更精确的建模，无论您喜欢或感觉更舒服。
所有步骤都非常迭代。一旦您对应用程序、其更广泛的上下文以及需要实现的功能列表来满足您的要求有更多的了解，您就可以给出一些非常粗略的估计，然后进行优先级排序过程。
不用说，这只是一个简化的框架，许多软件开发人员会根据他们的技能、需求、偏好等采用不同的方法来设计应用程序。但这可能是对问题进行更系统评估的一个很好的起点你想解决。
“无限”部分被打破......即使GMail也有上限......
编辑：虽然我的回答被否决了，但我认为这是正确的。一旦您与非程序员交谈，“无限”部分就会变得非常危险，并且可能会在背后刺伤您。此外，您不能真正拥有用于无限嵌套的可扩展数据模式......但这应该是显而易见的。