事实1：需求其实并非谈需求
对于软件产品、硬件产品、服务或任何你想构建的东西，需求就是它们要做的事或要成为的东西。不论你发现还是没发现，写下来或没写下来，需求都存在。显然，除非产品满足需求，否则就不对。所以，从这个角度你可以认为，需求是某种自然法则，等着你来发现。
需求活动主要不是编写需求文档。相反，它专注于理解业务问题，并为之提供解决方案。需求发现的真正艺术是发现真实的问题。
另外，我们讲的“业务”、“业务问题”或“工作时”，我们的意思是你所关心的各种活动，它们可以是商业上的、科学上的、嵌入式的、政府的、军方的、实际上也可以是所有其他类型的活动、服务或消费品。
事实2：如果我们必须构建软件，那么它必须为拥有它的人提供最理想的价值
拥有者是为产品付费的人或组织，不论拥有者为该软件付了钱，还是从其他地方购买了该软件，软件拥有者和软件的关系都是，拥有者花钱买了好处。
我们要明确，除非产品提供了利益，否则拥有者不会付钱。
而需求发现者的职责，就是确定拥有者着重的利益、价值是什么。
事实3：如果软件不必满足要求，那你怎么干都行。但是，如果它打算满足要求，你就必须知道要求是什么，才能构建正确的软件。
如果开发者正确地理解了产品打算为用户完成什么，以怎样的方式完成，这些产品就是最有用的。要理解这些事情，你必须理解拥有者的业务工作，并决定将来工作如何进行。
你必须得到需求的正确理解，并与客户达成一致意见，否则你的产品或项目就会有严重的缺陷。（关键词是正确理解，达成一致，也就是说光你自己理解了是不够的，还要客户能和你是在统一的思考线上，这样，你才能做到产品是客户需要的，且让客户满意。有时候你做的其实是对的，但是如果没有和客户达成一致，那客户以为没有达到他的要求的时候，他可能也不会买单）
事实4：构建一个软件和解决一个业务问题之间，存在巨大的差别。前者不一定实现后者
软件就是要解决一个业务问题，所有开发工作都必须从问题开始，而不是从看到的解决方案开始。
事实5：需求不一定要写下来，但构建者必须知道它们
需求并不是要为项目增加额外的负担，所以除非很有必要，否则就不应该写任何东西。但是，如果有需要，那么编写需求的工作将带来数倍的回报，因为需求的准确性和对将来维护工作的减少。
事实6：客 户有时候也不知道正确答案是什么，他们可能不知道什么是对的，甚至，他们也不知道自己需要什么
有时候，你的客户就是匹诺曹，不会告诉你真相。业务分析师必须表演戏法。有时候他必须记录下客户的要求，有时候他必须说服客户，他们要求的并不是他们需要的，有时候他必须从客户的解决方案中导出需求，有时候他必须提出没人提到的创新，得到更好的解决方案。
事实7：需求并不是偶然得到的，要通过某种有序的过程得到
所有重要的努力都需要有序的过程。随机使用钢筋和水泥不会建成大楼，需要一个定义的过程来设计和建造这样的结构。有序的过程由一组任务构成，实现预期的结果，但这些任务的次序，重点和应用程度需要采用该过程的人或团队决定。重要的是，参与这个过程的人必须能看到，为什么过程中不同的任务是重要的，哪些任务对项目最重要。
事实8：你怎么迭代都可以，但仍需要理解业务的需求
软件开发过程可以用各种技术实现。但是在此之前，需要理解客户的业务问题，以及产品必须做些什么来解决这个问题。
事实9：分析师使用最重要的工具：头脑、眼睛和耳朵
一些自动化的工具可以对需求活动有帮助，但是辅助工具永远无法替代好的需求实践。盲目遵循事先制定的实践，根本不能取得有经验的业务分析师能取得的结果。
事实10：要想成功地实现需求，需求就必须可度量，可测试
需求来自于人，而人并非准确，所以，要是的需求达到一定的准确程度，必须为需求找到测量目标，对需求进行测量，让需求可测试。
例如“系统应该对新用户有吸引力”，转化成一个可测量的目标，那么我们可以描述：初次使用的用户能够在2分钟内成功建立一个账号。之类的指标
从本质上说，功能需求是产品支持其拥有者的业务必须做的事。非功能需求是产品要在拥有者的环境中取得成功，必须将工完成得多好的量化描述。
事实11：作为业务分析师，你将改变用户思考这个问题的方式，不是现在就是将来
在你开始理解需求时，尤其只需求来自于不同的利益相关者时，你就开始建立了一些抽象概念，并建立一个词汇表。你展示业务过程的模型，与利益相关者一起发现工作的本质，得到清晰可测量的需求，并将所有这些事实反馈给利益相关者。在做这些事情时，你会改变（改进）他们对业务问题的看法。
本文参考文献：
《掌握需求过程》，作者Suzanne Robertson James Robertson
网友评论