Техническое задание содержит требования к системе в терминах предметной области Заказчика. Предполагается, что Заказчик хорошо разбирается в логике свое предметной области и может сформулировать что он понимает под хорошо выполненной (им) работой (критерии эффективности) и понимает, что именно нужно сделать, чтобы можно было сделать эту работу
а) лучше и/или
б) быстрее.
Естественно, что при этом также может объяснить, как именно нужно оценивать "быстрее" и "лучше". Это и должно быть описано в ТЗ. Можно еще добавить требования, которые огововаривают, что именно не должно стать хуже.

Что самое важное, что это все должно быть описано на уровне представления о системе как "черного ящика".

От лица Заказчика:
Грубо говоря, что будет, если я, Заказчик, нажму на эту кнопку, какой полезный результат ( в терминах предметной области) я, Заказчик, получу. По большому счету мне, Заказчику, по-барабану будет ли системе делать там внутри себя запрос к некой БД, или все это будет реализовано перемещением шестеренок и сложением аналоговых сигналов.
То, что программист понимает мою предметную область на языке запросов, циклов, индексов и интерфесов - это его проблемы. Мне нужно, чтобы то что я получу, можно было понять из ТЗ без необходимости изучения каких-то там принципов нормализации каких-то отношений или изучения принципов формирования IP-адресов в сети Интернет.

От автора :
Вот сама возможность формулировки требования с таким уровнем точности и однозначности возможно только если Заказчик действительно хорошо понимает дело, которое он делает.
Как ни парадоксально, но :
1. именно отсутствие чёткого понимания Заказчиком, трудности описания (им) логики своей предметной области именно в терминах предметной области являются причиной низкого качества ТЗ, а часто и причиной провала проекта. К сожалению, для России это похоже очень актуально....
2. именно дефекты в понимании Заказчиком своего дела часто являются как причиной обращения к IT- решениям (программисты выступают носителями знаний, полученных при работе над другими проектами и фактически являются консультатами Заказчика). Приобретение западных систем часто рассматривается Заказчиком не только как средство системной интеграции своей деятельности, но обретения знаний о том как оно правильно должно делаться с точки зрения его предментой области , поскольку такие программы так или иначе регламентирует порядок ведения бизнеса (что, собственно и называется такой-то системой управления ).
3. Универсализм логики программных и логических средств создания автомтизированных систем часто культивируют ложное представление у программистов о том, что навыки алгоритмизации позволяют заменить опыт работы в конкретной области и если "просто запрограммировать" все непротиворечивым с точки зрения программиста образом, то всё будет в порядке, а что нужно, то всегда можно поправить по результатам тестирования или опытной эксплуатации.

Если не удается удержаться в рамках предметной области ТЗ содержит смешанное описание того, что хочет пользователь и как именно программист это будет делать, но уже в терминах программных средств реализации (которое полностью уже не понимают ни тот ни другой).

Неспособность Заказчика сформулировать в своих терминах требования к системе приводит к тому, что он:
1. либо "прогибается" и соглашается с формулировками, сформулированнми автоматизаторами, хотя они не отображаются однозначно на его деятельность.
2. либо молчит до поры до времени, когда программа почтие реализаоана, а несоответствие формулировки ТЗ и реальных потребностией становится очевидным. А "плохой" в результате будет объявлена программа, хотя вроде все по ТЗ делали.

Кто именно должен вытаскивать из Заказчика эти требования - аналитик, или другой "специально обученный" специалист - следующий воспрос. Но принципиально важным является понимание источника проблемы постановки задач и формулировки требований (не этапность или способ организации работ!) : требования должны быть извлечены из Заказчика и изложены в ТЗ в терминах его предметной области . Делать системы для невменяемого заказчика просто опасно - проект может быть и не закончен, кроме того при работе над такими проектами может произойти реальная дисквалификация автоматизаторов (утрата чувста реального, жизненно необходимого)....

Описание спсоба, средств реализции, архитекуры приложения и пр. только после ТЗ - в проектной документации в терминах и представлениях программиста .