需求分析心得——噪声收集小分队

我们小组采用的是NABCD模型，分析项目需求。

弯路总要走的，最开始我们没有意识到规范性的重要，带着用户（导师）的口头需求和满腔热情开了第一次会议，结果讨论出来的需求没有条理不说，整理成文档后，在需求文档1.01版本中基本被推翻了。

N为Need

用户是上帝，所以需求的核心是要实现用户所有想要的，也就是在用户角度的需求，在核心的需求中，不需要考虑实现方式、竞争力度等外在因素，只需要分析完成哪些功能才能拿到用户所允诺的报酬。在我们的项目中，老师的需求就是：测量噪声数据，上传给服务器，生成噪声地图。

解决了核心需求，就要从这些需求联想创新点了，这些是用户不会告诉我们的，只完成了核心需求的版本，用户会说“可以，但是不好”，但是依旧不会告诉我们哪里不好，还需要什么。需要注意的是，这些创新点一定是跟核心需求相关联的。我们一开始的弯路就是因为还没有落实核心需求，就开始发散了。

A为Approach

有了需求，就要看我们的需求要用什么招数来解决。这些招数包括技术上的（开发语言、技术水平、开发平台等）、人脉上的（比如我们的项目是偏公益的，如何获得足够多的用户）、成本上的（比如作为学生，我们能承担起多高的开发成本）等等。

B为Benifit

产品的好处就和需求中的创新点息息相关了，要看我们的产品能给用户带来什么好处。这是我们项目的一大重点，作为公益性质的项目，我们必须有足够的理由说服用户使用我们的产品，并提供给我们数据。我们的项目，既要满足核心用户——导师的需求，也就是他需要的数据，又要满足实现过程中产生的用户——app使用者的需求。

C为Competitors

产品的竞争是无法逃避的，既然是根据需求产生的产品，那绝不会只有我们要去满足用户的这个需求，如果我们是先进入市场的，那就要面临如何不被后面的产品碾压的问题，如果我们是后进入市场的，就要做到碾压有先发优势的产品，让用户放弃竞品，改选我们。

D为Deliver

在这个项目的需求分析中，我们并没有注重推广这个元素。