在总结需求分析之前,我先谈谈我对事物的认识吧。因为人对事物的认识才能有自己的观点,每个人观点不一样因此对事物理解不一样。也就是在获取需求和分析需求不一样。
学习和实践任何技术和事物都存成开始的入门和进阶最后精通。我个人对精通感冒。因为我知道精通是个高深的境界。
[b]学习事物观点:[/b]
[b][color=red]任何事物都有它的一般性和特性。掌握一般性也就等于入门,至于掌握特性那可能是遥遥无期。特性和一般性是互相转化。[/color][/b]
[img]http://dl.iteye.com/upload/picture/pic/58896/69fdd59b-1de7-35dc-805a-c6ca96cee140.jpg[/img]
在理解上面的观点的话:那么就来总结下需求的获取它有什么一般性和它有什么特性。一般性和特性怎么个转化法。怎么让你在获取和分析需求的时候更符合用户的意思和他的行为。
需求获取的手段有很多种,我比较常用的就是说、看、听。[color=red][b]说[/b][/color]则是去和真正使用系统的用户去交流。(这里是真正使用系统的用户而不是买你系统的客户)。[b][color=red]看[/color][/b]则是去看真正使用系统的用户对业务的操作或者对替代系统的操作。[b][color=red]听[/color][/b]则是在你提出问题后,把真正使用系统的用户当成你的上帝去聆听(用户更喜欢自己是老大,而不是你是老大)。
1.[b] 说和听的目的[/b]: 将整个要做系统与该用户有关的业务流程跟他进行交流。这可谓是你做需求的一般性。如果在说的时候你所说的流程得到用户的认可后,记住不要高兴。因为你只是成功了一步,那就是你还知道你所做系统的一般流程。也可以说你还了解这个流程。如果在说的时候被用户发现了问题,不要沮丧。其实这才是你有进步的地方。这时候你就认真聆听。不管你说还是听,如果你能够用UseCase画出来很好。如果不行,那么至少你的脑子里面要呈现出一张UseCase(UseCase不要忘了使用者的身份)。在完成了一般性的交流后,接着你必须要去引导用户说出他的一些特性的流程,可能不是很常用但是实际很重要的一些流程。你要想想任何人都可能会遇到处理一般事件和特殊事件。特殊事件是你不能忽视的,每个公司或者每个使用者都有它的特性。这些你都要尽量收集到。
2.[b] 看的目的[/b]: 其实是一个验证说的步骤,光说,听是不够完善的。毕竟人会遗忘。尤其是他认为不重要但是对未来的系统可能很重要的东西他没有说。这时候看尤其重要了。看操作者在处理业务的整个过程。通过看来验证你和操作者的说和他说给你听的事情。是否不一致,是否有不同的地方。记住一定要将看到的、听到的、交流的联系起来。互相进行验证。只有这样才能尽量获取到需求。
在获取需求的时候你必须对将去获取需求的公司或者用户有点了解。比如公司的业务,使用者的职位工作范畴等待。了解的越详细对获取越有帮助。如果能够了解该使用者的上下游也是一件好事情。毕竟事物有衔接。
学习和实践任何技术和事物都存成开始的入门和进阶最后精通。我个人对精通感冒。因为我知道精通是个高深的境界。
[b]学习事物观点:[/b]
[b][color=red]任何事物都有它的一般性和特性。掌握一般性也就等于入门,至于掌握特性那可能是遥遥无期。特性和一般性是互相转化。[/color][/b]
[img]http://dl.iteye.com/upload/picture/pic/58896/69fdd59b-1de7-35dc-805a-c6ca96cee140.jpg[/img]
在理解上面的观点的话:那么就来总结下需求的获取它有什么一般性和它有什么特性。一般性和特性怎么个转化法。怎么让你在获取和分析需求的时候更符合用户的意思和他的行为。
需求获取的手段有很多种,我比较常用的就是说、看、听。[color=red][b]说[/b][/color]则是去和真正使用系统的用户去交流。(这里是真正使用系统的用户而不是买你系统的客户)。[b][color=red]看[/color][/b]则是去看真正使用系统的用户对业务的操作或者对替代系统的操作。[b][color=red]听[/color][/b]则是在你提出问题后,把真正使用系统的用户当成你的上帝去聆听(用户更喜欢自己是老大,而不是你是老大)。
1.[b] 说和听的目的[/b]: 将整个要做系统与该用户有关的业务流程跟他进行交流。这可谓是你做需求的一般性。如果在说的时候你所说的流程得到用户的认可后,记住不要高兴。因为你只是成功了一步,那就是你还知道你所做系统的一般流程。也可以说你还了解这个流程。如果在说的时候被用户发现了问题,不要沮丧。其实这才是你有进步的地方。这时候你就认真聆听。不管你说还是听,如果你能够用UseCase画出来很好。如果不行,那么至少你的脑子里面要呈现出一张UseCase(UseCase不要忘了使用者的身份)。在完成了一般性的交流后,接着你必须要去引导用户说出他的一些特性的流程,可能不是很常用但是实际很重要的一些流程。你要想想任何人都可能会遇到处理一般事件和特殊事件。特殊事件是你不能忽视的,每个公司或者每个使用者都有它的特性。这些你都要尽量收集到。
2.[b] 看的目的[/b]: 其实是一个验证说的步骤,光说,听是不够完善的。毕竟人会遗忘。尤其是他认为不重要但是对未来的系统可能很重要的东西他没有说。这时候看尤其重要了。看操作者在处理业务的整个过程。通过看来验证你和操作者的说和他说给你听的事情。是否不一致,是否有不同的地方。记住一定要将看到的、听到的、交流的联系起来。互相进行验证。只有这样才能尽量获取到需求。
在获取需求的时候你必须对将去获取需求的公司或者用户有点了解。比如公司的业务,使用者的职位工作范畴等待。了解的越详细对获取越有帮助。如果能够了解该使用者的上下游也是一件好事情。毕竟事物有衔接。