DOC《Think in Requirement》

再说其二,笔者所总结的需求分析工作是以在中企动力的工作经验为蓝本的,管中窥豹,实用而已.其不妥与疏漏之处,还请各位 大侠 指正.如不吝赐教或追求与笔者心灵的又一次绝对碰撞,您可以在致谢中找到我的电子邮箱,并顺便获知我的公开代号. 最后,笔者还有一点小小心愿:希望拙文能给读者带来知识和快乐.如果读者是需求分析师,或是其他对需求分析感兴趣的热血人士,那么笔者的小小心愿就更容易实现了. 多言无益. 现在我们就开始Think in Requirement!

第二章 需求分析的目标 干什么事都要讲个目标.管理学家总结了一条思考的长链:使命――价值――愿景――目标――项目――任务.看到 目标 在这根长链中的位置了吗?不过,笔者在这里所说的目标不同于链条中的目标,特指的是 需求分析的目标 . 那么 需求分析的目标 是什么呢?笔者将其定义为 正确的需求 .本文所要回答的核心问题就是:(1)什么是 正确的需求 ?(2)如何获得 正确的需求 . 本章就从第一个问题开始谈起. 2.1 谁的目标? 要谈论需求分析的目标,首先要谈谈这是 谁的目标 .常常我们可以轻易地提出一个目标,但却不知道这是 谁的目标 ,谁是目标的实现者;

或者即使我们知道了这是 谁的目标 ,但却不知道谁在目标的实现中发挥关键作用.在确定了一个目标,而没有为目标实现所依赖的组织和个体明确地划分职责,定义角色的时候,听到 让我们大家一起干吧 这种话,总是应该警惕的. 那么需求分析的目标是 谁的目标 呢? 读者可能会说: 这还用问吗?不就是需求分析师的目标吗? 笔者认为,这种说法虽然抓住了关键,但却没有在整体上看待需求分析及需求分析所依赖的组织和过程. 实际上,需求分析目标的实现依赖的是一个组织,这个组织中的每个个体通过相互间的协作都对整个需求分析的过程和结果发挥作用,贡献力量.需求分析师只是在需求分析中发挥了主导作用.但如果没有组织中其他个体的参与和协作,结果将是很难想象的. 2.2 成果是什么? 知道了需求分析的目标是 谁的目标 还是不够的,还要问问目标最终表现为什么, 成果是什么 .如果目标失去了展现的载体,那我们拿什么来测度目标实现的情况呢?起码需要一个测度的对象吧. 那么需求分析的 成果是什么 呢?一般称之为 需求规格说明书 .本文则有所不同.成果表现为两个方面:一是需求文档;

一是用户界面.这两个方面具有直接的映射关系[2].需求文档定义了用户界面要展现的内容;

而用户界面则以特定的风格把需求文档中的内容直观化、形象化. 注[2]:本文仅探讨功能性需求,非功能性需求因不在笔者工作范围之内,所以没有考虑. 以后,不作特殊说明,需求成果就是对需求文档和用户界面的统称. 在一般的 需求规格说明书 中,既包含对需求的文字性描述,又包含示意性的界面.需求文档则可以看作是将 需求规格说明书 中的文字性描述提取出来,形成一个文档;

而用户界面则可以看作是将 需求规格说明书 中的所有示意界面提取出来,形成一组关联的界面.此时的用户界面不单单是为了示意,确切地讲是对最终用户界面设计. 需求规格说明书 的这种分化为需求分析的分工和专业化奠定了基础,需求分析师可以专注于需求文档中内容,页面制作人员可以专注于需求在用户界面上的展现. 2.3 什么是正确的需求? 知道了 谁的目标 和 成果是什么 之后,我们就可以详细谈谈需求分析的目标是什么了. 在笔者看来,需求分析的目标是目标的实现者提交的成果要达到什么样的程度,满足什么样的要求.这是对需求成果质量的要求和约束. 前面说过了,需求分析的目标是 正确的需求 . 需求必须是正确的,错误的需求是要不得的.需求分析处于整个项目生命周期的上游,因此,需求分析的质量直接决定整个项目的成败.听说过 上梁不正下梁歪 的说法吗?听说过 根正苗直 的说法吗?一反一正,说的就是这个道理. 当然,读者可能会说 太落伍了吧,这是典型的瀑布式开发思想,现在都提倡迭代增量式开发了! 笔者很欣赏你的博学.但笔者对你的说法不敢苟同.一则瀑布式开发在中国仍然占有一席之地,不能指望所有人都赶时髦;