51Testing软件测试论坛

标题: 如何学习掌握用户需求？（09-1-12）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2009-1-12 17:21
标题: 如何学习掌握用户需求？（09-1-12）（获奖名单已公布）

客户的参与是发布一个优秀软件的关键因素，在项目的开始阶段就应该努力致力于为你的项目征求各个客户的意见。软件需求的成功，和软件开发的成功都取决于开发者是否尽可能地采纳客户的意见。为了征求客户的意见，我们该如何学习/快速掌握用户需求？

感谢会员zero_up提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	rolei	当当购物卡50元	4#
二等奖	wxm2004734	300论坛积分	3#
二等奖	luoyear	300论坛积分	25#
三等奖	老肥羊	100论坛积分	28#
	阿七		10#

作者: 橙色苹果 时间: 2009-1-12 22:03
标题: 初学者回答
在项目一开始就介入项目，其实测试就应该在一开始就介入，比方说各种文档的审查，就需要测试人员参与，评审！了解各种文档的设计，比方说测试计划，概要设计，详细设计等，从中了解用户的需求。还要看需求说明书！问问需求人员或业务人员。

作者: wxm2004734 时间: 2009-1-13 09:02
软件生命周期

1.萌芽阶段 2.定义阶段 3.具体阶段 4.设计 5.开发 6.测试 7.试运行 8.上线

1-2：产品概念的明确，有哪些模块？大块功能？特性功能？
如何：
s1.学习相关领域知识，！！必须地！！；
s2.了解产品客户群，具体产品使用角色，该角色在真是生产中的工作流程，哪些可能需要在产品中哪些？！重要！
s3.明确项目组可以做到功能范围，包括大概的量、技术实现等。了解一下。

3.明确产品的明细需求，该出需求规格说明书了。
s1.能参加的会尽量参加。和客户的总结、确定的会议必须参加。重要的发散思维的会，俗称头脑风暴，可以参加。
s2.尽量在此阶段，把用例图（谁在什么地方做了什么事情）都画出来。工具，推荐visio，门槛低，半天就会。
s3.业务流程图，visio。

4-5.需求实现阶段，需要！确认！是否符合需求！（V&V不明确的，google一下）
s1.周例会、阶段确认会议
s2.如果项目在尝试AGI，客户在此过程的参与程度就是决定产品成败的关键。

6.好好做一个UAT或者SIT的流程或用例吧，一切都解决了。
s1.用例的REVIEW，一定叫上客户。尽可能。
s2.UAT，叫上特定客户。
s3.整理客户的话，这些可能成为变更或者下一期的需求（公司口水ing……）。
s4.不明白的一定要！！问！！，开发是第三者，项目经理、顾问是第二者，客户是第一者，尽量靠近吧。（不会提问的测试我从来不招）

7.类似上一阶段，客户在用了。
s1.整理客户的话，这些可能成为变更或者下一期的需求（公司口水ing……）。有个不恰当的形容，“尽孝”，片面解释一下。

8.上线，变更貌似不在了，总结吧。如果有，参照上一阶段。

忏悔：写的比较真实、简单、实用。针对测试（咱这不是测试论坛嘛）。欢迎大家拍砖。

[ 本帖最后由 wxm2004734 于 2009-1-13 10:28 编辑 ]

作者: rolei 时间: 2009-1-13 09:17
标题: 学习，反思，掌握客户需求
1、与客户保持密切关系－－关键
1）多与客户交流，切忌闭门造车。（不能见实际客户，就多与需求人员交流吧，多思考，多提问题，多理解）
2）多与实际应用的客户交流，软件的目的是为了方便使用。如果只是为了满足某些高层的需要的软件，真正应用时的实施将是一个大麻烦。
3）如果条件允许，跟终端客户工作一段时间，了解他们要使用这个软件的原因，基本需求、操作规程等。（这个方法对理解实际需求很有效）
4）将客户拉入自己的开发团队，与客户工作在一起，不断的与客户学习，不断的争求客户意见。（客户应该是开发团队的一员，应该为自己将要使用的软件负责）

