另一种就是客户压根儿没有想到的需求。也许你会提出这样的疑问,客户压根儿没有想到的需求我们还提出来做什么?这种压根儿没有想到的,实际是在业务需求阶段压根儿没有想到的,并不代表最终都没有想到。很多开发人员总在埋怨,说客户需求总是在软件项目的后期改来改去,为什么?客户并不是软件研发领域的专业人员。在业务需求阶段,由于没有可以展示和操作的实物,客户总是在空对空的凭空想象今后的软件应当做成什么样子。这就注定了客户会有很多自己压根儿没有想到的需求。那么为什么他们会在软件研发的后期提出来呢?因为软件研发的后期,客户能拿到那些研发成果的实物,去操作,可以看到。这时候,很多他们起初没有想到的需求就会源源不断地被提出来。但这时候,我们作为研发人员会很伤,我们付出的代价会很大。所以,以被动的态度去完成需求分析工作,必然会给项目研发带来巨大的风险。
如何解决这样的问题呢?首先,在需求分析阶段,虽然客户压根儿没有想到,但需求分析人员是软件研发领域的专业人员,他们应当在深入理解业务领域与需求的基础上,通过分析提前发现这些需求。作为需求分析人员,他们应当站在客户的角度去思考,我们的软件应当设计成什么样子,每个需求的真实意图是什么。站在这个基础上,再运用专业知识去整理、分析与设计。我前面谈到,客户描述的最原始的需求是编写在需求列表中的,而经过需求分析人员的整理、分析与设计,经过用例分析、领域建模,最终形成产品需求说明书(或称为产品规格说明书)。从需求列表到产品需求说明书,这之间要经过一段长长的路,这段路就是我们的分析与设计,而不是简单的记录与编写文档。只有经过这样的过程,最后得到的才是高质量的需求分析,才能有效地指导软件研发,避免项目的风险。所以说,好的需求分析人员就是软件项目的司命,掌握着项目的生死。
我们再换一个角度来分析,客户之所以提不出需求,关键就在于他们没有可以展示和操作的实物,总是在空对空的凭空想象今后的软件应当做成什么样子。我们能否改变这样一种现状呢?于是,迭代式的需求分析与开发就出现了。我们先用最短的时间先做一个可以展示和操作的原型给客户看,让客户提一些意见。然后我们再在这个原型的基础上再多做一些,再给客户看。我们就这样一步一步推进,直到最终项目研发结束。采用这样的方式,最适合那些客户在项目初期提不出什么需求,也没用合适的参照物来进行需求分析的软件项目,特别是那些数据分析与决策类的软件项目。
接下来,我们再回到那些从客户嘴里说出的需求。在需求分析人员中,比较普遍的一个看法就是,只要是从客户嘴里说出来的,就一定是对的,我们必须照着做的,这种看法是不正确的。因为客户在软件开发方面是非专业的,所以他们在提出需求的时候往往会考虑不够周全。有一次,客户在提出来一系列业务操作以后,最后提出了一个统计报表的功能。这个统计报表是从前面这一系统操作数据中统计出来的,因此我们就对这些业务操作及其结果数据进行了一个详细的分析,最后发现根据这些数据统计出来的数据存在很多的问题,甚至可能出现相互矛盾的地方。随后我们与客户就这些问题进行了深入地探讨,最终客户不得不承认,他当初在设计这个报表的时候考虑不周全。在提出问题的同时,我们又提出了我们的解决方案,这是非常关键的。当我们提出我们的合理化建议以后,客户欣然接受了。同时,客户对我们这种非常专业的分析与处理过程大加赞赏,无形中也提高了我们在客户心目中的威望。
不仅如此,客户作为一个群体,客户与客户之前对同一问题也可能存在不同的看法,这特别突出地体现在那些多组织机构的管理系统中。因此,对于一些客户非正式的场合提出的需求我们要仔细甄别。一个比较可行的方法就是,先在一些非正式的场合单独跟客户聊,产生第一手资料,最后将这些需求在比较正式的场合,如各部门参加的业务讨论会、有用户代表参加的需求评审会、需求定稿签字确认会等等,以比较正式的形式讨论和确定下来。
最后,我不得不说,企业信息化管理实质就是一次改革,是企业摒弃手工操作,向信息化建设迈进的一次改革。既然是改革,就必须要改变过去不合理的管理流程,向更加合理和高效的管理流程迈进。因此,我们的需求捕获最初是源于企业现有的操作流程,但当我们深入理解了客户现有的操作流程以后,应当有意识地发现那些不合理的部分,并最终提出更加合理、更适于信息化管理的流程。如果需求人员能上到这样一个高度,我们的需求分析就进入了一个更加崭新的层面(关于需求分析中的流程分析,我们还会在后面详细探讨)。
我们应当怎样做需求分析
我们应当怎样做需求调研:初识
我们应当怎样做需求调研:拜访
我们应当怎样做需求调研:研讨会
我们应当怎样做需求调研:需求研讨
我们应当怎样做需求调研:迭代
我们应当怎样做需求调研:需求捕获(上)
我们应当怎样做需求调研:需求捕获(下)
我们应当怎样做需求分析:功能角色分析与用例图
我们应当怎样做需求分析:业务流程分析(上)
我们应当怎样做需求分析:业务流程分析(下)
我们应当怎样做需求分析:用例说明
我们应当怎样做需求分析:查询报表分析
我们应当怎样做需求分析:子用例与扩展用例
我们应当怎样做需求分析:行动图和状态图
我们应当怎样做需求分析:业务领域分析
我们应当怎样做需求分析:原文分析法
我们应当怎样做需求分析:领域驱动设计
我们应当怎样做需求分析:非功能需求
我们应当怎样做需求确认:需求列表
我们应当怎样做需求确认:一个需求列表的实例
我们应当怎样做需求确认:快速原型法
我们应当怎样做需求确认:需求规格说明书
我们应当怎样做需求确认:评审与签字确认会
(续)
分享到:
相关推荐
我们应当怎样做需求调研:需求捕获 12 我们应当怎样做需求分析:功能角色分析与用例图 15 我们应当怎样做需求分析:业务流程分析 18 我们应当怎样做需求分析:用例说明 21 我们应当怎样做需求分析:查询报表分析 24 ...
1. 需求捕获技术 在需求捕获中最常见的技术就是: 用户访谈 问卷表 小组会议 上述的各种技术在特定场合都能很好发挥作用,应该好好的考虑在何时使用哪项技术。在大多数项目中,捕获需求不可能只采用某个...
java源码:网络数据包捕获函数库 jNetPcap.zip
实验报告:用Ethereal捕获并分析TCP数据包.pdf
这是需求捕获指南(中英文对照)系列文章的压缩。。。
[信息安全]大海捞针:使用沙箱捕获多个零日漏洞 安全人才 WEB应用防火墙 安全资讯 安全测试 基础架构安全
在需求获取的过程中,经常会遇到用户种种不同的反应,而消极心理是造成负面反应的主要原因。 本 文针对五种最典型的心理现象进行分析,并分享了一些行之有效的解决手段。
实验:IP报文的捕获与分析,对了解网络的基本原理有一定的帮助。
网络安全专业调研报告-企业对网络安全需求调研报告-精品全文共5页,当前为第1页。网络安全专业调研报告-企业对网络安全需求调研报告-精品全文共5页,当前为第1页。络安全专业调研报告企业对络安全需求调研报告 网络...
2022数字藏品研究报告!NFT:中西方价值捕获的分化之路
分层要求:Google表格“应用脚本”(又名宏):向需求捕获电子表格添加功能
IP数据包捕获与解析程序设计 设计内容:捕获本机网卡的IP包,对捕获的IP包进行解析。要求必须输出以下字段:版本号、总长度、标志位、片偏移、协议、源地址和目的地址。 设计要求: 1. 实现程序应为图形化界面,输出...
软件开发流程进行开发 的设计合理;包括类的继承多态等; 块划分清晰合理; 实用性好。 在基本要求达到后,可进行创新设计,比如系统用户功能控制,对管理员级和一般级别的用户系统功能操作不同。...
碳中和实现手段CCUS:二氧化碳的捕获、封存和利用情况(2021年).docx
习题集 1单项选择题 2填空题 3名词解释 4简答题 5问答题 6分析题 知识要点 1为什么软件需求这么难? 2软件需求的定义 ...32需求分析主要用来做什么 33建模的要点与原则 34建模工具的选择 35UML的优
在学习过程中我们经常使用输入捕获模式来捕获pwm信号,这种方法适合捕获低频和占空比区中的波形,在捕获相对高频和占空比1%或者说99%这些极端情况下的话会造成很大误差。其实stm32有一个很好用模式用来捕获pwm信号,...
软件需求工程,讲述了需求工程的主要概念与主要问题
普通的输入捕获可以使用定时器的四个通道,一路捕获占用一个捕获寄存器,而 PWM 输入则只能使用两个通道,即通道 1 和通道 2, 且一路 PWM 输入要占用两个捕获寄存器,一个用于捕获周期,一个用于捕获占空比。...
1.领域:matlab,GPS信号捕获算法 2.内容:GPS信号捕获matlab仿真+操作视频 3.用处:用于GPS信号捕获算法编程学习 4.指向人群:本硕博等教研学习使用 5.运行注意事项: 使用matlab2021a或者更高版本测试,运行...
颜色捕获器 捕获器 捕获 颜色颜色捕获器 捕获器 捕获 颜色颜色捕获器 捕获器 捕获 颜色颜色捕获器 捕获器 捕获 颜色