从架构活动的整体目标出发，确认需求存在的必要性。很多时候，尤其是大的项目，需求方经常会夹带私货。虽然他们并没有什么恶意，但是这些附加的需求不仅会消耗研发资源，还会增加项目复杂度和规划难度。而最坏的情况，就是附加需求会引入风险，导致整个项目的失败。
作为架构师，你需要准确区分最小必要的需求和无关紧要的需求。只有那些与项目目标形成因果关系的强依赖需求，才是属于架构活动的需求。
这个梳理过程，之所以要放在问题域和执行域划分之后，是因为需求属于问题域的范畴，而需求的执行则属于执行域的范畴。如果没有领域划分，你就需要自行砍掉附加需求。真要到这种情况，估计你这个架构师很快就混不下去了。
砍需求是个非常得罪人的事情。你做这件事情必须要有个同盟，也就是与需求对应的、问题域映射到执行域的负责人。因为在砍掉不必要的需求上，你们两个人的利益是一致的。你为了整个架构活动的成功，他则是为了控制自己领域的风险。你可以站出来表达比较客观的立场，而他则可以帮助你证实这个立场的合理性。
这个过程与确认目标的过程类似，你的关注点应该放在如下五个方面。
1、需求的必要性
这个需求有必要吗？与整体目标是因果关系吗？无论这个需求的价值有多大，只要它不是架构活动的必要条件，就应该分开考虑，最好完全隔离在架构活动之外。架构规划最忌好大喜功。
2、需求的正确性
需求是否和架构目标相匹配？想要得到赞助者所期望的商业价值，那你这个需求目标的正确数量级应该是多少？如果一个需求的预期目标，比赞助者所需要的值还要小一个数量级，说明这个目标是不正确的。
事实上，需求不正确的情况在架构活动中频繁发生。表面上看，可能是执行的队友不给力。但更真实的原因是你这个架构师不给力，没有及早发现规划的软肋。
3、需求合理性
在当前交付时间的约束下，需求的交付时间和质量要求是否合理？ 是否会出现研发团队动作和设计完全变形的情况？
4、需求的可达性
当前的时间要求和资源投入，能产出质量上可以接受的实施方案吗？实施方案是否高于质量底线？如果某个需求需要多个团队协同，那么我们能留出足够的时间，让团队处理集成中出现的问题吗？
5、需求的承接方
这个需求有且仅有一个团队承接吗？是他们应该承接的吗？他们愿意吗？能力够吗？有研发带宽吗？
一个架构活动中最终要承接的需求，在这五个问题的答案上必须是肯定的。而这个梳理需求的过程，其实也是执行风险的梳理过程。完成这个梳理过程后，你应该对需求与架构目标之间的因果联系有了信心。那么接下来，我们就需要形成一张完整的映射关系表。
此文章为5月Day16 学习笔记，内容来源于极客时间《郭东白的架构课》，推荐该课程。
