什么是好的用户需求

用户需求是系统开发，风险评估和系统测试的前提，也是验证活动的基础，那么怎么样的用户需求才是好的用户需求呢？

用户需求描述的是系统必须达到的功能，所以用户需求的表述应该准确清晰，只有准确清晰的需求，才能保证后续程序的开发或者系统选型的时候，不至于产生误解。

比如，以HPLC系统为例，如果有一条需求这样写到“系统应该具有报警功能”，那么这条需求就不是很准确清楚，倒底是什么情况下系统应该报警呢？是系统超过了规定的柱压，还是系统发生漏液，还是系统的紫外检测器需要更换，亦或是进校序列中抓取样品失败？HPLC系统报警的场景太多了，UR不写清楚，谁知道你想要什么。

用户需求的另一个关键点就是技术上可以达到，不要提一些不切实际、没有实际意义的需求。从产品的角度或者系统实现的功能的角度而言，建立的控制策略应该是有效的，而不是无限度的高标准，严格要求。比如一台混合机，假定混合工艺要求的混合时间是关键参数，工艺规定的混合时间允许的范围是±5秒，那么对于计时器的精度有必要达到±0.1秒嘛？

需求要可以被测试，还是回到上面混合机的例子，现在从行业水平来讲，自动化设备控制时间的精度达到±0.1秒是没有问题的，但是如果你把±0.1秒做为需求，那测试方案怎么去写呢，你是不是还要找个精度为±0.01秒的秒表去做测试？怎么去保证你启停秒表的时候没有人为误差呢？所以在写需求的时候要结合实际的工艺要求去写，要确保写出的需求是可被测试的。

需求之间不要有冲突，不要自相矛盾。尤其是对于一些复杂的系统，往往需要结合业务流程去写需求，比如文档管理系统，审批完成后究竟是立即生效，还是保持在批准的状态，需要事先定义好业务流程的要求，要不然在写需求的时候可能前面要求审批完成生效，后面又要求审批完成后保持在批准状态。

不要把所有的需求混在一条需求里，以微信为例发消息的功能为例，如果一条需求写成这样“微信发消息的功能应该能够发送语音、文字、图片、纸包、视频、位置消息和名片，同时通过消息功能还能实现转账和视频聊天”，估计程序员要哭死在当场了，因为软件或者系统开发的时候往往是模块化开发的，或者是一段代码实现一个具体功能的，这种混合所有需求在一条需求到最后很容易产生遗漏。

用户需求写好了，要及时和供应商沟通，不要想当然觉得系统肯定能够实现。笔者亲身经历过一个例子，由于供应商不够专业，我们对系统有电子签名的要求，供应商信誓旦旦会有这个功能，结果设备确认的时候发现如果要有电子签名的功能还要购买额外的模块，遇到这种情况，就相当被动了。

用户需求最好有唯一的编号，这是为了后续进行测试确认的时候便于追溯需求是否达到；用户需求还可以根据不同的类型进行分类，比如功能性需求，安全性需求，自动化控制方面需求，数据报告方面的需求等等。还有，系统的需求最好采用主谓宾结构来表述，这样最为简洁和清楚。

最后再强调一点，用户需求是系统验证生命周期内的动态文件，在变更时，不要忘记对用户需求进行评估，看是否需要更新。

感谢昨天赞赏的朋友，有些出乎意料，开通赞赏功能的第一天就收到了红包，感谢大家的鼓励！