In short: A specification for a team abroad needs three things that an internal document can do without: a glossary that sets one translation for every business term, acceptance criteria that can be checked without asking, and an Israeli section covering what a foreign team does not know: the ID number with its check digit, VAT and invoice allocation numbers, a Sunday to Thursday work week, Hebrew right-to-left text inside an English interface, and Amendment 13 to the Privacy Protection Law. Without that section, the team builds a system that is right for another country.
Why translation is not enough
A specification written in Hebrew for an Israeli team relies on shared context. When it says invoice, everyone knows it means a tax invoice with VAT, and that above a certain amount it needs an allocation number. When it says week, everyone knows it starts on Sunday. A team abroad does not know this, and will not ask, because it does not know there is anything to ask.
The rule: everything an Israeli team understands without being told has to be written in a specification for a team abroad.
The structure
The standard structure of requirements documents in English follows IEEE 830 and ISO/IEC/IEEE 29148, and teams abroad know it:
| Section | What goes in it |
|---|
| Introduction: Purpose, Scope, Definitions | Purpose, scope, what is out of scope, and the glossary |
| Overall Description | The product, the users, constraints and assumptions |
| Specific Requirements | User stories with acceptance criteria, data model, integrations |
| Verification | How each requirement is verified and who signs off |
| Appendixes | Screens, sample files, the Israeli section |
Glossary: one translation per term
A common mistake is translating the same Hebrew term in several different ways across the document. A customer becomes customer, then client, then account, and the team builds three entities. The glossary fixes one translation, and the whole document uses only that.
| Hebrew | In the English document | Note |
|---|
| עוסק מורשה | Licensed VAT dealer (osek murshe) | Keep the Hebrew term as well: it will appear in the interface and in documents |
| מספר הקצאה | Invoice allocation number | A number the Tax Authority issues for an invoice |
| חשבונית מס | Tax invoice | Not just invoice |
| תעודת זהות | Israeli ID number (teudat zehut) | Nine digits including the check digit |
The Israeli section
This is the section a team abroad needs most, and the one most often missing. What to include:
- Israeli ID number: nine digits, left-padded with zeros, with a check digit calculated by the Luhn algorithm. A wrong check rejects real customers.
- VAT and invoices: the tax invoice, an allocation number for invoices above the threshold, and the VAT rate as a parameter rather than a number in the code.
- Work week: Sunday to Thursday, Friday is a short day, Saturday is the day of rest. Holidays start in the evening.
- Hebrew in the interface: right-to-left direction, fields that mix Hebrew and English, numbers inside Hebrew text. For input fields, point the team to automatic direction detection.
- Privacy: Amendment 13 to the Privacy Protection Law, especially what counts as information of special sensitivity and who may access it.
- Currency and formats: the shekel, dates with the day before the month, addresses and seven-digit postal codes.
Acceptance criteria nobody has to ask about
Every requirement gets an acceptance criterion in Given, When, Then form: given a state, when an action happens, then a result follows. Development and QA teams know this form worldwide, and it prevents the question what exactly did you mean, which in a team abroad comes up only after the code is written.
Write the acceptance criteria for the Israeli section with real test data: a valid and an invalid ID number, a Hebrew name with an English word inside it, a date that falls on a Saturday.
Frequently asked questions
How do you write a specification for an offshore team?
Following the accepted structure of requirements documents: introduction and scope with a glossary, overall description, specific requirements with acceptance criteria, and verification. For a team abroad, add a section on what is specific to Israel.
Is it enough to translate the Hebrew specification?
No. Translation carries over the words, but not what an Israeli team knows without being told: VAT and allocation numbers, the work week, the ID number, Hebrew right-to-left text, and privacy. All of that has to be written explicitly.
What is a glossary and why does it matter?
A list that sets one translation for each business term. Without it, the same term is translated in several ways and the team builds several entities instead of one.
What does an offshore team not know about Israel?
That the ID number has a check digit, that an invoice above a certain amount needs an allocation number, that the work week starts on Sunday, that the interface must support Hebrew right-to-left, and what Amendment 13 to the Privacy Protection Law requires.
In what form should acceptance criteria be written?
In Given, When, Then form, which teams know worldwide, with real test data for everything specific to Israel.
Where to start
List the ten most important business terms in your system and, next to each one, the translation your team abroad uses today. If any term has more than one translation, you have found the first problem.
Talk to me
Related: Software specification template, CRM requirements and development, Architecture review