Идеальное или близкое к таковому ТЗ на программинг

Какое оно с Вашей точки зрения? Можно несколько ссылок на примеры?

Для себя я давно сформировал такой идеал и стараюсь в любой работе его придерживаться.

1. Общее описание.

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

2. Интерфейс пользователя.

Схематичное описание взаимодействия пользователя с программой.
Должны описываться хотя бы главные ветки выполнения, а также действия при
возникновении ошибок. Оговариваются требования к локализации, поддержка
тем оформления, устройств ввода-вывода, работа на терминалах и все остальное,
имеющее отношение к данному пункту.

3. Возможности программы.

- обязательные;
- необязательные, но желаемые;
- опциональные.

4. Требования и ограничения.

- функциональные;
- технические;
- затрагивающие вопросы безопасности;
- административные;
- связанные с разработкой;
- прочие.

5. Тесты, контролирующие готовность ПО и его качество.

- функциональные;
- нагрузочные;
- тесты совместимости;
- другие.

Идеальное или близкое к таковому ТЗ должно содержать разделы перечисленные в п.1.4 ГОСТ 19.201-78 - ссылка Содержание разделов ТЗ должно соответствовать требованиям перечисленным в разделе 2 этого документа. Менее формализованные требования к "идеальному ТЗ" приводятся, напр., в User Requirements Document ESA PSS-05-02 - см. краткое изложение в ссылка

Если все делать идеально, то ТЗ по ГОСТу для программинга недостаточно. Нужен еще техпроект, опять же по ГОСТу. Если в ТЗ описываются общие требования, то в тех проекте конкретные детали реализации. Ссылка в предыдущем сообщении неправильная. Есть ГОСТ по ТЗ конкретно для программных продуктов.

yhop2012, Суть идеального техзадания в том, чтобы выбить из заказчика как можно больше информации по предполагаемому проекту.
Эта информация нужна именно вам, и только вы знаете, что вам надо для успешной работы над проектом!
Пусть это будет один лист разумных вопросов, а не трехтомник околесицы с тех.терминами, которые порой не осилит человек с высшим, но не компьютерным образованием

Идеальное ТЗ - это UML файл.

yhop2012, это ГОСТ. Если ты хотя бы раз напишешь ТЗ по ГОСТУ (или близко к нему) поймешь, что такое полноценное ТЗ.

okman, Спасибо, очень обстоятельно. То, что нужно.

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

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

Постановка задачи должна быть по возможности лаконична и исчерпывающая: т.е. вместо
"добавить фильтр для списка компаний - поставщиков - там где это возможно" лучше записать
"добавить фильтры для основных гридов в следующих формах:
1) Metallica (ShowCompany, Companies);
2) MetallicaView (ShowCompany);
Фильтр должен позволять фильтровать данные по нескольким полям одновременно. Для фильтрации следует использовать, по возможности, все поля, кроме 'Прайс-лист'. Следует предусмотреть список подстановки для значения фильтра, элементы которого должны браться из столбца под ним. Визуальная реализация не должна отличаться от существующей реализации: MetallicaView (форма ShowTree)".
Т.е. данный раздел должен носить также справочный характер, чтобы разработчик ничего не упустил из виду. Описывать причину требования в данном месте не следует, здесь должны быть, по возможности, только утверждения. Если же есть потребность описывать причину - это может быть признаком сомнений по данному пункту. Это может означать, что по данному пункту требуется провести согласование, но(!) за рамками ТЗ и, при необходимости, внести корректировки в задание. Поэтому ТЗ лучше оформлять как файл-документ с указанием версии.
Надеюсь, не утомил изложением. На самом деле, мне иногда приходилось тратить недели, чтобы из информации от заказчика сформировать задание понятное разработчикам. И, иногда, процесс фактического программирования занимает гораздо меньше времени, чем на подготовку и согласование ТЗ : ).
Ну, надеюсь, тебе теперь будет понятней, почему я прошу все структурировано записывать. ...»

P.S. Естественно, не рекомендую писать подобные тексты заказчикам, если вы точно не знаете какая будет реакция.

Цитата ("yhop2012"):

Какое оно с Вашей точки зрения? Можно несколько ссылок на примеры?

Текстовое описание+визуальная часть, что бы небыло двуякого толкования