Here is a heuristic - "All formal/written requirements are vague – only exception is when requirements are collected using a process that does not involve any human”
(Wait … if at all such process exists, where it came from? There must have been a human being such a process needs to be designed by a human … …hence there is a human element here too … Is above heuristic, an axiom or hypothesis or law?)
So there will be always gaps between "Customers view", "end user view" and programmers view". ET can help you to explore these gaps.
Jerry Weinberg in his book on Exploring requirements.. - gives the example of a nursery rhyme "Mary had a little lamb" and goes on to prove that there can be at least more than a dozen ways of interpreting above sentence ... Remember we typically deal with requirements documents of 50-60 pages ... Imagine the amount of misinterpretation possibilities....
I was discussing with this with Michael Bolton, recently. I said “I can say for sure that as long as requirements are written in English, they will be ambiguous. English is a funny language". He immediately shot back and said "you can say same thing with Hind, Tamil, French or any other human language"... I laughed and said “well, you are right, how about this ... One way to get unambiguous requirements is to express them formal languages like computer programming languages ... say Java. "Class MyClass" in java is nearly unambiguous". Michael continued "Here, the ambiguities come, not from written requirement but from the process of translating what is there in one’s mind to formal language".
That brought us to the real truth about software requirements ... "As long as one human tries convert what is there in her mind to some thing that written form; mind to document or mind to mind data transfer .... There will be ambiguities"
People can say a thing in different words but might mean one thing or they might say one thing and might mean differently....
Welcome to the world of software ... a discipline with high human content ....hence we need skilled software testers to keep world "lighted"
First thing you need to acknowledge is Requirements are fallible - they can be wrong - horribly incorrect (so will be corresponding program). If you base your entire testing only on requirement - you can go wrong by miles ... beware of this requirement based testing trap...
BTW there is a type of testing called requirement based testing ... can you imagine how narrow it can be?
You might have heard of people counting requirements … Can we count requirements as we count apples and pizzas?
What do you say about this concept of Requirements Traceability Matrix (RTM) – a holy thing that most swear by? Fundamental principle on which the concept is that “requirements and test cases can be counted”
Please… for God’s sake understand requirements, bugs, test cases are not real things and can not be counted in a way you count physical things, they are mere concepts, ideas …
