DOC《Think in Requirement》

二则即使是迭代增量式开发,每一个迭代片断仍然是一个瀑布式开发过程;

三则在迭代增量式开发过程中,如果不能保证需求的质量,将不可避免地增加迭代次数,这对项目在时间上的保证是不利的. 所以综上, 正确的需求 无论对采用哪种开发模式都至关重要,对项目的成败具有重要意义. 读者可能会问:什么是 正确的需求 呢? 笔者对这个问题曾沉思良久,那是绝然不能用 秒 来计算的.现在笔者想谈谈自己一些不成熟的但又十分认可的想法. 笔者将 正确的需求 概括为 内涵一致,外延完整 八个字.具体来说包含两个基本特征:一个是一致性,另一个是全面性.这两个基本特征既各自具有自己独立的内容,又密切联系. 下面我们就来谈谈第一个基本特征. 2.3.1 一致性与正确的需求 记得一日,笔者某软件发烧友对我神侃起一本书,名曰《人月神话》.对笔者这种半专业人士,往往望文生义,笔者先是猜想:可能是写嫦娥奔月的故事吧?又闻是一老外Brooks所写,更是茫然.老外怎么关心起嫦娥奔月来了呢?继续猜想,笔者认为极可能是写Apollo登月的,但想想还是不对,他怎么可能有如此高的兴致关心航天事业来了呢? 随着交流的深入,笔者渐渐明白该书原来是一本项目管理的书,该书的笔者Brooks曾在IBM主持开发著名的360系列,正是因为《人月神话》这本书中的若干深刻见解使人们开始重视软件的项目管理.其中提出的重要问题 软件开发有没有银弹 奠定了世界软件精英思考的方向.而Brooks因为对软件项目管理的卓越贡献,获得了计算机界的 诺贝尔奖 ――图灵奖. 读者这时可能有些不耐烦了: 本想了解你关于一致性的分析,怎么开起'

先进事迹报告会'

了? 读者有所不知,笔者关于 一致性 的思考,始点正是Brooks的《人月神话》. Brooks在《人月神话》提出的核心观点是 概念完整性最根本地决定软件的最终质量 .请注意这么几个字: 最根本地决定 ,笔者于是意识到 概念完整性 一定非常神圣.进一步了解到Brooks关于 概念完整性 的确切内涵:设计的一致性. 笔者由此获得了 一致性 的概念.但却有些失望:一则 一致性 仅仅是针对 设计 而言;

二则Brooks没有确切定义 一致性 的内涵,难于把握和应用. 后来随着知识的增多,了解了一下软件开发史.其实,在软件开发早期,需求分析和系统设计不分家.况且,结合当前的需求分析工作,笔者更进一步认为:需求分析带有设计性质. 读者可能会说 真好笑,需求分析怎么又设计起来了? 请听笔者慢慢道来. 说需求带有设计性质.是因为需求分析虽然不像当前系统设计一样侧重于技术层面,但需求分析围绕客户关心的问题与系统开发的价值,详细界定了系统表现层的结构:展现的内容、页面流转逻辑、用户与系统间的交互规则.因此,需求分析师实质上是系统表现层的设计者.笔者的观点正是针对此点而发的.尽管需求分析对表现层的结构设计仅仅是在某个抽象层次,但笔者要说的是:相对需求定义,已经有了相当程度的深化. 于是,笔者第一则失望就被化解了. 下面笔者想谈谈 一致性 的内涵问题. 什么是一致性呢?笔者认为可以作如下定义:必要关联因素(或事物)之间的相容性,即内涵一致.具体包括如下两个方面: 其一,从纵向来讲,整体和部分之间相互贯通. 那么什么是整体和部分之间的相互贯通呢?笔者认为,这由整体和部分的内在关系来决定.一般而言,整体确定主题、统一规则和标准,界定范围,限定各部分展现的内容和方式;