击破“正确”的神话，需求评审思维方式
本帖最后由 pmlpml6509 于 2012-3-24 10:46 编辑“做正确的事！”，需求培训的教师都是这样描述写需求的重要作用！
这是一句最有用的话。因为，正确、有效的需求才有正确的设计； 正确、有效的设计才有正确的实现；正确、有效的实现才能满足需求。
这是一句最没有用的话。因为，需求其实并不需要写，那是“客观存在”。当你产品上市后，客户会用脚去投票，去验证你所写的“需求”，所做的产品功能。
其实，写“需求”是一种智力创造劳动。用一种合适的方式表达（揣摩）能给客户带来最大性价比价的信息服务（流程优化、信息处理、数据通讯）。所以，许多伟大产品设计者并不知道他的伟大。例如：第一个写BBS软件的人，并不知道现在BBS尽有那么多用途和功能。这是IT技术的发展中最优特色的地方；USB标准化后，谁预料它的增值产品是手机充电器呢。
写的“需求”只是沟通工具。它告诉开发人员需要实现什么特性，告诉其他利益相关者如将何用。大家能达成共识，避免一些经济纠纷。
需求存在缺陷。揣摩的东西，大家理解不一致应该是家常便饭了。主要包括：表达缺陷（模糊、歧义、技术性过强、图表错误）；获取过程缺陷（略）；需求模型（元素）缺陷，即组织、利益相关者、用例、用例描述、非功能约束等等的识别缺陷（遗漏、错误）。
由于需求人员的特殊地位，所以很少人能够挑战他们的“权威”。当一个测试人员缺乏丰富领域知识时，可以用以下的思维方式，帮助你有效识别一些需求文档中的缺陷
概括为四种思维模式。击破需求“正确”的神话，这是测试人员的基本功力。
逆向思维
问题：“能不这样吗？”
案例：“ATM能不存款吗？”。回答：能，取款机！可以省设计成本。Good！存款是一个可选需求。
案例：“存取款ATM能存款吗？”。回答：不能！Good！，否则项目就要改名或目标。
极限思维
问题：“存在反例吗？” “很大（小）如何？”
案例： “所有网页在5秒内响应！”。回答：有，网络阻塞时就达不到了。这是一个不可达的需求。
模型化思维
问题：“存在悖论吗？”，“状态可达吗？”
案例：“Office产品中，a.doc文档写保护，新文档插入a.doc，那么？”。 回答：这是悖论！因为a.doc文档可读，一定能完整插入到一个新文档，新文档存为a.doc，所以a.doc不可能写保护。doc写保护功能，是Office软件不可解决的安全BUG。
严谨的思维
问题：“结果可观察、可量化、可验证吗？”
案例：“系统界面美观、风格统一”。回答：无法量化与验证，这是真要求，但是伪需求。
案例研究：经典问题，"三角形判定"。
原始需求：“The triangle program reads three numbers from a punch card（现在没有穿孔机，就使用键盘输入） and interprets them as the sides of a triangle. The program then states whether the triangle is scalene, equilateral, or isosceles.”
第一个问题：“不是三角形需要判断吗？” BUG：应用缺乏非三角形输出；
第二个问题：“输入负数或很大的数如何？” BUG：应用没有限制输入范围；
第三个问题："有没有三角形是不可判定的？”么有那高水平分析；
第四个问题：“等腰可验证吗？”BUG：（可选的）我怎么验证它的结果，请它自己画出来？ 我还是没弄清楚你想讲什么。。不好意思，说简单 判断需求是否必要、正确的基本方法。
假如：你要做一个聊天系统。那么管理朋友，聊天，传文件，电子白板，都是聊天系统的用例吗？
你只需要问“能不这样吗”？你就可以暂时忘了传文件，电子白板这两个用例，直到你打算做支持多人协作聊天工具时，电子白板才是一个不能不要的用例。
通过问问题，你才知道软件需求中有许多暂时不必要的内容，这样才能做好敏捷开发。
页:
[1]