2、从用户和专业化角度理解需求－－快速学习和掌握的基础
1）想用户之所想，急用户之所急。
2）站在客户角度想问题，对每一个问题多问几个为什么。
3）努力成为行业专家，当你成为了行业专家，对需求的理解将会站在更高一层面想问题。

3、尽可能早的了解用户需求，在不断的开发推进中深化对需求的理解。
1）加强团队内部沟通、需求评审、问题讨论，从不同的角度、不同岗位去看待和评审需求。（最好是有客户进行答疑）
2）太晚了，除非你是行业专家，否则很难跟得上用户的需求。

只有在不断的深入交流、学习、思考中，才能快速、有效、全面的理解和掌握客户需求。

[ 本帖最后由 rolei 于 2009-1-13 09:24 编辑 ]

作者: yunyan 时间: 2009-1-14 13:53
学习/快速掌握用户需求的两个工作:
第一:准备工作
1.必要的业务知识
2.需求说明书
3.与需求人员的沟通
第二:分析整理
1.以需求说明书为基准,业务知识与需求沟通为辅助分析需求.
2.整理需求

写的有些笼统,希望大家来拍砖!

作者: binlove1 时间: 2009-1-14 15:10
严谨思路，换位思考！

作者: 海福 时间: 2009-1-14 15:17

作者: maclehappy13 时间: 2009-1-14 15:45
1、多与客户（需求提出人）沟通，通过沟通了解与引导客户提出真正需求；
2、多与项目相关人员沟通，保证对需求的理解正确，与其他人理解一致；
3、跟项目最终使用者沟通，了解项目要解决的问题，如有必要可以参观或参与最终用户要通过项目解决的问题的手工解决过程；
4、阅读项目的相关资料；
5、从软件标准角度以专业化角度了解非功能性需求；
6、学习行业业务知识；

个人想法，抛砖引玉。

作者: EVA1987 时间: 2009-1-14 15:49
根据所学我也总结一下吧！
从需求获取来说，主要是与项目客户和实际用户之间的交流，相关合同和一些本质需求图文资料，并且在此之前，相关人员需要对项目的业务流程进行熟悉，在获取需求信息时要明确了解对方的根本需求，从而可以尽可能多的了解到用户的实际需求。
从需求分析阶段来说，需求分析人员首先要对项目业务流程掌握清楚，能根据客户的显示需求尽可能全面的分析出隐式需求。
需求跟踪遍布整个软件生命周期，对于需求的变更可谓牵一发而动全身，所以尽可能早的将需求明确是很有必要的。
虽然没有实战，但是可以理清思路，我认为需求是软件的灵魂，没有需求其它都是空谈。纸上谈兵，希望自己可以在实战中验证一下。也希望大家能多多提点一下！

作者: 阿七 时间: 2009-1-14 16:31
标题: 答题目
软件需求包括三个不同的层次—业务需求、用户需求和功能需求.
业务需求
反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
用户需求
描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。
功能需求
定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。
[attach]48724[/attach]
由此,可以看出用户需求是业务需求的具体体现,又是作为功能需求的补充.所以,用户需求的准确性是非常重要的.
我个人觉得对用户需求的把握要从这几方面入手.

1 了解客户的需求观
有的客户(如专门是负责管事的,但是和别的公司谈需求却是出面人)提出对软件的需求,其实是业务需求层面的,但是客户却坚信他提出来的就是想要的结果,但是这对软件制作方只是说明了整个项目的概念与目标,而对业务目标所需的各种功能和用户的要求等细致的功能面上是没有实际的指导意义的.所以在讨论需求的时候,要先了解客户的需求观,最好是从最终使用软件的客户处提取需求,因为只有最终使用者才明白自己想要的是什么样子的.

