构建之法阅读笔记04

      这是第四篇阅读笔记，从第八章开始。第八章是需求分析，记得我们大三应该有一门课是软件需求分析。因此这章阅读的格外认真。首先，团队全面的找到用户的需求分为几个步骤：获取和引导需求（需求捕捉），需求不仅仅来自外界，还可以来自软件企业本身和技术团队本身。分析和定义需求，验证需求，在软件产品的生命周期中管理需求。要注意需求不是一成不变的，要根据外界的各种变化时时做出调整。软件需求分为对产品功能性的要求、对产品开发过程的需求、非功能性需求、综合需求。我认为，功能性需求的实现与否决定了用户是否会使用这个软件，而非功能性需求则决定了用户是否会继续使用这个软件，毕竟是和使用感息息相关的。一个使用感不好的软件会让用户抓狂的。软件开发要尽力与满足利益相关者的需求，明白，他们想要什么。

      而如何或许用户的需求，要进行用户调查。用户调查有很多种方法，就我个人看来，最直接有效的是深入面谈，面对面的交流，开诚布公，能让用户与工程师之间互相了解对方。而用户调查问卷是最简便的，但如果问题设置的有问题那么这个问卷就不能实现需求。

      然后是竞争性需求分析的框架，段落里提到了创新，并且生动的描写了我们“间歇性凌云壮志”的场景，一拍脑袋想要做系统，再一拍胸脯觉得没问题。这显然是不靠谱的。而NABCD模型，即需求、做法、好处、竞争、推广。这样可以让理性回归头脑，并且，按部就班的做出一个系统。当然我们也没必要力求创新而忽略的基础。

      并不是所有的需求都需要面面俱到，就像心理学上如何安排时间的象限图一样，也有一个软件功能的象限。首先功能分为杀手功能和外围功能，然后需求分为必要需求和辅助需求。这样得到的象限图如下：

      接下来是计划和估计，然后就是老生常谈的分解，也就是书上说的分而治之，同样提到了愚公，这里不再赘述。

    以前觉得分析出来的需求就要全部实现，当然全部实现是最好的。但是在一些特殊原因时我们应该舍弃非必要需求。比如，为了系统的稳定性，或是为了能否运行。