Comments on: Writing Unambiguous Requirements http://tynerblain.com/blog/2006/06/12/writing-unambiguous-requirements/ Software product success. Sun, 12 Feb 2012 19:10:25 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: Scott Sehlhorst http://tynerblain.com/blog/2006/06/12/writing-unambiguous-requirements/comment-page-1/#comment-512007 Scott Sehlhorst Wed, 29 Jul 2009 14:54:24 +0000 http://tynerblain.com/blog/2006/06/12/writing-unambiguous-requirements/#comment-512007 Thanks David! Quick reply - MRD = Market Requirements Document. But from now on, it is indeed "Merde!" Thanks David! Quick reply – MRD = Market Requirements Document. But from now on, it is indeed “Merde!”

]]> By: David Robinson http://tynerblain.com/blog/2006/06/12/writing-unambiguous-requirements/comment-page-1/#comment-511919 David Robinson Wed, 29 Jul 2009 09:19:23 +0000 http://tynerblain.com/blog/2006/06/12/writing-unambiguous-requirements/#comment-511919 Oops, a bit of ambiguity straight away with "MRD", an undefined term :-) I can take a stab at R and D, but no ideas on M... I'll check acronym buster. I predict if I have to write an MRD it'll be about an hour before I start calling it a "merde"! Oops, a bit of ambiguity straight away with “MRD”, an undefined term :-) I can take a stab at R and D, but no ideas on M… I’ll check acronym buster. I predict if I have to write an MRD it’ll be about an hour before I start calling it a “merde”!

]]> By: Scott Sehlhorst http://tynerblain.com/blog/2006/06/12/writing-unambiguous-requirements/comment-page-1/#comment-3550 Scott Sehlhorst Tue, 13 Jun 2006 14:25:03 +0000 http://tynerblain.com/blog/2006/06/12/writing-unambiguous-requirements/#comment-3550 Thanks for the comments Roger! You can also group sources of language ambiguity as <i>conceptual</i> and <i>audience</i>. There is still ambiguity that comes from incompleteness and assumption. Good points on testability in your post, thanks for sharing the link! Thanks for the comments Roger! You can also group sources of language ambiguity as conceptual and audience. There is still ambiguity that comes from incompleteness and assumption.

Good points on testability in your post, thanks for sharing the link!

]]> By: Roger L. Cauvin http://tynerblain.com/blog/2006/06/12/writing-unambiguous-requirements/comment-page-1/#comment-3545 Roger L. Cauvin Tue, 13 Jun 2006 12:26:59 +0000 http://tynerblain.com/blog/2006/06/12/writing-unambiguous-requirements/#comment-3545 There are really two types of ambiguity: conceptual and audience. <i>Audience</i> ambiguity comes from different readers interpreting the language differently. You and the Seilevel folks have cited the famous Gause and Weinberg of "Mary had a little lamb." Does it mean she kept one as a pet? Does it mean she gave birth to one? Or something else? <i>Conceptual</i> ambiguity is independent of the audience. It is function of the logical structure of the statement. "The system shall be fast" is conceptually ambiguous, because speed is a matter of degree, and the statement contains no constraint on it. The reason for writing requirements that are testable in principle is to prevent <i>conceptual</i> ambiguity. I just <a href="http://cauvin.blogspot.com/2006/06/why-testable-requirements.html" rel="nofollow">wrote</a> about it in today's blog entry. There are really two types of ambiguity: conceptual and audience.

Audience ambiguity comes from different readers interpreting the language differently. You and the Seilevel folks have cited the famous Gause and Weinberg of “Mary had a little lamb.” Does it mean she kept one as a pet? Does it mean she gave birth to one? Or something else?

Conceptual ambiguity is independent of the audience. It is function of the logical structure of the statement. “The system shall be fast” is conceptually ambiguous, because speed is a matter of degree, and the statement contains no constraint on it.

The reason for writing requirements that are testable in principle is to prevent conceptual ambiguity. I just wrote about it in today’s blog entry.

]]>