2 客户与开发人员之间的合作关系
优秀的软件产品是建立在优秀的需求基础之上的。而高质量的需求来源于客户与开发人员之间有效的交流与合作。通常，开发人员与客户或客户代理人，如市场人员间的关系反而会成为一种对立关系。双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦，在这种情况下，不会给双方带来一点益处。
只有当双方参与者都明白要成功自己需要什么，同时也应知道要成功合作方需要什么时，才能建立起一种合作关系。由于项目压力与日渐增，所有风险承担者有着一个共同的目标这一点容易被遗忘。其实大家都想开发出一个既能实现商业价值，又能满足用户需要，还能使开发者感到满足的优秀软件产品。

3 客户的义务和权利
客户有如下权利：
1. 要求分析人员使用符合客户语言习惯的表达。
2. 要求分析人员了解客户系统的业务及目标。
3. 要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。
4. 要求开发人员对需求过程中所产生的工作结果进行解释说明。
5. 要求开发人员在整个交流过程中保持和维护一种合作的职业态度。
6. 要求开发人员对产品的实现及需求都要提供建议，拿出主意。
7. 描述产品使其具有易用、好用的特性。
8. 可以调整需求，允许重用已有的软件组件。
9. 当需要对需求进行变更时，对成本、影响、得失有个真实可信的评估。
10. 获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。
客户有下列义务：
1. 给分析人员讲解业务及说明业务方面的术语等专业问题。
2. 抽出时间清楚地说明需求并不断完善。
3. 当说明系统需求时，力求准确详细。
4. 需要时要及时对需求做出决策。
5. 要尊重开发人员的成本估算和对需求的可行性分析。
6. 对单项需求、系统特性或使用实例划分优先级。
7. 评审需求文档和原型。
8. 一旦知道要对项目需求进行变更，要马上与开发人员联系。
9. 在要求需求变更时，应遵照开发组织确定的工作过程来处理。
10. 尊重需求工程中开发人员采用的流程（过程）。
作为项目计划的一部分，客户和开发人员应评审上述两张列表并达成共识。一些很忙的客户可能不愿意积极参与需求过程（也即，他们不太接受软件客户需求义务书），而缺少客户参与将很可能导致不理想的产品。故一定要确保需求开发中的主要参与者都了解并接受他们的义务。如果遇到分歧，通过协商以达成对各自义务的相互理解，这样能减少今后的摩擦（如一方要求而另一方不愿意或不能满足要求）。

4 寻找客户的需求
1. 访问并与有潜力的用户探讨,与产品不同用户类的代表进行沟通
2. 把对目前的或竞争产品的描述写成文档
3. 系统需求规格说明,明确使用该产品的不同类型的用户
一个包含软、硬件的产品需要一个高档次的系统需求规格说明以介绍整个产品。
4. 对当前系统的问题报告和增强要求
指导用户和提供技术支持的工作人员是最有价值的需求来源。他们收集了用户在使用现系统过程中所遇到问题的信息，还接受了用户关于系统改进的想法。
5. 市场调查和用户问卷调查
6. 观察正在工作的用户
7. 遵从项目的最终决策者的意见。

5 聆听客户的需求,加以补充和扩展,发散思维
1. 定义项目的视图和范围
2. 确定用户类
3. 在每个用户类中确定适当的代表
4. 确定需求决策者和他们的决策过程
5. 选择你所用的需求获取技术
6. 运用需求获取技术对作为系统一部分的使用实例进行开发并设置优先级
7. 从用户那里收集质量属性的信息和其它非功能需求
8. 详细拟订使用实例使其融合到必要的功能需求中
9. 评审使用实例的描述和功能需求
10. 如果有必要，就要开发分析模型用以澄清需求获取的参与者对需求的理解
11. 开发并评估用户界面原型以助想像还未理解的需求
12. 从使用实例中开发出概念测试用例
13. 用测试用例来论证使用实例、功能需求、分析模型和原型
14. 在继续进行设计和构造系统每一部分之前，重复 6 ~ 1 3步

