我们如何进入需求收集阶段？有没有人要遵循一套很好的指导方针或者提示？有什么好问题要问利益相关者？

我目前正在从事一个新项目，并且有很多未知数。我正在提出一系列问题，向利益相关者提问。但是，我不禁感到自己缺少某些东西或者忘记提出一个关键问题。

解决方案

回答

我们永远不能问太多或者"愚蠢"的问题。我们提出的问题越多，收到的答案也就越多。

回答

请参阅下面的强制性漫画...

通常，我会尝试了解我的客户/客户试图模仿他们想要构建的应用程序的业务模型。我们是否正在构建一个美化的表单处理器？我们是否在单个应用程序中从多个来源检索数据以节省时间？我们正在执行某种整合吗？

一旦建立了一般业务模型，我便转到应用程序的"必须"和"不得"，以指示我可以检索哪些数据，谁可以执行什么功能等。

通常，如果我们可以让客户解释他们的模型或者工作流程，则可以从那里开始寻找其他关键问题。

我总是确保以某种形式问到的一个问题是："执行X时，我们最棘手/最烦人的事情是什么。通常，答案是我们必须实施的最疯狂的业务/数据规则。 。

希望这可以帮助！

回答

我们几乎肯定会丢失一些东西。可能有很多事情。不用担心，没关系。即使我们记住了所有内容并涵盖了所有基础，利益相关者也将无法在没有任何参考的情况下为我们提供非常清晰的要求。进行此类操作的最佳方法是立即从他们那里得到我们所能提供的东西，然后接受并给予他们一些反应。它可以是纸质原型，模型，软件的0.1版等。然后他们可以开始告诉我们他们真正想要的是什么。

回答

根据史蒂夫·耶格(Steve Yegge)的说法，这是一个错误的问题。如果我们正在收集需求，已经为时已晚，那么项目就注定了。

回答

首先，在开始编码之前收集需求。我们可以在收集它们时开始设计，具体取决于项目生命周期，但没有它们就永远不要开始编码。

需求是一组保护客户和我们自己的书面文件。永远别忘了。如果不存在任何要求，则无需支付费用(因此需要正式的变更请求)，如果存在，则必须实施且必须正常工作。

要求必须是可测试的。如果需求无法测试，则不是需求。意思是"系统"

要求必须是具体的。这意味着陈述"系统用户界面应易于使用"不是正确的要求。

为了真正"收集"需求，我们首先需要确保我们了解业务模型。客户会用自己的话语告诉我们他们想要什么，理解并在正确的上下文中解释是工作。

在开发需求时与客户举行会议。用我们自己的话向客户描述它们，并确保我们和客户在需求中具有相同的概念。

需求需要简洁，可测试的示例，但要跟踪会议中出现的所有其他情况，图表，疑问，并尝试保留每次会议的记录。

如果我们可以使用递增的生命周期，那将使我们能够改善一些不良的收集需求。

回答

史蒂夫·耶格(Steve Yegge)说的很有趣，但是要弄清楚其他人的要求是可以赚钱的，所以我不妨多加盐。

由于通信的工作方式，需求收集非常困难。这是一个四步过程，每一步都是有损失的。

• 我脑子里有个主意
• 我把它变成文字和图片
• 我们解释图片和文字
• 我们以自己的方式描绘出我的原始想法的图像

人类由于其可爱的缺陷而频频令人担忧地失败了。

敏捷正确地促进了迭代开发。将早期版本发布给客户端对于确定最重要的功能(0.1 0.5 ish附带的功能)非常重要，有助于使我们在应用程序的工作方式上保持正确的轨道，并快速识别出我们所隐藏的功能将错过。

两个主要的问题场景是量表的两端：

• 没有关于我们正在做的事情的奇特线索-获取一些领域专家
• 要求过多-功能坑。 -问题，剔除(prioritise;))功能并使用迭代开发

Yegge很好地指出领域专家对于产生良好的需求是必不可少的，因为他们了解业务并从事其中。他们可以帮助确定客户的核心需求，并帮助解释他们的员工将如何使用该系统以及对员工而言重要的方面。
替代方案和补充措施包括尝试自己动手做以进入心态，或者偶尔在现场安排客户工作人员，尽管后者不太可能发生。

