需求收集
您如何进行需求收集阶段？ 有人有一套好的指南或技巧可供遵循吗？ 有哪些值得向利益相关者提出的好问题？
我目前正在开发一个新项目，有很多未知因素。 我正在列出一系列问题来询问利益相关者。 然而，我忍不住觉得我错过了一些东西或者忘记问一个关键问题。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
您如何进行需求收集阶段？ 有人有一套好的指南或技巧可供遵循吗？ 有哪些值得向利益相关者提出的好问题？
我目前正在开发一个新项目，有很多未知因素。 我正在列出一系列问题来询问利益相关者。 然而，我忍不住觉得我错过了一些东西或者忘记问一个关键问题。
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（20）
我更喜欢让我的需求收集过程尽可能简单、直接和彻底。 您可以在此博客文章中下载我用作项目模板的示例文档：http://allthingscs.blogspot.com/2011/03/documenting-software-architectural.html
I prefer to keep my requirements gathering process as simple, direct and thorough as possible. You can download a sample document that I use as a template for my projects at this blog posting: http://allthingscs.blogspot.com/2011/03/documenting-software-architectural.html
我写了一篇关于我使用的方法的博客文章：
http ://pm4web.blogspot.com/2008/10/needs-analysis-for-business-websites.html
基本上：在构建网站之前向客户询问的问题。
我应该补充一点，此调查表仅适用于基本网站建设 - 例如商业网站。 如果你谈论的是基于网络的软件，情况就完全不同了。 尽管其中一些仍然相关（例如与外观和感觉相关的问题）。
i wrote a blog article about the approach i use:
http://pm4web.blogspot.com/2008/10/needs-analysis-for-business-websites.html
basically: questions to ask your client before building their website.
i should add this questionnaire sheet is only geared towards basic website builds - like a business web presence. totally different story if you are talking about web-based software. although some of it is still relavant (e.g. questions relating to look and feel).
IMO 最重要的第一步是建立一个特定领域单词的字典。 当你的客户说“订单”时，他是什么意思？ 他从客户那里收到的东西还是发送给供应商的东西？ 或者也许两者兼而有之？
找到利益相关者业务中的关键词，让他们解释这些词，直到你在这个过程中理解它们的含义。 如果没有这一点，您将很难理解这些要求。
IMO the most important first step is to set up a dictornary of domain-specific words. When your client says "order", what does he mean? Something he receives from his customers or something he sends to his suppliers? Or maybe both?
Find the keywords in the stakeholders' business, and let them explain those words until you comprehend their meaning in the process. Without that, you will have a hard time trying to understand the requirements.
需求工程是一门艺术，有很多不同的方法可以实现，您确实必须根据您的项目和所涉及的利益相关者进行定制。 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）。
Requirements Engineering is a bit of an art, there are lots of different ways to go about it, you really have to tailor it to your project and the stakeholders involved. A good place to start is with Requirements Engineering by 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
and a requirements engineering process which may consist of a number of steps e.g.:
Also, there are a number of ways of documenting the requirements (Use Cases, Prototypes, Specifications, Modelling Languages). Each have their advantages and disadvantages. For example prototypes are very good for elicitation of ideas from the business and discussion of ideas.
I generally find that writing a set of use cases and including wireframe prototypes works well to identify an initial set of requirements. From that point it's a continual process of working with technical people and business people to further clarify and elaborate on the requirements. Keeping track of what was initially agreed and tracking additional requirements are essential to avoid scope creep. Negotiation plays a bit part here also between the various parties as per the Broken Iron Triangle (http://www.ambysoft.com/essays/brokenTriangle.html).
我最近开始使用国际商业分析师协会组织 (IIBA）。
他们有一本非常好的 BOK（知识之书），可以从他们的网站下载。 他们也有证书。
I recently started using the concepts, standards and templates defined by the International Institute of Business Analysts organization (IIBA).
They have a pretty good BOK (Book of Knowledge) that can be downloaded from their website. They do also have a certificate.
我一直在使用思维导图（如工作分解结构）来帮助收集需求并定义未知数（第一项目杀手）。 从高水平开始，然后逐步降低。 您需要与赞助商、用户和开发团队合作，以确保您获得所有角度并且不错过任何内容。 如果没有他们的参与，您不能期望了解他们想要的全部范围……您 - 作为项目经理/BA - 需要让他们参与（工作中最重要的部分）。
I've been using mind mapping (like a work breakdown structure) to help gather requirements and define the unknowns (the #1 project killer). Start at a high level and work your way down. You need to work with the sponsors, users and development team to ensure you get all the angles and don't miss anything. You can't be expected to know the entire scope of what they want without their involvement...you - as a project manager/BA - need to get them involved (most important part of the job).
这里已经有一些很棒的想法了。 以下是我始终牢记的一些需求收集原则：
了解用户和客户之间的区别。
批准闪亮项目的企业主通常是客户。 然而，一个毁灭性的错误是容易将他们作为用户混淆。 客户通常是认识到您的产品需求的人，但用户是实际使用该解决方案的人（并且很可能稍后会抱怨您的产品未满足要求）。
去找多个人
因为我们都是人，我们往往不会记住每一个令人痛苦的细节。 当您与更多的人交谈并交叉检查时，您发现遗漏需求的可能性就会增加。
避免特价
当用户要求非常具体的内容时，请保持警惕。 始终质疑偏见，看看这是否真的能让你的产品变得更好。
原型
不要等到发布才向用户展示您拥有的内容。 经常制作原型（您甚至可以将其称为测试版）并在整个开发过程中不断获得反馈。 当您这样做时，您可能会发现更多要求。
There are some great ideas here already. Here are some requirements gathering principles that I always like to keep in mind:
Know the difference between the user and the customer.
The business owners that approve the shiny project are usually the customers. However, a devastating mistake is the tendency to confuse them as the user. The customer is usually the person that recognizes the need for your product, but the user is the person that will actually be using the solution (and will most likely complain later about a requirement your product did not meet).
Go to more than one person
Because we’re all human, and we tend to not remember every excruciating detail. You increase your likelihood of finding missed requirements as you talk to more people and cross-check.
Avoid specials
When a user asks for something very specific, be wary. Always question the biases and see if this will really make your product better.
Prototype
Don’t wait till launch to show what you have to the user. Do frequent prototypes (you can even call them beta versions) and get constant feedback throughout the development process. You’ll probably find more requirements as you do this.
在与利益相关者/用户/任何人交谈之前，请确保您能够以有用且持久的方式记录收集到的信息。
我知道这个问题是从会前的角度提出的，但请注意，您可以在会议之前解决这个问题，并最终获得一次非常有用、完整和高质量的聚会。
Before you go talking to the stakeholders/users/anyone be sure you will be able to put down the gathered information in a usefull and days-lasting way.
I know the question was in the perspective of the pre-meeting, but please be aware that you can work on this matters before the meeting and end up with a much usefull, complete and quality gathering.
我建议您阅读 Roger-Pressman 的 软件工程：从业者的方法
I would suggest you to read Roger-Pressman's Software Engineering: A Practitioner's Approach
与软件开发过程的大多数阶段一样，迭代效果最好。
首先找出你的用户是谁——XYZ部门，
然后找出他们在组织中的位置——Z部门的一部分，
然后找出他们一般做什么——管理现金
然后具体来说——收取现金从收银台检查收银台欺诈行为。
然后你就可以开始和他们交谈了。
询问他们想要你解决什么问题——你会得到一个答案，就像使用 OCR 和鲨鱼技术编写一个迷惑系统一样。
忽略这个答案，再问一些问题来找出真正的问题是什么——他们无法阅读收银单来核对现金。
与用户商定一个真正的解决方案——寻找更好的色带供应商——或者将电子收银台连接到网络并将日志上传到中央服务器。
然后详细商定他们将如何衡量项目的成功。
然后才提出并同意一套详细的要求。
Like most stages of the software development process its iteration works best.
First find out who your users are -- the XYZ dept,
Then find out where they fit into the organisation -- part of Z division,
Then find out what they do in general terms -- manage cash
Then in specific terms -- collect cash from tills, and check for till fraud.
Then you can start talking to them.
Ask what problem they want you want to solve -- you will get an answer like write a bamboozling system using OCR with shark technoligies.
Ignore that answer and ask some more questions to find out what the real problem is -- they cant read the till slips to reconcile the cash.
Agree a real solution with the users -- get a better ink ribbon supplier - or connect the electronic tills to the network and upload the logs to a central server.
Then agree in detail how they will measure the success of the project.
Then and only then propose and agree a detailed set of requirements.
收集业务需求都是废话 - Steve Yegge
Gathering Business Requirements Are Bullshit - Steve Yegge
关于目的、范围、操作环境限制、规模等的高级讨论
试听以下内容的单段描述系统，敲定
模拟UI
形式化已知需求
现在在 3 和 4 之间迭代，具有越来越多的功能原型和更多规格以及更多细节。 边走边写测试。 这样做，直到您拥有功能性软件和完整、客观、可测试的需求规范。
这就是梦想。 现实情况通常是，经过几次迭代后，每个人都会低头编码，直到还剩一个月的时间进行测试。
High-level discussions about purpose, scope, limitations of operating environment, size, etc
Audition a single paragraph description of the system, hammer it out
Mock up UI
Formalize known requirements
Now iterate between 3 and 4 with more and more functional prototypes and more specs with more details. Write tests as you go. Do this until you have functional software and a complete, objective, testable requirements spec.
That's the dream. The reality is usually after a couple iterations everybody goes head-down and codes until there's a month left to test.
根据 Steve Yegge 的说法，这是问错误的问题。 如果您正在收集需求，那就已经太晚了，您的项目注定要失败。
According to Steve Yegge that's the wrong question to ask. If you're gathering requirement it's already too late, your project is doomed.
你永远不能问太多或“愚蠢”的问题。 您提出的问题越多，您收到的答案就越多。
You can never ask too many or "stupid" questions. The more questions you ask, the more answers you receive.
首先，在开始编码之前收集需求。 您可以在收集它们时开始设计，具体取决于您的项目生命周期，但您不应该在没有它们的情况下开始编码。
要求是一组精心编写的文件，可以保护客户和您自己。 永远别忘了。 如果不存在任何要求，则未支付费用（因此需要正式的变更请求），如果存在，则必须实施并且必须正常工作。
需求必须是可测试的。 如果一个需求无法被测试，那么它就不是一个需求。 这意味着“系统”
要求必须是具体的。 这意味着“系统用户界面应易于使用”并不是一个正确的要求。
为了真正“收集”需求，您首先需要确保您了解业务模型。 客户会用自己的话告诉你他们想要什么，你的工作就是理解它并在正确的上下文中解释它。
在制定需求时与客户召开会议。 用你自己的话向客户描述它们，并确保你和客户在需求中具有相同的概念。
要求需要简洁、可测试的示例，但要跟踪会议中出现的所有其他事情、图表、疑问，并尝试保留每次会议的记录。
如果您可以使用增量生命周期，那么您将能够改进一些不良的收集需求。
First of all gather the requirements before you start coding. You can begin the design while you are gathering them depending on your project life cicle but you shouldn't ever start coding without them.
Requirements are a set of well written documents that protect both the client and yourself. Never forget that. If no requirement is present then it was not paid for (and thus it requires a formal change request), if it's present then it must be implemented and must work correctly.
Requirements must be testable. If a requirement cannot be tested then it isn't a requirement. That means something like, "The system "
Requirements must be concrete. That means stating "The system user interface shall be easy to use" is not a correct requirment.
In order to actually "gather" the requirements you need to first make sure you understand the businness model. The client will tell you what they want with its own words, it is your job to understand it and interpret it in the right context.
Make meetings with the client while you're developing the requirements. Describe them to the client with your own words and make sure you and the client have the same concept in the requirements.
Requirements require concise, testable example, but keep track of every other thing that comes up in the meetings, diagrams, doubts and try to mantain a record of every meeting.
If you can use an incremental life cycle, that will give you the ability to improve some bad gathered requirements.
哇，从哪里开始呢？
首先，有人应该具备一套知识来对某些项目进行分析，但这实际上取决于您为谁构建什么。 换句话说，如果您正在为财富 100 强公司修改企业应用程序、构建 iPhone 应用程序或向个人网页添加功能，这会产生很大的差异。
其次，要求不同。
第三，最有效地收集需求并获得反馈的方法（你会这样做，对吧？）是使用模型。 用户案例和用户故事是用户需要做什么的模型。 流程模型是需要发生的事情的另一个版本。 系统图只是程序不同部分如何交互的另一种模型。 良好的数据建模将定义业务概念并向您展示程序中发生的输入、输出和更改。 模型（比我列出的更多）确实是您列出的问题的关键。 一些好的模型将捕获需求，并且您可以从模型中确定您的需求。
第四，获取反馈。 我知道我已经提到过这一点，但你不可能一次就把所有事情都做好，所以要根据客户的需求做出回应。
尽管我很欣赏需求以及驱动它们的模型，但用户通常不了解他们所有请求的后果。 持续的沟通以及审查和反馈的机会将使用户更好地理解您所提供的内容。 此外，他们将根据所看到的内容完善他们的理解。 除非您为政府工作，否则迭代和/或原型会很有帮助。
Wow, where to start?
First, there is a set of knowledge someone should have to do analysis on some projects, but it really depends on what you are building for who. In other words, it makes a big difference if you are modifying an enterprise application for a Fortune 100 corporation, building an iPhone app, or adding functionality to a personal webpage.
Second, there are different kinds of requirements.
Third, the way to gather requirements most effectively, and then get feedback on them (which you will do, right?) is to use models. User cases and user stories are a model of what the user needs to do. Process models are another version of what needs to happen. System diagrams are just another model of how different parts of the program(s) interact. Good data modeling will define business concepts and show you the inputs, outputs, and changes that happen within your program. Models (and there are more than I listed) are really the key to the concern you list. A few good models will capture the needs and from models you can determine your requirements.
Fourth, get feedback. I know I mentioned this already, but you will not get everything right the first time, so get responses to what your customer wants.
As much as I appreciate requirements, and the models that drive them, users typically do not understand the ramifications of of all their requests. Constant communication with chances for review and feedback will give users a better understanding of what you are delivering. Further, they will refine their understanding based on what they see. Unless you're working for the government, iterations and / or prototypes are helpful.
Steve Yegge 说话很有趣，但有钱是为了弄清楚其他人的需求是什么，所以我对他的文章持保留态度。
由于沟通方式的原因，收集需求非常困难。 它是一个四步过程，每一步都是有损的。
而人类由于他们可爱的缺陷而以令人担忧的频率在这方面惨遭失败。
敏捷在促进迭代开发方面做得很好。 将早期版本提供给客户对于确定哪些功能最重要（0.1 - 0.5 左右的功能）非常重要，有助于让您在应用程序如何工作方面保持在正确的轨道上，并快速识别需要隐藏的功能。你将会错过。
两个主要问题场景是天平的两端：
Yegge 很好地指出，领域专家对于产生良好的需求至关重要，因为他们了解业务并在其中工作过。 他们可以帮助确定客户的核心愿望，并帮助解释他们的员工将如何使用该系统以及什么对员工来说很重要。
替代方案和补充包括尝试自己完成工作以进入思维模式或偶尔让客户工作人员在现场，尽管后者不太可能发生。
功能坑在另一边，大部分都是失败的政府 IT 项目。 太多、太快、对现实主义的思考或应用不够（但你指望他们只有大约四年的时间来让自己感到重要吗？）。 这里的目的是弄清楚客户真正想要什么。
只要您努力使核心组件正确，高效且无错误的客户通常仍然可以容忍稍后发货中到达的缺失功能，只要它们最终到达即可。 这就是迭代开发真正有用的地方。
请记住将客户对程序的想法与他们希望程序实现的目标分开。。
一些客户可能会通过以应用程序功能的形式传达他们的需求而造成混乱，这些功能可能没有经过深思熟虑，或者由于功能比他们认为需要的简单得多而变得多余。 虽然我不主张称客户为白痴或不听他们的意见，但我认为值得永远询问他们为什么想要某个特定功能来实现其根本目的。
请记住，在任何一种情况下，找出满足客户核心需求的最快路径并使您双方都能从这种关系中获利的情况都至关重要。
Steve Yegge talks fun but there is money to be made in working out what other people's requirements are so i'd take his article with a pinch of salt.
Requirements gathering is incredibly tough because of the manner in which communication works. Its a four step process that is lossy in each step.
And humans fail miserably at this with worrying frequency through their adorable imperfections.
Agile does right in promoting iterative development. Getting early versions out to the client is important in identifying what features are most important (what ships in 0.1 - 0.5 ish), helps to keep you both on the right track in terms of how the application will work and quickly identifies the hidden features that you will miss.
The two main problem scenarios are the two ends of the scales:
Yegge does well in pointing out that domain experts are essential to produce good requirements because they know the business and have worked in it. They can help identify the core desire of the client and will help explain how their staff will use the system and what is important to the staff.
Alternatives and additions include trying to do the job yourself to get into the mindset or having a client staff member occasionally on-site, although the latter is unlikely to happen.
The feature pit is the other side, mostly full of failed government IT projects. Too much, too soon, not enough thought or application of realism (but what do you expect they have only about four years to make themselves feel important?). The aim here is to work out what the customer really wants.
As long as you work on getting the core components correct, efficient and bug-free clients usually remain tolerant of missing features that arrive in later shipments, as long as they eventually arrive. This is where iterative development really helps.
Remember to separate the client's ideas of what the program will be like and what they want the program to achieve.
Some clients can create confusion by communicating their requirements in the form of application features which may be poorly thought out or made redundant by much simpler functionality then they think they require. While I'm not advocating calling the client an idiot or not listening to them I feel that it is worth forever asking why they want a particular feature to get to its underlying purpose.
Remember that in either scenario it is of imperative importantance to root out the quickest path to fulfilling the customers core need and put you in a scenario where you are both profiting from the relationship.
请参阅下面的必读漫画...
一般来说，我会尝试了解我的客户/客户试图用他们想要构建的应用程序来模拟的业务模型。 我们正在构建一个出色的表单处理器吗？ 我们是否在单个应用程序中从多个源检索数据以节省时间？ 我们正在执行某种集成吗？
一旦建立了一般业务模型，我就会转向应用程序的“必须”和“不得”，以规定我可以检索哪些数据、谁可以执行哪些功能等。
通常，如果您能让客户解释他们的需求 ，模型或工作流程，您可以从那里移动并找到其他关键问题。
我总是确保以某种形式问的一个问题是“在做 X 时你必须做的最棘手/最烦人的事情是什么。通常，这个问题的答案揭示了你必须实施的最疯狂的业务/数据规则.
希望这有帮助
！
See obligatory comic below...
In general, I try and get a feel for the business model my customer/client is trying to emulate with the application they want built. Are we building a glorified forms processor? Are we retrieving data from multiple sources in a single application to save time? Are we performing some kind of integration?
Once the general businesss model is established, I then move to the "must" and "must nots" for the application to dictate what data I can retrieve, who can perform what functions, etc.
Usually if you can get the customer to explain their model or workflow, you can move from there and find additional key questions.
The one question I always make sure to ask in some form or another is "What is the trickiest/most annoying thing you have to do when doing X. Typically the answer to that reveals the craziest business/data rule you'll have to implement.
Hope this helps!
几乎可以肯定你错过了一些东西。 可能有很多事情。 别担心，没关系。 即使您记住了所有内容并涵盖了所有基础，利益相关者也无法在没有任何参考点的情况下为您提供非常好的、明确的要求。 做这种事情的最好方法就是现在就从他们那里得到你能得到的东西，然后给他们一些东西来做出反应。 它可以是纸质原型、模型、软件的 0.1 版本等等。 然后他们就可以开始告诉你他们真正想要什么。
You're almost certainly missing something. A lot of things, probably. Don't worry, it's ok. Even if you remembered everything and covered all the bases stakeholders aren't going to be able to give you very good, clear requirements without any point of reference. The best way to do this sort of thing is to get what you can from them now, then take that and give them something to react to. It can be a paper prototype, a mockup, version 0.1 of the software, whatever. Then they can start telling you what they really want.