知乎问答-如何做一个软件需求分析师

标签: 随笔文章 | 发表时间:2013-10-30 11:32 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
这个问题很大,这篇不想再去重复一个软件需求分析员的知识体系结构,而是挑重点来谈下成为一个合格的软件需求分析人员的关键点。

我原来对软件需求的定义或描述更多是偏于对现实世界的定义,而对软件架构的描述为现实到实现之间的第一层抽象。在这里纠正一下即:用户需求是对现实世界的定义,而软件系统需求是现实到实现的第一层抽象,即业务建模和软件系统用例建模。在原来的软件工程里面我们更多谈到的一个词是系统分析员,我现在将其拆分为了软件需求BA和系统架构SA两个角色。而实际上一个真正优秀的软件需求人员必须具备两方面的能力。

从软件需求在整个软件生命周期中的定位来看,其上接业务,下接设计和技术。从这个概念上来讲软件需求人员必须具备业务和技术两个方面的能力。

对于业务,首先要解决的是对业务的理解,然后才是在理解后业务的形式化表达和业务建模能力。而对业务如何理解,最核心的仍然是顶层的流程建模和分析能力,底层的业务活动和规则清晰的描述能力。在这里里面涉及到流程梳理和定义能力,业务单据和对象的抽取和定义能力,业务规则的清晰阐述能力,和流程配套的相关的岗位角色,交互等描述能力。要知道在这块往往并不需要太多的IT背景和软件工程的知识,更多的是对业务的熟悉,对流程管理和分析方法的了解。

上面一步的业务更多的是属于顶层方面的内容,而第二个层面往往会过渡到系统软件需求层面的内容,在这里我们更加强调的是类似面向对象的用例分析和建模的方法,这包含了业务用例和系统用例分析和建模,是一种很好的形式化的方式来定义和描述业务的方法。包括从流程分析转入到用例,单个具体的用例分析和建模,每个用例详细的基本流,扩展流,业务规则,参与角色,界面原型,业务对象和对象属性等各个方面内容的描述,要知道我们做用例建模的目的是能够按用例驱动的核心,平滑的转入到架构设计中去,因此用例分析建模已经不是简单的描述现实世界的问题,已经涉及到业务或用户需求到系统需求的第一层抽象转换。

要做好需求的第二步的事情,那么单纯的只有业务背景就不足够的,必须还具备相应的IT和软件工程的技术背景。这个背景往往并不是说要做过多久的软件设计开发,但是只是是做过,通过软件开发你能够很清楚的知道一个软件从需求调研和分析开始,最终是如何形成一个软件系统的。这个背景知识可以更加方便我们去考虑用例建模,去认识到为何要采用这种方式去用例建模,真正理解用例中每个描述点如何影响到最终业务系统的实现。

没有技术背景很难真正成为一个优秀的软件需求分析师,最多也就是一个业务需求分析师。

要知道,当你进行用户需求调研后,往往收集到的都是一个个的用户需求点,而一个软件需求分析员要做的是最终将这些需求实现为一个完整的业务系统。这里面就涉及到业务模块的划分,模块间的分析,需求层面的复用能力分析,各种性能,可靠性,安全等非功能性需求。这些更加已经是一个完全的系统分析方面的内容,或者说软件需求已经会兼顾部分软件架构设计的内容,因此作为一个软件需求人员更加需要去了解业务组件化,服务化,软件模块集成,复用等方面的技术内容。也需要去了解涉及到UCD,交互设计方面的内容,这些都是形成一个高质量的软件业务系统的重要输入。

一个优秀的软件需求人员既不应该因为具备技术和开发背景而导致在需求分析和建模中的各种程序员思维,也不应该完全抛弃技术单纯的去描述业务不管实现的难易度。软件需求人员衔接了最终用户和内部的设计开发,是两者之间重要的沟通和协同桥梁。各种沟通和人际关系处理技巧,各种软技能的要求更是必不可少的,在此不再展开去描述。

一个优秀的软件需求人员不存在是否能做新领域的软件需求的问题,因为最终真正有用的需求分析的方法论和模式,去理解和熟悉业务和快速形式化描述和建模的方法,有不断的实践总结出来的快速理解业务的能力。

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [知乎 软件 需求] 推荐:

