软件需求分析的方法论

原创
2024/04/11 20:25
阅读数 105

软件需求分析的方法论:结构化分析方法、面向对象分析方法、面向问题域分析方法。

结构化分析方法:

结构化分析方法是一种传统的需求分析方法,它不需要在需求阶段精确地定义系统,而是根据业务框架确定系统的功能范围及每个功能的处理逻辑和业务规则。这种方法将需求分解为更小、更具体的部分,并采用图表、示例图、文字等方式来描述系统的功能和数据流动。在开发新系统时,结构化分析可以帮助确定主要功能模块,并为每个模块定义具体的业务规则和处理流程。

因为不需要精确描述,因此描述系统的方式比较灵活多样,可以采用图表、示例图、文字等等方式来描述系统。在系统开发以前,一般还可以采用更为直观的原型系统方式和最终用户进行交流和确认,因此对业务需求的要求会低一些,业务需求阶段的周期相对容易控制;通过业务全景图,最终用户也能了解系统的功能;通过功能活动图和业务规则的描述,也可以相对精确地描述业务系统;因为没有严格的标记语言,可以采用适当的篇幅描述适当的系统。当然,这种方法的缺点也是明显的,分析人员和业务人员之间可能缺乏共同语言,机器不能识别业务需求书,在设计阶段还需要继续和用户确认一部分功能。

面向对象分析方法(OOA):

面向对象分析方法是一种基于对象的分析方法,它将现实世界的事物抽象为对象,并通过类和对象来组织软件系统的结构和行为。在面向对象分析中,分析师会识别系统中的对象、类以及它们之间的关系,定义类的属性和方法,并考虑对象之间的协作关系。这种方法有助于建立与问题域紧密相关的模型,提高软件的可维护性和可扩展性。

最大好处是在需求阶段,就能够非常精确地描述一个系统,采用程序语言的方式和最终用户交流(最终用户必须要熟悉这种语言),能够在项目一开始就发现很多问题,避免在开发的过程中出现需求的反复,而且在系统设计和开发阶段不需要最终用户参与。但是,我们也要看到,在现实中,绝大多数的应用系统都很难在需求阶段就可以被精确地抽象化定义,所以这种方法的缺点和困难也是显而易见的:首先,用户要非常清楚地知道最终的业务系统应该是什么样,或者采用一种抽象的方式能够确定最终的应用系统;其次,因为最终用户不需要参与设计和开发阶段的工作,所以双方确定业务需求的过程也会比较长;同时,因为是精确描述,因此描述系统的语言是非常逻辑化的,一般通过某种方式可以使机器识别业务需求,采用这种方式写的业务需求是非常格式化的,一方面描述一个系统需要的信息非常多,可能使需求说明的篇幅非常长,不便于理解和阅读;另外由于通过抽象的方式来推演最终系统的运行方式,对业务人员的要求非常高。

面向领域分析方法:

面向领域的分析方法是一种强调对问题域进行深入理解和建模的方法。它通过使用自然语言、流程图、数据流图、状态图等工具对问题域进行描述和可视化,从而捕获问题的背景、目标、约束等关键信息。这种方法还强调对问题域中的对象、属性、服务及它们之间的协作关系进行明确和清晰的定义。通过面向问题域的分析,开发团队可以更好地理解用户需求,为后续的设计和开发提供有力支持。

DDD(领域驱动设计)可以被视为面向领域分析方法的一种具体实践。领域驱动设计强调将业务领域划分成为多个子领域,并在每个子领域中针对领域对象进行分析、设计和开发。这种方法论的核心在于将业务模型翻译成系统架构设计,根据业务语义抽象梳理设计成领域模型,而不是通过数据库等数据源驱动设计。因此,DDD确实体现了面向领域的分析方法,它通过领域模型来指导软件系统的设计和开发,使得软件能够更好地满足业务需求。

具体来说,DDD在战略设计中建立领域模型,这个领域模型用于指导微服务的设计和拆分。事件风暴是建立领域模型的主要方法,通过用例分析、场景分析和用户旅程分析,全面不遗漏地分解业务领域,并梳理领域对象之间的关系。这种分析过程与面向领域的分析方法紧密相关,都是对特定领域进行深入分析,理解并抽象出业务模型,进而指导软件系统的设计和开发。

因此,DDD不仅体现了面向领域的分析方法,还通过其独特的设计理念和实践方法,使得面向领域的分析更加具体和可操作。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
0 收藏
0
分享
返回顶部
顶部