浅谈软件需求分析

浅谈软件需求分析

一、什么是需求分析?

通俗的讲,对用户的意图不断揭示和验叛的过程,要对经过系统可行性分析所确定的系统目标做更为详细的描述。

假如你是个建筑工程师,有个客户找你建一个鸡窝,这个时候要需要与客户沟通,来确定客户到底想要一个什么样子的鸡窝。我们应该注意三点:

1、准确的理解和描述客户需要的功能。

客户说,我的鸡窝要三层的,带电梯,饮水池,厕所,饮水池要自动判断水位供水,电梯要可以同时乘坐10只鸡….客户滔滔不绝的讲了一大堆,你也都非常忠实的按照自己的理解再一一的向客户描述一遍,以便于确认客户的需求是否正确。

2、帮助客户挖掘需求。

等客户把自己的需求说完了,你发现客户没有说鸡的卧室,于是,你向客户提议说:“你看,这鸡的卧室要什么样子的?”,客户连连的拍着脑门说,我差点给忘记了,鸡们啊喜欢晚上在一起聊天,所以呢,需要一个长而大的卧室,但一定要舒适。

3、分析客户需求的可行性。

客户临走时又说,最近啊,黄鼠狼很多,我这个鸡窝啊,一楼就不用盖了,直接盖二楼和三楼吧!以免晚上遭遇黄鼠狼的攻击。你这么一分析,客户这要求,按照目前的技术可没法建啊,于是,你向客户提议,一楼采用坚固架子来支撑二三楼的建筑。

二、需求分析困难在哪儿?

有几种原因使需求分析变得困难:

(1)客户说不清楚需求;

有些客户对需求只有朦胧的感觉,当然说不清楚具体的需求。

有些客户心里非常清楚想要什么,但却说不明白。

如果客户本身就懂软件开发,能把需求说得清清楚楚,这样的需求分析将会非常轻松、愉快。如果客户全不懂软件,但信任软件开发方,这事也好办。分析人员可以引导客户,先阐述常规的需求,再由客户否定不需要的,最终确定客户真正的需求。最怕的就是“不懂装懂”或者“半懂充内行”的客户,他们会提出不切实际的需求。

(2)需求自身经常变动;

尽可能地分析清楚哪些是稳定的需求,哪些是易变的需求。以便在进行系统设计时,将软件的核心建筑在稳定的需求上。

在合同中或需求书中一定要确定清楚“做什么”和“不做什么”。

(3)分析人员或客户理解有误。

需求分析人员不可能都是全才。客户表达的需求,不同的分析人员可能有不同的理解。如果理解错了,可能会导致开发浪费时间和精力。所以分析人员写好需求说明书后,最好要请客户方的验证。有条件的设计原型来论证需求。

三、需求分析的分类:

需求分析一般可分为功能需求、非功能需求和领域需求

1、功能需求

功能需求主要说明了系统实际应做到什么。这是用户最直观也是最主要的需求,如系统的输入输出、系统能完成的功能以及其它相关处理等;

2、非功能需求

非功能需求又称“约束”,它主要从各个角度对系统起约束和限制作用。如响应时间、存储效率、报表的规格和界面的样式等

3、领域需求

领域需求的来源不是用户,而是系统应用的领域,其主要反映了该领域的基本问题。

四、如何进行需求分析?

进行需求分析不象情人之间的浪漫做法——“让我摸摸你的头发,感觉它是什么颜色。”我们需要了解需求分析的渠道和过程。

需求分析的过程:

(1)可行性研究

它指明现有的软件、硬件技术能否实现用户对系统的要求,从业务角度来决定系统开发是否可行以及在预算范围内能否开发出来。可行性研究的结果是清楚的回答:该系统是否值得开发?

(2)需求导出和分析

这是一个通过对现有系统分析、与潜在客户讨论、进行任务分析等导出系统需求的过程,也可能需要开发一个或多个不同的系统原型,以帮助分析员了解所要描述的系统。

(3)需求描述

