语言和符号系统
语言是我们表达思想的工具，也是某种文化的载体。在开发系统方法中，我们也有语言，那就是符号系统。相信所有人都遇到过因为语言不通而产生的交流障碍；同样，在符号系统上，我们也遇到了交流障碍。
语言文字所传递的信息包括“内涵”和“外延”两部分。人们在说话传递信息时，往往会附加上各种语态、表情、动作作为对其所说语音的外延；甚至我们可以认为，因为我们来自各个不同的省份县市，各种不同的方言乡音也传递了丰富的外延。
于是，对于同样的事件或需求，我相信没有任何两个人的描述是完全一致的。承认这一点对于我们直面需求分析的困难会有很大的帮助。
我们这里给出优秀符号系统的两个重要要求（当然这仅仅是众多要求中的两个），以帮助我们将来使用这些符号。例如说，首先符号系统要能够比较全面地表述我们所遇到的绝大部分问题；其次为了适合产品开发的过程化，符号系统的表述结果要比较容易保存和修订。这也是对一个优秀的CASE和CAD工具的基本要求：在任何时候都可以保留并修改我们当前的结果。
实际上，几乎所有的符号系统本身是不可能完全“直观”和“易读”的。
如果，要让所有相关人员都能够理解某种符号系统，那么，最直接的办法就是培训这些相关人员。下面的步骤可以测试一下当前的映射图到底有多直观：
把每一幅映射图展示给那些不知道这种符号系统的人来看。这种方法能够揭示出符号系统中不直观的地方。当然，也有可能揭示的是这个映射图中需要表达的那部分信息本身的不直观。
让每个人用自己熟悉的符号系统重新描述一遍对映射图的理解，然后再让一个理解这两种符号系统的人来核对。这样可以揭示映射图中的一些人为的假设。
使用某种能够把别的符号系统自动转换成某种“标准”的符号系统的自动化工具。
上面讲到了因为不同的符号系统导致的对映射图的理解的分歧，这就相当于由于语言不通而导致了交流障碍。最直接最常见的办法就是推迟需求工作的进度，先让大家都来学习这种语言（或符号系统）。但是，这也是不切合实际的，因为这样有可能还会让大家失去对需求过程的兴趣和冲动。经验表明，把这些学习时间安排为需求阶段的一部分会好一些，因为这时候我们可以一边学习语言，一边解决问题。
特别地，我们需要指出，任何一种符号系统都不可能百分之百地反映需求。下面提出了一些关于如何让开发者较好地表述需求的语言的建议。
在生活（或开发项目）当中，我们往往会遇到一些不明是由的旁人（非专业人员）横加职责，他们往往不愿意或者不屑于花时间来了解设计过程的时候，这时候，建议雇用一个明白事理而又口齿伶俐的调解人会比较有效。
人们不愿意参与设计过程的一个重要原因是现在的所谓“专业设计人员”的高高在上的姿态。千万要注意顾客和旁人（实际上是决定事态结果的裁决者）仅仅是对开发过程不了解，他们在别的方面（比如说法律、业务等）却是专家，这也是需要他们参与的原因。
一部分自动化过程的固执而忠实的拥趸认为他们的“直观”的符号系统很容易被别人看懂。这时候，不妨让他给小组里外的成员培训一下他的符号系统。
对于同一个需求过程中的两批不同背景的专家，常常会倾向于说两种不同的符号系统。那么最好的办法就是用两种不同的符号系统都表述一遍。
用一种大家都能听懂的语言来作为正式文档的语言会比较有效，那么在需求过程中也最好事先指定一种“大家都能理解的”符号系统作为正式文档。如果谁不懂的话，就让他去学好了。
不同母语之间的翻译会有优劣之分，同样不同符号系统之间的翻译也有优劣。优劣的背后就是分歧，也就是歧义。需求过程经历了从真正最终用户——用户代表——需求分析员——需求规格说明书这么一长串的步骤，每一步都是一种翻译，因此保证每一个步骤都是最优的就显得格外重要了。
需要注意的是，需求过程并不完全是瀑布式的。随着过程的深入，我们极有可能会像老牛一样进行反刍。
文章来源于领测软件测试网 https://www.ltesting.net/
