Comments on: Edge cases and impossibilities http://lostechies.com/jimmybogard/2011/08/10/edge-cases-and-impossibilities/ Strong opinions, weakly held Sun, 19 May 2013 03:22:18 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: The Morning Brew - Chris Alcock » The Morning Brew #914 http://lostechies.com/jimmybogard/2011/08/10/edge-cases-and-impossibilities/#comment-3707 The Morning Brew - Chris Alcock » The Morning Brew #914 Thu, 11 Aug 2011 07:51:37 +0000 http://lostechies.com/jimmybogard/2011/08/10/edge-cases-and-impossibilities/#comment-3707 [...] Edge cases and impossibilities - Jimmy Bogard discusses the three types of behaviour our systems have, how the system Should, Does and Did behave, discussing how these factors lead to assumptions which allow us to ignore possibilities when debugging issues when in fact we should consider them improbable edge cases. [...] [...] Edge cases and impossibilities – Jimmy Bogard discusses the three types of behaviour our systems have, how the system Should, Does and Did behave, discussing how these factors lead to assumptions which allow us to ignore possibilities when debugging issues when in fact we should consider them improbable edge cases. [...]

]]> By: Anonymous http://lostechies.com/jimmybogard/2011/08/10/edge-cases-and-impossibilities/#comment-3669 Anonymous Wed, 10 Aug 2011 15:21:00 +0000 http://lostechies.com/jimmybogard/2011/08/10/edge-cases-and-impossibilities/#comment-3669 I can relate to the misunderstandings you're describing here. Nice point on calling out the importance of what the system *used* to do. I often trip over the word "should" in requirements docs that are enhancing an existing system. Are those sentences describing what the analyst assumes is currently true, or specifying what they want changed so that it becomes true? Your use of "should" is the first sense, I think. Because of the inherent ambiguity in modal verbs, I wish we'd leave them out of requirements discussions altogether. There's always a way to revise the sentence without them so that it is clear. "The system should prevent duplicate emails" becomes "[I believe] The system currently prevents duplicate emails." "The system should handle data containing duplicate emails" becomes "[Change the system to] Handle duplicate emails by flagging them for a report for human review." We probably can't change how requirements are communicated to us, but we ought to pounce on every "should" as an ambiguity to follow up on. I can relate to the misunderstandings you’re describing here. Nice point on calling out the importance of what the system *used* to do. I often trip over the word “should” in requirements docs that are enhancing an existing system. Are those sentences describing what the analyst assumes is currently true, or specifying what they want changed so that it becomes true? Your use of “should” is the first sense, I think.

Because of the inherent ambiguity in modal verbs, I wish we’d leave them out of requirements discussions altogether. There’s always a way to revise the sentence without them so that it is clear.

“The system should prevent duplicate emails” becomes “[I believe] The system currently prevents duplicate emails.”

“The system should handle data containing duplicate emails” becomes “[Change the system to] Handle duplicate emails by flagging them for a report for human review.”

We probably can’t change how requirements are communicated to us, but we ought to pounce on every “should” as an ambiguity to follow up on.

]]>