首页 / 知识

需求收集

2023-04-13 07:12:00

Requirements Gathering

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

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

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

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

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

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

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

希望这可以帮助！

enter image description here

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

史蒂夫·耶格(Steve Yegge)说的很有趣，但是要弄清楚别人的要求是有钱的，所以我会带着一点点盐来考虑他的文章。

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

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

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

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

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

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

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

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

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

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

哇，从哪里开始？

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

其次，有不同的要求。

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

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

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

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

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

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

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

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

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

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

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

如果您可以使用递增的生命周期，那将使您能够改善一些不好的需求。

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

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

有关目的，范围，操作环境限制，大小等的高级讨论

试听系统的单个段落描述，将其敲定

模拟用户界面

正式化已知需求

现在，使用越来越多的功能性原型和更多规格以及更多细节在3至4之间进行迭代。随手编写测试。进行此操作，直到您具有功能软件和完整，客观，可测试的需求规格。

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

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

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

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

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

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

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

在与涉众/用户/任何人交谈之前，请确保您将能够以有用且持久的方式放下收集的信息。

如果对方可以接受并且信息量很大，请使用录音机。
如果您听到了重要的事情，并且需要一些合理的时间来写下来，那么您有两种选择：请对方等待一会儿，或者告别这些宝贵的信息。您不会记错，请问任何神经科学家。
如果您发现某个问题需要更深入的审查，或者需要一些您刚听过的文件，请确保与其他人作出承诺，发送该文件或安排其他具有特定目的的会议。永远不要说"我会记得要那个xls文件"，因为在大多数情况下，您不会。
会议结束后不久，请总结您的所有笔记，录音和新想法。只是总结一下它的正确性。为承诺创建有效的提醒。
同样，在会议刚结束时，是了解为什么您刚才的聚会不如会议结束时所想的那么正确的最佳时机。到那时，您将能够为另一个会议提出很多有意义的问题。

我知道问题是在会前的角度来看的，但是请注意，您可以在会议之前处理此事项，并最终进行非常有用，完整和高质量的聚会。

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

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

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

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

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

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

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

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

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

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

与用户达成一个真正的解决方案-获得更好的色带供应商-或将电子设备连接到网络并将日志上传到中央服务器。

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

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

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

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

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

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

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

需求工程是一门艺术，有很多不同的处理方法，您确实必须根据项目和所涉及的利益相关者对其进行定制。 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最重要的第一步是建立特定领域词汇词典。当您的客户说"订单"时，他是什么意思？他从客户那里收到的东西还是他向供应商发送的东西？或两者兼而有之？

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

我希望我的需求收集过程尽可能简单，直接和彻底。您可以在此博客文章中下载用作我的项目模板的示例文档：http://allthingscs.blogspot.com/2011/03/documenting-software-architectural.html

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

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

需求利益客户提示