系统设计前的需求探索:降低需求含混性的工具和方法

发表于:2008-01-16来源:作者:点击数: 标签:需求
引言 需求分析 阶段需要经历两个步骤:首先,提出问题的人说一些话,以告诉帮助他解决问题的人他要干什么,这就是“问题陈述”,即通过语言或者文字对某个关注点的细节进行表述。然后,解决问题的人和提出问题的人进行沟通,以确证这个问题的细节,这就是“

引言

    需求分析阶段需要经历两个步骤:首先,提出问题的人说一些话,以告诉帮助他解决问题的人他要干什么,这就是“问题陈述”,即通过语言或者文字对某个关注点的细节进行表述。然后,解决问题的人和提出问题的人进行沟通,以确证这个问题的细节,这就是“探索需求”,这是一个反复沟通的过程。

    需求分析在现代软件开发中的地位日趋重要,这也意味着我们认为现今的需求过程尚不完善。这种不完善很大程度上体现在“问题陈述”和“人们真正想要的东西”之间的差距上,或者说,“问题陈述”没有能够陈述清楚“人们真正想要的东西”。

    在过去几年,软件过程和软件工程流行的时代,很多人已经被时尚所左右,言必称自动化,开口即软件工程,仿佛所有的开发问题都已经解决。更有甚者,有人还认为需求分析中的歧义的根源是因为“人”的参与。有人认为“人”的不确定性导致了“陈述”的不确定性,由此导致了“人”提出的“问题陈述”的歧义。并且,他们认为只要排除掉需求分析过程中的人的因素,然后用一种严格论证、高度自动化的、规范的方法论来进行分析,就能够消除这种歧义了。

    但是,我们无法“剔除”具有严重不确定性的“顾客”;同样,我们实在不能不把顾客当人看待的。

    自动化方法干的是“大事情”。40年前需要很多个星期才能完成的工作量,今天只需要一个小时就能够搞定。而且,由于自动化工具的发展,我们还开始挑战那些在以前想都不敢想的系统。然而,随着工具的进步,软件产品在可用性方面的口碑却并没有多少提高。

    对于那些需求明确、陈述无歧义、一定程度上模式化了的内容,自动化方法非常擅长;但是也还有一些涉及到人性心理方面的棘手问题却无法用这些方法来解决。换句话说,只要是有规律的、统一的开发过程,自动化方法非常擅长;而在不同项目或产品之间的差异和个性化,则需要更细致的分析。

    我们不妨做一个简单的计算。

    规模为S的项目中有P%的问题为公共问题,有Q%(Q+P=100)的问题为个性问题。

    在时间T1时,我们每解决一个公共问题需要投入T,每解决一个个性问题需要投入M。解决个性问题在整个项目中所占的投入为:R1=M×Q/(T×P+M×Q)。

    在时间T2时,我们每解决一个公共问题需要投入t,每解决一个个性问题需要投入m。解决个性问题在整个项目中所占的投入为:R2=m×Q/(t×P+m×Q)。

    从T1到T2,自动化水平提高了,于是有T>>t,公共问题和个性问题的比例变化很小,而且对于每个个性问题的投入也变化很小,即有M≈m。从而可以得到R1<<R2。

    这表明,随着自动化水平的急剧提高,我们在个性问题方面的投入比例也急剧提高。

    个性问题,亦即是人性方面的因素反而随着自动化程度提高而愈显得重要了。这一特征在那些具有多年开发经验的人们当中早已成为了共识。也就是说,经验丰富的专家们在技术任务上的投入少了,而在人性因素方面的投入更多了。

 

原文转自:http://www.ltesting.net