Requirements Gathering您如何进入需求收集阶段？ 有没有人要遵循一套很好的指导方针或提示？ 有什么好问题要问利益相关者？ 我目前正在一个新项目上，有很多未知数。 我正在提出一系列问题，向利益相关者提问。 但是，我不禁感到自己缺少某些东西或忘记提出一个关键问题。 请参阅下面的强制性漫画... 通常，我会尝试了解客户/客户试图用他们想要构建的应用程序进行仿真的业务模型。我们是否正在构建一个美化的表单处理器？我们是否在单个应用程序中从多个来源检索数据以节省时间？我们正在执行某种整合吗？ 一旦建立了一般业务模型，我便转到应用程序的"必须"和"不得"，以指示我可以检索哪些数据，谁可以执行什么功能等。 通常，如果您可以让客户解释他们的模型或工作流程，则可以从那里开始寻找其他关键问题。 我总是要确保以某种形式问到的一个问题是："执行X时，您最棘手/最烦人的事情是什么。通常，答案是您必须实施的最疯狂的业务/数据规则。 。 希望这可以帮助！
您几乎肯定会丢失一些东西。可能有很多事情。不用担心，没关系。即使您记住了所有内容并涵盖了所有基础，利益相关者也将无法在没有任何参考的情况下为您提供非常清晰的要求。进行此类操作的最佳方法是立即从他们那里得到您所能提供的东西，然后接受它们并给予他们一些反应。它可以是纸质原型，模型，软件的0.1版等。然后他们可以开始告诉您他们真正想要的是什么。 史蒂夫·耶格(Steve Yegge)说的很有趣，但是要弄清楚别人的要求是有钱的，所以我会带着一点点盐来考虑他的文章。 由于通信的工作方式，需求收集非常困难。这是一个四步过程，每一步都是有损失的。
而人类由于其可爱的缺陷而频频令人担忧地失败了。 敏捷正确地促进了迭代开发。将早期版本发布给客户端对于确定最重要的功能(0.1-0.5 ish附带的功能)非常重要，有助于使您在应用程序的工作方式上保持正确的轨道，并快速识别出隐藏的功能。你会想念的。 两个主要的问题场景是量表的两端：
Yegge很好地指出领域专家对于产生良好的需求是必不可少的，因为他们了解业务并从事其中。他们可以帮助确定客户的核心需求，并帮助解释他们的员工将如何使用该系统以及对员工而言重要的方面。
特征坑是另一面，大部分都是失败的政府IT项目。对现实主义的思考或运用太多，为时太早(但是您期望他们只有大约四年的时间才能使自己感到重要吗？)。目的是弄清客户真正想要的东西。
请记住将客户对程序的外观和他们希望程序实现的想法分开。 请记住，在这两种情况下，至关重要的是必须根除最快的途径来满足客户的核心需求，并使您处于双方都从中受益的情况下。 哇，从哪里开始？ 首先，某人必须对某些项目进行分析，这实际上取决于您为谁建立的知识。换句话说，如果您要为《财富》 100强公司修改企业应用程序，构建iPhone应用程序或向个人网页添加功能，那将有很大的不同。 其次，有不同的要求。
第三，最有效地收集需求，然后获得需求反馈的方法(您会这样做，对吗？)是使用模型。用户案例和用户故事是用户需要做什么的模型。流程模型是需要发生的事情的另一个版本。系统图只是程序不同部分如何交互的另一个模型。良好的数据建模将定义业务概念，并向您显示程序中发生的输入，输出和更改。模型(还有我列出的更多)确实是列出您所关注的问题的关键。一些好的模型可以捕获需求，您可以从模型中确定需求。 第四，获取反馈。我知道我已经提到过这一点，但是您不会在第一时间就把所有事情都做好，所以要对客户的需求做出回应。 尽管我很欣赏需求以及推动需求的模型，但用户通常不理解所有需求的后果。不断进行交流，有机会进行审查和反馈，可以使用户更好地了解您所提供的内容。此外，他们将根据所见所闻进一步完善自己的理解。除非您为政府工作，否则迭代和/或原型会有所帮助。 首先，在开始编码之前收集需求。您可以在收集它们时开始设计，具体取决于项目生命周期，但没有它们就永远不要开始编码。 需求是一组保护客户和您自己的书面文件。永远别忘了。如果不存在任何要求，则无需支付费用(因此需要正式的变更请求)，如果存在，则必须实施且必须正常运行。 要求必须是可测试的。如果需求无法测试，则不是需求。意思是"系统" 要求必须是具体的。这意味着陈述"系统用户界面应易于使用"不是正确的要求。 为了真正地"收集"需求，您首先需要确保您了解业务模型。客户会用自己的话语告诉您他们想要什么，理解并在正确的上下文中解释是您的工作。 在开发需求时与客户举行会议。用您自己的话向客户描述它们，并确保您和客户在需求中具有相同的概念。 需求需要简洁，可测试的示例，但要跟踪会议中出现的所有其他情况，图表，疑问，并尝试保留每次会议的记录。 如果您可以使用递增的生命周期，那将使您能够改善一些不好的需求。 根据史蒂夫·耶格(Steve Yegge)的说法，这是一个错误的问题。如果您收集需求已经为时已晚，那么您的项目就注定了。 您永远不能问太多或"愚蠢"的问题。您提出的问题越多，收到的答案就越多。 有关目的，范围，操作环境限制，大小等的高级讨论 试听系统的单个段落描述，将其敲定 模拟用户界面 正式化已知需求 现在，使用越来越多的功能性原型和更多规格以及更多细节在3至4之间进行迭代。随手编写测试。进行此操作，直到您具有功能软件和完整，客观，可测试的需求规格。 那是梦想。现实通常是在几次迭代之后，每个人都会低下头并编写代码，直到剩下一个月的时间来测试。 这里已经有一些很棒的主意。以下是我一直希望牢记的一些需求收集原则：
了解用户和客户之间的区别。 因为我们都是人，所以我们往往不记得所有令人毛骨悚然的细节。与更多的人交谈并进行交叉检查时，发现错过需求的可能性增加。
避免特价
原型 收集业务需求是胡扯-史蒂夫·耶格(Steve Yegge) 在与涉众/用户/任何人交谈之前，请确保您将能够以有用且持久的方式放下收集的信息。
我知道问题是在会前的角度来看的，但是请注意，您可以在会议之前处理此事项，并最终进行非常有用，完整和高质量的聚会。 我一直在使用思维导图(如工作分解结构)来帮助收集需求和定义未知项(项目杀手的第一名)。从高层次开始，然后逐步解决。您需要与赞助商，用户和开发团队合作，以确保您获得所有角度并且不会错过任何内容。如果没有他们的参与，就无法期望他们了解自己想要的整个范围...作为项目经理/ BA，您需要让他们参与(工作中最重要的部分)。
像软件开发过程的大多数阶段一样，其迭代效果最佳。 首先找出您的用户是谁-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(知识手册)，可以从他们的网站上下载。他们也有证书。 |
需求收集
推荐阅读
