9.1.3 系统建模
需求分析员根据业务建模阶段的成果进行系统建模。站在系统实现的角度,深入实现的细节和具体实现信息,结合业务模型,进行系统建模,最终做出系统模型,以及界面原型,达到与客户进行需求确认的目标。
RA人员会根据业务情景活动图画出反映系统执行的静态系统用例视图,并根据系统用例画出反映具体用户和计算机系统交互运行的系统情境活动图,然后再画出具体的原型界面,通过与业务人员的会话,RA人员结合画出的图落实和细化系统建模细节问题。我们就其中发工资的用例开始模拟访谈过程,获取更多细节。
根据发工资的业务情景视图,RA已经画出了如图9-12所示的发工资的系统用例视图,根据此用例视图,随后开始访谈,以便获取更多的细节。

图9-12 发工资系统用例视图
RA:这是我们目前根据需求所画出来的关于发工资的系统用例,主要有查看审核后的薪资表和发送薪资表到银行,那么针对发工资的系统用例,需要填写什么文件吗?或者有什么前提吗?以及具体处理过程是如何的?
业务人员:正如系统用例获取的,发工资的前提就是经过薪资审核委员会审核过的薪资表,最后这个表会传到财务出纳那里,薪资表之前就已经发给你们了,如果需要数据,我可以填写假数据,让你们做些参考。
RA:谢谢,这样最好。我可以在具体理解一下每个数据的意义,在系统中我们会将之前的薪资表格式化,形成薪资审核流程,结果就是审核的薪资表。这样是不是可以满足要求。
业务人员:可以,审核的单据结果是直接到出纳,而且一定是不允许修改的,因为这是工资。
RA:也就是出纳那边是不是只能查看,不能修改,那页面上就不能修改和新增信息了,我们提供生成PDF版本的薪资表是不是可以满足这个要求?
业务人员:对,出纳也只能看薪资表,导出的薪资表要符合银行的要求,但是也不能导出PDF,因为银行要求的是Excel形式,而且各个月份的薪资表,在系统中可以随时生成查看,每次发完工资后的薪资表是不允许改动的,就算是生成后的薪资表,在审核期间若有修改也能有记录查看到是谁,什么时候修改的,修改了什么数据。
RA:哦,也就是薪资表所有的操作都要有日志,要能够追踪到每次的修改情况。
业务人员:对,就是要具有不可抵赖性。(https://www.daowen.com)
RA:好的,这个我们可以在系统管理的日志中体现出来。
…………
关于日志管理部分,这里不做介绍,下面将发工资的主要系统情景视图展示,如图9-13和图9-14所示。

图9-13 系统情景视图(1)

图9-14 系统情景视图(2)
根据系统情景视图,结合业务人员给出的约束和要求,我们画出了初步的系统原型界面,以方便客户确定主要显示信息,页面的主要布局,功能和实现方式是否符合客户要求,当然这里也需要和客户经过几轮交互,确定最终的原型信息。这里展示的是主要界面,还有个别弹出界面和子页面,如图9-15和图9-16所示。

图9-15 查看审核薪资-原型界面

图9-16 导出薪资表-原型界面