6 使用实例的方法(类似于界面原型的功能)
使用实例方法给需求获取带来的好处来自于该方法是以任务为中心和以用户为中心的观点。比起使用以功能为中心的方法，使用实例方法可以使用户更清楚地认识到新系统允许他们做什么。在许多We b开发工程中，用户代表发现，使用实例的方法真正有助于他们弄清 We b站点的访问者可以做什么。使用实例有助于分析者和开发者理解用户的业务和应用领域。认真思考执行者—系统对话的顺序，使其可以在开发过程早期发现模糊性，也有助于从使用实例中生成测试用例。
[attach]48725[/attach]

7 阿七签名专用...嘿嘿

其实大家都可以这样想啊,客户花钱叫你们做东西,你们给他们做出来,双方都是想吧这个东西做好的,他那边可以用,你们这边可以拿钱, 如果需求没做好,做出来的东西不好使,他那边用不上,你这边返工还拿不到钱,互亏的事谁都不想做撒,所以原则上大家都是想做好的,那么就要沟通了,他那边提要求,你这边配合加引导,错误的可以交流和纠正,我看见有的朋友说,客户啥都不知道,说空话,那么你就可以给他定性嘛,他要是不知道,你给弄好了,他是很认同你的,认为你很专业,反过来说这也是你又一次学习的机会了.平常心,平常心哈.
虽然我现在没怎末做产品,弄需求,不过我也一直在学习这方面,我以后的打算也是往需求这方面靠,希望大家有什么好经验,好的经历都可以拿出来分享,呵呵!

[ 本帖最后由阿七于 2009-1-19 16:51 编辑 ]

作者: 多米尼克 时间: 2009-1-14 17:16
我觉得很难

很多时候只有用户在真正使用一样东西的时候，才知道他需要什么，不需要什么，如果只是叫他凭空说的话，用户也说不清，或者不能在有限的时间内说清自己的需求，会造成后期的需求不断变更，和项目时间的延长，人力和物力的过多消耗。

所以需求分析师的职位才如此重要，他必须要了解用户真正想要什么，定位产品。需求分析师要有丰富的产品和市场经验，对流程，用户的操作习惯都要相当的熟悉

作者: 志大才疏 时间: 2009-1-14 17:43
学习应来自于理论和实践理论：书籍、文档、视频等相关资料；实践：当然就是实际操作。
掌握：一、与用户进行有效的沟通；二、对用户的需求进行准确的分析。方能等到用户的原始需求，说的简单，做起来还是确实不易的。

作者: hukongli 时间: 2009-1-14 20:42
标题: 初学者
需求是解决用户问题或达到用户目标所需要的条件或能力，客户或用户是根据自身环境需要作出的要求，目的是使自身使用方面。也就是说软件在开发过程中有很大的易变性，特别是在产品开发初期。此时，我们如何了解和掌握准确的需求，这就要与客户或用户及其其他成员要时刻相互沟通，理解。为此，我们可以到客户实际环境下与客户一起分析需要软件实现什么样的功能？该要什么和不该要什么。反复的验证，反复的了解用户到底需要什么样的需求。这样我们就在第一时间掌握用户的需求。如何学习且快速的掌握用户需求那就是与用户之间的沟通，理论与实践相结合。当然还要有深厚的技术支持啊！

作者: qinxiaocang1202 时间: 2009-1-15 15:57
初学者：
（1）到客户工作的现场去看，去听，去交流；
（2）了解客户从事行业的知识；
（3）因为用户的描述并不是从如何开发考虑的，所以要会听，知道哪些才是开发的关键；
（4）也要多和开发人员进行沟通；
（5）分析人员也可以根据自己以往的经验判断用户的需求；

[ 本帖最后由 qinxiaocang1202 于 2009-1-15 16:00 编辑 ]

作者: qinxiaocang1202 时间: 2009-1-15 16:02
标题: 回复 4# 的帖子
支持哈，总结的很好！！

作者: dodollss 时间: 2009-1-15 16:14
1立即对客户的工作环境和工作需求进行现场的调查观察和简单的小组制的讨论。
2在单位内部针对上述分析的理念和结果进行问卷调查以进行快速有效的总结。

作者: yetties2005 时间: 2009-1-16 10:21

