快速理解需求

 

快速理解需求的捷径：需求宣讲
发布时间: 2011-2-15 13:36    作者: 肖利琼    来源: 51Testing软件测试网采编

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 推荐标签： 需求管理 软件测试

　　识别庐山真面目——分析需求

　　测试需求的获取，是测试工作迈开的第一步，这在上节做了介绍，接下来是在有了需求后，如何理解它、分析透它，成了问题的关键。也只有解决了这个问题，才能提取出具体的可操作的测试对象出来。

　　1、快速理解需求的捷径：需求宣讲

　　软件需求是软件项目开发的依据，代表着用户的需求，是软件设计及软件测试工作的入口，在整个软件项目开发过程中起着举足轻重的作用。对需求的理解是否到位，在很大程度上影响着开发过程的效率。曾经有个小项目（整个项目时间约两个月），需求不多，在进行需求评审时，包括开发及测试人员都认为理解了需求，但在后来版本测试中才发现，有一个重要需求点，开发人员与测试人员的理解完全不一样，到底谁的理解才是对的呢？双方找来需求讨论，恰恰需求设计人员对这一块的理解也讲不太清楚，写在文档中的描述就更不用说了。也就为此一点，开发整改设计及编码，测试整改测试方案及用例，最后版本的发布推迟了两周。俗话说“吃一堑，长一智”，通过这样的项目事例，我们需反思整个开发过程做得不够的环节，就“开发过程中如何更好地理解软件需求”有以下几方面的最佳实践。

　　需求宣讲的组织：需求基线一旦形成后（即需求完成第一版后），启动内审，通知项目组相关人员事先预审，给出问题反馈的截止时间与内审时间。

　　介绍需求的背景：需求编写人宣讲需求，介绍需求的用户背景。这点很重要，让开发及测试人员能清楚知道用户的用途，实现后的软件是用来做什么的、能满足用户哪些要求、能给公司创造什么样的价值等，使开发及测试人员的工作目标很明确，处处从用户立场考虑。

　　需求宣讲内容：需求宣讲是否需把所有内容都讲一遍？回答是肯定的。正如前面所述，需求的至关重要性，如果需求内容多，可分开多次宣讲。当然讲解时，也要分开重难点，对于大家容易理解的需求（如之前项目做过或众所周知的需求）可以几句话带过。

　　辅助答疑式宣讲：在需求宣讲时，对项目组成员收集到的问题，一一进行解释，回答提问者疑问的同时，也分享给其他同事。

　　有一个事实我们不得不承认，需求不可能详细到面面俱到，总会存在着隐含需求，这种隐含需求的理解会体现出你对需求的掌握程度。对于这种情况怎么办呢？无论对于开发还是测试，如果自己意识到了，但不能确认，把问题记录下来，与需求确认，并要求需求补充明确。

　　需求的设计也不可能是完美无缺的，在测试活动的整个过程中，特别是在设计用例的过程中，测试人员会发现不少有需求定义的Bug，此时把它也录入缺陷库，作为一个缺陷来跟踪管理是一个不错的方法。俗语说“好记性不如烂笔头”，事实证明，只在口头上说的事，需求人员容易忘改需求，使得最后测试用例与需求对应不上，且给后续加入项目人员的工作增添麻烦。后面常会发生“这个地方的需求与实现不同，是以需求还是以实现为准”的局面。

　　2、需求定义也会错并不是谎言

　　需求定义是否存在二义性，一直以来是衡量需求是否明确的一个标准。尽管需求设计人员采用了图、表等图文并茂的方式来表达，但面对有着不同背景的读者群，同样一段话，理解的结果就是不一样。特别是对于一些需要有一定背景知识的需求，不是理解不到位，就是理解错误，这也就有了显式需求与隐式需求的叫法。显式需求指有明确定义的一系列约束软件实现的要求，可以是有给定具体值的数据字典，或有序的业务流程图，或一段介绍业务功能的需求描述等。隐式需求并不是需求设计人员特意隐藏，更多的是由理解人员对某方面专业知识，或对产品的业务了解程度有限导致的。例如：某软件需求中有一句这样的定义“对用户产生的数据，需每天定时备份（默认为每天晚上12：00，用户可设置），并可按需生成书面报告，报告中的数据不存在法规风险”。那么，此句话中的“法规风险”具体是指什么呢？这正是需求背后的需求，也就是隐式需求。

　　隐式需求的识别要求较高，分析需求时，测试人员能否过滤到，直接影响着后续测试工作的有效性与全面性。另外，对显式需求中存在的错误是否能及时发现或意识到也同样重要。下面是一个需求定义中存在缺陷未及时发现的案例。

 

案例】需求定义隐含缺陷

　　问题现象：软件版本国际化后，输入限制变小了？

