Ambiguous functional requirements. Definition and examples of ambiguity.

Ambiguous functional requirements are any requirements that:
  • have any kind of ambiguity.
  • have more than one type of interpretation.
    Any task in requirements that can have more than one correct output that is contingent on a different understanding of the task is ambiguous.
    I will start with a simple example from a grade 1 class:

    An ambiguous task can be as simple as dividing 8 in a half.
    What is half of 8?
    Is the answer 4 correct?
    Yes, but other answers like 0 and 3 may be the correct answers to this question as well! It all depends on how you define "a half".
    One more example of a task that is difficult to solve because of its ambiguous nature:

    The following is a developer’s requirement for creating a question for an online brain game for software testers:
    From any word related to software testing, create another word randomly by adding 3 letters. As a result, the following is one of the online questions created by the application:
    Cross out 3 letters so that a familiar software testing vocabulary word will remain.

    Is it difficult to find? To find the correct answer, note that you need to cross out 3 letters as many times as they can be found in the word above. Cross cde two times and you will be left with the word – BUG. What is uncertain is whether or not this was one of the original ideas of the requirement. What was ambiguous?

    This is not a true historical story according to - Urban Legends Reference Pages, but it is very popular on the WEB and related to our topic:

    J. Edgar Hoover, former director of the FBI, always scribbled his views in bright blue ink in the margins of all documents and reports he received from underlings. Sometimes, he would fill all four borders of a typewritten sheet with his observations, handwritten with a fountain pen. Once, an assistant made the mistake of sending him a typewritten page in which the copy ran almost to the edges of the paper, leaving Hoover very little room to write.

    "Watch the borders!" Hoover printed in angry, bright blue block letters across the top of the page.
    And all FBI agents were sent to the Canadian and Mexican borders for the next five days.
    And, lastly, here is a fairy tale about what happened to one ambitious software product manager (who was not a very qualified for his position, in my opinion):
    Once upon a time, a software product manager woke up alone in the morning, looked at his naked body in the mirror, and said "I will never manage to find a wife with my small willy".
    Planning to spend the day drinking away his sorrows, he headed into the kitchen, opened the refrigerator, and pulled out a bottle of beer. He set it on the counter, and was rummaging around for a bottle opener, when the cap snapped off with a loud pop. He looked up, and watched a djinni come out of the bottle and ask him to make a wish.
    The software product manager immediately complained "My willy is so small! Can you make it so that it reaches the floor?"
    "Your wish is my command", responded the djinni, and disappeared in a puff of smoke. The software product manager headed into his bedroom and stood in front of the mirror. As he watched, his legs slowly became shorter and shorter, until finally his wish was granted, and his willy really did reach the floor.
    Suddenly, he understood why his clients always seemed to complain that the software he was responsible for never did what they expected.
    Please take this short quiz. Answers, which are counter intuitive but logically correct, are provided.
    1. Question: Where was the Declaration of Independence signed?
      Answer: At the bottom of the page
    2. Question: Funny River flows in which state?
      Answer: Liquid
    3. Question: What is the main reason for divorce?
      Answer: Marriage
    4. Question: What can you never eat for breakfast?
      Answer: Lunch & dinner
    5. Question: What looks like half an apple?
      Answer: The other half
    6. Question: What will happen if you throw a red stone into the blue sea?
      Answer: The stone will become wet
    7. Question: How can a man go eight days without sleeping?
      Answer: No problem, he sleeps at night.
    8. Question: How can you lift an elephant with one hand?
      Answer: You will never find an elephant that has only one hand..
    9. Question: If you had three apples and four oranges in one hand and four apples and three oranges in other hand, what would you have?
      Answer: Very large hands
    10. Question: If it took eight men ten hours to build a wall, how long would it take four men to build it?
      Answer: No time at all, the wall is already built.
    11. Question: How can you drop a raw egg onto a concrete floor without cracking it?
      Answer: Concrete floors are very hard to crack.

    So try to avoid ambiguity because of communication problems it can cost. This is especially a good idea for software requirements related to critical software like medical and other safety-critical software.

    What is functional requirement document?
    A functional requirements document is the most important document for development and it describes what this system should do. What happens when you define ambiguous functional requirements?
    Sometimes implementation of these requirements can create completely unexpected results perhaps because of these ambiguous statements. This applies to any kind of development but particularly to new software development and testing.

    Define ambiguous:
    Ambiguity is the property of being ambiguous, where a word, term, notation, sign, symbol, phrase, sentence, or any other form used for communication, is called ambiguous if it can be interpreted in more than one way. [wiki]
    Define requirements:

    a requirement is a singular documented need of what a particular product or service should be or perform.

    Define requirements:

    Requirements (IEEE) (1) A condition or capability needed by a user to solve a problem or achieve an objective (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard. specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2). See: design requirement, functional requirement, implementation requirement, interface requirement, performance requirement, physical requirement.

    Define Specification:

    Specification (IEEE). A document that specifies, in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a system or component, and often, the procedures for determining whether these provisions have been satisfied. Contrast with requirement. See: specification, formal; specification, requirements; specification, functional; specification, performance; specification, interface; specification, design; coding standards; design standards

    Define Software requirements specification

    A software requirements specification (SRS) is a complete description of the behavior of the system to be developed

    Define requirements gathering:

    requirements gathering The task of communicating with customers and users to determine what their requirements are called requirements gathering.

    On this site you can find jokes about software testers, software testing, QA, funny online quiz for software testers as well as information about software testing like software testing dictionary, samples of software testing documentation including test case template and more ...

    If you have navigated to this page from another site, and you would like to go to the main page software testing humor, please click:
    Software testing humor and jokes Main Page
    © June 2006 © 2009