If you had the following customer requirement how would you interpret it for coding purposes?
The field should display: “Initial Review Date” OR “Planned Review Date”, “Date of Last Review”
Option 1: (“Initial Review Date” OR “Planned Review Date”) AND “Date of Last Review”
Option 2: “Initial Review Date” OR (“Planned Review Date” AND “Date of Last Review”)
We’ve coded for option 1, the customer wanted option 2.
I can see both sides and it’s a badly written requirement (which was signed-off before I got involved). I’m asking the customer to pay as an enhancement, customer wants it fixed as a defect.
Logically you cannot have a date of last review if you’ve not had an initial review, so a common-sense reading would favour option 2, but my team are arguing that option 1 is a reasonable interpretation too.
So… does Option 1 seem a valid or reasonable interpretation of the requirement?
I agree that it’s an ambiguously written requirement. Both interpretations are reasonable, but it’s not a defect if you’ve fulfilled one reasonable interpretation. If the customer signed off on the requirements as written before you began coding, they can’t call it a defect the way you coded it. If they want it changed, they should pay, and they should absorb an important lesson: anyone who writes legally binding specifications/contracts should know to be very careful about writing things such that they are not easily misinterpreted.
The interpretation “(initial or planned), last review” might make sense if you had a bunch of things ona list and they were all phrased that way, but by itself it doesn’t make entirely sense - why would you need an initial date AND a last review date?
And of course I think of a comma as being like “and”. When figuring out precedence, “and” takes precedence over “or”. So a or b and c should parse out to “a or (b and c)”.
On first glance, I wondered what the comma could possibly have meant.
If you held a gun to my head and said “Decide NOW!” I would have chosen option 1. But if it had been at all possible to contact the customer or the author of the requirements, I would have asked for clarification.
Given just those two options, option two seems to make the most sense to me from how I would interpret it as a programmer. Option one would provide some bad information. There’s basically two different scenarios, so it’s easy to consider.
If we have a item that is already on follow-up review, we’ll see the same information displayed in both cases, the date of the next review followed by the date of the previous one. So that scenario doesn’t matter. However, if we consider the case where we have a new item for review, that’s when the display will be different. In the first option, we’ll be showing the date of the previous review when there is none. For the second option, you wouldn’t show the previous review date since it’s the first one. I go with the second because it would be immediately obvious to the user that there shouldn’t be a previous date if it’s the initial review date. I suppose you could display NULL or N/A or some dummy date instead.
So, really, it just seems like it’s a bit of a design decision on your part on how you want to handle that case of displaying the information for initial reviews. My choice would be the second.
It’s ambiguous, but I would have gone for option 2.
Seems a fairly pissy thing to charge the client for - surely someone could have made a quick enquiry before they coded when the ambiguity was first noticed.
I would have gone with option 2, unless I had spotted the ambiguity and asked for clarification. I’m always looking for things like that in reqs, but I don’t always find them.
Will it be hard to fix? If it’s just the principle you’re fighting for, I’d just let the customer win this one.
That’s what we went for - if there’s an initial review date we show a null value against the date of last review to indicate it’s a new item. So doesn’t add any confusion for users, just doesn’t quite match what the customer thought they wanted.
I would have inclined towards option 2, but I agree that the specification is ambiguous. Of course, the best thing to do with ambiguous specs is to ask for clarification, but the problem with them is that sometimes the person reading them won’t even notice the ambiguity.
Part of the problem was that our developers didn’t see any ambiguity… they saw the requirement, interpreted it as Option 1 and coded what was in front of them, then moved on to the next issue (this was one of several thousand requirements).
It’s only when the business users on each side review the test results that the ambiguity becomes apparent, up to then each side thought they were a model of lucid clarity.
My impression is that this is a good time to apply the “customer is always right” principle. You didn’t produce exactly what the customer wanted, and from the customer’s point of view, this is a defect that ought to be corrected at no further expense to them. The specification is indeed ambiguous, and it seems to me that the fault can just as easily be argued to be on your side as on the customer’s side. You might be able to successfully stand on your side, and charge the customer for the “enhancement”, but I think this is a case where the customer rightfully will be much more satisfied if you accept responsibility for the error, and correct it at no charge.
What is more important to you—a satisfied customer, or that small additional fee that you could charge for treating this as an “enhancement” rather than a bug fix?
User here, and just looking at the syntax, option 1 is what I would have meant if I wrote it that way, but I think I would have put
The field should display: [“Initial Review Date” OR “Planned Review Date”], “Date of Last Review”
Looking at the content, option 2 makes more sense. But I would put
The field should display: [“Initial Review Date”] OR [“Planned Review Date”, “Date of Last Review”]
Would this have been sufficient to make it clear? I don’t want our tech guys to have to do any mind-reading! Or would you be tempted to code in the brackets?
I read it as Option 1. I’m used to seeing requirements with comma-separated lists of fields, so I read “display A or B, and then display C”. But reading it in context with other requirements might have influenced how I read it.
