您如何进行需求收集阶段？有没有人有一套好的指导方针或提示可以遵循？问利益相关者有什么好的问题？
我目前正在做一个新项目，还有很多未知数。我正在提出要向利益相关者提出的问题清单。然而，我不禁觉得我错过了一些东西或忘记提出一个关键问题。
Aros
问问题
22553 次
20 回答
20
请参阅下面的强制性漫画...
一般来说，我会尝试了解我的客户/客户试图用他们想要构建的应用程序来模拟的商业模式。我们是否正在构建一个美化的表单处理器？我们是否在单个应用程序中从多个来源检索数据以节省时间？我们是否在执行某种集成？
建立通用业务模型后，我将转到应用程序的“必须”和“不得”来规定我可以检索哪些数据，谁可以执行哪些功能等。
通常，如果您可以让客户解释他们的模型或工作流程，您可以从那里移动并找到其他关键问题。
我总是确保以某种形式提出的一个问题是“在做 X 时，你必须做的最棘手/最烦人的事情是什么。通常，这个问题的答案揭示了你必须实施的最疯狂的业务/数据规则.
希望这可以帮助！
于 2008-08-26T22:36:10.250 回答
20
你几乎肯定错过了一些东西。很多事情，大概。别担心，没关系。即使您记住了所有内容并涵盖了所有基础，利益相关者也无法在没有任何参考点的情况下为您提供非常好的、清晰的需求。做这种事情的最好方法是现在从他们那里得到你能得到的东西，然后拿走它，给他们一些反应。它可以是纸质原型、模型、软件的 0.1 版，等等。然后他们可以开始告诉你他们真正想要什么。
于 2008-08-26T22:36:16.053 回答
12
Steve Yegge的谈话很有趣，但要弄清楚其他人的要求是什么可以赚到钱，所以我会对他的文章持怀疑态度。
由于沟通的工作方式，需求收集非常困难。它是一个四步过程，每一步都是有损的。
- 我脑子里有个主意
- 我把它变成文字和图片
- 你解读图片和文字
- 你在自己的脑海中描绘出我最初的想法是什么样的
人类在这方面惨遭失败，由于他们可爱的缺陷，令人担忧的频率令人担忧。
敏捷在促进迭代开发方面做得很好。将早期版本提供给客户对于确定哪些功能最重要（0.1 - 0.5 ish 中的内容）非常重要，有助于让您在应用程序如何工作方面保持正确的轨道，并快速识别隐藏的功能你会想念的。
两个主要的问题场景是天平的两端：
- 对自己在做什么一无所知- 找一些领域专家
- 需求太多——功能坑。- 问题，剔除（优先；））特征和使用迭代开发
Yegge 很好地指出领域专家对于产生好的需求是必不可少的，因为他们了解业务并且已经在其中工作过。他们可以帮助确定客户的核心愿望，并帮助解释他们的员工将如何使用该系统以及对员工来说什么是重要的。替代方案和补充包括尝试自己完成工作以进入心态或让客户工作人员偶尔在现场，尽管后者不太可能发生。
功能坑是另一边，大多都是失败的政府IT项目。太多，太快，没有足够的思考或现实主义的应用（但你认为他们只有大约四年的时间让自己感到重要吗？）。这里的目的是弄清楚客户真正想要什么。只要您致力于使核心组件正确，高效且无错误，客户端通常会容忍稍后发货的缺失功能，只要它们最终到达。这是迭代开发真正有用的地方。
请记住将客户对程序将是什么样的想法和他们希望程序实现什么的想法分开。一些客户可能会通过以应用程序功能的形式传达他们的需求来制造混乱，这些功能可能经过深思熟虑，或者由于比他们认为需要的更简单的功能而变得多余。虽然我不主张称客户为白痴或不听他们的意见，但我觉得值得永远问他们为什么要某个特定功能来实现其潜在目的。
请记住，在任何一种情况下，都必须找出满足客户核心需求的最快途径，并将您置于双方都能从这种关系中获利的情况下。
于 2008-08-27T00:30:51.050 回答
8
哇，从哪里开始？
首先，有人应该对某些项目进行分析，但它确实取决于您为谁构建的内容。换句话说，如果您正在为财富 100 强公司修改企业应用程序、构建 iPhone 应用程序或向个人网页添加功能，这会产生很大的不同。
二是要求不同。
- 目标：用户想要完成什么？
- 功能性：用户需要做什么才能达到他们的目标？（思考实现目标的步骤）
- 非功能性：您的程序需要执行的约束是什么？（想想 10 对 10k 同时用户、增长、备份等）
- 业务规则：您必须满足哪些动态约束？（想想计算、定义、法律问题等）
第三，最有效地收集需求并获得反馈的方法（你会这样做，对吗？）是使用模型。用户案例和用户故事是用户需要做什么的模型。流程模型是需要发生的事情的另一个版本。系统图只是程序不同部分如何交互的另一种模型。良好的数据建模将定义业务概念并向您展示程序中发生的输入、输出和更改。模型（还有比我列出的更多）确实是您列出的关注点的关键。一些好的模型将捕获需求，您可以从模型中确定您的需求。
第四，获得反馈。我知道我已经提到过这一点，但你不会第一次就做好一切，所以要对客户的需求做出回应。
尽管我很欣赏需求以及驱动它们的模型，但用户通常不了解他们所有请求的后果。与审查和反馈机会的持续沟通将使用户更好地了解您提供的内容。此外，他们将根据他们所看到的来完善他们的理解。除非您为政府工作，否则迭代和/或原型是有帮助的。
于 2008-09-20T16:05:51.000 回答
6
首先在开始编码之前收集需求。您可以在收集它们的同时根据您的项目生命周期开始设计，但您不应该在没有它们的情况下开始编码。
需求是一组写得很好的文档，可以保护客户和您自己。永远别忘了。如果没有要求，那么它就没有被支付（因此它需要一个正式的变更请求），如果它存在，那么它必须被实施并且必须正常工作。
需求必须是可测试的。如果一个需求不能被测试，那么它就不是一个需求。这意味着类似“系统”
要求必须是具体的。这意味着声明“系统用户界面应易于使用”不是正确的要求。
为了真正“收集”需求，您首先需要确保您了解业务模型。客户会用自己的话告诉你他们想要什么，你的工作是理解它并在正确的上下文中解释它。
在开发需求时与客户开会。用您自己的话向客户描述它们，并确保您和客户在需求中具有相同的概念。
需求需要简洁、可测试的示例，但要跟踪会议中出现的所有其他事情、图表、疑问，并尝试保存每次会议的记录。
如果您可以使用增量生命周期，这将使您能够改进一些不良收集的需求。
于 2008-08-26T23:56:58.213 回答
3
你永远不能问太多或“愚蠢”的问题。你问的问题越多，你得到的答案就越多。
于 2008-08-26T22:34:47.583 回答
3
根据史蒂夫·耶格的说法，这是一个错误的问题。如果您正在收集需求已经为时已晚，您的项目注定要失败。
于 2008-08-26T23:25:38.897 回答
2
关于目的、范围、操作环境限制、规模等的高层讨论
试听系统的单段描述，敲定
模拟 UI
形式化已知需求
现在在 3 和 4 之间迭代，使用越来越多的功能原型和更多细节的规范。边走边写测试。这样做，直到您拥有功能性软件和完整、客观、可测试的需求规范。
这就是梦想。现实情况通常是在几次迭代之后，每个人都低头编写代码，直到还有一个月的时间进行测试。
于 2008-08-27T00:45:14.727 回答
1
这里已经有一些很棒的想法了。以下是一些我一直喜欢牢记的需求收集原则：
了解用户和客户之间的区别。 批准闪亮项目的企业主通常是客户。然而，一个毁灭性的错误是倾向于将他们作为用户混淆。客户通常是认识到对您的产品的需求的人，但用户是实际使用解决方案的人（并且很可能稍后会抱怨您的产品未满足的要求）。去多人
因为我们都是人类，我们往往不会记住每一个令人痛苦的细节。当您与更多人交谈并进行交叉检查时，您发现遗漏需求的可能性就会增加。
避免特价 当用户要求一些非常具体的东西时，要小心。始终质疑偏见，看看这是否真的会让你的产品变得更好。
原型 不要等到发布后才向用户展示你拥有的东西。做频繁的原型（你甚至可以称它们为 beta 版本）并在整个开发过程中获得持续的反馈。执行此操作时，您可能会发现更多要求。
于 2008-09-16T06:17:58.787 回答
1
收集业务需求是胡说八道- Steve Yegge
于 2008-09-16T10:56:06.077 回答
1
我一直在使用思维导图（如工作分解结构）来帮助收集需求并定义未知数（#1 项目杀手）。从高水平开始，然后逐步下降。您需要与赞助商、用户和开发团队合作，以确保您获得所有角度并且不会遗漏任何内容。在没有他们参与的情况下，你不可能知道他们想要什么的全部范围……作为项目经理/BA，你需要让他们参与进来（工作中最重要的部分）。
于 2009-01-14T01:56:08.603 回答
1
- 阅读敏捷宣言——工作软件是软件项目成功的唯一衡量标准
- 熟悉敏捷软件实践——学习 Scrum、精益编程、xp 等——这将为您节省大量时间，不仅用于收集需求，还用于整个软件开发生命周期
- 与客户，尤其是未来的用户和关键用户保持定期讨论
- 确保您与了解问题领域的人交谈 - 例如该领域的专家
- 在会谈期间做一些小笔记
- 每次对话后，写一份正式的需求清单并提交批准。以后很难反对所有商定的文件
- 确保您的客户大致了解实施“有条件”要求所需的时间和金钱的大致费用是多少
- 确保从一开始就将要求标记为“必须有”、“应该有”和“很高兴有”，确保客户也了解这些类型之间的差异
- 将所有文档集成到最新和最终的需求分析中（或当前用于迭代的文档或您正在使用的任何敏捷编程周期......）
- 请记住，需求在软件生命周期中确实会发生变化，因此收集是一回事，而管理和实施则是另一回事。
- KISS - 尽可能简单
- 还要研究未来系统将驻留的环境——遗留系统或周边系统的技术限制越来越多，因为公司不愿意把他们几十年来投资的钱扔进垃圾箱，即使在我们现代人的头脑中是 20 年。旧代码是垃圾......
于 2009-05-19T06:03:23.880 回答
1
像软件开发过程的大多数阶段一样，它的迭代效果最好。
首先找出你的用户是谁——XYZ部门，
然后找出他们适合组织的位置——Z部门的一部分，
然后找出他们在一般情况下所做的事情——管理现金
然后具体来说——从收银台收取现金，并检查收银台是否存在欺诈行为。
然后你就可以开始和他们交谈了。
询问他们想要你解决什么问题——你会得到一个答案，比如使用 OCR 和鲨鱼技术编写一个令人毛骨悚然的系统。
忽略这个答案并提出更多问题以找出真正的问题 - 他们无法阅读收款单来核对现金。
与用户商定一个真正的解决方案 - 获得更好的色带供应商 - 或将电子收银机连接到网络并将日志上传到中央服务器。
然后详细商定他们将如何衡量项目的成功。
然后才提出并同意一套详细的要求。
于 2009-05-27T08:24:30.330 回答
1
我建议您阅读Roger-Pressman 的 软件工程：从业者的方法
于 2009-05-27T08:33:25.913 回答
1
在与利益相关者/用户/任何人交谈之前，请确保您能够以一种有用且持续数天的方式记录下收集到的信息。
- 如果对方同意并且信息量大，请使用录音机。
- 如果您听到重要的事情并且需要一些合理的时间来写下来，您有两个选择：让对方稍等，或者告别那些宝贵的信息。你不会记得对的，问问任何神经科学家。
- 如果您发现某点需要更深入的审查，或者您需要一些刚刚听说的文件，请确保您与其他人承诺发送该文件或安排另一次具有更具体目的的会议。永远不要说“我会记得要那个 xls 文件”，因为在大多数情况下你不会。
- 会议结束后不久，总结一下你所有的笔记、录音和新鲜的想法。简单总结一下。为承诺创建有效的提醒。
- 同样，在会议结束后，正是了解为什么您刚刚进行的聚会不像您在会议结束时想象的那样正确的最佳时机。那时您将能够为另一次会议提出许多有意义的问题。
我知道这个问题是从会前的角度来看的，但请注意，您可以在会前处理这些问题，并最终获得一个非常有用、完整和高质量的会议。
于 2011-08-24T17:04:58.817 回答
0
我写了一篇关于我使用的方法的博客文章：
http://pm4web.blogspot.com/2008/10/needs-analysis-for-business-websites.html
基本上：在建立他们的网站之前问你的客户的问题。
我应该添加此调查表仅适用于基本网站构建 - 例如商业网站。如果您谈论的是基于 Web 的软件，则完全不同。尽管其中一些仍然是相关的（例如与外观和感觉有关的问题）。
- LM
于 2009-05-27T07:46:56.333 回答
0
需求工程是一门艺术，有很多不同的方法来实现它，你真的必须根据你的项目和相关的利益相关者来调整它。Karl Wiegers 的需求工程是一个很好的起点：
和一个需求工程过程，它可能包括许多步骤，例如：
- 引诱——作为与企业讨论的基础
- 分析和描述 - 用于开发人员的技术描述
- 详细说明、澄清、验证和协商 - 进一步细化要求
此外，还有许多记录需求的方法（用例、原型、规范、建模语言）。每个都有其优点和缺点。例如，原型非常适合从业务中引出想法和讨论想法。
我通常发现编写一组用例并包括线框原型可以很好地确定一组初始需求。从那时起，这是一个与技术人员和业务人员合作以进一步阐明和详细说明需求的持续过程。跟踪最初商定的内容并跟踪附加要求对于避免范围蔓延至关重要。根据断铁三角 ( http://www.ambysoft.com/essays/brokenTriangle.html )，各方之间的谈判也起到了一定的作用。
于 2009-05-27T08:01:19.550 回答
0
IMO 最重要的第一步是建立一个特定领域单词的字典。当您的客户说“订单”时，他是什么意思？他从客户那里收到的东西还是他发送给供应商的东西？或者两者兼而有之？
在利益相关者的业务中找到关键词，让他们解释这些词，直到你在这个过程中理解它们的含义。否则，您将很难理解需求。
于 2009-05-27T08:16:06.213 回答
0
我更喜欢让我的需求收集过程尽可能简单、直接和彻底。您可以在此博客文章中下载我用作项目模板的示例文档：http: //allthingscs.blogspot.com/2011/03/documenting-software-architectural.html
于 2011-03-25T22:46:06.930 回答