Forest Gump(78***43) 15:22:23
潘老师，在需求人员和业务部门确认需求时如何更好的使用UML，减少确认会议次数（目前业务部门对需求确认基本不重视，但是对界面确认的非常细），但是我们这边是需求由甲方写，界面设计是乙方的工作。
刘黉(187***16) 18:42:26
那就让乙方亲自和他们谈
潘加宇(3504847) 19:35:45
课上讲过的：把视图和模型分开，把行政和开发分开
UML（模型）是帮助软件开发团队内部交流和思考的，涉众喜欢用什么方式（视图）交流就用什么方式交流。
"需求人员和业务部门确认需求"属于行政，"确认"了也不代表什么
"业务部门对需求确认基本不重视，但是对界面确认的非常细"--就在这个约束下，尽可能把责任承担起来。
如果把问题转换成"潘老师，在医生和病人家属确认病情时如何更好的使用医学谱图，减少确认病情的协商次数，目前病人家属对病情确认基本不重视，但是对病人的脸色变化非常敏感"
可以再复习《软件方法》第一章1.7和第七章
Forest Gump(78***43) 19:52:37
好的，谢谢潘老师，我明白该怎么做了
千里观澜(168***047) 1:04:32
潘老师回答妙啊！
hawk(33***970) 12:25:10
这个比喻好
TrueMan(122***781) 13:36:02
我这两天让一个需求分析师跑现场去观摩业务处理流程和内容。。。让他呆个几天，彻底摸清了，才能做需求分析。。。
TrueMan(122***781) 13:36:32
需求调研，万万不可蜻蜓点水。。。
TrueMan(122***781) 21:14:32
其实做需求调研，要求是经验最丰富的人参加
TrueMan(122***781) 21:16:48
否则，让没有多少经验的人调研，很可能问题一大堆
行者(315***850) 21:16:12
现在软件开发有很多本末倒置，宁愿后来找一堆程序员一遍遍的改 ，也不愿初期多花些资源
潘加宇(3504847) 7:21:06
不是愿不愿，而是能不能，需求是一种技能，不是说"我愿做"就能做好的，需要学习。哪个医生不知道先诊断好病情再开药，可惜这个医生是护士提拔的，就学过怎么打针，她"愿意"诊断也没效果，要学。
潘加宇(3504847) 7:21:17
系统的质量不可能比需求好。如果需求出了问题，在后面的工作流可能需要上百倍的成本来修正它，所以需求是软件公司最值得改进的环节。这个道理大多数软件组织是懂的，即使有的组织暂时不懂，碰壁之后也很快就会意识到。于是领导下定决心，"下一次要重视需求的采集"。
可惜需求不是蘑菇，乖乖地躺在森林里。开发人员无法象采蘑菇的小姑娘一样，一个，两个，三个，四个…把它们都采回来。很多时候开发团队也匀了时间来做需求，但一拨人到了客户那里，也不知道具体该怎么做，随便看看，问一些问题，开个会，就不知如何往下走了。开发人员只好自己"头脑风暴"，胡乱猜想系统的需求，草草写出用例，然后投身于最擅长也最喜欢做的事情――设计和编码。
……

需求不是蘑菇。开发人员要能够象猎人一样，用锐利的眼睛发现隐藏在丛林中的猎物；象侦探一样，用慎密的思维判断出伪装成好人的凶手。而这些，都需要学习。
--潘加宇《需求不是蘑菇》
行者(315***850) 7:59:36
说起头脑风暴，有个公司和客户交流的时候总喜欢派十几个人去，客户调侃我们说你们这是来打群架，哈哈。
回来的时候还要评审，十几个人天天占着会议室，好多人完全不懂，扯什么界面呀，字体呀，排版呀，语句不通呀，场面那个乱啊。
81561136(815***36) 8:10:29
所谓需求，人性使然
行者(315***850) 8:18:09
就是，就是，那场面我想起我孩子的幼儿园。双击查看原图，人性被无限制的流露出来了
刘黉(187***416) 8:36:18
怎么流露出来了？
行者(315***850) 8:54:19
童言无忌，天真无邪
肖威(47***80) 9:32:40
潘老师的 需求不是蘑菇 典型的是我们公司的现状。好久都没有一点改善了