需求描述就是把在分析活动中收集的信息通过分析整理之后以文档的形式确定下来。该文档中有两类需求:用户需求是从客户和最终用户角度对系统需求的抽象描述;系统需求是对系统要提供的功能的详尽描述。

(4)需求有效性验证

主要是通过评审、验证等一系列活动来找出需求文档中的错漏并加以改正。

(5)需求管理

需求管理需求管理是一种系统化方法,可用于获取、组织和记录系统需求并使用户和开发方在系统变更需求上始终保持一致。

五、需求分析的方法

1、功能分析方法

功能分析法功能分解法以系统提供的功能为中心来组织系统。首先定义各种功能, 然后把功能分解为子功能, 同时定义功能之间的接口。数据结构是根据功能/子功能的需要设计的。 其基本策略是以分析员的经验为依据, 确定新系统所期望的处理步骤或子步骤, 然后, 将问题空间映射到功能和子功能上。

2、数据流方法

数据流法也叫结构化分析, 其基本策略是研究问题域中数据如何流动以及在各个环节上进行何种处理, 从而发现数据流和加工。 问题域被映射为由数据流、加工以及文件、端点等成份构成的数据流图(DFD) , 并用数据字典对数据流和加工进行详细说明。这种方法的关键是动态跟踪数据流动。

3、信息建模方法

信息建模法的核心概念是实体和关系, 主要工具是语义数据模型(实体关系图) , 其基本策略是找出现实世界的对象, 然后用属性来描述对象, 增添对象与对象之间的关系, 定义父类与子类, 用父类型/子类型提炼属性的共性, 用关联对象关系作细化的描述, 最后进行规范化处理。 其实质是将问题空间直接映射成模型中的对象。

原文地址:https://www.cnblogs.com/show2008/p/8335844.html

时间: 2024-08-26 04:05:26

浅谈软件需求分析的相关文章

浅谈软件项目的需求管理

软件项目区别于其它项目的最显著的特征是其不可见性,它不像硬件购销.建筑工程,都是实实在在可见的东西.而软件项目在系统交付之前很长一段时间,客户是无法感知自己想要的系统究竟是什么样子.因此,需求管理就显得十分重要,据相关统计数据分析,软件项目90%以上失败的原因都在于没有重视需求或者需求管理方面做的不到位导致的. 需求管理作为软件项目管理的一个重要内容,贯穿项目实施的全生命周期.俗话说:万事开头难.需求作为软件开发的第一个环节,其重要性不言而喻.市面上关于需求管理的相关理论和书籍很多,但多数停留在

浅谈软件性能测试中关键指标的监控与分析

浅谈软件性能测试中关键指标的监控与分析 一.软件性能测试需要监控哪些关键指标? 软件性能测试的目的主要有以下三点: Ø  评价系统当前性能,判断系统是否满足预期的性能需求. Ø  寻找软件系统可能存在的性能问题,定位性能瓶颈并解决问题. Ø  判定软件系统的性能表现,预见系统负载压力承受力,在应用部署之前,评估系统性能. 而对于用户来说,则最关注的是当前系统: Ø  是否满足上线性能要求? Ø  系统极限承载如何? Ø  系统稳定性如何? 因此,针对以上性能测试的目的以及用户的关注点,要达到以上

浅谈软件工程师的代码素养

WeTest 导读 写这篇文章时内心是比较忐忑的,因为文章的话题范围非常大,怕自己驾驭不了.在实际工作中,维护过很多类型的代码,其中不乏高级工程师完成的逻辑,大家的需求能力都很不错,能够快速满足产品的需要,但很少能有人能注意到代码的整洁度,甚至很多代码经过多人维护后已经变得无法再进行任何一处的修改,最后不得不花大量的时间进行重构.因此我决定还是写一篇文章来"浅谈"软件工程师应具备的代码素养,希望能够对大家有所帮助,水平所限,如有不当之处还请不吝指正~ "程序是写给人读的,只是

浅谈软件开发者应具备的基本素质

