Programming

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:

There are edge-cases with if outcome can be "Complete or Cncelled

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