软件研发之需求分析(一)
2009-10-14 12:53
316 查看
何谓需求?简单的理解,就是用户期望软件达到的效果。既然是期望,一个看不见摸不到的东西,凭着客户去想,再让研发人员去分析,理想与现实的差距也就慢慢显现出来。用户的需求分析不准,需求的界限又难以清除的划定,失败的由头便开始埋下,毕竟需求才是软件的始源。因此,对软件开发我一直持悲观的态度,在处理用户需求方面也是谨慎的避免歧义的产生,而非单方面激进的提出过多的功能设想。
大多数情况下,在软件未开发之前,用户对软件功能的要求是非常多的,用一句业内话来说,就是他希望点一下按钮就解决所有的问题。这是用户的理想,当然也是软件供应商的理想,但终归是理想。现实来说,这个要求很难满足,我们惟有对用户的要求一一分析,分清主次,量力而行。
现在很多管理类文档将需求分为合理需求和不合理需求两种类型,这种分类方式本身并没有错误,但在实际判断起来却很难,主要是无法清晰的界定合理和不合理的属性,用户和研发人员的出发点是不一样的,每个研发人员也都有各自的认识,很难确定合理与不合理的标准。因此我更主张将需求按重要程度进行分级,需要解决用户核心问题、必须问题的需求就是重要的,其他的就可以认为是次要的,这就很容易区分了。而且不同的项目可以根据客户与研发人员的共同认识,灵活的定义重要程度的级次,可以都是重要的需求,可以分为重要的和次要的,也可以分为重要的、次要的和更次要的,每个项目都可以有自己的灵活性。需求分类好了,自然就可以在以重要需求为出发点,兼顾次要需求的基础上来进行设计。
问题的关键开始转移到如何具体的对用户需求按重要程度进行分类。这个就是每个项目自己的灵活性了,如果你做的是财务系统,财务数据处理和票据打印就是重要需求;如果你做的是公文系统,文件撰写和流程处理就是重要需求,等等。做为用户和软件研发人员,这方面的共识还是很容易达成的。如果要想做的更好,则可以将一个系统分成若干个子系统,每个子系统又分成若干个模块,模块再划分成功能点,这样每一个单元都给其标注重要程度,一个清晰完整的需求框架就出来了。需求有了主次之分,则就容易做出取舍了。
对需求按重要程度进行分类可以认为是需求分析在宏观层面的东西,微观方面则是对每一个需求点如何理解和处理。前者是项目经理或需求负责人的责任,后者则是实际参与需求分析的团队成员的责任。既然是微观方面,则越详细越好,越具体越好,模糊性的词语一定要杜绝,如“大概”、“应该”、“可能”等等。另外,大家还容易犯的毛病,就是文档描述过于简略,凭自己的感觉理解去叙述,把文档的读者只定义成自己,而不是完全基于需求事实,将文档的读者定义成所有参与项目的人。初入行者和懒于写文档的人都容易出现这种问题,但结果是,概括性的语言无限放大了大家对需求的理解,造成歧义。所以,需求越具体、详细就越好,磨刀不误砍柴功。
一言一蔽之,需求要先分主次,再具体分析。
大多数情况下,在软件未开发之前,用户对软件功能的要求是非常多的,用一句业内话来说,就是他希望点一下按钮就解决所有的问题。这是用户的理想,当然也是软件供应商的理想,但终归是理想。现实来说,这个要求很难满足,我们惟有对用户的要求一一分析,分清主次,量力而行。
现在很多管理类文档将需求分为合理需求和不合理需求两种类型,这种分类方式本身并没有错误,但在实际判断起来却很难,主要是无法清晰的界定合理和不合理的属性,用户和研发人员的出发点是不一样的,每个研发人员也都有各自的认识,很难确定合理与不合理的标准。因此我更主张将需求按重要程度进行分级,需要解决用户核心问题、必须问题的需求就是重要的,其他的就可以认为是次要的,这就很容易区分了。而且不同的项目可以根据客户与研发人员的共同认识,灵活的定义重要程度的级次,可以都是重要的需求,可以分为重要的和次要的,也可以分为重要的、次要的和更次要的,每个项目都可以有自己的灵活性。需求分类好了,自然就可以在以重要需求为出发点,兼顾次要需求的基础上来进行设计。
问题的关键开始转移到如何具体的对用户需求按重要程度进行分类。这个就是每个项目自己的灵活性了,如果你做的是财务系统,财务数据处理和票据打印就是重要需求;如果你做的是公文系统,文件撰写和流程处理就是重要需求,等等。做为用户和软件研发人员,这方面的共识还是很容易达成的。如果要想做的更好,则可以将一个系统分成若干个子系统,每个子系统又分成若干个模块,模块再划分成功能点,这样每一个单元都给其标注重要程度,一个清晰完整的需求框架就出来了。需求有了主次之分,则就容易做出取舍了。
对需求按重要程度进行分类可以认为是需求分析在宏观层面的东西,微观方面则是对每一个需求点如何理解和处理。前者是项目经理或需求负责人的责任,后者则是实际参与需求分析的团队成员的责任。既然是微观方面,则越详细越好,越具体越好,模糊性的词语一定要杜绝,如“大概”、“应该”、“可能”等等。另外,大家还容易犯的毛病,就是文档描述过于简略,凭自己的感觉理解去叙述,把文档的读者只定义成自己,而不是完全基于需求事实,将文档的读者定义成所有参与项目的人。初入行者和懒于写文档的人都容易出现这种问题,但结果是,概括性的语言无限放大了大家对需求的理解,造成歧义。所以,需求越具体、详细就越好,磨刀不误砍柴功。
一言一蔽之,需求要先分主次,再具体分析。
相关文章推荐
- 软件研发之需求分析(二)
- 软件需求与分析课堂讨论
- 软件需求与分析课堂讨论一
- 软件需求分析课堂讨论1
- 软件项目的需求分析
- 浅析-软件需求分析
- 如何进行软件需求分析
- 细谈软件需求分析过程:提取、抽象、升华
- 部分关于需求分析和软件构架的书籍
- 需求分析与软件可靠性保证
- 论软件需求分析方法和工具的选用—论文4:IC行业内部的CAD应用
- 功能点分析方法在软件需求管理中的应用
- 软件项目需求分析的文档都包括哪些内容
- 对软件工程需求分析及创新项目等实际问题给提出建议
- 03需求工程-软件建模与分析阅读笔记之三
- 为什么软件项目的需求分析工作比较困难
- [转]如何进行软件需求分析
- 对软件工程需求分析的意见
- 软件开发:需求分析的20条法则
- 软件工程(三)软件需求分析