特征坑是另一面，大部分都是失败的政府IT项目。对现实主义的思考或者运用太多，为时太早(但是我们认为他们只有大约四年的时间才能使自己感到重要吗？)。目的是弄清客户真正想要的东西。
只要我们致力于使核心组件正确无误，高效且无错误的客户端通常就可以容忍丢失的功能，这些功能在最终交付时才可以使用。这就是迭代开发真正有帮助的地方。

请记住将客户对程序的想法和他们希望程序实现的想法分开。
一些客户可能会以应用程序功能的形式传达他们的要求，从而造成混乱，而这些功能可能会被认为较差的功能或者由于其认为比其所需的功能简单得多而变得多余的功能。尽管我不主张称呼客户为白痴或者不听他们的话，但我觉得永远值得一提的是，为什么他们希望某个特定功能达到其基本目的。

请记住，在这两种情况下，至关重要的是必须根除最快的途径来满足客户的核心需求，并让我们处于双方都从中受益的情况下。

回答

• 有关目的，范围，操作环境限制，大小等的高级讨论
• 试听系统的单个段落描述，将其敲定
• 模拟用户界面
• 正式化已知需求
• 现在，使用越来越多的功能原型和更多规格和更多细节在3至4之间进行迭代。随手编写测试。进行此操作，直到我们具有功能软件和完整，客观，可测试的需求规格。

那是梦想。现实通常是在几次迭代之后，每个人都会低下头并编写代码，直到剩下一个月的时间来测试。

回答

这里已经有一些很棒的主意。以下是我一直希望牢记的一些需求收集原则：

了解用户和客户之间的区别。
批准闪亮项目的企业主通常是客户。但是，一个毁灭性的错误是倾向于将它们混淆为用户。客户通常是认识到产品需求的人，而用户则是实际将使用该解决方案的人(以后很可能会抱怨产品未满足要求)。
去一个以上的人

因为都是人类，所以我们往往不记得所有令人毛骨悚然的细节。与更多的人交谈并进行交叉检查时，发现未满足需求的可能性增加。

避免特价
当用户要求非常具体的内容时，请多加注意。总是质疑偏见，看看这是否真的会使产品更好。

原型
不要等到启动后向用户显示我们拥有什么。经常制作原型(我们甚至可以将其称为Beta版本)，并在整个开发过程中不断获得反馈。这样做可能会发现更多要求。

回答

我最近开始使用国际商业分析师协会(IIBA)定义的概念，标准和模板。

他们有一个很好的BOK(知识手册)，可以从他们的网站上下载。他们也有证书。

回答

收集业务需求是胡扯史蒂夫·叶格(Steve Yegge)

回答

哇，从哪里开始？

首先，有人必须对某些项目进行分析，这需要一些知识，但这实际上取决于我们为谁构建的内容。换句话说，如果我们要为《财富》 100强公司修改企业应用程序，构建iPhone应用程序或者向个人网页添加功能，那将有很大的不同。

其次，有不同的要求。

• 目标：用户想要完成什么？
• 功能性：用户需要做什么才能实现其目标？ (想想达到目标的步骤)
• 非功能性：程序需要在哪些限制内执行？ (请考虑10个和10k并发用户，增长，备份等)
• 业务规则：我们必须满足哪些动态约束？ (请考虑一下计算，定义，法律问题等)

第三，最有效地收集需求，然后获得需求反馈的方法(我们会这样做，对吗？)是使用模型。用户案例和用户故事是用户需要做什么的模型。流程模型是需要发生的事情的另一个版本。系统图只是程序不同部分如何交互的另一个模型。良好的数据建模将定义业务概念，并向我们显示程序中发生的输入，输出和更改。模型(还有我列出的更多模型)确实是我们列出的关注点的关键。一些好的模型可以捕获需求，我们可以从模型中确定需求。

第四，获取反馈。我知道我已经提到过这一点，但是我们不会在第一时间就把所有事情都做好，因此请对客户的需求做出回应。

就我对需求以及推动需求的模型的理解而言，用户通常不理解所有需求的后果。不断进行交流，有机会进行审查和反馈，可以使用户更好地了解我们所提供的内容。此外，他们将根据所见所闻进一步完善自己的理解。除非我们为政府工作，否则迭代和/或者原型会有所帮助。

回答

