我们如何向客户/雇主表明我们了解他们的要求？

我们建议使用什么？用例图？流程图？数据流图？决策树？

我并不是真正想要一个非常详细的答案。只是一些简单的事情，可以帮助我与编写需求的人进行沟通，并查看你们两个人是否在同一页面上。

解决方案

流程图往往会混淆一些非技术人员(即客户)以及数据流程图。用例很好，也可以理解，还有业务需求和技术需求文档，可能还有一些粗略的线框草图。

我只是用我自己的语言解释要求，提供了我的假设并增加了限制。

要求可能是"单击时按钮变为绿色"

我会问："好吧，所以当用户单击按钮时，按钮的背景颜色变为绿色，但是文本保持相同的颜色吗？"

基本上是在提示提出要求的人员，以说明他们如何设想其工作原理。

我通常在项目的早期就将PowerPoint平台放在一起，对项目进行高层概述，并提供一些架构图(越简单越好)和屏幕模型/线框。然后，我召开了一次"会议"，以进行需求审查，并讨论业务问题和建议的解决方案。

这实际上取决于我们正在谈论的要求。

• 功能要求？也许UML是最严格的工具。但是我更喜欢测试或者测试规范
• GUI要求？没有什么能比得上纸和铅笔了。
• 安全要求？通过描述安全限制，可以避免意外的欺骗。
• 可靠性要求？测试机制和软件/硬件备份/恢复计划。
• 其他要求：取决于客户。

但是无论如何，请记住并向客户说明在开发阶段需求将发生变化，并且这将始终是讨论并在成本和功能之间进行折衷。诚实会给客户更多的信心。

我认为表明我们真正了解客户想法的最好方法是构建原型。

顺便说一句，在上一版的需求工程会议和一个讲习班(MERE)中，我是西门子的代表，他正在根据构成客户想法的视频展示和有趣的软件(不限于软件)只是为了确保完全理解所有要求。

无论如何，问题是有时候展示它们的创造性方法会更好。不要局限于标准图表。

我的角色有很多需求收集。我发现最好的方法是两种方法，通过PowerPoint演示文稿进行交谈，使其保持简单和高水平，并显示概念证明或者模型。走动与顾客交谈将使他们看到许多"如果是"的反应，例如"我能把握颜色吗？"这使每个人都对自己得到的东西有了一个广泛的了解。如果我们能得到某些东西，那么用户可以触摸并玩这些东西，在发现隐藏的内容时非常有效。

然后，使用真正详细的低层需求来支持此高层。拼出虚线" i"并越过" t"。在完成POC之前，请让用户通读并签名。通常，带有大量屏幕截图的单词效果很好。

除非用户可以带给我们UML和数据流程图，否则请勿在客户看到或者签名的地方使用它们。如果它是由客户签名的，并且我们必须重新注册后端以满足"如果"的要求，则我们必须完全放弃所有内容。

最后一件事是确保客户可以用自己的话与我们谈谈他们的要求，并阐明他们得到了什么。一种方法是将任何中层管理人员出售给高级管理人员。

如果客户希望在最后一刻更改某些内容，请不要bamboo之以鼻，告诉他们成本，时间和金钱的成本，并询问他们是否完全需要这样做。这样做通常会阻止人们进行微不足道的更改，并迫使他们考虑为什么要更改。

需求正在从客户的需求中获得客户的需求。

编辑
为了尽早显示屏幕截图，有时候这需要一个好的PM，以便让客户知道时间范围和一切。如果项目经理帮助设定一些体面的时间框架和期望，那么客户将不会感到兴奋。 POC和屏幕截图的好处是，人们可以了解它的样子，并且经常可以在他们的脑海中发挥作用。

如果要避免屏幕截图，请使用线框外观或者使用白板和20分钟的绘图时间。只需记住在鞭打白板之前将其另存为照片即可。

白板(以及良好的旧版OHP)可以成为需求收集的天赐之物。开发出清晰清晰的绘图概念样式可以节省车间工作时间。

我在创建一个简单的词汇方面有很好的经验，使用领域中的术语以及它们的含义和关系，然后仔细阅读并确保所有人都同意。

写作和讨论词汇会迫使我们思考，而不仅仅是思考"我们稍后会解决"。

当然，这不是灵丹妙药，应该与其他方式(例如功能需求规范和原型)一起使用。