问题账户需求分析

Posted 2020-10-10 悦尔

材料：

　　某大银行的一位银行卡办公室的收账经理Liz遇到了一个问题。她每周都收到一份过期未付款的账户名单。这份报告已经从两年前的250个账户增加到现在的1250个账户。为了确定那些严重拖欠债务的账户，Liz需要通读这份报告。严重拖欠债务的账户由几个不同的规则确定，每个规则都要求Liz检查客户的一项或几项数据。过去半天的工作量现在增加到了每周三天。即使在确定了严重拖欠债务的账户后，如果没有查阅该账户三年内的历史资料，Liz也不能做出最后的信用决定(例如严厉的催款电话、断绝信用或将这个账户转给一个收账代理)。另外，Liz需要报告所有账户中过期未付款的、拖欠债务的、严重拖欠债务的和呆死账的比例。目前的报告中并没有给她提供这个信息。

　　需求分析应该首先在问题定义上达成共识。理解真实世界中的问题和用户需求并提出满足这些多方面的解决方案的过程第一步显然是把问题拿出来，并且要得到所有人的共识。根据材料分析可知liz遇到的问题主要是问题账户增多导致的工作量增加，客户账户的历史数据繁多和问题账户的比例统计。

　　然后是理解根本原因，也就是分析问题背后的问题。Liz的工作量增加直接原因是因为账户数量增加，但是根本原因则是因为使用原始的人工检索方式。人工检查客户的多个数据项和查阅账户历史资料本就是非常费时费劲的事情，而且很容易出错。

　　接着是确定相关人员和用户。账户分析系统的使用者应当就是Liz这样的银行卡办公室的收账经理，而涉及到其他的人员应该包括账户户主，因为需要存储账户的历史记录。

　　最后是定义解决方案。我们可以建立一个数据库存放客户的账户信息，历史记录，判定问题账户的条件等。然后编写程序检索问题账户，判定账户信用以及显示账户比例等。

　　我认为需求分析材料中最欠缺的就是问题账户判定的条例。没有具体的条例当然没办法做出判定。另外是没有用户的数据。

 

　　我觉得系统应该包含如下功能

1. 1. 判定账户是否是问题账户。
   2. 判定账户的信用。
   3. 统计问题账户比例，生成报表。

 

　　简单设计数据库如下：

　　　　　　客户信息表：

字段名称	字段类型	长度	说明
Clientid	Char	32	客户编号
ClientName	Char	10	客户姓名
Clientbalance	Decimal	10	账户余额

　　　　　　历史信息表：

字段名称	字段类型	长度	说明
clientID	Char	32	客户编号
RecordTime	Datatime		记录时间
Content	Char	255	记录内容

 

 

　　　　　　操作流程：

　　　　　　　　输入客户编号或者用户姓名==》显示客户信息，系统自动判定是否是问题账户和信用等级==》所有账户都录入完成==》生成报表