在需求采集结束后，就进入了一个相对重要的环节：问题分析。
1.问题与客户达成共识
这个共识有签字式的——协议，也有非签字式的——确认。
记住，所有的共识都基于双方的理解。文字的东西往往会引起歧义，电话确认又往往失于严肃。图形化的方法可以弥补这些缺憾。个人经验，文字的描述比较适用于
早起的问题收集，或者是简单的问题确认。复杂的问题需要交给图形化来解决，wireframe——虚拟界面，是个不错的选择。它除了可以收集输入输出数据
项，还可以给客户一个比较直观的感觉。当然，这个也相对费时一些。但对于需求的确认至关重要，可以减少客户与软件人员的误解。
2.找出问题背后的发生原因
韦伯说过，社会行为是行动者赋予主观意义的人类行为。任何人（团体、组织）的活动在社会中都会牵涉到另一个人（团体、组织）。任何行为本身都具有意义，如
无意义，则无行为。
扯远了，还是谈谈需求问题。客户问题的提出，是为了解决问题。要想解决问题，就必需知道问题是如何产生的。也就是说，要想找到蛋，就必需先找到下蛋的鸡，
研究它的活动轨迹，最后定位鸡蛋的位置——解决问题。在社会学里，找到了行为的意义，也就掌握了行为本身。记住，无意义就无行为，有行为则必有意义。
3.确定系统用户
包括用户的角色和权限。这是系统能够运行起来的基本条件。如果不能引起足够的重视，对于系统将是严重的灾难。笔者曾做过一个office
resource
management系统，从初始的一个角色对应一个office,到一个role对应多个office,一个人一个角色，到一个人多个角色。修改之多，
之繁重，不能与人言。
4.确定系统边界
在实践过程中，个人引入了"内外表"来定义系统边界。这个在稍后的usecase中具体描述
5.划分子系统的三个原则：
a.职责不同的功能划归不同子系统：将一类包含统一职责的功能划分为一个子系统。如权限管理系统与业务系统分离。（企业系统需要统一的权限管理：安全认证
以及系统授权），再如社会保障信息系统按业务类别的划分：养老，医疗，工伤，失业，生育。按照业务规则划分又可以分为：公共业务（单位，个人），待遇，报
表
b.需要不同开发技能的单元划归不同子系统:如报表系统与数据仓库的独立开发。
C.软件工程管理的划分：
1)兼顾工作量的相对均衡，进一步切分太大的子系统。交给不同的team进行并行开发。
2)同一类公用\复用模块划分为一个子系统：如规则引擎，简单报表，css
theme管理，数据同步\交换，基础平台的二次开发(统一弹出式查询,输入校验,页面组件)等等。