需求建模是软件建模最为重要的工作。需求模型描述软件的外部特性，包括软件能够给用户提供的功能和性能，分析模型、设计模型和测试模型均建立在需求模型的基础上。需求模型包括用例模型和非功能模型两个方面的内容。

本章主要从软件需求、需求分析、软件需求建模、需求模型等概念进行阐述，同时简要阐述软件需求建模所需要遵循的一些原则。

软件需求（software requirement）是所要开发的软件系统为解决用户问题所具有的能力与特性。

软件需求可分为功能需求和非功能需求两个方面:

需求分析（requirement analysis）是为获得合理的软件需求所从事的调查、分析、建模、编写文档及审核等工作。

需求分析是开发软件的一项十分重要的工作，它是软件开发中软件分析、软件设计、编码和测试的基础，只有确定了正确、合理的软件需求，才有可能开发出成功的软件，错误或不完善的软件需求将导致软件开发工作的失败。

软件需求建模（modeling for software requirement）是软件需求分析的一项重要工作，软件需求建模又简称需求建模，是在需求调查的基础上，在需求分析过程中采用软件建模工具建立软件需求模型的过程。

需求模型（requirement model）是通过建模语言描述软件需求的模型。 在需求模型中，需要对需求结构、软件功能、软件性能等内容进行建模。需求建模建立在业务模型的基础上，它又是软件其他模型的基础，如下图，描述了需求模型与其他软件模型之间的关系。 需求模型包括用例模型、(功能模型)和非功能模型两部分。UML通过一组用例图来描述软件需求，功能模型用来描述软件的功能(用例和功能不一定能画等号，往往一个用例可能需要系统的多个功能来协作完成)。软件非功能需求一般表现为一组指标，非功能需求可以采用需求条目来表示。

为了分清楚用例和需求的关系，笔者还特意做了相关文献的查阅和分析，如下:

软件功能：功能是计算机术语，是用来描述计算机的，而非定义需求的术语。功能实际描述的是 输入->计算机->输出。一般用DFD图来表示，也是典型的面向过程分析模式。因此把用例当做功能点的分析员实际在做面向过程的分析。

用例：用例不是计算机术语，是针对参与者来描述的，是从参与者的角度来描述，主要描述参与者可以做什么。用例的几个特征:

业务流程：业务流程是要分析某项业务是如何一步一步完成的，有每个一步有哪些参与者，做什么业务动作，描述完成某个业务流程中多个业务动作的前后依赖关系。在UML中用活动图或序列图来描述。 用例的核心是以参与者为中心，从参与者的角度来描述他要做什么日常工作(区分以业务流程描述的方式)，并分析这些日常工作之间是如何交互的(区别于数据流的描述方式)换句话说， 用例要分析的首要目标不是要弄清楚某个业务是如何一步一步完成的，而是要弄清楚有多少参与者，每个参与者都做什么；业务流程分析则是后续的工作。其次，用例就是面向对象而生的，其思想完全符合OO。用例分析方法试图找到问题领域内所有相对独立的参与者和事件，并把业务流程当成这些参与者和事件之间的交互结果\

需求模型一定要真实的反映实际的软件需求。软件需求来自用户，需求模型的变更需要征求用户的意见，最后确定需求模型应通过用户确认。

需求模型一定要在具体的业务的基础上进行革新和抽象。需求模型不是现行业务的模拟和照搬，而是对现行业务的改造和创新，因此，需求模型必须抽象的反映软件需求。

需求模型应该简单、直观地反映软件需求，使用户和开发人员能够容易理解。在需求建模过程中尽量用直观、易懂和简单的形式描述需求模型。

（后续将根据软件设计的几个维度分别进行阐述,欢迎关注后续文章!）

如果你在这方面有不同方面的见解，也欢迎在下方进行留言，一起讨论

想要了解更多信息，可关注本公众号(一起学开源)；或请长按以下二维码添加助手。将拉你加入社区进行更多交流