需求工程的过程分为需求准备、需求获取、业务建模、系统建模等阶段,中间各环节通过关联规则体系串接起来以达到跟踪监控整体需求工程进度的目的。......
2025-09-30
涉众不等于用户,通常意义上的用户是指系统的使用者,只要有利益关系的人或事都是涉众,都可能对系统建设造成影响,这一点将会贯穿本书始末。
很多涉众是系统的用户。由于直接和系统的定义、使用有关,这些涉众的期望相对容易被考虑到。相反,有些涉众仅仅是系统的间接用户,或只是受到系统商业结果的影响,这些涉众可在商业系统内部或特殊应用环境的周围找到。在部分例子中,有些涉众甚至不在应用环境中。例如,在系统的开发过程中涉及到的人或组织、转包商、客户的客户、一些管理机构,如美国联邦飞行管理局(FAA)或食品药品监督管理局(FDA)、其他与系统或开发过程有交互的机构。这些利益相关者的每一类都成为系统的需求来源,或以某种方式涉及系统的结果。
确定项目的涉众有助于获得更多的关键需求,我们可通过8个大类寻找软件项目的涉众:
1.业 主
业主是系统建设的出资方、投资者。虽然大多数情况下业主指的就是系统的需求提出者和使用者,即业务方,但并不是绝对的。比如可以假设系统建设是由国家国际风险投资机构投资的,本身并不管理和运营这个系统,只是从资本上拥有这个系统并从运营收入中获得回报。
即使业主与业务主是重合的,但是业主从概念上讲并不等于业务方,他们关心的内容是不一样的。了解业主的期望是必需的和重要的,业主的资金是这个项目存在的原因。若系统建设不符合业主的期望,导致其撤回投资,那么再好的愿望也是空洞的。
一般来说,业主关心的是建设成本、建设周期以及建成后的效益。虽然这些看上去与系统需求没什么大的关系,但是,建设成本、建设周期将直接影响到可采用的技术,可选用的软件架构,可承受的系统范围。一个不能达到业主成本和周期要求的项目是一个失败的项目。同样,一个达到了业主成本和周期要求,但却没有赚到钱的项目仍然是一个失败的项目。
2.业务提出者
业务提出者是业务范围、模式和规则的制定者,一般指业务方的高层人物,如CEO、高级经理等。业务提出者最关心项目建设带来的社会影响、效率提升、管理改进、成本节约等宏观效果。也就是说,业务提出者只关心统计意义而不关心具体细节,但是如果开发的系统不能给出业务提出者满意的统计结果,这必定是一个失败的项目。
实际上,由于业务提出者的期望是非常原则化和粗略化的,因此留给了系统开发者很大的调整空间和规避风险的余地。
3.业务管理者
业务管理者是指实际管理和监督业务执行的人员,一般指中层干部。业务管理者起到将业务提出者的意志付诸实施,并监督底层员工工作的作用。
业务管理者关心系统将如何实现自己的管理职能,如何能方便地得知业务执行情况,如何下达指令、如何得到反馈、如何评估结果等。业务管理者的期望相对比较细节,是需求调研过程中最重要的需求来源。
4.业务执行者
业务执行者是指底层的业务操作人员,是与将来的系统直接交互最多的人员。业务执行者最关心的内容是系统会带来什么样的方便,会怎样改变业务操作人员的工作模式。业务执行者的需求最为细节,系统界面风格、操作方式、数据展现方式、录入方式、业务细节都需要从业务操作人员这里了解。
这类人员的期望灵活性最大,也最容易说服和妥协。同时业务执行者的期望又往往是最不统一的。但是不管业务执行者的期望有多不统一,都必须服从业务管理者的期望。所以,需求分析人员要做的事情就是从业务执行者的各种期望中找出具有普遍意义,解决大部分利益相关者的期望。
5.第三方(https://www.chuimin.cn)
第三方是指与这项业务有关系的,但并非业务方的其他人或事。比如购物网站系统,如果交易双方是通过网上银行支付交易的,则网上银行就成为购物网站系统的一个利益相关者。
一般来说,第三方的期望对系统来说不会产生什么决定性影响,但大多会成为系统的一个约束。通常,在最终系统中,这些期望将体现为标准、协议或接口。
6.承建方
实际上,承建方的期望也是不容忽视的。承建方的期望将很大程度上影响一个项目的运作模式、技术选择、架构建立和范围确定。
案例&知识:
例如,如果老板试图通过一个项目打开和培育一个新兴市场,那么需求分析员就需要尽可能深入地挖掘潜在业务。反之,老板如果只是想通过这个项目赚更多的钱,那么需求分析员就需要引导业务方压缩业务范围。这样一来,可能仅仅考虑系统的可维护性是否能够被接受,而较少考虑系统扩展能力。
7.相关的法律法规
相关的法律法规是一个很重要的,但也最容易被忽视的利益相关者。这里的法律法规,既指国家和地方法律法规,也指行业规范和标准。
案例&知识:
例如,服务行业建立客户档案,就必须保障客户的隐私权,系统设计时,就不能将涉及隐私的信息向非授权用户开放。
8.用 户
这里的用户是指预期的系统使用者。每一个用户将来都可能是系统中的一个角色,是实实在在参与系统的,需要编程来实现。而上述的其他利益相关者,则有可能只是在需求阶段用来分析系统,最终并不与系统直接交互。在建模过程中,概念模型的建立和系统模型的建立都只从用户开始分析,而不再理会其他的利益相关者。
最后,关于涉众的最大问题是,如果没有找齐所有关键的涉众,或者在需求收集过程中把某些涉众排除在外,就可能会遗漏一些需求。
从上文提到的几个大类中寻找涉众。一些组织机构或人员与“薪酬管理项目”是有利益关系的:
综合管理部是对考勤记录、月度薪资表、员工信息、薪资规则等进行管理维护的部门,确保业务流程中用到的各个单据可以顺利准确地生成;财务部是审核月度薪资表,并将月度薪资表以银行所需的形式呈交给银行的部门,作为公司与银行之间的桥梁,是薪资发放流程的重要环节;银行不会使用薪酬管理系统,但是作为薪资发放的最后一个环节,系统需要根据银行定义的格式产生指定的文件,所以银行也应作为系统的涉众之一;公司部门经理、总经理、董事长作为各个审核流程的关键环节,确保了业务流程能够正确实施,此外,他们还需要通过系统掌握各部门或公司整体的薪资情况;普通员工可以查看自己的薪资及考勤情况,保证了系统的公开透明,还可以对异常情况进行申诉,减少了系统出错的几率。
这些组织机构或人员都参与了薪酬管理的业务建设,对系统的建设有不同角度的期望。这些期望是建设系统的重要分析来源。发现项目中的涉众之后,就可以着手进行涉众分析报告的编写了。
相关文章
需求工程的过程分为需求准备、需求获取、业务建模、系统建模等阶段,中间各环节通过关联规则体系串接起来以达到跟踪监控整体需求工程进度的目的。......
2025-09-30
UML核心元素讲述了方法论中需要用到的一些关键概念,在业务建模以及系统建模阶段都有所涉及。接下来讨论这两种UML图形的组成以及在方法论中的应用情况。在UML中一般使用带圆端的矩形框表示。在UML一般使用带箭头的直线表示,线上可以添加条件。在UML中使用菱形表示分支。分叉和汇合在图形上都使用同步条来表达,在UML中一般使用一条粗水平线表示。在UML中泳道一般用垂直实线来表示,垂直线分割出的区域就是泳道。......
2025-09-30
要给一个名词下定义,是一件很严肃和严谨的事情,因此,要给出需求工程准确的定义是不太现实的。本书从方法论推进和实施的角度出发,提出了本书对需求工程的理解和定义。需求工程是面向业务全局、系统顶层的一种着眼于软件过程全过程的工程,是将客户业务作为内部研究对象、将软件工程实施作为外部研究对象的工程。之后,书中提到的需求工程即以此定义为准。......
2025-09-30
这里就以审核薪资表为例,建立起系统情景模型如图3-16所示。图3-16审核薪资系统情景视图当然,活动图只描述了过程,并未展示出系统实现需求的所有细节,这些细节就使用用例规约来描述,如图3-17所示审核薪资表的用例规约。......
2025-09-30
UML作为方法论实施建模过程用到的主要建模元素,本节将对使用到的核心元素的基本概念和使用方法进行详细介绍,对使用到的一些重要元素会进行较为深入的讨论。在方法论中我们把收银员这类由于被动“参与”了业务流程的人员称为业务工人,而与之对应的主动发起或主导业务流程的小明们就被称为业务主角。......
2025-09-30
被害人一词来自拉丁文的Victima,指因他人的犯罪行为直接侵害而遭受伤害、损失的个人。受害人,并非一个正式的法律概念,我国刑事诉讼法律中亦无此称谓。但涉众型经济犯罪被害人在犯罪的产生和发展中存在主观的“过错性”,使学界对部分被害人是否具备“被害人”身份各执一词。涉众型经济犯罪以被害人众多得名,一些案件侦办人员为节省资源,提高办案效率,在诉讼程序中将被害人认定为证人,从而无须考虑保障被害人的诸多诉讼权利。......
2025-09-29
在方法论中原型界面就是原型,并不代表系统的最终实现,可以使用草图来表示。图3-18审核薪资原型界面同时配合原型界面的使用以及为设计人员提供关键元素,每个原型界面都有对应的用例脚本展示,主要以边界类、业务类及实体类的划分为依据,按照MVC的主要思想将设计的关键要素表达出来。......
2025-09-30
犯罪预防是犯罪学研究的出发点和归宿,也是犯罪学研究的难点之一。社会预防理论认为犯罪是各种社会因素共同作用于行为人的结果,强调从社会各个方面预防犯罪。广义犯罪预防概念反映了犯罪原因的复杂性和多层次的特征。狭义的犯罪预防指在犯罪发生前主动采取措施进行防范。......
2025-09-29
相关推荐