系统分析师论文范文-论系统设计中对用户需求的把握2

2022-08-11 21:53:08   第一文档网     [ 字体: ] [ 阅读: ] [ 文档下载 ]

#第一文档网# 导语】以下是®第一文档网的小编为您整理的《系统分析师论文范文-论系统设计中对用户需求的把握2》,欢迎阅读!
系统,分析师,范文,把握,需求
论系统设计中对用户需求的把握

【摘要】

2010年我所在的公司承揽了西北某电厂的基于电气逻辑控制的厂用电系统(ECS。这种系统和以往传统ECS系统的区别是强调了电气控制,而不是单纯的监测。对我公司来说,这是一个全新内容,公司对此非常重视,抽调了精干人马参与系统前期的调研和设计作为公司的骨干力量,在此项目中,我负责系统的需求分析。结合以往的项目经验,我采用了查资料调查问卷、用户访谈等手段迅速取得了前期的基本需求;而对于逻辑控制这一最核心的问题,我采用了原型法,通过快速原型,经过几次迭代过程后,明确了逻辑控制的核心需求。由于措施得当、方法对路,圆满完成了需求分析这一关键任务,为后续的系统设计下了良好的基础。该系统于2011年顺利投产,受到用户好评。文中详细讨论了需求分析过程中,多种方法的组合应用发挥每一种方法的优点,特别强调了要根据项目的具体情况灵活运用的必要性,同时,也提到了激发用户思考,调动用户热情的重要意义。最后,也指出工作中的不足。 【正文】

我所在的公司是国内一家长期从事电力系统研发的知名企业,长期从事厂用电电气自动化(ECS)等业务的研发。ECS系统的主要功能是完成厂用电设备的实时采集和监控,监测变压器、线路的电流、电压、功率,开关的分合及现场综合保护装置的保护信号。此外,还包括现场智能装置实现的直流、快切、励磁等就地功能,以及向第三方进行实时数据的接入和转出。 2010年,我公司承揽了西北某电厂的基于电气逻辑控制的厂用电系统。该系统和传统ECS系统系统的最大区别是:在ECS实时采集、监控的基础上,强调了基于电气的逻辑控制,也就是说,系统不再是传统ECS那样仅仅是一个单向的实时采集,而是更注重下行的控制调节,是一个真正的闭环控制系统,这是最本质的区别,也是本系统中最大的难点。公司对此项目十分重视,抽调了最精悍的核心力量投入到前期的调研和设计作为骨干中的一员,我负责系统的需求分析。 这里要交代一下,公司之所以非常重视,更重要的是从战略高度考虑,希望以此项目为突破口,实现从基于测控ECS产品向基于控制的DCS(分布式控制系统)的战略转移。所以,这个项目具有十分重要的意义,从这一点上说,前期的需求分析就显得十分关键。 可是,当我们和电厂的用户在初步接洽时发现,用户对系统的一


些基本需求构想却比较模糊,只是含糊的说: 只要把DCS那一套差不多搬过来就可以了,另外,一定要组态很方便、控制要快、维护要方便。我们问道,怎样程度就感觉方便,实时性指标多少可以满意?能否提供一个文档具体描述一下呢? 用户说,我们只能说这些,计算机处理方面的事情我们哪里懂得啊。我们当时就被hold住了。 事后,我们了解到,像这种把逻辑控制引入到ECS领域的做法是一种十分超前的做法,这样的系统目前在国内还不多见。我们很快冷静下来,指望用户提供文档描述是不可能了,我们很快制定了“从零做起,以问题驱动用户,逐步推进”的策略。 按以往的项目经验,在需求分析阶段,我的常用方法是: 1、用户访谈:这种方法交流很充分,准确率高,但对沟通技巧有一定要求。2调查问卷:效率高,能在短期内获得多方信息,但有些信息可能反馈不出来 3、联合需求计划能集合多数人的意见,效率也比较高,但真要做得气氛开放、言之有物,并不容易。考虑到本项目中,用户需求模糊性内容多,技术难度大的特点,我决定采用多种方法组合使用,发挥各种方法的优点。 从用户提到的“把DCS大部分功能照搬过来”这一提法看,DCS系统的功能中应该蕴含了电气逻辑控制的大部分需求。我决定以此为突破口,我首先仔细查阅了DCS系统的有关资料对逻辑组态、逻辑任务运行的基本应用有了基本了解后,精心设计调查问卷,主要包括前期的一些方向性的问题,涉及实际应用中要完成的控制类型、采用的功能块、逻辑任务的周期等等。 由于问卷的问题设计得当、直白明了,一些具体的问题摆在了用户面前。有些用户答题时就开始了讨论,气氛逐渐热烈。在以往的做法中,一般都是用户单独答卷,彼此不做交流。但这次我们并不拘泥以往的做法,大家尽可以自由交流。我认为,不论什么方式,只要能激发用户的热情,引起他们思考的兴趣,目的就算达到了。 次问卷的成功之处在于,从众多问卷的反馈中,能够清楚地体现出ECS逻辑控制的业务特征: ECS的逻辑控制更注重对数字量的逻辑控制,而很少有DCS中的PID一类的模拟量调节;此外,参与ECS逻辑组态的元素也不同于DCS,是采集的测点或是计算点,而不会是IEC变量。整个系统的基本需求开始变得明晰起来,为需求的进一步细化提供了参考的依据。 在获得了初步需求之后,我们就迅速进入了详细分析阶段,这个阶段的任务是,对各需求的具体内容要细化,尽可能详细,功能、性能、约束都要尽可能具体。这个阶段,我选择了用户访谈的方式,其优点是交流比较充分,不仅能获得许多背景知识,也能捕获更多细节、更多一线感受,这种优势是调查问卷所不能比拟的。 同样,为了使访谈更有效率和更具针对性,我事先仍然做足了功课。 我了解到,未来的用户群基本分为三类:一类负责逻辑组态,一类负责画面组态,一类负责现场装置的维护。于是,我针对每类用户的工作内容、特点专设计了针对性的交流提纲,目的是尽量鼓励用户多说;对参与访谈的用户也进行了仔细筛


选,基本原则是: 要有代表性,对自身的业务要非常熟,而且每种类型的用户都要覆盖到。 为了尊重每位参与者的付出,我们还精心准备了礼物,这样的效果非常好,用户看到我们如此认真、职业,也感到自己的劳动得到了尊重,交流起来也十分配合。 事先准备的提纲发挥了关键的作用,每一项内容都非常具体,这样可以避免谈话时泛泛而论。交谈中,负责逻辑组态和画面组态的用户都提到了ECS数据规模非常大,遍历选点会十分困难,希望能采用快捷选点的方法。最初,我考虑采用控制器、二级装置、一级装置、I/O点这样的层次方式选点。但很快用户反映,希望能从现场工艺的组织方式逐层选点,因为用户对工艺过程十分了解,而对现场设备的网络结构并不关心,这样可以更专注于工艺过程的实现,而无需关心更多工程技术的细节。最终,我们采纳这个建议。 用户访谈时,有时一些细节问题很重要,如果不注意捕捉,以后就很可能产生疏漏。比如,有用户偶然谈到:有些情况下,工艺逻辑的设计会受到制约。我敏锐地感觉到了这里的问题,经后续深入交流后了解到:有时由于现场工艺条件的限制,参与一个完整逻辑的I/O点不能全部接入到同一个控制器中,而是就近接入到了其他控制器中。要保证工艺逻辑的运行完整性,就必须实现控制器之间的数据同步。了解到这个情况后,我们在后续的方案设计中,专门设计了用于控制器互联的的实时以太网,用来保证控制器之间的逻辑数据的同步。事后表明这个处理十分成功,在后来的施工中,对现场工艺的各种复杂的需求,都表现出了很强的适应性。 再后来,我们还采用了演化的方法,做了电气逻辑控制的快速原型。在功能导航的基础上,对每个功能的实现,表现方式都以更直观、更具体的形式展现出来。按我的经验用户似乎更愿意以这样的方式对分析的结果进行确认,而对大篇幅的需求规格说明常常不大感兴趣。 工程历时约一年。由于在需求分析这一关键过程中,策略得当、方法对路,系统比较充分的实现了用户的各项预期,受到了用户的肯定。总结来看,我最大的体会就是: 1、对各种需求获取方法的组合使用是十分必要的,这样可以发挥各种方法的优势 2需求获取和分析是一个不断细化和深入的过程。在这个过程中,要采用多种表现方式以利于用户确认 3用户的热情参与十分重要,应该总结这方面的技巧 施工中,也暴露出了一些不足之处:最初希望能够通过业务实践的方法,参与到用户的日常运营中,但用户从运行安全的角度考虑,最终没有同意。在进行演化方法的过程中,由于工期很紧,部分功能在快速原型中体现的深度不够,这导致在以后的工程出现个别细节的疏漏,这是比较遗憾的地方。


本文来源:https://www.dy1993.cn/6SQ.html

相关推荐