收集项目需求的最佳方法是什么？

Question

如何收集系统工程或产品要求？ 例如，如果我们想制造汽车，我们应该如何收集要求？请指导我。

Answer 1

这实际上是一个非常大的问题。我要提出的答案是“这取决于”。收集要求是一件非常困难的事情。收集需求的最佳方式取决于您的项目方法。首先，您将使用迭代方法还是瀑布方法？您还需要确定您的项目利益相关者是谁（例如项目经理，开发人员，业务分析师，客户，项目发起人......）然后，您需要让项目利益相关者谈论他们想要的内容。

当你让每个人都在谈论你想要什么时，业务分析师应该帮助指导客户描述他们想要的东西。您的分析师需要挖掘需求。很多时候，客户不知道他们真正想要什么，或者如何以对开发人员有意义的方式描述系统。

此阶段的第一步是描述项目范围。一旦确定了良好的范围，您将能够确定哪些要求在范围内或超出范围。在此之后，确定需求的最佳方法是讨论问题以及他们想要解决的问题。尽量不要在需求阶段建立解决方案，只描述最终产品应该做什么。

不要太花时间收集要求。您在项目生命周期中稍后进行的更改越多，进行这些修改的成本就越高。此外，不要花太多时间来完善要求，否则你会发现自己陷入所谓的“分析瘫痪”。请记住，这些要点只是表面上的问题。这里有一些不错的书，我在这里读到了一些信息：

Karl E. Wiegers的

软件要求第2版

有关软件要求的更多信息，作者：Karl E. Wiegers

这些都是体面的书籍，他们谈论从为多个观众准备SRS到“需求启发”的所有主题。

Answer 2

我可能会从准备Gathering Requirements开始 然后我会结帐Joel On Software和37Signals。他们有关于创建需求文档的正确信息。软件网站上的Joel有一个example。

Answer 3

这称为系统分析 - 您可以与产品的潜在用户交谈。

Answer 4

使用SRS document记录您从客户端获取的要求。

Answer 5

• 定期与客户讨论，特别是未来的用户和关键用户
• 在会谈中记笔记
• 每次CONVERSATION之后写一份官方要求清单并提交批准。后来很难反驳所有商定的文件
• 确保您的客户大致知道实施“很高兴”要求的时间和金钱的大致费用
• 确保从一开始就将要求标记为“必须拥有”，“应该拥有”和“很高兴”，确保客户了解这些类型之间的差异
• 将所有文档集成到最新和最终需求分析中（或当前的迭代或您使用的敏捷编程周期......）
• 请记住，需求会在软件生命周期中发生变化，因此收集是一回事，但管理和实施另一个
• 亲吻 - 尽量保持简单
• 阅读敏捷宣言 - 工作软件是软件项目成功的唯一衡量标准
• 还研究未来系统所处的环境 - 传统或周边系统的技术限制越来越多，因为公司不愿意将他们投入的资金投入垃圾几十年，即使在现代20岁的代码是垃圾......

Answer 6

1. 与人们交流 - 特别是项目利益相关者和用户。
2. 提问。他们很多。
3. 记录您的讨论和结论。
4. 使用原型验证结论。

Answer 7

通常情况下，记住你一次为几个主人服务是有帮助的：

1. 最终用户
2. 管理
3. 您的设计环境及其施加的限制

最好的事情是花时间与上述所有

例如：我最近被聘请为一个包裹递送公司编制一个系统 - 我必须取悦最终用户（驱动程序 - 简化和快速）管理（我们想知道每个人做了什么，什么时候做/如何）以及在限制性环境（移动扫描仪）中工作

我花了很多时间与管理层然后转身，并与司机交付。只有在那之后，我才能真正掌握它。

要记住的一件重要事情是，不要简单地想出一个你的解决方案，而是一个能够解决客户每天面临的问题的解决方案。 唯一的方式就是与他们共度美好时光，最好是在他们工作的时候。

最后一点也是值得肯定的 - 虽然他们做他们的工作......如果你只是问他们你几乎肯定会得到不完整的答案。大多数人在工作中做了许多他们甚至不再思考的事情，它已成为习惯。正是这些小工作的怪癖难以接受并包含在没有第一手经验的新系统中。

如果您要求工具而不是方法，我道歉。