软件工程模型与方法 04、软件需求分析

《软件工程模型与方法 04、软件需求分析》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、软件工程模型与方法Models&MethodsofSE第四章软件需求分析肖丁引言为何要进行软件的需求分析？软件的需求分析处于软件生命周期的那个阶段？起到什么作用？怎样才能做好软件需求分析？软件需求分析的过程和步骤是什么？软件需求分析的最终结果是什么？4.1需求的定义需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。Boehm给出软件需求的定义：研究一种无二义性的表达工具，它能为用户和软件人员双方都接受，并能够把“需求”严格地、形式地表达出来。“需求、设计、编程、测试四者究竟哪个环节最重要？”首先，每个环节都是很重要，任何一个环

2、节出现问题，都会导致软件的质量问题。但是，从管理的角度来看，需求是软件产品的起源，因而是最重要的一个环节4.2一个需求分析的案例某大型的电信设备供应商，案例中涉及6个部门A,B,C,D,E和F，它们之间的关系如下图所示：F客户E：网管软件承包商D销售机构A：增值业务研发机构C：项目管理机构B：核心平台研发机构一年前，B研制了一种数据接入服务器的原型。B对A讲：“我们的接入服务器前途很好，请你们帮助开发网管软件（属于增值业务范畴），大家合作把产品做好，一起发财。”D对B和A讲：“你们把接入服务器和网管软件做好，我们负责卖，挣了钱大家一起分。”4.2一个需求分析的案例A觉得机会难得，于是向C申请

3、立项。立项后，A把项目外包给专业做网管软件的公司E，期望半年内完成。由于接入服务器是B的，于是A和E就派开发人员到B处搞需求分析。B的接入服务器并不成熟，老在变，三方折腾了好久，最终E用了一年时间把接入服务器的网管软件做出来了。E把网管软件交付给A，A付清了E的开发费用，再把网管软件交付给D，D再卖给客户F（某地电信局）。F对D讲：“你们的网管软件不是我们想要的东西，等你们把软件改好后我们再付钱。”D赶紧对A讲：“兄弟阿，货已经出手了，但是不对路，请赶紧把它改好，不然大家都没钱赚。”A很愤怒，怨天不公：“我们辛苦了一年，又花了很多钱，可是产品做完了却没人要，岂有此理！”4.2一个需求分析的案

4、例祸不单行的是，C来找A的麻烦：“你们的项目延期半年多了，经费也用光了，请尽快结束项目。”A的那位项目经理为此每天愁眉苦脸，他的上司请来几位参谋商量对策，设法把事情搞定。大家挖空心思只想出一个馊主意：既然套子是B下的，那么就把套子还给B。要设法把“那么好”的网管产品转让给B，只要B能给我们成本费，以后就跟B拜拜。这个案例的问题根源在于进行软件开发之前没有搞清楚网管软件的需求，这都是B,A,E闭门造车惹的祸。最可悲的是，相关责任人关心的是如何把事情“完成”，而不是深刻了解用户的具体需求。这种类似的事情在软件开发行业中经常发生而且还会继续发生，最主要的是每发生一次就损失大量的人力和物力。4.3需

5、求分析的必要性需求分析是一项必须的软件工程活动。它在系统需求分析和软件设计之间起到桥梁的作用：它使得软件开发人员在系统分析的基础上深入描述软件的功能和性能、指明软件和其他系统元素的接口，建立软件必须满足的约束条件。它允许软件开发人员对关键问题进行细化，并构建相应的分析模型：数据、功能和行为模型。分析模型成为设计模型的基础，需求规格说明书也为软件测试人员和用户提供了软件质量评估的依据。它能准确表达用户对系统的各项要求。4.4需求分析的对象、任务和目标软件需求分析的对象是用户要求。其任务是要准确地定义新系统的目标。回答系统必须“做什么”的问题并编制需求规格说明书。作为目标系统的参考，需求分析的任

6、务就是借助于（业务）系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。4.5需求分析建模的原则需求分析方法的一组操作性原则是：问题的信息域必须被表示和理解。软件将完成的功能必须被定义。软件的行为（作为外部事件的结果）必须被表示。描述信息、功能和行为的模型必须被划分，使得可以用层次的方式揭示细节。分析过程应该遵从自顶向下，逐层细化的原则。一组三元模型：第1条原则表示需要建立数据模型，第2条和第3条原则表示需要建立功能和行为模型。4.6需求工程的指导性原则首先要正确地理解问题，再建立分析模型。记录每个需求的起源及原因，保证需求的可回溯性。开发一个能使用户能够了解人机交互过程的

7、原型。因为对软件质量的感觉经常基于对界面“友好性”的感觉。使用多个需求视图。建立数据模型、功能模型和行为模型，为软件工程师提供三种不同的视图，增加识别不一致性的基础。给需求赋予优先级。紧张的开发时间要求尽量避免一次性实现每个软件需求，应采用迭代增量的开发模型。努力删除歧义性。因为大多数需求以自然语言描述，存在歧义性的可能性，正式的技术评审是发现并删除歧义性的一种有效方法。4.6.1数据建模需求分析的第1条操作