软件架构基本功：如何去分析业务需求

按：在软件架构的基本功中，需求分析与建模是第一关。但大部分人都不根本不懂...orz....还有小部分人懂、却不用....orz.....本文虽长、但却较系统的介绍了下需求分析相关知识，要耐下心来多琢磨的。这也是专业和业务选手的根本区别。本文来自简书昆仑怒道的分享。

 

1.1 需求分析建模的要点与误区

1.1.1 需求分析到底做什么

需求分析的任务不是分析系统如何实现用户的需要，而是对业务分析，形成一个体系完整，内容清晰的业务框架，以指导后续的设计开发工作。

需求分析就是先分解，再提炼，在这个过程中消除矛盾。

1.1.1.1 分解

现代需求工程理论更建议采用业务导向分解，而非传统的系统导向分解。

》业务流程为线索的分解结构

这种结构是以业务流程为主线索，对于联机事务处理系统，管理信息系统而言都是非常适用的方法。

》程序结构为线索的分解结构

这种分解结构过早的进入了程序结构，割裂了与问题域之间的联系，从医导致对问题研究不足的情况，从而降低需求质量，增加变更风险。这种结构适用于问题不复杂，系统与问题关联性不强的情况，例如工具软件，面向设备的系统等。

》基于场景的分解结构

对于决策支持系统，面向用户的嵌入式系统，就比较适合使用场景作为线索。这些场景向上可以总结成一系列关注点或功能域，向下可以分解成具体的决策步骤。

》基于数据的分解结构

 

》小结

选择了合适的分解结构之后，就可以按其线索把需求规格说明书大纲确定下来了，就知道应该捕获什么信息了，信息捕获回来之后就将其填充到大纲里，并不断验证。

1.1.1.2 提炼

分解是一种自顶向下的方法，按任何一种线索分解，都会破坏其他线索的完整性。所以还需要自底向上的方法进行提炼，抽取出共性的部分，建立针对全局的领域模型。

1.1.1.3 消除矛盾

1.1.2 建模的目标和要点

建模的过程比结果重要。

建模是需求分析的主要手段。但如果为了建模而建模，它就会变成一个问题，导致华而不实，造成沟通障碍。

1.1.2.1 建模的目的

建模的好处在于更好地理解正在开发的系统。建模的目的在于帮助我们按照需要的样式对系统进行可视化，提供一种详细说明系统的结构或行为的方法，给出一个指导系统构造的模板，对我们所做出的决策进行文档化。

1.1.2.3 建模的要点与原则

要点：设计要文档化；用可视化的模型表达架构；不要为了建模而建模，如果模型不能对系统的构建起到帮助作用，那么就是一种人力资源的浪费。

模型是用来沟通的，因此仅当需要的时候才构建模型。

1.1.3 选择建模工具的要点

1.1.3.1 正确认识建模方法论

建模的要点是根据要完成的任务，选择合适的建模工具。

 

1.1.3.2 正确认识UML

》UML的发展历史

》UML的准确理解

》为什么要用UML建模

》如何选择UML图

1.2 周期一：理清框架与脉络

任务：理清需求的结构框架(领域类图)，行为脉络(流程图和用例图)。

输入：需求定义阶段产生的业务时间列表和报表列表。

输出：领域模型和用例模型。

该任务对应于RUP中细化阶段的第一次迭代，该阶段的结束标志是标识除了绝大部分用例，生成了领域模型。

1.2.1 业务流程分析