不同成长环境、不同年龄段、不同教育背景、不同知识结构的人对软件的使用偏好也有所不同。比如，现今新一代交警逐步成为交警单位中的中坚力量，他们普遍具有大学以上学历，学历较高，接受新事物能力强，对电脑、手机等使用非常熟悉，加之现今网络发达，了解信息的渠道非常多，这使得他们有很强的意愿将自己了解接触到的一些新产品、新技术应用到智能交通软件产品中。

一、个性化需求产生的原因
软件产品个性化需求产生的原因很多，本文将其归纳为如下4种。
1.1角色立场不同
很多软件产品是按照客户（为项目买单的人）的需求设计的，需求分析时往往接受了他们的意见，毕竟只有通过他们的认可，项目可能才可验收，但他们的需求并不代表产品最终用户（产品使用者）的需求，比如：业务领导、基层交警、业务人员、管理员、系统维护人员等不同的岗位角色，总队用户、支队用户、大队用户等不同层级组织机构人员对产品都有自己的需求。
另外，不同成长环境、不同年龄段、不同教育背景、不同知识结构的人对软件的使用偏好也有所不同。比如，现今新一代交警逐步成为交警单位中的中坚力量，他们普遍具有大学以上学历，学历较高，接受新事物能力强，对电脑、手机等使用非常熟悉，加之现今网络发达，了解信息的渠道非常多，这使得他们有很强的意愿将自己了解接触到的一些新产品、新技术应用到智能交通软件产品中。
1.2应用环境、场景不同
各地区信息化程度不同，在各地项目中运行环境也存在较大差异，尤其我们作为集成厂商，需要面对来自不同厂家的设备、系统，另外，在业务系统运行的环境和用户使用的环境方面，也都存在着不同操作系统、IE版本等差异，这些也导致需求差异化和个性化需求的产生。
1.3“特色”、“亮点”工程的需要
“人无我有，人有我优，人优我新，人新我智”这种思想是很多信息化建设主管领导以及追求政绩的领导进行各类项目建设的指导思想，为了建设“特色”，搞出“亮点”，有些人不顾项目建设范围，不理项目建设经费，盲目攀比跟风，而忽略业务实际。
1.4对软件研发规律的错误认识
很多用户简单的认为软件产品的发布就是开发、修改一些代码就可以了，对软件研发的规律缺乏了解，殊不知，软件产品研发有其自身的规律，需要历经需求分析、设计、开发、测试、发布、维护、撰写文档、技术支持的阶段。
二、个性化需求对产品研发的影响
随着智能交通产业由卖方市场向买方市场的转变，用户的主导地位得以确立。他们对个性化的要求越来越高，都愿意选择“自己想要的东西”，而非通用的“软件产品”。需求的个性化表现为需求的不确定性、多样性和快变性三个主要特征。这对软件产品研发工作造成巨大的影响，主要表现在如下几个方面。
2.1需求的不确定性造成软件产品的大量返工
       每个产品版本研发都要历经从需求分析到技术支持的多个阶段，用户需求的不确定性，会引起上述过程的反复，直接增加研发成本，换个角度来说，这部分被牵制的研发力量无法转移到别的研发项目，一方面需要增加人手，另一方面也导致其他产品研发的延误。另外，从团队管理的角度来讲，反复的工作，会使人产生受挫感，消磨人的斗志，打击人的积极性，不利于研发团队的稳定。
2.2需求的多样性使产品呈现多样化
用户需求的多样化最终会表现为对产品或对产品功能需求的多样化。一个组织所拥有的资源是有限的，如果产品的种类增多，那么单个产品的研发规模就会减小，可能会造成规模不经济；并且一个组织中研发人员的工作量一般是确定的，在软件研发人员投入、进度等要素恒定的情况下，产品质量与数量成反比，面对大量的客户需求，如果全部接受，将导致产品质量的下降。同时多个定制版本、分支版本的产生，无疑增加了很多后期维护升级的工作量和成本。
2.3需求的快变性引起产品生命周期缩短
用户需求的多变性在时间上表现为需求变化速度的加快，这导致了产品生命周期的缩短。产品更新换代速度的加快，会造成软件产品生命周期单位时间研发工时的增加，使研发成本增加，从而影响利润率。
三、如何应对个性化需求
3.1听用户的但不要照着做
客户在描述需求时，习惯提出自己的解决方案，但不一定抓住了需求的本质。需求分析的过程就是要发现问题的本质，提供更合理的解决方案。多数用户其实不喜欢定制软件，他们更喜欢通用产品，因为通用产品的兼容性、数据移植性更好，改进速度更快，也更容易获得技术支持。
产品需求不能用户说了算，原因如下：
软件的研制是一种人的智力创造，软件产品是一种信息产品，是无形的，而根据自然辩证法的认识论观点，物质是第一性、精神是第二性的，人的认识过程是不断深化的，所以，当用户在看到具体的软件产品之前，用户很难知道自己想要什么；

用户不知道什么样的产品是可行的（在目前的技术条件下可以实现）；

各种角色、各个部门用户之间缺少沟通，需求很难统一。
需求分析的过程，就是要将用户需求转化为产品需求，确定需求的基本属性，并识别个性化需求，对于个性化需求，尽可能引导用户、说服客户按软件产品既定的业务流程、操作方式使用。
3.2产品设计尽可能多考虑
在我们研发的产品中，有很多产品通用的需求被当做个性化需求开发实现，或者说本不应该出现的分支版本因为产品架构设计的原因，被硬生生的从主干中分了出来。
我认为，针对个性化需求的设计原则，应遵循组件（插件）化、可配置（参数、界面）化两个原则，违背上述原则的个性化需求则建议评估是否必须做。
下文以上述两个原则的应用为例，针对某适配服务的设计做一简要说明。
现状：因多个项目数据来源类型不同，数据格式不同，因此每个项目开发一套独立的适配服务；
分析：虽然数据来源、格式不同，但数据是有一定规律的，而且最终输出的数据格式是一致的；
设计思路：如下图所示，可按组件化思路将该适配服务分为3层，分别为数据链接层、数据解析配置层、数据转换加载层，各层主要说明如下：
数据链接层：将来源自图片、数据库表、文件等不同的数据源的数据通过不同的驱动进行链接，通过配置实现不同数据源的访问；
数据解析配置层：获取到数据，参考协议文档通过配置，按数据对应的规律定义数据的取位及顺序，实现对数据的解析；
数据转换加载层：将解析后的数据上载到统一接口，完成数据的转换加载。
通过上面的工作，最终达到使用一个通用适配接入软件，解决来自不同数据源类型格式的适配接入问题。针对新项目的数据接入，只需要选择不同的数据来源，配置相应连接参数，然后定义数据的接入规则和顺序，最后配置上载目标数据源的信息，就可完成数据适配工作，不需要研发人员干预，普通技支人员就可完成。

3.3学会说“NO”
有时候“拒绝”和“承诺”同样重要。
项目启动时用户就能提出比较完善的需求，是每个项目最理想的状态。但事实上，99%项目都不是这样的，有的客户认为自已花了钱，软件就应该满足他们的一切需求，如果全部答应，就会出现上文中提到的那些影响。
因此，在确保双方利益、友好和谐的状况下，回绝用户的一些对产品研发有重大影响的个性化需求，我认为是我们每个人都应该考虑的问题。
在说“NO”的方面，也有一些技巧，比如：
将当前涉及的问题与客户想法满足之后的状况进行对比，分析如果把这样需求带入系统后可能会引发什么后果；
询问是否可以通过其它途径处理，而不是占用宝贵的研发资源；
评估用户新提出的需求的可行性与必要性。