　　问题背景：某软件有可输入用户信息功能，需求是这样定义的：姓名可输入16个中文，32个英文，也即最多输入32字节字符。于是软件开发在实现此输入功能时，“姓名”字段的长度限制为32 Bytes。但是有一天，软件需进行国际化实现，以支持法语、俄语、西班牙语等。开发人员于是在字符的编码格式上把原来的GBK换成了UTF8。这样一来，对于每个字符的编码是不固定的（英文除外），测试人员发现原来中文可输入16个汉字，现在只能输入10个汉字了，于是提了一个Bug给开发。而开发人员认为是需求定义考虑不全面的问题，需求后来改为能输入32个字符，这个字符无论是什么符号（中、英、俄等语言）都一样。

　　问题分析：初看“姓名可输入16个中文，32个英文，也即最多输入32字节字符”这句需求，是明确的，不存在二义性。当软件只支持中、英两种语言时，它也是没问题的。但是产品进入国际化市场是必然趋势，需求设计人员当初定义此条需求时，是否考虑了这一点呢？如果考虑到这一点，是否又能意识到目前定义的局限性？这让笔者领悟到“需求设计人员要有软件设计相关知识的重要性”。从开发人员角度分析，在编码格式转变后，表面上软件是被国际化了，但是否对原有功能造成了影响，并未无及时提出。从测试角度分析，在分析需求，同时也在对需求进行测试时（在本书的第8章需求测试部分有单独介绍），同样并关注到。

　　思考：类似这种需求定义不合理问题，测试人员该如何在早期发现，这正是需我们解决的问题。可能有不少测试朋友会觉得诧异，笔者也曾多次听一些开发或测试人员提到“怎么需求也会错？”需求定义错误的原因很多，如需求定义者并没有真正理解用户的需求，文字表达上引起的歧义，需求写过头了，如把对设计的要求写进等。案例中需求定义“也即最多输入32字节字符”便是一个例子，“32字节字符”是一种开发语言，而不是用户需求。另外，采用需求评审、需求宣讲、需求测试的方式对挖掘隐含需求都是有帮助的。

相关链接：

 

具体到一个项目中，当你接手一个功能的时候，首先应该了解需求，这个过程中一定要求甚解，要把需求吃透，甚至要把一个需求点周围的东西都了解清楚。这是一个痛苦的过程，工作量会很大，而且充满挫败感。但是这是一个必须要过的坎，做到这一点，后面写测试用例，执行测试，报bug，这些只会越来越轻松。

 

=============================

By ME:

1、透彻理解需求很重要。这是一个痛苦的过程，工作量会很大，而且充满挫败感。
2、站在用户的角度理解他为什么需要这个功能，站在设计者角度考虑他为什么这样设计，站在测试者角度分析容易出现的问题。
3、怎样快速准确的理解需求？

　　需求宣讲的组织：需求基线一旦形成后（即需求完成第一版后），启动内审，通知项目组相关人员事先预审，给出问题反馈的截止时间与内审时间。
　　介绍需求的背景：需求编写人宣讲需求，介绍需求的用户背景。这点很重要，让开发及测试人员能清楚知道用户的用途，实现后的软件是用来做什么的、能满足用户哪些要求、能给公司创造什么样的价值等，使开发及测试人员的工作目标很明确，处处从用户立场考虑。
　　需求宣讲内容：需求宣讲是否需把所有内容都讲一遍？回答是肯定的。正如前面所述，需求的至关重要性，如果需求内容多，可分开多次宣讲。当然讲解时，也要分开重难点，对于大家容易理解的需求（如之前项目做过或众所周知的需求）可以几句话带过。
　　辅助答疑式宣讲：在需求宣讲时，对项目组成员收集到的问题，一一进行解释，回答提问者疑问的同时，也分享给其他同事。
　　有一个事实我们不得不承认，需求不可能详细到面面俱到，总会存在着隐含需求，这种隐含需求的理解会体现出你对需求的掌握程度。对于这种情况怎么办呢？无论对于开发还是测试，如果自己意识到了，但不能确认，把问题记录下来，与需求确认，并要求需求补充明确。
　　需求的设计也不可能是完美无缺的，在测试活动的整个过程中，特别是在设计用例的过程中，测试人员会发现不少有需求定义的Bug，此时把它也录入缺陷库，作为一个缺陷来跟踪管理是一个不错的方法。俗语说“好记性不如烂笔头”，事实证明，只在口头上说的事，需求人员容易忘改需求，使得最后测试用例与需求对应不上，且给后续加入项目人员的工作增添麻烦。后面常会发生“这个地方的需求与实现不同，是以需求还是以实现为准”的局面。

 

流程改进：

PO了解了需求后，作出一个说明文档，会议开始前发给与会者；与会者仔细阅读该文档并整理问题（包括理解困难的和认为有问题的）；PO开会宣讲，回答与会者的提问；会后整理会议记录，并将会议中提出的问题或者建议整合到需求文档中；将补充过的文档发给项目组所有成员；其他有问题者继续提问，问题解答后如有必要可以在补充到需求为文档中。