搜索
架构设计之功能树一、获取功能树获取需求有三种途径：1、拿到文档；2、进行沟通；3、分析产品。具体来讲：1、《软件需求规格说明书（SRS）》。a)《SRS》应该系统化地描述各种功能，是功能树最可能出现的地方。b)《SRS》里如果没有“显式地”把功能树画出来，你留意一下它的目录——目录的“章-节-小节”结构经常直观体现了功能树。c)如果你希望尽早开始架构设计（《SRS》提交之前），你可以关注更上游的文档，或者借助沟通，或者分析竞争对手的产品。2、更上游文档a)《愿景文档》分析机会、陈述价值、刻画功能体系……功能树正堪其用。b)《方案建议书》梳理需求背景，明确设计原则，刻画系统方案，对比方案优势等等，说明系统功能时可能使用功能树。3、沟通+自画a)和业务人员、需求分析人员沟通，获得信息，自己梳理功能树。4、分析产品a)如果你要设计的是产品的4.0版本，何不研究3.0的产品、文档、市场彩页等，获取信息。b)当然，也不要忽视竞争对手公司的产品资料。甚至可以运行它，从它的UI界面中你可以获得很多帮助，自己梳理功能树。功能树除了“树状结构”之外，还可能是“列表结构”、“表格结构”或者“功能框图结构”等。二、评审功能树功能树与非功能树对比图-1非功能树图-2功能树判断功能树是否合理，不满足要求的功能树则应进行改进1、面向使用，体现使用价值；2、覆盖全面，没有范围遗漏。三、粗粒度“功能模块”划分如前两步所述，架构师知道如何与需求人员打交道、如何评价拿到的需求，是架构师岗位本身应有的技能，也是架构师作为“通才”的一个例证。如图-3所示：图-3一方面，业务上紧密相关的一组功能在实现上也常会涉及相同的函数、类、数据结构等，因此我们应该将“这组功能”映射到一个“功能模块”，这样有利于设计的高聚合、松耦合，还有利于程序小组之间的分工。另一方面，一些公共服务（例如报错处理、Log日志、安全验证）会用于同时支持多组功能的实现，它们不单独属于任何“功能模块”，应当进行独立的模块化——将这些公共服务分别放入相应的“通用模块”或“通用机制”中。