如何作好软件项目需求分析？

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

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

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

原始需求分析

原始需求是从用户或业务角度看到的，或应该有的需求，或项目团队通过初步挖掘后整理出来的、未经进一步提炼的需求。

若是拿作项目与作产品作个类比，原始需求有点相似与产品经理所说的“用户故事”，因为原始需求多是开发者分析出来了，也多是行业专家或目标客户 / 用户提出来的，原始需求能够不止步于“用户故事”，在该阶段作必定的业务逻辑的抽取和提炼，对接下来“业务架构”阶段的需求分析也是有帮助的，因此这两个阶段不必确立一个严格的界限。

例如，对一个多人博客系统而言，原始需求多是这样的：

而对于更有经验的人而言，原始需求可能更加体系化：

首先，多人博客系统由前台展现子系统和后台管理子系统构成，两个子系统的功能能够分别来描述。

前台子系统

前台子系统应该对任何人可见，该子系统至少包含如下页面或功能：

文章列表 + 概要页面
文章详情页面
做者主页
文章评论功能
文章搜索功能
侧边栏的目录、tag 等博客经典功能
后台子系统

后台子系统只对登陆用户开放，对应多人博客而言，该子系统应该分用户组，为不一样类型用户分配不一样的权限，该子系统至少包含如下页面或功能：

用户登陆或注册功能
根据不一样用户的权限，登陆后看到不一样的页面或功能
建立新文章
修改或删除文章
维护博客名称描述等内容的功能
原始需求阶段作的，主要是需求是收集、整理和简单分析工做，为业务架构阶段的需求分析奠基了基础。

业务架构分析

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

当业务架构梳理过程当中，尤为是整理潜在功能需求时，必定会发现上一阶段疏漏或在上一阶段的视角下考虑不到的需求点，此时应结合项目的进度要求，考虑是否进行一轮需求的迭代和补充。

对上文提到的多人博客系统而言，业务架构能够设计以下：

多人博客系统业务架构

作好业务架构，是为整个软件项目迈出坚实的第一步。业务架构是需求分析中最重要的阶段，经历了整理业务架构分析的过程，基本上才真正把系统需求梳理出来了，若是简单粗暴的在需求和开发之间切出一个交接面，把交接面放在业务架构上是比较合适的，系统开发的底线是要与业务架构保持一致，后续的需求迭代或变动，也要基于业务架构扩展或重构。

业务架构对软件系统开发也有重要影响。开发软件系统，一般要求具有充分的可扩展性，而可扩展性，在需求分析阶段就奠基了基础，需求分析作的充分，就能在很大程度上给系统可扩展性定性了，当增长新功能时，系统可否扩展功能，仍是系统的某些功能要打破重来，业务架构阶段就能看出端倪。好比，若是想在多人博客系统中增长用户的社交功能，能够把该功能插入到用户模块和我的模块中去，也能够单独开一个社交模块来封闭相关功能，前者会更多的打破原有业务逻辑，从而改变已有功能的代码实现，然后者更多的是在新的模块中梳理业务逻辑，开发新功能，前者重构多于扩展，然后者扩展多于重构。因此若是业务架构设计的具备足够的扩展性，至关于软件系统先天具有较强的可扩展性。

功能架构分析

业务架构为软件系统的开发奠基了基础，在实际的软件项目中，一般能够在此基础上让需求分析再往前迈一步，将"作什么"和“怎么作”是紧密联系起来，承上启下，我将这部分需求分析称之为“功能架构分析”。

为何需求分析中要作功能架构分析？

定性的说，这一步工做也能够归入“怎么作”的环节再开展，但我认为把它做为需求分析的最后阶段，对整个项目过程而言更有效率。这部分工做依然是围绕需求分析展开的，前文所述的需求分析工做一般开发者也会参与进去，因此业务架构分析和功能架构分析原本就是衔接在一块儿的连续过程，若是把这一步工做从需求分析中抛离，项目进行到怎么作或作的阶段时，发现现实（代码逻辑和系统实施）和理想（业务逻辑）不一致的几率会更大，开发过程当中可能会有更多关于“需求分析没作到位”的扯皮，甚至不得不从新返回需求分析阶段再次梳理需求，这都会带来本可避免的项目进度延误。

