APP开发项目的需求要怎么做

 

开始一个APP开发项目，对于APP开发团队而言，首先要知道做什么。APP开发的全过程是：做什么，怎么做，做 ，成果检验，交付部署；其中，“做什么”对应的是需求分析过程，“怎么做”对应于软件架构设计过程，“做”对应于开发过程，“成果检验”对应于测试，部署由运维团队执行后，如果达到用户的要求，则软件上线后进入软件的运行生命周期。

在实际的软件项目开发中，“做什么”，“怎么做”和“做”是紧密结合在一起的，“做”，“成果检验”和“交付部署”通常也会是一个持续交付过程，“成果检验”的内容会受到“做什么”的影响，开展“做什么”阶段的时候，也要考虑到如何部署和交付。所以软件开发的全过程，都是紧密结合在一起的，如果刻意划分为独立的几个阶段，忽视其作为一个整理的综合影响，每个环节的实施过程必然会遇到因上一阶段考虑不周全带来的问题，从而影响整体开发效率。

基于此，我们的需求分析，从需求深度划分，可以分为三个层次：原始需求分析、业务架构分析和功能架构分析。这三个层次依次递进，没有严格的界限。

原始需求是从用户或业务角度看到的，或应该有的需求，或项目团队经过初步挖掘后整理出来的、未经进一步提炼的需求。
如果拿做项目与做产品做个类比，原始需求有点类似与产品经理所说的“用户故事”，由于原始需求可能是开发者分析出来了，也可能是行业专家或目标客户 / 用户提出来的，原始需求可以不止步于“用户故事”，在该阶段做一定的业务逻辑的抽取和提炼，对接下来“业务架构”阶段的需求分析也是有帮助的，所以这两个阶段没必要确立一个严格的界限。

业务架构阶段的需求分析，是对原始需求的抽象和再提炼，在形成业务架构之前，首先要梳理清楚功能需求和非功能需求，非功能需求是为接下来的功能架构及怎么做铺路的，本节暂不展开；功能需求又分为“显式的功能需求”和“潜在的功能需求”，如上一节列出的需求，均为显式功能需求，潜在的功能需求要从多个角度去考虑，如整理出用户组、权限对应的完整业务逻辑，是属于可以推测并进一步开展工作的潜在功能需求，而修改密码、个人信息、用户管理和忘记密码等功能，是上面漏掉的、但又会影响到系统完整性的潜在需求，而需要提供一个系统初始化接口的功能需求，是站在运维实施角度提出来的潜在需求。

业务架构为软件系统的开发奠定了基础，在实际的软件项目中，通常可以在此基础上让需求分析再往前迈一步，将"做什么"和“怎么做”是紧密联系起来，承上启下，我将这部分需求分析称之为“功能架构分析”。
为什么需求分析中要做功能架构分析？
定性的说，这一步工作也可以纳入“怎么做”的环节再开展，但我认为把它作为需求分析的最后阶段，对整个项目过程而言更有效率。这部分工作依然是围绕需求分析展开的，前文所述的需求分析工作通常开发者也会参与进去，所以业务架构分析和功能架构分析本来就是衔接在一起的连续过程，如果把这一步工作从需求分析中抛离，项目进行到怎么做或做的阶段时，发现现实（代码逻辑和系统实施）和理想（业务逻辑）不一致的概率会更大，开发过程中可能会有更多关于“需求分析没做到位”的扯皮，甚至不得不重新返回需求分析阶段再次梳理需求，这都会带来本可避免的项目进度延误。
所以，需求分析如果只考虑“原始需求”和“业务架构”两个维度，是有盲点的，功能架构分析虽然可以作为“怎么做”的第一步，但把它作为“做什么”的最后一步，能有效减少因为没有“向后看”带来的需求分析不充分的问题，能够把需求和实现更紧密的结合在一起，它在一定程度上对业务架构做了进一步的细化，也在一定程度上影响了业务架构的最终成果。

综上，在APP开发项目中，如果要把需求分析做到位，止于功能架构分析才是保险的。