Just had some requirements through for a query that a customer has specified.
āSet the value to 1 if the Outcome is not Complete or Cancelled or NULLā
This could be variously interpreted as:
āif the Outcome is NOT Complete and NOT Cancelled and NOT NULLā
Or āif the Outcome is NOT Complete, and NOT Cancelled, or IS NULLā
Or perhaps even āif the Outcome is NOT āComplete or Cancelledā or IS NULLā
Obviously Iāll go back to them for clarity, but itās a wonder why so often ābugsā arise based on interpretation of specifications.
Technical requirements are often ambiguous when written as free text, the way someone would speak them, because as you have discovered the free text fails to capture where the linguistic stress would be that disambiguates in speech.
Instead, I suggest using a format that is more suited to text.
I would recommend a table. Email the customer back with your current interpretation of the requirements, with a column for outcome and a column for value. Ask them to check and sign off on the table, or to correct the table where it is wrong.
Example:
Outcome Value NULL x Complete x Cancelled x (Other) x There are edge-cases with if outcome can be "Complete or Cncelled
Cheers yeah, that is standard usually. I was just having a whinge rather than asking for a solution. In this case the customer was trying to preempt having to complete a change request form (similar to what youāve described) and get the relevant sign off etc, and had emailed over a āminor alterationā to an existing request, for which they should know better at this stage of the project.
Haha yeah, fair enough. Applogies for turning your deserved whinge into a serious question.
Wrangling annoying customers is always the most annoying part of the job isnāt it. How nice it would be to spend more time programmingā¦
Even using bullet points can help a lot in these situations (I use them quite often in emails with non-technical recipients).
This helps with writing unit tests as well.
Donāt forget to ask what is the other possible value(s) if the scenario doesnāt happen, because that is something forgotten most of the time.
Completely agree, requirements are key and often badly defined due to the customersā lack of knowledge of the intricacies of the system. You are correct to ask for clarity or it could come back to bite you later on.
Iāve just had a spec through from a BA which consists entirely of screenshots of an existing system with no technical definitition of any of the requested fields so relate to this right now.
Whatās the difference between case 2 and 3? Those look the same to me. The three cases look like:
- Ā¬complete ā§ Ā¬cancelled ā§ Ā¬null
- (Ā¬complete ā§ Ā¬cancelled) āØ null
- Ā¬(complete āØ cancelled) āØ null
Case 3 is one separate text string containing the words āComplete or Cancelledā (hence the quotes).
Oh, I thought that was just a grouping
