作为一个软件架构师，最难的事情之一是收集需求。你可以和地球上最伟大的明星工程师团队一起工作，建造出有史以来最神奇的技术作品，伟大到你可以欺骗大多数，看到它的人相信它是魔术，但如果它不是利益相关者想要的或市场需要的，它就像一个USB仓鼠轮一样毫无价值。
为什么架构如此困难
工程中最难的事情是通常是沟通，工程师们一直在努力沟通复杂的抽象想法，在大多数情况下，这些想法属于需要一些领域知识才能理解的问题，对话中充满了缩略语和发明的术语，这些术语已经成为目标行业的术语，它对每个行业都是不同的，更糟糕的是它对每个学科都是不同的，软件工程师和固件工程师说的不是同一种语言，后者几乎听不懂电子工程师的话，而后者甚至不想和机械工程师交谈。这种情况使沟通成为一场噩梦。
现在我们同意沟通想法是很难的，让我们研究一些技术来做到这一点。 第一种技术，似乎每一个初出茅庐的工程师都会尝试用 “产品应该 “的语句来捕捉需求。 产品应该与用户对接，产品应该为用户提供服务，但是如果你给相关人员一个产品可以做的一长串功能清单，他们可能会点头称是，然后增加一些产品应该做的额外需求。这里的情况似乎是，向产品添加需求是很便宜和容易的。不需要真正考虑为什么需求应该存在。不需要做任何工作来添加需求到列表中。 任何出现在利益相关者头脑中的疯狂想法都可以被捕捉为需求，现在开发团队必须尝试去实现它。 不可避免的功能蠕变伴随着一长串的需求清单，造成的问题不仅仅是给开发团队带来大量的工作。很多时候，这些需求是相互冲突的，使得产品实际上无法建立。 产品应画红线 产品应使用一些需求分析，会很快发现像这样那样的公然的问题，但大多数这些类型的冲突会更微妙。所有这些都会导致额外的会议，以决定哪个需求应该被支持。 也许列表的最大问题是它没有给利益相关者一个产品行为方式的感觉。有一长串产品需要做的事情，但没有关于产品将如何做的信息。 如果没有对用户如何与产品互动的感觉，利益相关者似乎就不会那么投入。他们开始对需求征集阶段采取漠不关心的态度，以便开发可以 “快点开始”，这样他们就可以看到产品是如何工作的。这样做的结果很糟糕，因为它导致了在项目结束时的改变，而这时重构的成本很高。
用例是一种比用户故事更正式的捕捉需求的方式。维基百科将其定义为 “一个步骤的列表，通常定义一个角色之间的相互作用”。与用户故事类似，用例谈论的是将要进行活动的用户，但与用户故事不同，用例不是一个单一的句子。 相反，它们会详细说明用户将如何一步步地与系统互动。 写得好的用例还包括错误条件和替代流程。 开发团队喜欢所有这些细节。这正是他们想要的，以便能够建立和测试用户想要的系统。利益相关者在这里似乎是站在对立面的。 根据我的经验，他们讨厌用例。所有这些细节读起来很无聊，写起来也很乏味。找到愿意审查哪怕是一小套用例的利益相关者是不太可能的。 愿意并能够帮助编写用例的利益相关者是不可得的。
我们已经确定，用户故事太过模糊，无法让开发团队独立工作，而用户故事又太过详细，无法用于与利益相关者的沟通。我们所需要的是在两者之间的东西。我目前的解决方案是我将其称为用户案例。用户案例是用户故事和用例的结合。 利益相关者写一个标准的用户故事。这被用作需求的标题，并在需求被添加之前产生一些开销、思考和讨论。关于用户故事应该如何实际运作的讨论被记录为用户故事的用例。随着故事的细节越来越清晰，应该增加额外的用例、替代流程和错误路径。 这种方法有一些相当有趣的结果。首先，利益相关者继续参与，因为他们正在编写用户故事，甚至可能是高层次的最初的快乐路径用例。 他们有时间审查这些需求，因为他们只仔细阅读用户故事，也许还有几个用例，他们关注的是功能。换句话说，他们不会被那些他们没有时间的细节所困住。另一方面，开发团队能够添加他们所需要的细节，与旨在与利益相关者沟通的文本保持一致。 这给了他们一定程度的安慰，当这份文件最终被同意时，有足够的细节来避免那些关于功能解释的争论。 是的，我意识到我在上面自相矛盾，因为我说利益相关者不会阅读和理解所有的用例，而开发团队则认为他们已经阅读和理解了。这就是这种方法的肮脏伎俩。 基本上，开发团队是在问：”你读了所有的细节，不是吗？好吧，那就在这里写首字母，然后在这里签名”。不幸的是，如果利益相关者在开发过程中没有时间参与，也没有时间完全理解所有的细节，那么第三种最好的方法就是我们所能希望的。第三种最好的办法似乎是为利益相关者提供一个摘要和所有的细节，让他们决定如何最好地利用他们的时间。
快速制作原型
我一直在考虑的捕捉需求的最后一种方法是快速原型设计。不幸的是，利益相关者往往需要 “感觉 “到产品来了解他们想要什么。上面提到的技术都不能传达一种感觉。 我对快速原型设计工具没有什么经验，但最近我玩了一个，对取得的进展印象颇深。 这个工具很容易使用，而且还能让人对用户与产品的互动产生良好的印象。它能够从原型中生成文档，从而产生一组漂亮的屏幕截图，并可以对其进行补充，以创建一个纸质跟踪。 似乎很快就会出现这样的情况，如果不是已经出现的话，制作解决方案的原型比正确记录需求所需的时间要短。