开发人员需要在前端确保项目成功？

Question

我对需要精心设计的Web应用程序的业务有所了解。我不是一名火箭外科医生，但我很聪明，知道你能得到你付出的代价，并愿意为人才买单。但是，我希望开发过程尽可能顺利，并希望知道如何实现这一目标。

那么，开发人员最初需要（或想要）从所有者获得哪些信息以避免对业务（或其他）要求做出假设？我是否需要创建状态转换图或编写用例？

基本上，我如何将这个概念放在脑海中并以一种允许开发人员做他们最擅长的方式打包它？ （假设这是创建好的软件。哈哈）

感谢任何建议。

肖恩

Answer 1

您可能需要重新提问，因为它太过一般而无法得到一个好的答案，所以一些模糊的细节会有所帮助。

但是，你对自己想要的东西有了更好的视野。

当你不打算做这项工作时，我发现UML图太局限了，因为你可能没有想出最好的设计。

因此，如果您开始设计每个页面应该是什么样子，正如您所设想的那样，那么您可以编写用例，这是一些简短的场景。

所以，你可以写一下：

用户需要能够使用OpenID登录。

这将告诉开发人员您想要的一个功能，以及您希望执行该操作的人。

但是，不要投入技术，因为您可能认为SOAP服务是您最好的选择，但在谈到它时您可能会发现有更好的解决方案。

用例是展示您想象的内容的好点，并为您的页面设计提供文本。

Answer 2

与开发者交谈。解释你想要什么，为什么你想要它。你一起制作流程图和诸如此类的东西。编写需求是设计过程的一部分，并且尽快让开发人员加入进程是个好主意。开始简单和小，然后在迭代时增长和扩展。

Answer 3

在讨论Web服务之前，我发现最好的起点是在一张纸上绘制您认为该网站的外观，并添加几个箭头，从您想要点击的内容到应该产生的页面。保持简单，没有什么太花哨，希望你和开发人员能够很快理解你想要的东西。

用例可能最适合在项目后期检查您的网站完整程度的所有要点;我并没有真正发现它是一个有用的起点，但我相信其他人不同意。 （实际编写代码时，他们似乎只是 tedius read 。）

与状态转换图相同;他们太乏味了，我想大多数开发人员都会认为你无论如何都会犯错误。 :)其他人都这样做......除非你的项目严重依赖于非常关于状态机的正确性，否则我真的不会打扰。

Answer 4

从程序员的角度来看，这个book包含了一些很好的建议。它还有一个有用的指导原则，即不要过早地设置您的要求形式，以及描述您试图解决的问题的重要部分。

Answer 5

我喜欢基于实际程序/站点流程的UI模型，例如注册客户或下订单。具有结构化，一致的数据示例的图表的图表/图片是明确的。

我同意UML和用例只有在每个人都说UML并且项目足够复杂（很少有）时才真正有用。

您可能希望了解敏捷/ Scrum技术。这些正在成为一种标准，如果管理得当，可以节省数周的开发时间。

Answer 6

我发现单词在沟通系统应该如何工作方面做得不好。线框，白板图纸/过渡图和低保真原型是传达具体想法的好方法。低保真原型的一个例子是“可点击”纸质原型，其允许用户触摸纸上的“按钮”以从一个图纸到另一个图纸。它花费的时间非常少（更便宜），但在两方之间传达一个想法还有很长的路要走。

远离正常文档，UML图表或不与您交流的类（技术文档）图表。这就是规避风险的大型企业走向更加“成熟”的趋势。这些也是一个被淘汰的想法的副产品，听起来好像你正处于散步阶段。