请问做需求时应该怎样与用户进行交流、进行怎样的交流,请各位谈谈自己的经验。

nie 2001-10-16 08:43:00
比如说,应该问些什么样的问题?我记得好想playcase里面就有一个什么需求分析单之类的东西!有没有这一类的模式呢?
还有,怎么样才能尽可能的让用户把它的需求谈清楚,我觉得好想很的用户根本对自己需求都不了解!
...全文
107 点赞 收藏 12
写回复
12 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
nie 2001-10-18
安装的话还需要许可文件,你的中文是哪的?
不会是自己翻译的吧!
回复
nie 2001-10-18
我下了rupc,说是中文,可是我直接看里面的html页面,还是英文的
回复
青润 2001-10-18
是的,我已经声明过这是rup中的“是RUP中关于需求研讨班的介绍”
回复
nie 2001-10-18
ok,让我先消化一下。
回复
WindowsMe 2001-10-18
中文rup记的在smiling电子小组UML的文件共享里见过,D下来后没怎么看

我做需求是很传统的那种,先了解用户目前系统的运做情况,特别是用户劳动重复繁重的地方。然后使用系统流程图和粗略的DFD与用户交流,确定方案后开始捉住用户一起细化DFD和数据字典以及一些比较关键的算法。最后都没什么问题了,就根据方案写份技术协议让他签个字 ;)
回复
nie 2001-10-18
我的rupc也是从umlchina上下载的,不过没安装,直接看的rupc\RationalUnifiedProcess2000\index.htm
回复
青润 2001-10-18
它的破解包和rose2001是一样的。
你下到的有多大?应该是五十多兆的文件包,里面应该都是中文的。我就是从umlchina上下载的。
回复
xxn_xxn 2001-10-18
先了解部分需求,做原型,继续了解需求,让客户试用,直到实现大部分需求。
以后逐版升级。
没有客户能真正知道他究竟需要什么,所以最好先有个样子,先操作一下,比开会讨论清楚许多。
不过时间和进度需要控制,不能让用户无休止地提出更正要求。
回复
Jack_Loo 2001-10-18
清润说的一套很科学.我来说说我们公司的一些做法.
1.正常,项目经理,业务支持,分析师和该项目的技术主管参与和客户进行的需求分析,而不是整个项目组所有成员.
2.需求会写进到合同中去.
3.立案的需求在以后的工程中正常都有修改的时候,如果要修改,就要有需求修改文档,由业务支持来和客户沟通,修改得到客户认可后,该修改文档正式编入需求文档中,生成最新版本.然后相应的将其余修改文档编入正式文档中.
4.编写需求中,较多的比例采用案例分析的方法进行.
回复
freebase 2001-10-17
qingrun(青润) :好像是RUP里面的东东?
回复
Jneu 2001-10-17
up
回复
青润 2001-10-17
我在另一个问题中给你做了回复,你过去看看,这里我给你一个例子,是RUP中关于需求研讨班的介绍:
工作指南:需求研讨班
目的
让项目团队与项目的涉众见面。
从项目涉众那里收集全面的“愿望列表”。
基于参加研讨班的涉众,对所收集的需求区分优先顺序。

工作指南:
集体讨论并整理提议,
制作示意板,
角色扮演,
复审现有需求


主题
准备研讨班
研讨班开始前
召开会议
整理结果
技巧
准备研讨班
举办需求研讨班就是将所有涉众集中在一起,进行一次深入的、有重点的会议。系统分析员担任会议的协调员。与会的每个人都应该积极主动,会议的结果应该立即让所有与会者看到。

需求研讨班提供应用其他获取技巧的框架,例如集体讨论、制作示意板、角色扮演和复审现有需求。这些技巧可以单独使用,也可以结合使用。所有技巧都可以与用例方法结合起来。例如,您可以为系统中预想的每个用例制作一个或几个示意板。还可以通过角色扮演来帮助您理解主角如何使用系统并帮助您确定用例。

需求研讨班的协调员需要为以下困难作好准备:

涉众知道自己需要什么,但无法明确地表达出来。
涉众可能不知道自己需要什么。
涉众认为只有您为其提供他们曾经说过的想要的东西,他们才能知道自己需要什么。
分析员认为他们能够比用户更好地理解用户的问题。
每个人都认为其他人是受小团体的利益推动的。
需求研讨班的结果记录在一个或几个涉众请求工件中。如果您拥有良好的工具支持,最好让涉众输入此信息。如果您选择在主角和用例方面讨论系统,您可能还要对用例模型进行概述。

研讨班开始前
协调员需要邀请应该参加研讨班的涉众,从而确定参加研讨班的小组。应该向参加者提供“热身”材料,供他们在到会之前阅读。协调员负责研讨班的后勤工作,比如发出邀请、申请带有会议所需设备的适当会议室,以及分发研讨班议程等。

召开会议
协调员主持会议,其中包括:

给每个人发言的机会。
确保会议不脱离正题。
收集关于适用的需求属性的意见
记录调查结果。
总结会议并得出结论。
整理结果
需求研讨班结束后,协调员与系统分析员需要花些时间对调查结果进行综合,并将信息精简为可介绍的形式。

技巧
下表列出了协调员迟早会遇到的一些问题和相应的推荐解决办法。用一组“票”来指解决办法,可能听起来没有必要,但在大多数情况下非常有效:

问题 解决办法
休息之后很难重新开始。 所有迟到的人都会得到一张“休息后迟到”的票,利用时钟来引起大家的注意,使用“慈善捐款箱”(比如说每次得到一张票交 1 美元)。
有针对性的批评:小偏见、小争执、耍手腕、没有意义的攻击。 “一张免费的没有意义的攻击”票,“好主意!”票。
故作姿态、态度专横、参与者的发言时间不平衡。 采用训练有素的协调员,将发言限制为“五分钟情况陈述”。
午餐后精神不振。 安排清淡的午餐、休息、咖啡、苏打水、糖果、甜点,重新调整会议室、改变房间温度。
回复
相关推荐
发帖
研发管理
创建于2007-08-27

1221

社区成员

软件工程/管理 管理版
申请成为版主
帖子事件
创建了帖子
2001-10-16 08:43
社区公告
暂无公告