java随记

坚持就是胜利!

 

需求收集、分析小结

绕不过去的坎---需求分析需求.分析师也好,系统分析师也好,架构师也好乃至PM都有一道绕不过去的坎,那就是需求分析。需求分析也绕不过需求收集。
需求收集的要点:
1,参与人。很重要。广义上是指各种干系人,如客户方,自己方的.具体的软件操作员可以是直接参与人,但也可能是代理参与人,比如声讯话务员,并不是系统的直接参与者,而是代理人。嗯,可以理解成别人请话员操作软件。甚至打电话进来的也是一个代理人,他帮别人办理业务。也有可能有数据权限要求。
2,用例。描述业务场景。通俗一点讲即参与人要办的事情。
3,边界。边界有两种意义。一种是技术实现层面,比如mvc模式中的V。另一种是业务层面的,指本用例需要达到的目标。
以上三点,UML中有业务用例图表示。但是仅此还不够。俺给加上第
4,业务规则。即完成业务的约束条件。这个单独抽出非常重要。有些业务规则最终可能会实现为一个系统用例。比如出国需要办理出入境业务。如果在电脑上实现预约,当然要考虑办理中心排班情况,比如除法定节假日以外星期一至星期六都工作。因为每年的法定节假日不是固定的,那我们需要做一个日期是否工作日的排班表出来。这条业务规则即变为一个系统用例,有人机交互界面。在预约出入境时就成了预约的前置条件。还有其它的业务规则比如报表的计算公式等。可见业务规则是如此重要。可以抽出来弄成单独的文档。
系统分析员或需求分析师需要根据业务需求做出系统用例。系统用例在人机交互应用中是指人做什么,然后电脑做什么的描述。
pm会跟用户聊到需求。架构师需要了然关键需求及可能存在风险的需求,尽早考虑解决方案。需求分析师也好,架构师也好,基本上应该擅长业务领域模型建模。业务领域模型可能映射成数据架构,即数据的存储方式,比如数据库和文件等。如何正确的建立领域模型?
1,不要放过业务场景中的名词。比如合同,销售单。
2,不要放过业务场景中的动名词,比如取款。描述可能一是条取款流水记录,如某人在某个时间某个地点用某种方式取了多少款。
3, 应当收集业务中用到的一些资料如销售单,出货单,甚至是公司章程如请假制度管理等。
参与人和业务规则往往容易被忽视掉,这会带来需求变更。那么问题来了,这些东西如何映射成程序中的对象?如下图中的商场的小票联.应该怎么建数据库表呢?有没有方法呢?当然有,那就是找出发票中有哪些对象。根据对象建数据表。
分析过程:
1,问问自己,小票是对象吗? 当然是.因为它有自己的属性。比如开票人,销售的商品。在商场pos系统里这个对象其实就是销售单对象。
2,销售时间是一个对象吗?不是。因为它只是一个时间字符串,本身没有其它属性。
3,可乐汽水及商品编号当然是一个对象。这容易理解。
4,金额3.1元也是一个基本属性,它属于什么对象?销售单本身吗?显然不是。它跟可乐汽水这个商品合起来才是一个对象,描述的是销售单什么价格销售了什么产品,应当单独建立一个表。如果有多个商品?那很容易扩充,销售单有一个LIST<销售明细> 的属性。
对象本身具有良好的继承性,换句话讲按对象模型建立的数据库表基本上都是很容易扩展的,在增加新功能的时候不至于大动干戈。架构师则根据此设计数据架构视图,比如销售单查询响应要求,大数据量的水平,垂直分库,数据库读写分离等。

posted on 2017-04-28 14:08 傻 瓜 阅读(384) 评论(0)  编辑  收藏 所属分类: 杂项


只有注册用户登录后才能发表评论。


网站导航:
 

导航

统计

常用链接

留言簿(4)

我参与的团队

随笔分类

随笔档案

文章分类

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