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