我们常常能在一些电子产品的发布会上听到新产品修复了某些BUG.开发出了某些先进的功能: 我们常常会听到某些黑客攻击某些网站的消息,也可能受过某些电脑病毒的侵害: 我们也常常能在一些科幻大片里见到程序员在紧急关头敲打代码拯救世界. 每天,我们都在使用着电子产品,使用着软件程序开发者的成果.但是,对于普通人,软件开发又高深.难以涉猎.而作为软件开发者,又应该怎么样对待软件开发,应当具备哪些素质?我正在学习软件开发,下面从个人的角度,浅谈自己的看法. 开发软件的基本前提是站在他人的角度考虑问题:软件开

浅谈软件销售工作

自技术领域转做销售有几年了.由于长期耕耘在技术领域,对于销售的角色进入有点晚,只是近期几年也逐渐的摸出些门道,而且按照这些门道来指导团队的实践,确实可以看到比較可喜的进步,在此总结一下.跟大家一起分享一下. 销售分为例如以下三种类型:1. 技术型销售.典型特征是逢人必谈技术,对于技术的内因外果非常清楚,当跟客户沟通时特别在技术沟通时,能说会道,涛涛不绝.但一到关系项目譬如玩.喝酒.K歌等表现平平.2. 关系型销售.典型特征是碰到人必称"哥"."老师"."领

康华:浅谈软件可维护性问题

前言 很多包括自己在内的开发人员都会经常去借用(我们不用剽窃这个词了!呵呵)开源代码进行二次开发:或者在前辈的遗留代码下,继续修修补补.这种经历往往并不像看起来那么简单--有时看懂,进而修改别人的少许代码,都会觉得老虎天--无从下手,究其原因主要是代码晦涩,关系复杂,难以隔离影响等. 而这时我们或者抱怨前人代码写的愚蠢,垃圾:或者又会自惭自己编码水平太次.其实这种困境的起源除了自己笨以外,更多是因为代码的可维护性不够. 由于前不久和朋友齐永升注释<代码质量>一书时曾关注过代码的可维护性,而近期

浅谈软件配置管理工具(github &amp; SVN)

1   配置管理名词定义 1.1 配置项 软件生存周期各个阶段活动的产物经审批后即可称之为软件配置项. 软件配置项包括: ①与合同.过程.计划和产品有关的文档和资料: ②源代码.目标代码和可执行代码: ③相关产品,包括软件工具.库内的可重用软件.外购软件及顾客提供的软件等. 1.2 配置项标识 配置标识是定义各类配置项.建立各种基线.描述相关软件配置及其文档的过程. 配置标识是指为了方便对软件配置的各个片段进行管理,必须对每一个配置项进行标识.其原则为: (1)用易于理解和推测的方式定义文件的标

浅谈软件项目开发过程中的主要项目风险及对策

软件项目成果的需求分析方和软件项目的承担者都十分关心这样的一个问题:什么样的因素会导致软件项目的失败?与项目有关的因素的改变将对按时.按经费预算交付符合预定质量要求的软件成果产生什么样的影响?这些都属于软件项目开发过程中考虑的风险问题. 软件项目的风险是指在软件开发过程中可能出现的不确定因而造成损失或者影响,如资金短缺.项目进度延误.人员变更以及预算和进度等方面的问题.风险关注未来的事情,这意味着,软件风险涉及选择及选择本身包含的不确定性,软件开发过程及软件产品都要面临各种决策的选择.风险是介于

浅谈软件行业中的重复性工作

我本人是软件专业出身,对于软件行业中的重复性工作也是见怪不怪了.然而对于这种重复对于软件行业的发展是一种极大的阻碍,以网上关于软件开发的技术性帖子为例,重复,雷同,抄袭,到处都是.在网上搜索一个关于“android....”的问题,就会出现一大批关于此问题的条目,看似很好解答很多,但点开一看就蒙了,各个论坛,各个用户写的有关“android...”的帖子都相似,甚至完全相同.这是为什么,我想不用明说. 上面所说的就是软件行业中的重复问题,网络资源看似满满的都是宝,打开就发现全都一样,满盆宝剩下一