5

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

你推荐使用什么？用例图？流程图？数据流图？决策树？

我并不是真的要求一个非常详细的答案。只是一些简单的东西来帮助我与编写需求的人交流，看看你们俩是否在同一页面上。

4

7 回答 7

8

我通常在项目的早期就将 PowerPoint 幻灯片放在一起，提供项目的高级概述，以及一些架构图（越简单越好）和屏幕模型/线框。然后我有一个需求审查的“启动”会议，讨论业务问题和提出的解决方案。

于 2008-09-22T19:35:25.487 回答
6

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

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

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

基本上是促使提出要求的人解释他们设想它是如何工作的。

于 2008-09-22T19:34:19.700 回答
5

我的角色有很多需求收集。我发现最好的方法是双管齐下，通过 PowerPoint 演示文稿进行讨论，保持一切简单和高水平，并展示概念证明或模型。走过并与客户交谈会看到他们回答许多“如果”，例如“我可以尝试颜色吗？” 这让每个人都能大致了解他们正在得到什么。如果你能得到一些用户可以触摸和玩的东西，那么它在揭示隐藏的假设方面非常有效。

然后，用非常详细的低级别要求支持这个高级别。拼出带点的“i”并划掉“t”。在完成 POC 之外的任何事情之前，让用户通读并签署它们。通常带有大量屏幕截图的单词效果很好。

除非用户可以为您带来 UML 和数据流程图，否则不要在客户看到或签署的任何内容中使用它们。如果它是由客户签署的，并且您必须重新安排后端以满足“假设”，那么您必须完全让所有事情都辞职。

最后一件事是确保客户可以用他们自己的话与您谈论他们的要求并说明他们得到了什么。做到这一点的一种方法是坐在任何中层管理人员向更高管理人员出售的情况下。

不要试图欺骗客户，如果他们想要在最后一刻改变某些东西，请解释成本是多少，时间和金钱，并询问他们是否完全需要这样做。这样做，通常会阻止人们做出微不足道的改变，并迫使他们思考为什么他们想要改变。

需求是从他们所说的他们想要的东西中得到客户需要的东西。

编辑 - 关于尽早显示屏幕截图 - 这有时需要一个好的 PM 让客户知道时间尺度和一切在哪里。如果 PM 帮助设定了一些体面的时间框架和期望，客户就不会感到兴奋。POC 和屏幕截图的好处是人们可以了解它可能是什么样的，并且通常可以在他们的脑海中发挥作用。

如果您想避免屏幕截图，请进行线框外观或使用白板和 20 分钟的绘图。只需记住在鞭打之前将白板保存为照片。

白板（和良好的旧 OHP）可以成为需求收集的天赐之物 - 开发一种清晰的绘图概念风格可以节省研讨会的时间。

于 2008-09-22T21:38:16.283 回答
4

流程图往往会混淆一些非技术人员（即客户），还有数据流程图。用例很好且易于理解，还有业务需求和技术需求文档，可能是某种粗略的线框草图。

于 2008-09-22T19:32:04.903 回答
3

这真的取决于你在谈论的要求。

  • 功能要求？也许UML是正确的工具。但我更喜欢测试 o 测试规范
  • 图形用户界面要求？没有什么能比得上一张纸和一支铅笔。
  • 安全要求？通过描述您的安全限制，您可以避免意外的欺骗。
  • 可靠性要求？测试机制和软件/硬件备份/恢复计划。
  • 其他要求：取决于您的客户。

但无论如何，请记住并向客户解释，在开发阶段需求会发生变化，这将始终是成本和功能之间的讨论和妥协。诚实让您的客户更有信心。

于 2008-09-22T19:39:09.847 回答
1

我认为展示你真正理解客户想法的最佳方式是构建原型。

顺便说一句，我参加了上一届需求工程会议和其中一个研讨会 (MERE)，西门子展示了基于编写客户想法视频的有趣软件（它适用于不限于软件的项目）只是为了确保完全理解所有要求。

无论如何，事情是有时以创造性的方式展示它们会更好。不要将自己局限于标准图表。

于 2008-09-22T19:45:49.643 回答
1

我在创建一个简单的词汇表方面有很好的经验，使用领域中的术语及其含义和关系，然后通过它并确保每个人都同意一切。

写作和讨论词汇会迫使你思考，而不是仅仅认为“我们稍后会解决这个问题”。

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

于 2008-09-22T21:46:56.373 回答