原帖由 rolei 于 2009-1-13 09:17 发表
1、与客户保持密切关系－－关键
1）多与客户交流，切忌闭门造车。（不能见实际客户，就多与需求人员交流吧，多思考，多提问题，多理解）
2）多与实际应用的客户交流，软件的目的是为了方便使用。如果只是为了满足某 ...

写的很好。

作者: silverchan2006 时间: 2009-1-17 20:44
标题: 回复 1# 的帖子
1.扎实的专业基础=“牛”的技术能力+良好的沟通协调能力。因为掌握用户的需求，本来就是一种的沟通，单单凭借着一身很牛的技术是行不通的；个人认为如果在坚实的技术上加上良好的沟通能力，那应该会加快掌握用户需求。
2.多从客户和软件的最终用户的角度看待问题，不要只从纯粹技术上想。
3.有条理地客户提出要求和问题，并对改记录组织人员进行讨论分析。

作者: chengxq 时间: 2009-1-18 15:43
1.对于用户需求不理解或理解错误，原因有很多，但最根本的就是沟通存在了问题，没有将客户需求转化为我们的产品需求，有的是时候，客户提出了进度等要求时，在没有很好的理解客户需求时，就盲目的开始做设计、编码工作，导致了在需求在没有确定下来，就先入为主的判定需求
2.对于出现的问题，我们应该不能希望与与客户的沟通，应该讲究一些方法和策略，将成功的理解客户需求的项目，进行分析，看是如何搞定的，应该将这些经验总结起来，作为公司的资产，供以后项目的使用
3.组织级流程的制定，组织级应该规范，在需求开发的标准过程，将以前好的项目的过程进行积累，作为项目需求开发的标准，以后的项目在此基础上进行裁剪
4.在需求理解阶段，要做好和客户的沟通计划，在什么时候，沟通什么，怎么沟通，沟通的方式是什么，这些东西最好定义好，最好在项目的每个阶段，每个过程都让客户参加，让客户进行确认，现在很多项目都按照原型进行了开发
5.人员的确定，在需求开发阶段时，要注意人员的确认，最好有相关经验的人参加需求的开发

作者: namisang 时间: 2009-1-19 09:30
学习一下．

作者: namisang 时间: 2009-1-19 09:30
学习一下。

作者: believe 时间: 2009-1-19 12:16
1.在用户角度,对需求彻底分析、理解，对有疑问的及时与用户（多个用户）沟通
2.对行业的特性、现状及将来发展目标，也要了解、分析
3.对用户群也要分析

作者: jian12278 时间: 2009-1-20 15:57
学习下

作者: twinsczl 时间: 2009-1-20 19:33
站在客户立场上看问题！
和客户多交流！
没技巧可言！

作者: luoyear 时间: 2009-1-31 15:10
这个问题有太多的场景，针对不同的场景也有不同的答案。我就选择其中一种和大家探讨一下：
项目开发过半，项目组内部已经开始集成，集成测试在即，尚未组建测试团队。在这种情况下，测试团队如何快速熟悉系统需求？

在这种情况下火烧眉毛，肯定是要从人和管理上去下功夫。
首先是团队的组成，最理想的方式是选择有相应行业经验的或者相对资深的测试人员组成核心测试团队负责测试设计工作，系统组和需求组人员协助指导和评审测试策略和测试设计；
其次，最快的知识传递的方法肯定不是看文档/使用和学习系统，肯定是人类最原始最直接的方式：口头沟通。一般建议组织系统设计或需求人员讲一下系统结构和主要功能点；
第三，在工作中学习，现实的压力加速了解需求。在初步掌握系统结构和系统的主要功能后，按照功能模块划分让各测试人员列出测试要点，在逐步的测试设计中了解需求；
第四，基于初步的测试要点开始测试工作，同时开始补充设计测试case和交叉评审测试设计。对于E2E的case，可以由需求人员协助先整理一些场景。

作者: ahu201 时间: 2009-2-2 12:03
标题: 拿把刀
小样...你不说清楚今天就别想走着出去...

作者: archonwang 时间: 2009-2-2 14:44
标题: 回复 25# 的帖子
老罗失踪好久了。。

