如何表明您了解项目的要求

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

你建议使用什么？用例图？流图表？数据流,图表？决策树？

我不是真的要求一个非常详细的答案.只是简单的东西,可以帮助我与编写需求的人沟通,看看你们两个是否在同一页面上.

我通常在项目的早期阶段组装一个PowerPoint套件,给出项目的高级概述,以及一些架构图(越简单越好)和屏幕模型/线框.然后我开始进行需求审核的"启动"会议,并讨论业务问题和建议的解决方案.

我只是用我自己的语言解释这些要求,提供我的假设并增加限制.

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

我会问"好的,所以当用户点击按钮时,按钮的背景颜色变为绿色,但文字保持相同的颜色？"

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

我的角色收集了很多要求.我找到的最好的方法是双管齐下的方法,通过PowerPoint演示文稿进行讨论,使其保持简单和高水平,并展示概念证明或模拟.走路和说话的顾客将看到他们回应许多"如果是",如"我可以冒险的颜色吗？" 这让每个人都对他们得到的东西有了广泛的了解.如果你能得到一些用户可以触摸和玩的东西,那么就能很好地发现隐藏的内容.

然后,通过非常详细的低级别要求将这个高级别提升回来.拼出点缀的"i"并越过"t".让用户在完成POC之前阅读并签名.通常带有很多屏幕截图的单词效果很好.

除非用户可以为您提供UML和数据流程图,否则请勿在客户看到或签署的任何内容中使用它们.如果它是由客户签署的,你必须重新命名后端才能满足"假设",你必须完全放弃一切.

最后一件事是确保客户能够用自己的语言与他们谈论他们的要求并说明他们得到的东西.实现这一目标的一种方法是让任何中层管理人员向高级管理层出售.

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

要求是从他们想要的东西中获得客户需求.

编辑 - 为了尽早显示屏幕截图 - 这有时需要一个好的PM让客户知道时间尺度和所有内容.如果PM有助于设定一些不错的时间框架和期望,客户将不会感到兴奋.POC和屏幕截图的好处是人们可以获得它可能是什么样的图像,并且经常可以在他们的脑海里工作.

如果你想避免截图,请做线框外观或使用白板和20分钟的绘图.只需记住将白板保存为照片即可.

白板(以及古老的OHP)可以成为需求收集的天赐之物 - 开发一种清晰的绘画概念可以节省工作时间.