常常听到许多朋友跟我埋怨,需求分析之难,就在于用户自身就常常弄不清楚自己的需求。起初在需求确认的时候说得好好的,一到软件上线的时候就不是那么回事了,这可没法整。但我们只要坐下来仔细分析就会发现,在需求分析的时候我们跟用户是在空对空地讨论问题。用户不是专业人士,他也搞不清楚软件到底会做成啥样,所以你跟他确认的时候他就点头了。但是,用户不是傻子,当你软件上线时,他拿到了实物了,知道软件做成啥样了,一旦不满意他就开始提变更了。所以,需求分析的症结就在与这个实物。
既然症结在此,毫无疑问,我们就应当在需求分析阶段拿出实物,用实物与用户确认需求,这就是快速原型法的基本思想。快速原型法,简称原型法(Prototyping),是20世纪80年代提出的一种从设计思想、工具、手段都全新的系统开发方法。它摒弃了那种一步步周密细致地调查分析,然后逐步整理出文字档案,设计开发,最后才能让用户看到软件结果的繁琐作法。当我们捕获了一批业务需求以后,就立即使用快速可视化工具开发出一个原型,交给用户去试用、补充和修改。再提出一些新的需求以后,再开发一版新的原型。原型法的关键就是这个快速开发。不用考虑性能、美观、可靠,原型的目的就是模拟客户的需求,与客户进行确认的。整个需求分析的过程就是“捕获需求->原型开发->确认需求->再捕获需求”的过程。
原型开发的快速与模拟到什么程度,是一对矛盾,我们要去把握。要快速开发,必然不可能和最终交付的软件系统一模一样,许多复杂问题被简化,非关键性流程被忽略,这就是所谓的模拟。因此,模拟到什么程度是关键,既能说明问题,又不耽误时间。根据我的经验,一般能拿出界面,并可以走通关键性流程就可以了。一些快速开发平台为快速原型法提供了可能。
当用户拿到原型可以自己操作时,需求研讨的气氛立即变得不太一样了。当用户享受原型给他们带来体验的快感时,需求被源源不断地被提出来。这时候的需求,就不再是枯燥无味的文字游戏,而是生动形象的图形界面。日后,如果项目采用迭代开发,让用户看着软件一点儿一点儿地成长,这又是多么美妙的体验啊。与此同时,你与用户的信任也在一步一步建立起来,软件风险在降低,项目将朝着正确方向前进。
快速原型法是美妙的,它给你与用户带来了从未有过的体验。但美妙的同时,也会带来一些的尴尬,不必要的误会,我们一定要注意。最常见的误会就是让用户将原型误以为最终交付的系统。开发一个系统需要持续数月,但你倒好,几天就搞定了,为什么还要在这个系统上投入大量资金呢?如果对方领导开始有这样的想法时,双方就开发费用进行的谈判就有一些不妙了。所以在给用户看到原型前,一定要跟用户解释清楚。
既然是原型,必要的校验、非正常操作的处理通通都被忽略。因此,当演示原型出错时,用户你可千万不要较真哟!这丑话可得说在前头,否则用户跟你较起真来,你在用户心目中的形象可就要大打折扣了。
总之,根据实际情况灵活运用原型法,可以更加顺畅地与用户确认需求。甚至在最后编写需求规格说明书的时候,都可以将原型的截图放进去。都是与用户确认好的东西,又能提高需求规格说明书的准确与生动,何乐而不为呢?
[url=http://fangang.iteye.com/blog/1345099]我们应当怎样做需求分析[/url]
[url=http://fangang.iteye.com/blog/1345283]我们应当怎样做需求调研:初识[/url]
[url=http://fangang.iteye.com/blog/1392009]我们应当怎样做需求调研:拜访[/url]
[url=http://fangang.iteye.com/blog/1394911]我们应当怎样做需求调研:研讨会[/url]
[url=http://fangang.iteye.com/blog/1396971]我们应当怎样做需求调研:需求研讨[/url]
[url=http://fangang.iteye.com/blog/1403342]我们应当怎样做需求调研:迭代[/url]
[url=http://fangang.iteye.com/blog/1474362]我们应当怎样做需求调研:需求捕获(上)[/url]
[url=http://fangang.iteye.com/blog/1474368]我们应当怎样做需求调研:需求捕获(下)[/url]
[url=http://fangang.iteye.com/blog/1481975]我们应当怎样做需求分析:功能角色分析与用例图[/url]
[url=http://fangang.iteye.com/blog/1481996]我们应当怎样做需求分析:业务流程分析(上)[/url]
[url=http://fangang.iteye.com/blog/1482008]我们应当怎样做需求分析:业务流程分析(下)[/url]
[url=http://fangang.iteye.com/blog/1482165]我们应当怎样做需求分析:用例说明[/url]
[url=http://fangang.iteye.com/blog/1482171]我们应当怎样做需求分析:查询报表分析[/url]
[url=http://fangang.iteye.com/blog/1483063]我们应当怎样做需求分析:子用例与扩展用例[/url]
[url=http://fangang.iteye.com/blog/1483082]我们应当怎样做需求分析:行动图和状态图[/url]
[url=http://fangang.iteye.com/blog/1487102]我们应当怎样做需求分析:业务领域分析[/url]
[url=http://fangang.iteye.com/blog/1488291]我们应当怎样做需求分析:原文分析法[/url]
[url=http://fangang.iteye.com/blog/1493720]我们应当怎样做需求分析:领域驱动设计[/url]
[url=http://fangang.iteye.com/blog/1497941]我们应当怎样做需求分析:非功能需求[/url]
[url=http://fangang.iteye.com/blog/1502857]我们应当怎样做需求确认:需求列表[/url]
[url=http://fangang.iteye.com/blog/1502858]我们应当怎样做需求确认:一个需求列表的实例[/url]
[url=http://fangang.iteye.com/blog/1504123]我们应当怎样做需求确认:快速原型法[/url]
[url=http://fangang.iteye.com/blog/1505381]我们应当怎样做需求确认:需求规格说明书[/url]
[url=http://fangang.iteye.com/blog/1506403]我们应当怎样做需求确认:评审与签字确认会[/url]
(续)
既然症结在此,毫无疑问,我们就应当在需求分析阶段拿出实物,用实物与用户确认需求,这就是快速原型法的基本思想。快速原型法,简称原型法(Prototyping),是20世纪80年代提出的一种从设计思想、工具、手段都全新的系统开发方法。它摒弃了那种一步步周密细致地调查分析,然后逐步整理出文字档案,设计开发,最后才能让用户看到软件结果的繁琐作法。当我们捕获了一批业务需求以后,就立即使用快速可视化工具开发出一个原型,交给用户去试用、补充和修改。再提出一些新的需求以后,再开发一版新的原型。原型法的关键就是这个快速开发。不用考虑性能、美观、可靠,原型的目的就是模拟客户的需求,与客户进行确认的。整个需求分析的过程就是“捕获需求->原型开发->确认需求->再捕获需求”的过程。
原型开发的快速与模拟到什么程度,是一对矛盾,我们要去把握。要快速开发,必然不可能和最终交付的软件系统一模一样,许多复杂问题被简化,非关键性流程被忽略,这就是所谓的模拟。因此,模拟到什么程度是关键,既能说明问题,又不耽误时间。根据我的经验,一般能拿出界面,并可以走通关键性流程就可以了。一些快速开发平台为快速原型法提供了可能。
当用户拿到原型可以自己操作时,需求研讨的气氛立即变得不太一样了。当用户享受原型给他们带来体验的快感时,需求被源源不断地被提出来。这时候的需求,就不再是枯燥无味的文字游戏,而是生动形象的图形界面。日后,如果项目采用迭代开发,让用户看着软件一点儿一点儿地成长,这又是多么美妙的体验啊。与此同时,你与用户的信任也在一步一步建立起来,软件风险在降低,项目将朝着正确方向前进。
快速原型法是美妙的,它给你与用户带来了从未有过的体验。但美妙的同时,也会带来一些的尴尬,不必要的误会,我们一定要注意。最常见的误会就是让用户将原型误以为最终交付的系统。开发一个系统需要持续数月,但你倒好,几天就搞定了,为什么还要在这个系统上投入大量资金呢?如果对方领导开始有这样的想法时,双方就开发费用进行的谈判就有一些不妙了。所以在给用户看到原型前,一定要跟用户解释清楚。
既然是原型,必要的校验、非正常操作的处理通通都被忽略。因此,当演示原型出错时,用户你可千万不要较真哟!这丑话可得说在前头,否则用户跟你较起真来,你在用户心目中的形象可就要大打折扣了。
总之,根据实际情况灵活运用原型法,可以更加顺畅地与用户确认需求。甚至在最后编写需求规格说明书的时候,都可以将原型的截图放进去。都是与用户确认好的东西,又能提高需求规格说明书的准确与生动,何乐而不为呢?
[url=http://fangang.iteye.com/blog/1345099]我们应当怎样做需求分析[/url]
[url=http://fangang.iteye.com/blog/1345283]我们应当怎样做需求调研:初识[/url]
[url=http://fangang.iteye.com/blog/1392009]我们应当怎样做需求调研:拜访[/url]
[url=http://fangang.iteye.com/blog/1394911]我们应当怎样做需求调研:研讨会[/url]
[url=http://fangang.iteye.com/blog/1396971]我们应当怎样做需求调研:需求研讨[/url]
[url=http://fangang.iteye.com/blog/1403342]我们应当怎样做需求调研:迭代[/url]
[url=http://fangang.iteye.com/blog/1474362]我们应当怎样做需求调研:需求捕获(上)[/url]
[url=http://fangang.iteye.com/blog/1474368]我们应当怎样做需求调研:需求捕获(下)[/url]
[url=http://fangang.iteye.com/blog/1481975]我们应当怎样做需求分析:功能角色分析与用例图[/url]
[url=http://fangang.iteye.com/blog/1481996]我们应当怎样做需求分析:业务流程分析(上)[/url]
[url=http://fangang.iteye.com/blog/1482008]我们应当怎样做需求分析:业务流程分析(下)[/url]
[url=http://fangang.iteye.com/blog/1482165]我们应当怎样做需求分析:用例说明[/url]
[url=http://fangang.iteye.com/blog/1482171]我们应当怎样做需求分析:查询报表分析[/url]
[url=http://fangang.iteye.com/blog/1483063]我们应当怎样做需求分析:子用例与扩展用例[/url]
[url=http://fangang.iteye.com/blog/1483082]我们应当怎样做需求分析:行动图和状态图[/url]
[url=http://fangang.iteye.com/blog/1487102]我们应当怎样做需求分析:业务领域分析[/url]
[url=http://fangang.iteye.com/blog/1488291]我们应当怎样做需求分析:原文分析法[/url]
[url=http://fangang.iteye.com/blog/1493720]我们应当怎样做需求分析:领域驱动设计[/url]
[url=http://fangang.iteye.com/blog/1497941]我们应当怎样做需求分析:非功能需求[/url]
[url=http://fangang.iteye.com/blog/1502857]我们应当怎样做需求确认:需求列表[/url]
[url=http://fangang.iteye.com/blog/1502858]我们应当怎样做需求确认:一个需求列表的实例[/url]
[url=http://fangang.iteye.com/blog/1504123]我们应当怎样做需求确认:快速原型法[/url]
[url=http://fangang.iteye.com/blog/1505381]我们应当怎样做需求确认:需求规格说明书[/url]
[url=http://fangang.iteye.com/blog/1506403]我们应当怎样做需求确认:评审与签字确认会[/url]
(续)