软件开发需求分析非常重要的一环，甚至高于系统分析，需求分析决定了系统分析的走势。在上一篇文章之后，今天借着这篇文章再聊一聊需求分析。
什么是需求？有一本书给出了一个非常精炼的回答：现实和期望之间的差距。就是中间这个差距需要我们去思考、调研，这是一个迭代的过程，直到最后达到期望甚至超过期望，如果用了一些错误的方法，或者被客户牵着鼻子走，最后结果可能还不如现实。
方案不是需求
开篇例举的一个生活中的小例子充分说明了什么是需求，什么是方案：
晚上小孩吵着说要吃饼干，最后给了点面包，小孩吃完就乖乖睡着了，在这里吃饼干是方案，需求是小孩的肚子饿了，当没有饼干时，可以使用第二种方案，给他吃面包也可以解决这个需求问题。
如果客户的接口人稍微懂点技术，在做需求调研时就很容易提出方案级的需求，这时就需要警惕了，需要用一些问题来深挖背后的真是需求，比如：
- 为什么会有这样一个项目，是因为同行业都有？还是因为内部管理需要？
- 这个系统是哪些角色的人用？能解决他们什么问题？
- 没有这个系统的时候现在是怎么来解决这些问题的？
- 用户使用这功能的频率是多少？这功能如果做砸了，对谁影响最大？
如果能挖到真实的需求，就可以根据情况来制定最优方案了。如果我们“完美”地满足了客户提出的“方案级需求”，最终的结果未必能让客户满意，客户通常善于发现问题，提出问题，但给出的方案往往不能完美解决问题。
在公司的内部其实也存在着这种问题，比如项目团队的同事在遇到产品满足不了的功能时，需要给产品提需求，经常看到的需求描述是：
- 在某某功能模块添加一种按钮类型；
- 在某某地方需要多一种搜索条件的配置。
这些都是方案，而不是需求，项目的同事根据自己的理解和认知完成了从需求到方案的转换，而这个方案很多时候并不是最优。
所以每每收到这种“需求”时，会马上跟项目的同事反复确认客户到底想要什么，了解到真实背景后，才能结合产品的功能给出合适的解决方案。
干系人
任何企业准备上一套系统有各种各样的原因，可能是为了提高生产效率、提高协同办公效率，也可能是为了做一些政绩。所以针对不同的场景，我们首先需要找出这个系统的相关干系人。
识别干系人有几个重要的判断标准：
- 是否是关键部门复杂人？
- 是否对项目有一票否决权？
- 系统上线是否对大量的使用者产生负面影响？比如：工作模式改变等
- 识别出的人员是否与项目有直接关系？
如果能够准确的识别关键关系人，还需要对关系人进行分析：
- 同一类如果有多个干系人，需要选出最有代表性的一个；
- 不同干系人之间是否有利益冲突；
- 干系人的专业背景、兴趣爱好（方便日后沟通）；
- 不同的干系人在各自角色上希望项目能解决什么问题？
- 对项目的落地有什么担心？
做项目不光是要做好事，关键还要能搞定人，能让重点干系人感受到系统的价值，项目就容易成功。
我认为项目的前期最核心的就是上面两个步骤：挖出核心诉求和找出重点干系人。剩下的就是分解需求进行开发实现了。不同的团队对需求分解和开发实现肯定都有适合自己的方式和方法，具体可以去阅读本书，下面说说在项目需求调研过程中经常会忽略的非功能性需求。
非功能性需求
非功能性需求通常指，安全性、性能、扩展性、稳定性等等，这些非常重要，但也是最容易被我们忽视掉的。
非功能性需求针对不同的客户或系统会有不同的侧重点，比如：
- 费控系统对计算的准确性要求高，接口需要做幂等处理等等；
- 客户是集团性质的企业，而且系统是全员使用，并发量大，性能上有较高的要求；
- 一些合资企业，系统需要进行多语言支持，可能还会进行跨地域部署；
- 事业单位、*机构对 UI 层面会有独到的见解；
- 公检法司的项目中会对安全性要求比较高，包括可能有些数据列需要加密。
这些非功能性的需求在调研阶段应该和功能性需求一起同步进行，根据客户的特征进行分析和识别，最终作为开发交付的一个检查项进行检查。
上面列举的都是和系统本身相关的一些要求，除此之外，还有很多的外在因素也是在前期调研时就应该考虑的，比如：
- 客户希望上线的时间节点？
- 如果功能较多，能不能进行分期交付？
- 客户有没有明确的技术上的要求，比如不能使用 Windows 部署，或者开发语言只能使用 Java？
- 有没有历史系统需要做数据迁移？如果有需要达到什么样的目标，是整体切换还是需要双系统并存一段时间进行逐步替换？
- 是否需要和第三方系统进行对接？如果需要，需要知道第三方系统的接口人信息以及接口规范。
现在各种各样的书籍琳琅满目，感兴趣的书买了，就有机会去阅读，这是我一直以来的一个观点，做需求每个项目负责人都有自己的方法，但多读书学习一些方法和技巧，没准哪天就能用上了。再说了，多读书，往上可以提升我们的格局和眼界，往下也能夯实和固化我们的能力。