`
jiangduxi
  • 浏览: 459129 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
社区版块
存档分类
最新评论
阅读更多
  现在越来越发先一些开发对需求获取过于泛泛。什么叫泛泛呢?其实中国人喜欢中庸。也听说过易经。在生活中处事不反对中庸。但是在获取需求和分析的时候坚决反对这种中庸。

  给个需求获取的场景:
 
引用

    一天一家裁缝店接到一个贵宾的电话,要在这个家裁缝店做一套衣服。但是不巧的是该店之前上门获取客户需求的人B不在,这是老板只好叫了小A去上门获取客户的需求了。(下面是小A 和 Customer的对话)
 

小A:  老板你想做什么
Customer: 我想做一件衣服
小A:  那我给你量尺寸吧!
Customer: 好
小A:三维分别是:29,28,31。于是小A就带着三维回到店里交给做衣服的人进行按三维做衣服。

当小A交货的时候:场景如下
小A: 老板你的衣服做好了,你试试看合身不!
Customer:怎么你用的不是棉布啊,怎么没给我的裤子放长一点啊。衣服好像有点紧啊!这不料不适合我!。。。。
小A: 你当时这些没告诉我啊!我是一般的规格给你做的啊!你还你还是穿起来提合身的嘛!
Customer: 你当时没我还有什么啊,再说了我以为你明白我想要的啊!

点评: 通过上面的场景发现小A在获取需求的时候,不完整而且能不能收到客户的款还是一个问题了。这个过程由于小A对客户的需求获取不周全导致这个场景很容易发生不愉快的事情。


下面看看B的获取分析过程:场景重现
B:  老板你想做什么
Customer: 我想做一件衣服
B: 那你想要冬天的还是热天的呢? 
Customer: 冬天
B: 你是想要这件衣服是做什么事情的时候穿(平时,参加聚会)
Customer: 平时
B: 那你平时冬天的衣服是希望紧凑点还是松散点
Customer: 松散点,因为怕冷想多穿几件衣服
B: 你一般冷天穿几件衣服呢?
Customer:一般3件,最多5件
B: 那你喜欢用什么布料呢!
Customer: 最好用丝的吧,
B: 那你喜欢什么样的颜色呢?
Customer: 浅蓝色或者浅红色
B: 我们店有一批不错的是浅红色的丝,那用浅红色的吧!你认为呢!
Customer: 好吧!不过我可不可以看看。
B: 没问题。你还有什么其他的要求吗?
Customer: 暂时没有:
B: 那我给你量下三维吧!你的三维分别是:29,28,31。到时候我们给你做的衣服三维是按照这个的基础上(+-0.5)你看怎么样!
Customer: 没问题。
B: 那今天先这样,到时候给你电话来我们店里试穿下衣服。
该需求获取基本上结束。下面进入一个试做和试穿的过程(开发原型)
B: 你好,有没有空?来我们店试穿下你上次订做的衣服
Customer:好的!不错!但是我觉得黑色的颜色好像更好看点。(用户开始进行需求变更了)
B: 不过上次我们交流的时候,我们说好的是浅红色啊。再说浅红色穿起来你看起来不错啊
Customer: 哦,那没关系了。看起来挺合身的。不过能不能在袖子上加些扣子
B: 不过这可能会增加这件衣服的费用!
Customer: 那没关系
B: 你想加两排扣子还是一排扣子或者其他什么样子
Customer: 我想在袖子上加两排扣子
B: 每排加几个扣子呢?
Customer: 3个
B: 好的。那还有什么要求没!
Customer: 没有了!
B: 下次我将专程将做好的衣服送到你家!
Customer: 好的
整个场景到处停一个段落:因为原型基本上完成,新增需求明确。上面这个场景可能不能很好的来说明需求获取和分析。但是能够得出如下
总结: 对于获取需求和需求分析,必须将一些模糊的词进行量化;比如大、小、几,多,高。。当客户说到这些的时候,最好能够得到一些具体的数词或者一个范围比如最少3件最多5件等等如果在需求或者和分析中出现模糊的词越多那么风险越大。在你无法更好的获取到需求的时候,请先将这些模糊的词进行量化。

希望可以来交流下,下次如果有需要将发帖给出通过需求到设计分析这个过程中的注意事项。同时也可以结合UML的一些图。前提是有朋友一起来交流或者要求!

分享到:
评论
28 楼 nininia 2011-01-18  
为什么现在需求都分析不清楚啊,我觉得不是成本问题。是现在的一个通病,需求人员的错误不是自己来弥补的,是开发人员用时间和加班给他擦屁股的。开发人员除了日外包,哪一个人在开发过程中,没遇到需求矛盾或者模糊的时候啊,你去问需求人员,他告诉你的过程,试问是不是一个他知道自己错了的过程,如果开发人员忽视这个需求错误呢,用户以后提出来,谁来改。说不定开发人员的上级还要说开发人员不够认真呢,这就是需求人员犯错没事。所以需求人员不用想太多的原因,多跟用户在没有程序界面的沟通下,那么难吗??
27 楼 ppgunjack 2011-01-17  
客户过来说做衣服,不给客户切二两肉的裁缝就算合格了
国内的公司跟着项目跑,跑需求的不懂实现,实现的不会面对客户,屠夫拉着当厨子,厨子拉着当马夫的多了,不用期望自己或者下属能当个类型2的裁缝,何况有些客户可能进了你的裁缝店开口就是来两斤肉
有能力能出快速原型的裁缝,不管是裁缝1还是裁缝2只要聪明点的都基本够摆平项目了
真要做需求,想办法弄几个老外的顶尖产品或者挖几个墙角研究研究,需求就解决一大半了
老外是产品驱动项目,边做产品边做标准,用标准裁剪需求,买了我第一代,你就得买我第二代
国内大多是项目驱动产品,人脉决定单子,吃了上顿没下顿,打枪换个地方
区别的本质原因就是国外好的企业sa,顾问都是1,20年工作经历的行业尖子,实现、业务和眼光俱佳,国内很多都是5-10年游击队,简历很耀眼,实现能力很狗血
26 楼 anky_end 2011-01-15  
gtssgtss 写道
amwiacel 写道
jiangduxi 写道
前一段时间面试过一个需求分析师的岗位,最后一个技术总监说需求分析需要有3年-5年的架构经验!大家也可以谈谈如果招聘需求分析该具备出业务,架构熟悉外的其他要求吗?


需求是业务活!那人讲的架构是业务还是技术?他是技术总监,那应该是系统架构吧!首先,这是二码事情,二来,他要懂业务和技术都熟悉的人!可是,真正有这料的人,难找!


不懂技术谈需求?谈完开发人员说实现不了,等着赔钱?

纯粹从技术上来说没有实现不了的,几乎可以这么说
唯一是看成本

公司够大往往需求人员是精通业务
但是小公司往往随便凑人

25 楼 gtssgtss 2011-01-06  
amwiacel 写道
jiangduxi 写道
前一段时间面试过一个需求分析师的岗位,最后一个技术总监说需求分析需要有3年-5年的架构经验!大家也可以谈谈如果招聘需求分析该具备出业务,架构熟悉外的其他要求吗?


需求是业务活!那人讲的架构是业务还是技术?他是技术总监,那应该是系统架构吧!首先,这是二码事情,二来,他要懂业务和技术都熟悉的人!可是,真正有这料的人,难找!


不懂技术谈需求?谈完开发人员说实现不了,等着赔钱?
24 楼 sleepinglord 2011-01-06  
lz的例子问题很大。我以为,情况大概应该是这样的(另一个学徒C去见客户)


C:老板你想做什么?
客户:我想做件衣服。
C:什么样的衣服呢?
客户:我也不是很清楚,只是我下星期要出席一个聚会,想做件新衣服。
C:有什么特别要求么?是晚礼服还是?
客户:不是很庄重的聚会,晚礼服就不必了,但是要显得精神一些,年轻一些才好。
C:颜色呢?
客户:嗯,不要太艳了吧。
…………
C获得了客户的尺寸以后,提出希望客户到店里去找一些衣服来试试看。
等客户到了店里,试穿了七八件衣服,仍然觉得不满意,但也都是些“这个是不是太老气了?”“这个蕾丝不好看,换一种样子。”这样的意见。
…………
后面的故事用软件的话就是,不断地提供原型(这个在裁缝铺来说成本太高了,但是在软件中太常见到),客户不断地提意见,最后才敲定某种样式。即便如此,做出来以后,客户仍然会提出“我需要配我新买的那条围巾,希望能在某些方面改改(仍然不会有具体整改意见)”这样的修改意见。

我想说的两件事是:
1.指望需求收集人员精通业务是不现实的:一方面太多的需求收集人员可能对业务了解仅限于表面,甚至一知半解;另一方面太多的业务你不真的去干上一年半载,根本无法了解。
2.我认为,在lz的例子里,A和B没有质的区别,只有量的不同。B因为比较熟悉业务,因此能在一开始提出更多的问题。但我以为需求最大的特性在于变化,永远不要认为收集到了全部的需求,也不能指望一次性地想到所有问题,即便你是个老裁缝。与其把精力放到一开始的全面,不如把精力放到如何适应变化。

据此,我的观点是:
1.用户通常不知道自己明确地想要什么,需要你引导用户来提,逐步引导用户说出他心中所想并明确之,而不是根据你的知识和经验来做问卷式的调查。你更多应该是倾听者的角色。
2.需求收集不是一蹴而就的,是一个长期的,变化的过程,因此应该拥抱变化,提高快速适应能力。
3.业务能力的提高是必要的,快速学习也是必要的,但不应要求需求收集人员有专家级别的专业水准和一线业务精英的业务水平(有当然更好,但不必要)!

菜鸟乱弹,欢迎拍砖。
23 楼 Dev|il 2010-12-26  
呵呵,这就是新手和老手的区别,老手能远观未来,而新手却想不到这么多,业务逻辑和重要
22 楼 jiangduxi 2010-08-09  
lihuachuan 写道
LZ的故事场景,感觉不是在和用户对话,而是在和领域专家对话
用户很多时候并不知道
三维是按照这个的基础上(+-0.5)是什么概念,
或者浅红色是什么样的,因为浅红色也有不下几十个的色值

这个时候就变成了要拿一个样板给用户看(这就要考验需求师的能力)
或者开发一个原型出来(这样当然比拿样板成本高了)
不然等你定型做出一件粉红色的衣服时,它要一件黑色衣服,那就亏了


该场景不是和领域专家对话。如果是的话,其引导方式有问题了。如果是领域专家的话,那么其实本质上那个需求分析人员就不会有那么多盲点了。领域专家会帮需求分析人员搞定!

用户很多时候是不知道,这就是需要需求分析人员了。他不知道是技术的实现,但是他知道他想要什么,只是不知道怎么实现而已!比如:  一个顾客点在饭馆里点了一个菜,他说要辣的口味。这个就是他的需求,他可能不知道你这个饭馆里面用什么办法让菜饭符合他的辣的口味,但是当他吃的是很就知道辣不辣。所以要引导的是你店里能够辣的作料,让他选择!

“三维是按照这个的基础上(+-0.5)是什么概念,”这个其实很简单当你和用户都不能很好的把握精度,那么就出现这个大于或者小于一个可接受的值。

“这个时候就变成了要拿一个样板给用户看(这就要考验需求师的能力)”:这个其实可以根据公司之前的一些已经有的功能或者一些模型暂时给客户看,这个本身不是需求分析师的能力而是该团队的案例。

“开发一个原型出来(这样当然比拿样板成本高了)”这个其实如果你一点都不明白用户想要做什么,这个原型可能会让需求分析人员发点时间。这个原型等同于伪代码!
21 楼 lihuachuan 2010-08-09  
LZ的故事场景,感觉不是在和用户对话,而是在和领域专家对话
用户很多时候并不知道
三维是按照这个的基础上(+-0.5)是什么概念,
或者浅红色是什么样的,因为浅红色也有不下几十个的色值

这个时候就变成了要拿一个样板给用户看(这就要考验需求师的能力)
或者开发一个原型出来(这样当然比拿样板成本高了)
不然等你定型做出一件粉红色的衣服时,它要一件黑色衣服,那就亏了
20 楼 jiangduxi 2010-08-09  
王者之剑 写道
有一个人,学了三个月裁缝出师了,就以为万事大吉了,客户上门了,问,你要做什么样的衣服阿,你想用什么样的布料阿,你想做成什么样式阿。

客户说,您看做什么样的合适,他做了,做的就是他师父教的那两种样式之一。
客户说,我想做什么什么样的,他不会做,说我给您推荐更合适的,推荐的就是他师父教的两种样式之一。


   切不可按照师傅或者书本上来做,师傅和书本上给出的是事务的内函,具体事务是可能内函是不变的诞生外延就有很多种了。原则是内函,灵活应变是外延。按照师傅教的或者书本上来的是呆板和书呆子。根本不适合去做需求。因为需求本身就是变于不变的合成体。师傅或者书本上给出的是不变的成型的。它是很难适应这种变于不变的合成体。但是你可以依据师傅或者书本上的成型体进行灵活应变。
19 楼 王者之剑 2010-08-09  
有一个人,学了三个月裁缝出师了,就以为万事大吉了,客户上门了,问,你要做什么样的衣服阿,你想用什么样的布料阿,你想做成什么样式阿。

客户说,您看做什么样的合适,他做了,做的就是他师父教的那两种样式之一。
客户说,我想做什么什么样的,他不会做,说我给您推荐更合适的,推荐的就是他师父教的两种样式之一。

18 楼 王者之剑 2010-08-09  
既然已经废话这么多了,那就再说两句
如果我去学做裁缝的需求

那么我的做法是
1.逛,大街,商场门口,写字楼门口,各种卖服装的。
  服装的风格,分类,对应什么样的人。(一周,目前为止,我上街从不关心这个)
2.学,学一些专业的知识,例如学术性的,什么样的人喜欢或者适合穿什么样的衣服。(一周,目前为止,我从不看这样的文字)
3.定,我服务一些什么样的对象,什么样的群体
4.看,客户来了,看客户目前是什么样的风格,试着猜测客户的职业,身份,爱好。
5.试,给客户推荐本店的几种风格款式,观察客户的态度
等等

信念:人靠衣裳马靠鞍,服装要能为客户加分

5分钟胡写,我想真要去搞个3个月,也会有些收获吧。
17 楼 王者之剑 2010-08-09  
这个例子非常经典,说明问题主要来源于软件开发人员不够专业。
现实中,即便是有名的裁缝,客户也可能会提出各种要求和问题,但这不会够成灾难。
要我去做裁缝,肯定栽了,要我做软件,目前为止还没有。
因为我对做裁缝没有兴趣,我对做软件,对通过软件系统解决问题最有兴趣。

我说的专业,首先是指一种态度,然后是指一些行动。
有积极的态度才能克服惰性,克服畏难情绪。需求搞不清楚,难道不是因为搞需求的人不想搞清楚需求吗?

态度:愿意学习新东西,不畏难。
行动:迅速学习新东西。

时时刻刻告诫自己:要有专业精神。

还有什么搞不定的吗?

如果让你白手起家,在一个比较复杂的行业中,估计要一年两年吧。但是你到的公司总有一些资料,总有一些经验,客户也不是抱着和你过不去的态度来给你钱让你做项目的吧。
我认为,你要是有积极的态度,不出三个月,你应该能比较好的做需求了。

如果系统有2000个功能,你看一个功能用10分钟,2000/(8*6)= 40天

关键是你有兴趣深入了解客户的业务吗?

关键是你有不怕麻烦,自己就是来解决麻烦的这样的信念吗?

有的人提到钱的问题?
当你根据客户最开始的2个小问题,整理出100个功能需求的时候
你可以对这些功能进行分类,搞清楚这些功能之间的关系。
20个是最小的子集
其他的是不同程度的增强
我相信能说服客户先做哪些后做哪些。

见得多的恐怕不是整理出了100个功能,而是客户说两个做两个,再说两个,再做两个。
客户说要按电话号码查询,那就不给做按其它方式查询的,不给做也就罢了,心里一直担心客户会提按其它方式查询。

我有一个经验,你担心的事情多半会发生的。

16 楼 rocwon 2010-08-06  
需求。。
1. 行业知识
2. 分析方法
3. 沟通技巧
15 楼 jiangduxi 2010-08-06  
一蓑烟雨任平生 写道
需求分析师,按照产品实施公司的说法,一般叫功能顾问,我的体会是要在某一个具体的业务领域有5年以上的项目经验,至少独立承担过2个同类项目的功能设计和功能测试,能独立完成售前方案,如果是开发人员出身最好,但是技术背景并不是非常的关键。至于你们技术总监所说的需要3-5年技术架构的经验,那是胡嘞嘞,能做技术架构的未必能做功能,完全不同的2个领域。

赞成!我个人也觉得做需求分析师,必须具备很好的沟通和对业务有一定的熟悉程度。并且对该业务的大致功能点清晰。至于需要架构经验。我觉得有点牵强:不管是企业架构还是系统应用架构都不是简单的事情!做企业架构的一般站的高度一定不定,做应用架构技术也相当的牛。而不是告诉人家现在流行MVC使用SSH这样的程度!
14 楼 一蓑烟雨任平生 2010-08-06  
需求分析师,按照产品实施公司的说法,一般叫功能顾问,我的体会是要在某一个具体的业务领域有5年以上的项目经验,至少独立承担过2个同类项目的功能设计和功能测试,能独立完成售前方案,如果是开发人员出身最好,但是技术背景并不是非常的关键。至于你们技术总监所说的需要3-5年技术架构的经验,那是胡嘞嘞,能做技术架构的未必能做功能,完全不同的2个领域。
13 楼 cleanerje 2010-08-06  
现在阶段,缺的是钱!而不是能做这个工作的人。
第一种方法,用户也凑合着能穿啊!虽然质量用户不满意,但用户就愿意出那么多钱。
第二种方法,用户虽然爽了,可是用户不给你那么多钱啊!
一件衣服用户就给你100块钱帮他做。如果你用第二种方法给他做衣服,光时间成本你就耗不起了。自然没有哪个服务商用第二种方法来赚钱。
12 楼 amwiacel 2010-08-06  
jiangduxi 写道
前一段时间面试过一个需求分析师的岗位,最后一个技术总监说需求分析需要有3年-5年的架构经验!大家也可以谈谈如果招聘需求分析该具备出业务,架构熟悉外的其他要求吗?


需求是业务活!那人讲的架构是业务还是技术?他是技术总监,那应该是系统架构吧!首先,这是二码事情,二来,他要懂业务和技术都熟悉的人!可是,真正有这料的人,难找!
11 楼 jordanlc 2010-08-05  
个人觉得首先是要搞明白客户是想要干什么,就算考虑非常细致如果不理解客户用来干什么,百密总有一疏
10 楼 jiangduxi 2010-08-05  
前一段时间面试过一个需求分析师的岗位,最后一个技术总监说需求分析需要有3年-5年的架构经验!大家也可以谈谈如果招聘需求分析该具备出业务,架构熟悉外的其他要求吗?
9 楼 jiangduxi 2010-08-05  
一蓑烟雨任平生 写道
照你的说法,是因为不够细致才导致需求获取出了问题,是个技术活,RP问题。这么简单?

你做需求,首先要能提出问题,这个能力怎么来,为什么会泛泛?不够细致、中庸?

你细致了,量化了,是否就能把客户的需求不断的给引出来?价格呢?

仔细想想,做需求的首先要具备什么能力。


做需求本质就是从中庸中获取程序要的0,1条件。而不是一些模糊的词。(所以不管业务熟悉还是不怎么熟悉你获取需求的手段可能不一样)但是必须尽量将一些模糊的词进行得到用户的明确答复。基本上现在没有谁敢说能够获取足够的需求。只能消除一些没有量化的因素而带来的风险。我不赞成能够完全将客户的需求引出来。这个不太现实,只能消除我们能够预防的风险,这里我观点是尽量将一些可以量化的东西量化

相关推荐

    系统分析师论文--需求获取技术

    "系统分析师论文--需求获取技术" 本文主要讨论了需求获取技术在项目中的具体应用,通过采用用户访谈、问卷调查、现场观摩等方法结合起来开展需求的获取,有效的降低项目风险,并最终项目于 2020 年 4 月成功上线。 ...

    软件需求获取与分析 软件需求分析的目标和任务

    总结来说,软件需求获取与分析是一项复杂而重要的工作,涉及到与用户的深度沟通、需求的识别和表达、模型的建立以及文档的编写等多个环节,需要结合各种技术和工具,确保需求的正确性和可实施性。

    系统需求分析方法 需求获取

    系统需求分析方法需求获取 系统需求分析方法是获取需求的重要步骤,它对如何获取需求、需求的采集、需求文档的整理进行了深入的讲解。该方法汇总系统调查中所得文档资料,对组织内部整体管理状况和信息处理过程进行...

    需求获取计划书.pdf

    涉众分析是需求获取过程中非常重要的一步,旨在识别项目涉及的所有利益相关者,并了解他们的需求和期望。涉众选择是指选择合适的涉众参与需求获取过程,以确保项目的需求被正确地识别和记录。 硬数据采样是指收集和...

    需求获取及分析(台湾:吴仁和、林信惠撰写)

    通过有效地执行需求获取和分析过程,不仅可以确保最终系统满足用户的实际需求,还可以减少项目风险和成本,提高项目的成功率。对于从事信息系统开发的专业人士来说,掌握这一领域的知识和技能至关重要。

    软件需求获取与结构化分析方法(共75张PPT).pptx

    软件需求获取与结构化分析方法是软件工程中一个非常重要的步骤,它的主要任务是获取和分析用户的需求,以便设计和开发出满足用户需求的软件系统。 软件需求获取的任务和原则: 软件需求获取的主要任务是与客户或...

    有效需求分析.pdf

    使了解需求工程基本理论,具有一定需求相关工作经验的技术人员、业务骨干的需求分析实战技能...•对项目目标建立正确的认识与概念,深入掌握项目目标、Stakeholder的分析思路和方法,能够有效地对相关需求进行跟踪。

    《有效需求分析》精读笔记.pdf

    软件需求分析的核心是业务驱动需求思想,要站在用户的视角,了解用户想要解决的问题和想要达成的业务目的。 在软件需求分析中,我们需要抛开具体的技术实现,站在用户的视角,了解用户想要解决的问题和想要达成的...

    软件需求分析国家标准

    《软件需求分析国家标准》是指导软件开发过程中的一个重要标准,旨在规范需求获取、分析、定义、验证和管理的流程,确保软件项目能够满足用户和业务的实际需求。这一国家标准的实施对于提升软件质量、减少开发成本、...

    需求分析 需求工程 需求建模 需求

    需求工程则是这一过程的系统化方法,包括需求获取、需求分析、需求定义、需求验证和需求管理等阶段。 需求分析是需求工程的核心环节,主要任务是明确系统的目标、功能和性能要求。在这个过程中,我们需要与利益相关...

    给数据分析新手的10条实用建议:如何科学制定需求,提升数据获取效率?.docx

    给数据分析新手的10条实用建议:如何科学制定需求,提升数据获取效率?.docx

    需求分析-需求的获取

    NULL 博文链接:https://dftwilson.iteye.com/blog/2079028

    软件工程第四章软件需求与获取分析(二)(精).ppt

    "软件工程第四章软件需求与获取分析(二)(精)" 软件需求分析是软件工程中一个重要的阶段,它涉及到软件需求的获取、分析和文档化。在这个阶段中,软件工程师需要使用各种技术和方法来获取和分析软件需求,确保软件...

    软件需求分析方法总结

    1. 需求获取:首先,我们需要通过各种途径收集需求,包括与客户沟通、用户调研、市场分析等。了解用户的真实需求,关注业务流程、功能期望以及性能指标。 2. 需求分类:将获取的需求分为功能性需求和非功能性需求。...

    UML系统分析/获取需求

    对于电力企业收取电费的系统而言,定义边界非常重要,因为它直接影响到系统的功能模块划分以及后续的需求获取。 **案例分析** 1. **根据业务目标推导边界**:例如,第一个业务目标是“为用电客户提供业务办理自动...

    软件成熟度模型需求获取计划书

    《软件成熟度模型需求获取计划书》是一份旨在指导软件开发过程中有效收集、理解和管理需求的重要文档。在软件工程领域,需求获取是项目初期的关键环节,它直接影响到后续设计、编码、测试等阶段的顺利进行。软件成熟...

    资深需求分析师经验总结

    1. **需求获取**:通过访谈、研讨会等方式从涉众那里收集需求。 2. **需求分析**:对收集到的需求进行分析,确保它们是完整、一致且可实现的。 3. **需求规格说明**:将经过分析的需求转换为正式的需求文档。 4. **...

    软件的需求分析需求分析

    在软件开发过程中,需求分析是至关重要的第一步,它定义了软件系统的核心功能、目标和预期的行为。需求分析不仅是理解用户需求的过程,也是确保项目成功的关键因素。以下将详细阐述需求分析的重要性和具体步骤。 ...

Global site tag (gtag.js) - Google Analytics