我们应该如何进行需求确认:快速原型法

经常听到很多朋友跟我抱怨，需求分析的难度在于用户往往搞不清自己的需求。一开始确定需求的时候说的很好，但是软件上线的时候不是这样的，无法调整。但是只要我们坐下来仔细分析一下，就会发现我们在分析需求的时候是在和用户空对空的讨论问题。用户不是专业人士，不知道软件会是什么样子，所以你跟他确认的时候他点了点头。但是，用户不是傻子。你的软件上线，他拿到了实物，知道软件是什么做的。一旦他不满意，他就开始做出改变。所以，需求分析的关键就在于这个实物。既然这是问题的关键，那么毫无疑问，我们应该在需求分析阶段拿出实物，用实物来确认需求。这是快速原型法的基本思想。快速原型法(Rapid Prototyping)，简称原型法，是20世纪80年代提出的一种从设计思想、工具和手段上来说的全新的系统开发方法。它摒弃了一步一步仔细调查分析，然后一步一步整理文本文件，设计开发，最后让用户看到软件结果的繁琐做法。当我们捕捉到一批业务需求后，马上用快速可视化工具开发出一个原型，交给用户进行试用、补充和修改。在提出一些新的需求后，我们将开发一个新的原型。原型法的关键就是这种快速发展。不考虑性能、美观、可靠性，样机的目的是模拟客户的需求，并与客户确认。需求分析的全过程是“捕获需求->；原型开发->；确认需求-& gt；再次捕获需求的过程。原型开发快速到什么程度和模拟到什么程度是一个矛盾，要把握。要快速开发，难免和最终交付的软件系统不完全一样。很多复杂的问题被简化，非关键流程被忽略。这就是所谓的模拟。所以模拟的程度是关键，既能说明问题又不浪费时间。根据我的经验，一般拿出界面，走一遍关键流程就够了。一些快速开发平台为快速原型开发提供了可能。当用户拿到原型，可以自己操作的时候，需求讨论的氛围马上就不一样了。当用户享受样机带来的体验快感时，需求不断被提出。这时候需求的不再是枯燥的文字游戏，而是生动的图形界面。未来如果项目采用迭代开发，用户看着软件一点一点成长，会是一种很美好的体验。同时，你和用户之间的信任也一步步建立起来了，软件风险在降低，项目也会朝着正确的方向前进。快速原型法很奇妙，带给你和用户前所未有的体验。但同时也会带来一些尴尬和不必要的误会，一定要注意。最常见的误解是让用户将原型误认为最终的交付系统。开发一个系统需要几个月的时间，但你可以在几天内完成。为什么要在这个系统上投入大量资金？如果对方领导开始有这样的想法，那双方关于开发成本的谈判就有问题了。所以在向用户展示原型之前，你必须向用户解释清楚。既然是原型，那么必要的验证和异常操作的处理都忽略了。所以，当演示样机出问题的时候，一定不能对用户认真！这个丑陋的故事必须先说出来，否则用户会对你更加坦诚，你在用户心目中的形象也会大打折扣。应该怎么做需求分析？应该怎么做需求调研？初次见面应该如何做需求调研？拜访时应该如何做需求调研？在研讨会中应该如何做需求调研？应该怎么做需求调研？迭代？应该怎么做需求调研？需求捕捉(一)？应该怎么做需求调研？需求捕捉(二)？应该怎么做需求分析？功能角色分析和用例图？需求分析:业务流程分析(一)我们应该如何做需求分析:业务流程分析(二)我们应该如何做需求分析:用例解释我们应该如何做需求分析:查询报告分析我们应该如何做需求分析:子用例与扩展用例我们应该如何做需求分析:动作图与状态图我们应该如何做需求分析:业务领域分析我们应该如何做需求分析:原文分析法我们应该如何做需求分析。分析:领域驱动设计:我们应该如何做需求分析:我们应该如何做非功能性需求的需求确认:我们应该如何做一个需求清单的需求确认:我们应该如何做一个需求清单的需求确认:需求规格说明:评审和签字确认会议(续)