1
需求工程是指应用已证实有效的技术、方法进行需求分析,确定客户需求,帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。
2
它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束,形成需求文档,并对用户不断变化的需求演进给予支持。
大数据技术在数据采集方面采用了哪些方法:
1、离线采集:
工具:ETL;
在数据仓库的语境下,ETL基本上就是数据采集的代表,包括数据的提取(Extract)、转换(Transform)和加载(Load)。在转换的过程中,需要针对具体的业务场景对数据进行治理,例如进行非法数据监测与过滤、格式转换与数据规范化、数据替换、保证数据完整性等。
2、实时采集:
工具:Flume/Kafka;
实时采集主要用在考虑流处理的业务场景,比如,用于记录数据源的执行的各种 *** 作活动,比如网络监控的流量管理、金融应用的股票记账和 web 服务器记录的用户访问行为。在流处理场景,数据采集会成为Kafka的消费者,就像一个水坝一般将上游源源不断的数据拦截住,然后根据业务场景做对应的处理(例如去重、去噪、中间计算等),之后再写入到对应的数据存储中。这个过程类似传统的ETL,但它是流式的处理方式,而非定时的批处理Job,些工具均采用分布式架构,能满足每秒数百MB的日志数据采集和传输需求
3、互联网采集:
工具:Crawler, DPI等;
Scribe是Facebook开发的数据(日志)收集系统。又被称为网页蜘蛛,网络机器人,是一种按照一定的规则,自动地抓取万维网信息的程序或者脚本,它支持、音频、视频等文件或附件的采集。
除了网络中包含的内容之外,对于网络流量的采集可以使用DPI或DFI等带宽管理技术进行处理。
4、其他数据采集方法
对于企业生产经营数据上的客户数据,财务数据等保密性要求较高的数据,可以通过与数据技术服务商合作,使用特定系统接口等相关方式采集数据。比如八度云计算的数企BDSaaS,无论是数据采集技术、BI数据分析,还是数据的安全性和保密性,都做得很好。
数据的采集是挖掘数据价值的第一步,当数据量越来越大时,可提取出来的有用数据必然也就更多。只要善用数据化处理平台,便能够保证数据分析结果的有效性,助力企业实现数据驱动~
1 客户访谈
客户访谈是最早开始使用的获取用户需求的技术,也是至今仍然广泛使用的一种需求分析技术。客户访谈是一个直接与客户交流的过程,既可以了解高层用户对软件的要求,也可以听取直接用户的呼声。访谈可分为正式的和非正式的两种基本形式。正式访谈时,系统分析员将提出一些用户可以自由回答的开发性问题,以鼓励被访问的人能说出自己的想法,如可以询问用户对目前正在使用系统有哪些不满意的地方,为什么等问题。另外对一些需要调查大量人员的意见的时候,可以采用向被调查人发调查表的方法进行,然后对收回的调查表仔细阅读,之后系统分析员可以针对性地访问一些用户,以便向他们了解在分析调查表中所发现的问题。
不同的系统,访谈对象很重要,做BI系统访谈普通员工一点用也没有;同样做MES系统,访谈行政副总也没啥用。其次双方之间定一个框架(可以用合同约定的)去谈,千万别毫无目的的去谈,谈着谈着把需求扯远了。吹牛一时爽,事后火葬场。
2 建立联合分析小组
系统在开始的时候,往往是系统分析员不熟悉用户领域内的专业知识,而用户也不熟悉计算机知识,这样就造成它们之间的交流存在着巨大的文化差异,因而需要建立一个由用户系统分析员和领域专家参加的联合分析小组,由领域专家来沟通。这对系统分析员与用户逐渐的交流和需求的获取将非常有用。另外特别要重视用户业务人员的作用。
到了成立联合分析小组,这样的系统一般就是专业程度比较高的了,一般领域专家时间都很紧,不喜欢唠叨,专业术语太强,所以调研选老手,尽可能做过类似项目的,不至于交流太困难,说个名词都听不懂,造成抵触情绪。涉及到算法的公式一定要整理保存好,最好经过专家确认,事后整理麻烦太多了。可以以身试法
3 问题分析与确认
不要期望用户在一两次交谈中就会对目标系统的需求阐述清楚,也不能限制用户在回答问题过程中的自由发挥。在每次访问之后,要及时进行整理、分析用户提供的信息,去掉错误的、无关的部分,整理有用的内容,以便在下一次与用户见面时由用户确认,同时准备下一次访问用户时更进一步的细节问题。如此循环大概需求3~5个来回。
传统的常规的需求获取方法定义需求时用户过于被动地而且往往与开发者区分“彼此”。由于不能像同一个团队的人那样齐心协力地识别和细化需求,所以这种方法有时效果不太理想。为了解决这个问题,人们研究出一种面向团队的需求获得方法,称为简易的应用规格说明技术。这种方法提倡用户与开发者密切合作,共同标识问题,提出解决方案要素,商讨不同方案并制定基本需求。这种方法有许多优点,开发者与用户不分彼此,齐心协力,密切配合,共同完成需求获取工作。感兴趣的读者可以查阅相关资料。
与客户确认需求,一定要采用“确认-分析”反复确认的模式。起码进行3-5回,因为有可能同一需求碰到的不是同一负责人;最好能留下双方确认过的纸质/电子文档,电子文档保留版本号,千万别搞乱了!上文提到的简易的应用规格说明技术,就是以双方讨论后达成共识的软件需求为基准,对软件的功能、性能、接口、约束条件等逐一讨论,最后双方确认下来。
以上就是关于说一说需求工程中需求获取的方法有哪些全部的内容,包括:说一说需求工程中需求获取的方法有哪些、需求获取技术有哪些方法、参与了哪些工作,使用了哪些软件需求获取方法等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)