我对需求分析与建模的认识与应有内容建议

本文探讨了软件需求分析的重要性和挑战,详细介绍了需求工程的各个阶段,包括可行性研究、需求导出与分析、需求描述和验证。强调了需求过程中的非技术性和社会性因素,并探讨了软件系统需求的分类。此外,文章还讨论了需求建模技术,如数据流图、实体关系图和用例模型,以及在需求获取过程中与用户的协作。最后,以船员工资系统为例,展示了需求分析的实际应用和建模过程中的心得体会。
摘要由CSDN通过智能技术生成
                      我对需求分析与建模的认识与应有内容建议
     需求分析作为软件工程开发的开始,为了能更好的开发一个软件,我们需要努力掌握需求分析与建模这门课程。
     软件需求位于软件工程的起始阶段,是软件系统开发中一个重要的独立工作阶段,为软件工程后续阶段提供了工作基础,对软件项目的成败至关重要。20世纪末,随着软件系统规模的扩大和复杂程度的增长,以需求分析为重心的传统需求处理技术已经不能适应现代软件技术发展的要求,完整的需求工程过程应运而生。需求工程是开发者在进一步深入理解软件项目需求处理活动之后提出的一个阶段性活动。同传统的需求分析相比,在需求工程中,软件需求处理不仅仅停留在单纯的分析与建模,需求的获取、建模、文档化、验证及管理等都是其中必需和重要的工作。
  到目前为止,学术界与产业界在需求工程领域取得了较大的进展,研发了一系列有效的需求技术、方法和工具,构成了一个完整的需求工程过程框架。但是,尚有大量理论、方法和技术有待于广泛传播和全面应用,特别是需要进行系统化的实践。 

1.什么是软件需求呢
目前,世界上几乎所有的国家都在使用复杂的计算机系统,越来越多的产品把计算机和控制软件以一定的方式结合起来,软件工程作为一门工程学科,他的目标在于使软件系统往更好的更高性价比的方向发展。
所有的软件工程都具有以下的基本活动:
(1)软件描述:软件的功能以及软件操作上的约束必须定义;(2)软件设计与软件实现:软件一定要按照描述来生产;(3)软件有效性验证:软件要被确定是有效的,能做客户想要做的事情才可以;( 4)软件进化:软件一定要按照客户的变化与跟进来进化。
其中,软件描述,目标是确定软件系统需要哪些服务以及开发和运行期间受到哪些约束。对服务和约束的发现、分析、建立文档、验证活动现在常称为需求工程。
需求工程对于软件过程是一个特别关键的阶段,这个阶段的错误将不可避免地带到后续的系统设计和实现阶段中。需求工程阶段的独特之处在于很少有现成模式或特制的文档可供参考。后续阶段可以建立在前期所做工作基础上(各种相关模型至少在一定程度上可以衍生导出),而需求工程阶段的成果却是靠创建而来的———几乎就是从无到有。
2.需求的过程
需求工程本身就是一个过程,这个过程产生用以描述系统的需求文档。通常需求在这个文档中被分成两个层次描述:最终用户和客户需要高层次的需求描述;而系统开发人员需要比较详细的系统描述。
需求过程的四个主要阶段:
1.可行性研究 指明现有的软件、硬件技术能否实现用户对新系统的要求。从业务角度来决定系统开发是否划算以及在预算范围内能否开发出来。可行性研究是比较便宜和省时的。结果就是要得出结论,该系统是否值得进行更细致的分析。
2.需求的导出和分析 这是一个通过对现有系统分析、与潜在用户和购买者讨论、进行任务分析等导出系统需求的过程。也可能需要开发一个或多个不同的系统模型和原型。这些都会帮助分析员了解所要描述的系统。
3.需求描述 需求描述就是把在分析活动中收集的信息以文档的形式确定下来。在这个文档中有两类需求。用户需求是从客户和最终用户对系统需求的抽象描述;系统需求是对系统要提供的功能的详尽描述。
4.需求有效性验证 这个活动检查需求实现、一致和完备。在这个过程中,不难发现需求文档中的错误,然后必须加以改正。
当然,需求过程中的各项活动并不是严格按顺序进行的。在定义和描述期间,需求分析继续进行,这样在整个需求工程过程中不断有新的需求出现。因此,分析、定义和描述是交替进行的。

3.软件系统需求
软件系统需求常常分为功能需求、非功能需求和领域需求三个方面:
功能需求 , 包括对系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为的描述。在某些情况下,功能需求可能还需要明确申明系统不应该做什么。
理论上,系统的功能需求描述应该既全面又具有一致性。全面意味着用户所需的所有服务都应该给出描述。一致性意味着需求描述不能前后矛盾。在实际过程中,对大型而又复杂的系统而言,要做到需求描述既全面又一致几乎是不可能的。一方面是因为系统固有的复杂性,另一方面是因为观点不同,需求也会发生矛盾。
非功能需求 , 对系统提供的服务或功能给出的约束。包括时间约束、开发过程约束、标准等。非功能需求愿于用户的限制,包括预算上的约束、机构政策、与其他软硬件系统间的相互操作,还包括如安全规章、隐私权利保护等外部因素。
领域需求 , 这是来自系统的应用程序领域的需求,反映了该领域的特点。他们也可能是功能需求或非功能需求。
软件需求文档
软件需求文档有时叫做软件需求描述(SRS)是对系统开发者要求的正式陈述。IEEE标准为需求文档提出了以下结构:引言(目的、范围、缩略词等),一般描述(产品透视、功能、用户特征、约束等),专门需求(功能、非功能、接口),附录,索引。
4.需求问题具体原因分析
软件生产中产生需求问题的最大原因在于对应用型软件的模拟特性理解不透彻或应用不坚决,它会导致软件开发者产生轻视需求的态度问题。除此之外,还有一些技术原因也会导致需求问题的产生。
1.非技术性和社会性因素重视不足
应用型软件的模拟特性使得需求处理具有很突出的特性。相对于软件开发的其他阶段而
言,需求处理阶段涉及更多的非技术性和社会性因素,并且其所受的影响也远远高于其他阶段。
20世纪90年代之前的需求处理往往更专注于技术处理,而对其中的非技术性和社会性因素重视不足。
需求建模与分析是需求处理中的核心活动,它用一些形式化或半形式化的语言进行知识
的描述。一方面,只有通过建模与分析才能将混乱、模糊的用户需求变成清晰、明确的软件需求,所以它是获取需求处理活动的必然后继,

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值