作者: 老肥羊 时间: 2009-2-2 14:51
如何學習/快速掌握用戶需求?
我覺得,這個問題主要的解決在學習,快速掌握這幾個字上面.
看了上面眾多樓的回覆,注意到大家都忽略了一個問題,就是測試人員自身的知識范圍,理解能力,學習能力,知識搜索速度,知識學習速度等等各種很難處理的人自身的問題,在很多的時候,文檔也有,客戶也會比較的配合,但局限於測試人員自身的能力的問題,會出現很多的問題.
引用<<咨詢的奧秘>>一書中的結論"在整個系統的行為裡面,一般情況下,都是人的問題"
掌握一種學習方法,或者從自己多年的學習經驗中不斷的總結出自己的學習方法,有些人習慣於一目一行的看,有些人習慣於一目十行的看,至於是一行的效果好,還是十行的效果好,因人而異.
掌握準確的理解的方法,這個最常見的例子就是口令快速傳遞的時候,經常會發現第一個傳出的人與最後一個收到的人有千奇百怪的差別,中間為什麼會出錯?百分之九十九屬於理解準確率的問題,所以這就有一點,用更準確的詞語來描述自己碰到的問題及向客戶提出的問題,更快的找出客戶語言或文檔中的不明確,不準確的位置,並進行尋味.
掌握準確的表達方式,如何更有效的表達?如何更準確的表達?有一本書名字叫<<談話的力量>>,同一件事情,不同的表達方式可能會造成天地之別,選用更合適的表達,會更容易掌握到用戶的需求
很多人提出說看需求文檔的效果不如與用戶口頭交流的效果,在某種程度上確實是這個樣子.但是有沒有想過一個問題,A(客戶)腦袋裡面想的需求是A,口頭表達出來的是A-,接收人接收到的信號為A--,當接收人經過自己的大腦處理之後,很有可能變成了A---,再由接收人寫成文檔的時候會變成A----,這個時候,可能已經與客戶的原始需求相差很多,我只是想說明,很多時候,並不是從文檔交流變換為面對面交流是一種更好的方式,如果客戶更擅長於面對面交流,那需要選一個擅長面對面交流的需求分析人員去,如果客戶更擅長於用文檔表達自己的需求,那麼可能選一個擅長面對面交流的需求分析人員,會造成很大的問題...
借一句古話,工欲善其事,必先利其器,在學習/快速掌握用戶需求這個事情上面,我們的器就是測試人員,或者是我們自身,提高自身的種種能力,素質,才會善於學習/快速掌握用戶需求這個事情.

作者: maggiegrubby 时间: 2009-2-2 17:33
1 找到真正的操作员，了解她的工作流程，工作方式
2 尽可能全面的搜集相关的纸质表单
3 与用户领导协商召开例会，最好每周一次，进行软件实施情况的反馈，具体的操作人员或用户代表需要参加。如果领导太忙不能参加，最好多利用其他时间与其沟通。理解领导想要达到的真正的目的。
4 不要一下子做的东西太多，从最基本的东西，不会变的东西，一点点做起。这个可以和具体的操作人员沟通。这样在对业务逐步熟悉的过程中，逐步完善系统。
5 最初的需求讨论会议，每周的例会，测试人员参与旁听。
6 开发人员开的概要设计、详细设计讨论会议测试人员也尽量参加。
7 测试人员深入需求的理解，个人认为了解系统的数据库结构很重要。以及数据流的走向，最好能自己画画图，这样可以比较快的深入到系统内部。

当然认真学习需求分析文档这些事情，就不再赘述了。

作者: 猫猫的拖鞋 时间: 2009-2-3 11:40

作者: yzylion 时间: 2009-2-3 14:34
阿七的和老罗的说的不错，学习了

作者: mfhmfj 时间: 2009-2-4 16:18
perfect

作者: sy123456 时间: 2009-2-5 16:53
初学者：总结的好。支持

作者: huifeituzi 时间: 2009-3-10 15:46
学习了，我是个初学者，大家讲的很好

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)