因此，需求分析若是只考虑“原始需求”和“业务架构”两个维度，是有盲点的，功能架构分析虽然能够做为“怎么作”的第一步，但把它做为“作什么”的最后一步，能有效减小由于没有“向后看”带来的需求分析不充分的问题，可以把需求和实现更紧密的结合在一块儿，它在必定程度上对业务架构作了进一步的细化，也在必定程度上影响了业务架构的最终成果。

功能架构分析怎么作？

功能架构没必要刻意设计的与业务架构不一样，但功能架构分析的关注点已是为怎么作和作这两个阶段铺路了，是怎么作的基础，“怎么作”是架构师负责的，功能架构分析最好也由须要架构师来牵头和落实。

功能架构分析的主要内容有 2 点：（1）再次提炼和抽象业务功能；（2）确认和完善非功能需求。

（1）再次提炼和抽象业务功能

博客系统比较简单，其业务架构和功能架构可能基本上是一致的。对于复杂的业务系统而言，业务架构分析阶段提炼的业务功能，是有可能被再次提炼的，如：

OA 系统中，咱们从业务架构的视角看，能够整理出如“计划管理”、“任务管理”和“表单管理”等模块，这些模块的业务流程都会包含“审批流程”、“短信通知”、“邮件通知”等基础功能，这些功能在每一个业务模块中，功效相似，但在业务架构的视角和颗粒度上，不必定能清晰的表达出来，但梳理功能架构的时候，能够将此做为从相关业务模块的核心业务逻辑中剥离的非核心业务逻辑，做为基础功能模块放到功能架构的恰当位置。

OA 系统中，可能还存在一些功能模块，涉及到上传附件、预览或下载附件等功能，甚至在此以外还会有独立的“文档管理”模块，顺着上一段的思路，咱们可能都意识到了“文件存储管理”也能够独立出来做为基础功能模块来实现；而有相关开发经验的人还知道，文件有大有小，大文件存储、管理和消费的业务逻辑和零散小文件相似业务逻辑的实现及性能上可能会有很大差异，致使不一样的应用场景对应不一样的实现方案，如某些业务场景下，该模块是能够与系统其它模块集成在一块儿的，而另一些场景下，该模块需求独立出来，单独服务器部署，另外文件的存储、备份和恢复机制等，也都要考虑进去。这些都是使得看似简单的文件存储功能，在具体实现和实施上很是麻烦，而这些多是“业务架构分析”中难以免的盲点。

因此业务架构分析阶段，虽然可以作到把业务需求和逻辑完整的整理出来，但不必定能把构成每一个业务逻辑的单位功能一一提炼和组织起来，也可能会由于缺少功能开发和系统性能上的背景知识，忽视某些须要单独处理的功能或模块的特殊性，为系统的稳定性和可扩展性埋下隐患，因此，在业务架构分析以后，在开发以前，必定要作“功能架构分析”。

业务架构是面向用户的，功能架构是面向开发者的，功能架构和业务架构是一致的，且功能架构能够看作是业务架构的超集。

（2）确认和完善非功能需求

非功能需求方面的考虑，其实已经属于架构师在怎么作阶段的起步了，怎么作的主要成果是软件架构，而设计软件架构要考虑的两个维度是“业务架构”和“业务量级”。设计软件架构，一方面要保证软件系统的功能符合用户预期，另外一方面，也是更重要的是，软件系统要能被正常部署、使用、维护和监控，前者对应的是原始须要和业务架构的初级阶段，后面面向的是潜在的功能需求和非功能需求。

非功能需求，一般要考虑系统的存储能力、吞吐能力和容错能力等，最多见的就是咱们常说的“日活”或“并发”，这些性能指标会影响到咱们的软件架构，例如，上面提到的多人博客系统，可能大部分状况下可能只有几千到一两万的日活，这种状况下单体架构确定能撑得住，但若是这个多人博客系统是 Tumblr 或 Medium 话，就必须是分布式架构。确立非功能需求，一方面是为了保证咱们的软件架构可以支撑起咱们的业务量，另外一方面也是为了防止咱们对软件架构作过分设计，为系统开发带来没必要要的复杂度。另外，这也为系统的性能测试提供了依据。

综上，在软件项目中，若是要把需求分析作到位，止于功能架构分析才是保险的。

合理而且有效地运用项目管理软件，不只可让咱们工做井井有理地进行，还能最大程度保证项目目标的达成。我推荐使用CORNERSTONE，它提供了包括任务/需求/测试管理、迭代规划、缺陷追踪、报表统计、团队协做、WIKI、共享文件和日历等功能模块,如今申请20人如下团队便可无偿使用。