采用[ICONIX] 方法实践分析和设计之三 [需求复核]（转）
需求复核旨在确保用例和域模型同时满足客户的功能性需求。同时确保客户知道开发小组
将根据这些需求做何种设计。同时它也是系统分析阶段的一个里程碑(milestone)。
这一阶段在ICONIX方法中的位置如下图：
三巨头的首次聚首：客户代表，开发小组代表，经理就已有的工具（用例，原型和域模型）
帮助客户理解其需求，并确定系统的功能需求。在这一过程中，ICONIX方法认为可跟踪性
（traceability）是非常关键的，它强调清楚每种需求是如何转换为一个或多个用例，以及域模
型中的一个或多个类和一个或多个原型元素如何同这些用例协同工作，从而实现需求。
域模型和用例模型在前两章中已做了讲解并进行了初步实践。而原型在之前还没有涉略，
这里有必要做一下简要介绍。
首先，ICONIX方法中的所谓“原型”与XP中所强调的原型有所不同。 ICONIX方法强调
不要用代码来创建原型（也可以是可工作的前端,甚至是两者之间的东西），而用铅笔在白纸上
绘制线条图，并称之为交互流程图（interaction flow diagram）。这种图实际上是一张很大
的纸，上面是小型的屏幕线条图以及在这些屏幕之间的导航选项。这种 GUI原型通过是发现和
探索用例的“起跳点”。确保用例文本同原型指出的导航情况一致，有助于确保创建的系统是
正确的。如果没有任何可视化框架供参考，则用户界面设计人员创建的东西可能同用例描述的
用户需要不相符。
然后，将这种思想深入下去，探讨 GUI和系统行为。就系统的外观方面同用户反复交流，
了解两三个屏幕的情况后，编写相应的用例。同时用例文本应与相应的GUI元素相符。
这里的用例文本已涉及 GUI的细节描述了。但正如ICONIX方法中所说的，“有一些杰出
OO专家对此持相反观点，他们认为用例文本不应描述大量细节，用文本尽可能抽象。而INCOIX
方法认为同具体的用例相比，驱动抽象用例，以后的代码的效率将更低”。
这一阶段同时也是对用例文本进行检查的阶段，而书写用例文本的方式在上一篇文章中已基
本上讲过了。
好了，有了上面一堆知识的介绍，相信大家对本文将要进行的实践过程有了一个大致了解。
下面就开始实践一下需求复核:)
下面所列的需求摘自(问题)域建模阶段的需求描述：
注册的用户可以在自己的管理后台对文章, 评论, 留言, 链接, 相册, 下载文件(格如RAR或ZIP),
签名, 个人信息，blog基本信息设置等相关信息。
用户在登陆后可以在前台回复本人其他人的文章。
后台管理员可以管理系统中所有人的文章，包括置为精华贴，创建俱乐部（或群）之类的组，
对用户注册信息进行审核等。
当看到这一段文字再对照如下的用例图（来自用例建模）
我突然发现还有下面几个需求未被"转换"成用例:
1.下载文件(格如RAR或ZIP)。
2.用户在登陆后可以在前台回复本人其他人发表的文章。
3.后台管理员可以管理系统中所有人的文章。
4.管理员设置精华贴。
当然如果需求继续挖下去还会有更多的东西会被发现:)
这里的设置精华贴可能做为管理文章用例的子用例会更合理，并且该用例是限于管理员才能调
用。而1和2的需求这里将会做为两个用例来补充到用例图中。经过上面的查缺补漏后，BLOG的用
例图变成了如下的样子。
同样在检查"删除文件"用例时，假定该用例描述是这样的:
基本流程：
用户在上传文件列表中点击相应文件上的删除按钮，系统提示是否删除该文件，在管理员
确认后则从文件列表中删除相应的文件。
分支流程：
如果用户在提示框中点击取消删除按钮，则系统将不会进行任何操作并将页面重定向到"
上传文件列表"页面。
因为这里的用例文本描述的操作界面有些模糊，这里做一下简要说明,参考用户提供的GUI :
看到这里，我发现有一个用例被"丢掉了", 那就是“浏览文件列表”，而这一步是非常关键，因
为在GUI中，它关联着删除和下载文件两个可能的用户操作，因此这里加上它十分必要，相应也要修
改一下用例图并补充相关的用例描述如下:
浏览文件列表(UC30)
基本流程：
用户在浏览文件列表时，系统显示文件名称，大小，类型，文件描述等信息。同时在相应
文件名称左侧显示下载和删除按钮。
分支流程：
如果用户没有上传任何文件，则浏传文件列表页面提示用户还未上传任何文件。
另外有一个名词出现在该描述中就是上传“文件列表”，它在域模型中还未出现，这里也一并补
上（这里要确保用例文本参考域对象）。
本来在这一章所作的事情会很多，但基本上都是在"交流"和"确认"层面上的操作。因为在前两篇
文章中做的工作比较粗糙，特别是分析需求，用例合并，用例文本描述，所以感觉这一章节能拿到桌
面上讨论的并不多。同时相信这也是不少人在实际工作容易犯的毛病，正是这种急功冒劲才导致在后
续工作时出现“补课”的情况。
ICONIX方法通过需求复核这一步从而缓解这一问题所带来的副效应。它既是总结同时也是给我
们"过热"的项目分析“踩刹车”，让我们再次清醒的从用户角度理解和思考我们要开发的系统。同时
书中对不进行需求复核，而让编码人随心所欲写代码这一现象有如下描述:
“需求复核能够挽救该项目（C3, XP引以自豪的项目）吗？我们不敢肯定，但要指出的是，让编
程小组决定需求优先级，且项目赞助商一道对这种优先级进行复核，必然会牺牲日程安排”。
本文到这里就要结束了，但我还是有"没把问题讲完"的感觉。也许正是这种对需求分析未做到位
的恐惧一直在影响着我，所以我对这篇文章不满意，相信大家也会有这种感觉，但事情应该从两面看，
也许正是这种不尽如人意才会让我在将来的开发中重视并想法杜绝类似事情的再度发生。
最后再把最常见的需求复核错误列出来，大家可以结合本文内容讨论一下，我会将您的反馈作为
修改正文的资料，在积累到一定数量后统一更新，并附上您的大名。
十个种最常见的需求复核错误
10.根本不进行需求复核，而是让编码人员随心所欲地编写。
9.不确保用例文本符合所需的系统行为。
8.不使用任何GUI原型或屏幕模型等帮助验证系统行为。
7.用例高度抽象，让不懂技术的客户就像看天书。
6.不确保域模型准确地反映真实世界的概念性对象。
5.不确保用例文本参考域对象。
4.不质疑不区别任何分支流程的用例。
3.不质疑每个用例是否考虑到了所有的分支流程。
2.不管用例是否使用被动语态书写。
1.不管用例是否占4页的篇幅。
