有幸与李经理一起参加了 中国软件测评中心 主办的 “高级软件需求分析培训班”，5.31-.6.2，3天，花费3900元，花了这么多钱，不过还是学到了一些东西，培训上老师主要提个思想，概念，主要努力还在自己，其实3天时间指望能达到什么什么样的结果是不可能，罗马之城不可能一日建好。
老师是：北京航空航天大学软件工程研究所的郭老师，感觉水平还可以，不是那种泛泛而谈的，至少通过上课知道了理论上需求分析应该怎么做，怎么避免一些风险。
第一天，上午主要讲了一下概念性东西，下午主要讲了ROSE工具，和用例建模的一些知识。
上午，9点开始上课，大家作了自我介绍，发现来的同学还不少，很多都不是苏州本地的，苏州的好像只有5个，我们公司2个人，住房公积金2个人，科大的一个老师，看来很多“培训还是很有市场的”，别的地方的同学，有常州的，无锡的，杭州的，远的有甘肃的，武汉的，大家在一起共同培训3天，一起学习，一起吃饭，一起交流。大家都是一些公司信息化部门的人，都有多年的工作经验，通过培训，大家肯定更加理清了思路，对需求分析的认识有了很大的提交，以前我也培训过一次，2天时间，讲了分析设计的，那时可能经验还不多，当然一些概念还是理解的，如“用例建模”，“域模型”，“序例图”，“活动图”。通过这次培训，我更加理解了这些概念，另外老师还给大家发了一个文档，需求分析的模板，用例卡的模板。
感觉如果需求分析真正能做到这样老师讲得那样，那项目的风险的确能降低不少了，但我们做项目时，往往时间太短，感觉真正要把文档写这么详细，很花时间，进度根本来不及，所以都是冲冲设计好数据库表，各个字段的定义，简单设计一下界面，就开始编码了，这里面有一定的风险，最主要的缺少了业务交互，以及这些业务交互要考虑的问题。比如大家都知道，新增订单，新增订单，仅仅是把记录插入到订单主辅表吗，也许对于软件需求来说，还要记录到日志里，还要发邮件通知谁谁，等等之类的。如果能有序列图，表达一下整个用例的要哪些对象参与，哪些类是边界类，实体类，控制类。这样会对程序员有更加深入的认识，才知道应该考虑的细节，但我们开发过程中，需求文档写的简单，没有深入考虑，所以做到后期才不断的新增，修补，这其实会增加后期的开发成本，如我现在做的体育馆项目，会员开卡，会员充值，套餐购买，表是设计好了，怎么存储，怎么交互，因为一开始没写的很认真，到现在都改了好几遍了，当然，也有一些一开始需求调研上，没有沟通好的地方，如和财务沟通一次，要增加一些，和运营的领导沟通一次，又变更一些东西。其它领导沟通一次，又增加一些。结果项目不断改，这也是需求分析不充分的一种表现吧。再加上文档不仔细，开发上来回修改是肯定的。 真希望下一个项目，能引入这次培训的一些东西，如用ROSE建模，在UML分析设计这一块加强。
上午主要讲了 “需求含混是问题之源”和“需求过程本质与常见问题剖析”这两讲。
对于需求含混是问题之源，讲了现状，原因，产生的主要现象
现状：需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键
总体上说，我们的需求分析是做了，但是做得很不够：
我们做的需求只解决了我们能做出这样的项目；
但是没有解决这样的需求是不是真就是客户想要的。
原因：
客户本身说不清楚
需求自身经常变动
分析人员或客户理解有误
产生的主要现象：
需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。很多方案就是这样的。
需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。
需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能
对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。
总结：
a) 需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。
b) 需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。
c) 需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。
d) 需求分析报告对功能细节的描述不能有歧义，可以通过评审，用大家的力量来避免这种情况发生
e) 需求报告的每个关乎功能的描述都要让客户明白和理解
f) 需求报告一定要经过一个有技术人员和业务人员参加的评审
g) 帮助客户去理解提交给他的需求分析报告而不是只等签字
对于 需求过程本质与常见问题剖析
过程本质我感觉比较抽象，
过程是将输入转化为输出的一组有序活动的集合。
过程的描述信息往往封装了相应的知识，并且重用这些知识可以实现从输入到输出的转化。
过程描述的例子：
洗碗机的操作说明书
烹饪手册
银行业务的职工操作指南
软件开发的过程说明
过程可以分为：设计性过程和非设计性过程
不过过程的参与者还是比较不错的：
过程参与者是指过程执行中所涉及的人员
参与者一般按照其职能、岗位等进行划分
需求过程的参与者包括与目标问题及其解决方案相关的人员：最终用户、系统设计人员。
角色-动作图描述参与者、过程活动及其相互关系。
系统涉众类型
软件工程师：负责系统开发；
最终用户：产品发布后的使用者；
用户领导：负责管理最终用户工作；
法律/法规/标准：用于评判需求的合法性；
领域专家：提供应用领域的专业知识、背景信息、经验等。
需求过程的常见问题
缺乏系统涉众的参与
系统建设与当前业务需求脱节
缺乏有效的需求管理
职能划分不清晰、分工不明确
涉众之间沟通少、不畅、低效等
计划拖沓冗长
需求质量水平低
上午快下课时，老师讲了例子，说需求分析常见问题中的“系统建设与当前实际需求脱节”。一个立足广泛的需求调研，“农村电脑系统”，主要功能包括农科学院，媒体中心，家庭医生，的确，对于农村来说很实用的功能，而且使用简洁方便，结果，几十块钱一套，卖了几十万套，很实用，所以成功了。另一套是“酒店电脑系统”，希望放在酒店里给客人用，功能也很多很强大，包括，商务功能，电影，游戏，但是主要上网收费和财务问题，因为要记录客人的使用时间，要与酒店的财务相结合，但酒店的财务又不开放，上网费分成又赚得很少，得到了还不够维护成本，结果不符合实际需要，结果失败了。
下午，主要讲了Rational Rose的安装与简单使用，以前感觉Rose很笨重，不过可能都是重量级的分析设计建模软件，许多大的企业都用Rose进行分析，所以还是跟着老师学了一下，的确功能还可以。我觉得工具只是一个方面，主要学习一种思想吧，建模你用Rose，EA，还是Visio都可以，你熟悉哪个用哪个，哪个你觉得方便用哪个，我用C#开发，用EA还可以支持代码生成，很方便啊。
另外讲了一个面向用例建模的一些基础知识。就是用例分析技术的。
主要用Actor 和 UseCase，找出一个系统的参与者，每个参与者的用例，用例之间的关系，如组成，扩展，只要标明就行了。如购物包括付账，扩展的如购物的一个扩展查看清单，还有一种关系，泛化关系，如支付，可以有现金和信用卡支付。
另外用例要进行编号，要分包，包如P1,P2,P3
用例如UC1,UC2,UC3，Rose会自动编成 UC1:P1，感觉很清晰。
另外Actor，编号成R1,R2,R3xxx
用例Actor放在最顶层，要用的时候拖一下，很方便。
用户登录用例：
系统设置用例：
仓库管理用例：
第1天很快就完了，感觉还不错，挺充实。
搞笑一下，经过了第2天，第3天，感觉还是第1天的饭最好，菜也多，吃饭上是一天不如一天，不过吃饱还是没问题的，我反正每天都吃2碗饭的，第2天还喝了两杯啤酒。