我一直在使用思维导图(如工作分解结构)来帮助收集需求和定义未知项(项目杀手＃1)。从高层次开始，然后逐步解决。我们需要与赞助商，用户和开发团队合作，以确保我们获得所有角度并且不会错过任何内容。如果没有他们的参与，就无法期望他们知道自己想要的全部范围。作为项目经理/ BA的我们需要让他们参与(工作中最重要的部分)。

回答

• 阅读敏捷宣言-工作软件是衡量软件项目成功与否的唯一标准
• 熟悉敏捷软件实践-学习Scrum，精益编程，xp等-这不仅可以节省大量时间，不仅可以收集需求，还可以节省整个软件开发生命周期
• 与客户(尤其是未来的用户和关键用户)进行定期讨论
• 确保我们与了解问题域的人员交谈-例如该领域的专家
• 在会谈中做一些小笔记
• 在每次对话之后，写一份正式的需求清单并出示以供批准。稍后，将很难与所有商定的文档进行抗辩
• 确保客户大致了解实施"精打细算"要求所需的时间和金钱。
• 确保从一开始就将需求标记为"必须拥有"，"应该拥有"和"很高兴"，并确保客户也了解这些类型之间的差异
• 将所有文档集成到最新和最终的需求分析中(或者将当前文档进行迭代，或者使用任何敏捷编程周期...)
• 请记住，需求确实会在软件生命周期中发生变化，因此收集是一回事，而管理和实施则是另一回事
• 吻-保持尽可能简单
• 还研究未来系统的生存环境-遗留系统或者周围系统对技术的限制越来越大，因为公司不愿意将几十年来的投资浪费掉，即使以我们20年的现代思维来看旧代码是垃圾...

回答

我写了一篇关于我使用的方法的博客文章：

http://pm4web.blogspot.com/2008/10/needs-analysis-for-business-websites.html

基本上：在建立客户网站之前要问客户的问题。

我应该添加此问卷表仅适用于基本网站构建，例如商业网站。如果我们谈论基于Web的软件，则完全不同。尽管其中的一些内容仍然很实用(例如与外观有关的问题)。

• LM

回答

需求工程是一门艺术，有很多不同的处理方法，我们实际上必须根据项目和所涉及的利益相关者对其进行定制。 Karl Wiegers的"需求工程"是一个不错的起点：

http://www.amazon.com/Software-Requirements-Second-Pro-Best-Practices/dp/0735618798/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1234910330&sr=8-2

以及需求工程流程，其中可能包含许多步骤，例如：

• 启发-与企业进行讨论的基础
• 分析和说明-针对开发人员的技术说明
• 详细说明，澄清，验证和谈判-进一步完善需求

另外，有多种记录需求的方法(用例，原型，规范，建模语言)。每种都有其优点和缺点。例如，原型对于从业务中启发想法和讨论想法非常有用。

我通常发现编写一组用例并包括线框原型可以很好地识别出一组初始需求。从那时起，这是与技术人员和业务人员合作以进一步阐明和详细说明要求的持续过程。跟踪最初达成的协议并跟踪其他要求对于避免范围蔓延至关重要。根据《断铁三角》(http://www.ambysoft.com/essays/brokenTriangle.html)，各方在此之间的谈判也起了一定作用。

回答

IMO最重要的第一步是建立特定领域词汇词典。当客户说"订单"时，他是什么意思？他从客户那里收到的东西或者他向供应商发送的东西？或者两者兼而有之？

在利益相关者的业务中找到关键字，并让他们解释这些词，直到我们理解其在过程中的含义为止。没有这些，我们将很难理解要求。

回答

像软件开发过程的大多数阶段一样，其迭代效果最佳。

首先找出用户是谁-XYZ部门，

然后找出适合他们的组织-Z部门的一部分，

然后找出他们的一般做法-管理现金

然后按照特定条款-从收银台收取现金，并检查收银台欺诈行为。

然后，我们可以开始与他们交谈。

询问他们想解决什么问题-我们将得到答案，例如使用结合了鲨鱼技术的OCR编写Bamboozling系统。

忽略该答案，再问一些其他问题，以找出真正的问题是-他们看不懂收据单以核对现金。

与用户达成真正的解决方案-寻求更好的色带供应商或者将电子设备连接到网络，然后将日志上传到中央服务器。

然后详细商定他们将如何衡量项目的成功。

然后然后才提出并同意一套详细的要求。

回答

我建议我们阅读Roger-Pressman的《软件工程：从业者的方法》