软件工程(四)——需求建模

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/sinat_21107433/article/details/83118559

笔者正在学习《软件工程-实践者的研究方法》这本书,记录下一些读书笔记,共勉!

1.需求分析

在技术层面上,软件工程开始于一系列的建模工作,最终生成待开发软件的需求规格说明和设计表示,指明软件和其他系统元素的接口,规定软件必须满足的约束。需求建模动作产生以下一种或多种模型类型:

  • 场景模型:出自各种系统“参与者”观点的需求;
  • 数据模型:描述问题信息域的模型;
  • 面向类的模型:表示面向对象类(属性和操作)的模型,其方式为通过类的协作获得系统需求;
  • 面向流程的模型:表示系统的功能元素并且当功能元素在系统中运行时怎样进行数据变换的模型;
  • 行为模型:描述如何将软件行为看作是外部“事件”后续的模型。

1.1总体目标和原理

在整个需求建模过程中个,软件工程师主要的关注点在“做什么”,而不是“怎么做”方面,包括:在特定环境下发生哪些用户交互?系统处理什么对象?系统必须执行什么功能?系统展示什么行为?定义什么接口?有什么约束?

需求模型必须实现三个目标:①描述客户需要什么;②为软件设计奠定基础;③定义在软件完成后可以被确认的一组需求。需求模型在系统级描述软件设计之间建立了桥梁,系统描述给出了在软件、硬件、数据、人员和其他系统元素共同作用下的整个系统或商业功能,而软件设计给出了软件的应用程序结构、用户接口以及构件级的结构。

1.2分析的经验原则

创建需求模型时有以下的经验原则:

  • 模型应关注在问题域或者业务域内可见的需求,抽象的级别应该高一些,不要试图解释系统如何工作;
  • 需求模型的每个元素都能增加对软件需求的整体理解,并提供对信息域、功能和系统行为的深入理解;
  • 关于基础结构和其他非功能的模型应推延到设计阶段再考虑;
  • 最小化整个系统内的关联;
  • 确认需求模型为所有利益相关者都带来价值;
  • 尽可能保持模型简洁。

1.3域分析

域分析是识别、分析和详细说明某个特定应用领域的公共需求,特别是那些在该应用领域内被某个项目重复使用的需求。

猜你喜欢

转载自blog.csdn.net/sinat_21107433/article/details/83118559