Разбалансированность ТЗ (превалирование «как » над «что»)

Часто бывает, что большую часть ТЗ занимают требования, как должен работать требуемый функционал ПО (процессы работы). А требования к самим результатам работы ПО даны в малом и часто недостаточном количестве. Обычно это связанно с тем, что ТЗ написано специалистами, которые уверены, что если очень детально описать процессы, то этот «путь» неминуемо приведет исполнителя к разработке требуемого ПО. Это ошибка. В реальности, исполнитель потратит дополнительное время на уточнение требований к целевому функционалу, а часть требований к процессам/методам/способам будут оспорены и в итоге признаны опциональными и вторичными.

В первую очередь, в ТЗ должны быть требования к результату работы («что»).

В ТЗ нет нефункциональных требований или они неполные

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

Полноценные нефункциональные требования должны быть неотъемлемой частью ТЗ.

Противоречивые требования

Бывает, что заказчик, часто сам того не осознавая, не знает точно, что хочет получить в результате. Из-за этого в ТЗ появляются требования в многословных общих расплывчатых формулировках. Более того, потом такие требования начинают ссылаться друг на друга, тем самым все окончательно запутывая. В итоге заказчик с исполнителем потратят значительное время на уточнение всех неконкретных и неточных формулировок.

ТЗ должно содержать конкретные и точные требования. Многословности без конкретики следует избегать.