知乎问答-如何做一个软件需求分析师

- - 人月神话的BLOG
这个问题很大,这篇不想再去重复一个软件需求分析员的知识体系结构,而是挑重点来谈下成为一个合格的软件需求分析人员的关键点. 我原来对软件需求的定义或描述更多是偏于对现实世界的定义,而对软件架构的描述为现实到实现之间的第一层抽象. 在这里纠正一下即:用户需求是对现实世界的定义,而软件系统需求是现实到实现的第一层抽象,即业务建模和软件系统用例建模.

软件需求获取方法

- - 研发管理 - ITeye博客
软件需求获取是软件需求开发的关口环节,关口没把守好,后面就会全面溃败. 软件需求获取个人认为有以下几个方法:. 现有产品和竞争对手的描述文档;. 面谈是获取软件需求的最有用的方法之一. 面谈对象:与系统相关的涉众,并具有代表性,保证涵盖到每个角色. 谁会受到系统结果的影响,谁来监管该系统. 面谈问题:需保证与背景无关,保证获取信息的公正性.

如何开展软件架构之需求分析

- - CSDN博客架构设计推荐文章
如何开展软件架构之需求分析.  在开始讨论如何开展软件架构之前,先让我们来看一张漫画. 相信大家看到这漫画的时候,总会不自主地会心一笑,客户希望得到礼物,我们却给了他一骨头. 一):未进行充分地需求分析. 解析:架构师未能初别用户群及使用环境约束因素,也许在接到项目时,他还在想着上一个为狗开发的项目,在这个项目中自然而然地认为用户是狗.

浅谈软件项目上的长期慢性需求问题

- - 外刊IT评论
本文的作者Capers Jones是Namcook Analytics公司的副总裁和首席技术总监. 他一直在收集软件质量和开发效率上的数据. 他写了几十本关于软件质量、最佳实践方法、评估、测量方面的著作. 在处理软件需求时,有三个问题一直折磨着我们,并使软件项目消耗无数资金. 其中很大一部分都产生在项目交付并运行后的新需求的收集工作中.

谈软件开发项目管理之需求变更(转)

- - CSDN博客研发管理推荐文章
在软件开发过程中需求的变更会给开发带来不确定性,但只要把需求变更作为重点、难点小心加以控制,软件开发的进度、成本和质量也就有了"安全"的基础. 变化并不是人们最害怕的,最怕的是跟不上变化的步伐. 需求变更是因为需求发生变化. 根据软件工程思想,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减,均属于需求变更.

软件“人工干预”需求太多 云计算将解放你的双手

- - 雷锋网
【编者注】Alan S Cohen为 IT 串行企业技术老手,Nicira副总裁. 数年前我在一个大型会议上开会,Yahoo消息窗口突然跳出来,我女儿给我发来信息说“爸爸, 我怎么让我的打印机工作,帮帮我”. 当时我只能说半小时后我再回复你然后关掉了这个应用. 当时我很尴尬,我想为什么这么多应用程序需要 人工的干预才能完成一些基本的任务,这样我们就像个软件“人工干预员”.

知乎问答

- - 人月神话的BLOG
没有编程经验的,至少需要掌握哪些知识,才能胜任软件产品的需求分析工作. 在这里首先要注意编程经验和懂编程,编码和软件工程是两回事情. 举个例子你没有在生产线做过工人,但是不代表你不可以了解一个产品从原材料开始如何从生产线生产出来的. 你可以当生产线去参观和学习,当然如果你能够在生产线实习一段时间印象更加深刻.

再谈需求

- - 人月神话的BLOG
谈需求工程方面的文章前面写过很多,本文仅做最近思考的一些点滴记录. 首先我们谈下业务建模层面,对于从用户提出最初的业务需求到交付一个完整的系统,在建模层面涉及到两个层面的抽象,其一就是业务建模解决现实世界本身的抽象描述,其二就是软件架构设计,解决从业务模型到IT架构模型的第二次转换. 在早些时候我们看到这两个层面的建模内容都由系统分析员承担或完成,在岗位不断细分后我们看到反而会出现忽视了业务建模的问题.