Нужно нормальное ТЗ

Нужно нормальное ТЗ, уже устал, искать человека, все кто берется, такую ихенею несут, что ужас.

Ася: 911992

Техническое задание.
----------------------------

ПОМОГИТЕ!!!!!!

Хи... бооольшой опыт составления ТЗ и спецификаций. Если интересно - пиши в личку, я тебе просто сброшу кусок ТЗ, который смогу выпросить у заказчика, обычно это идет под NDA.

Только занятие это не самое приятное и по цене я возьму как за программирование.

ТЗ это относительно просто.
1. Пишешь что вообще нужно. Т.е. что должен представлять из себя продукт, его назначение и функциональные возможности. Не смейся, иногда приходит такое... Читаешь и не можешь понять что вообще хотят.
2. Технические и програмные требования.
3. А дальше идет описание проекта, если это веб-проект - то постраничная развертка с макетами страниц. Везде описание алгоритмов работы, если нужно. Например по какому принципы выбираются статьи или товары, как сортируется и т.д.

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

Зачем всё усложнять? нормальный БРИФ и всё ок

nezabudkina, ну если на вопросы будет отвечать нормальный и адекватный человек, то бриф поможет. А если такогого не окажется и информацию придется "выдирать клещами"?

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

1) Цитата ("librarian"):

полностью расписывать все мелочи, как и что работает....

т.е. программа уже работает ?

2) ссылка

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

nezabudkina, ну если на вопросы будет отвечать нормальный и адекватный человек, то бриф поможет. А если такогого не окажется и информацию придется "выдирать клещами"?

как правило потом "выдирать клещами" приходится и оплату

Цитата:

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

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

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

1. Пишешь что вообще нужно. Т.е. что должен представлять из себя продукт, его назначение и функциональные возможности. Не смейся, иногда приходит такое... Читаешь и не можешь понять что вообще хотят.

Этточно почему то стандартный вводный раздел "Цель и назначение изделия" и "Сфера применения" часто игнорируется тех.писателями.

Цитата:

почему то стандартный вводный раздел "Цель и назначение изделия" часто игнорируется

Потому что в ТЗ этого быть не должно.

Цель и зазначение - это часть документа с названием "Технические требования".

keymaster, Вы уверены? Разве что если ТТ, неотъемлемая часть ТЗ... Или как?

Мир построен на мелочах, которых нет в ТЗ...)

а вообще в даже самом подробном тз Вы не сможете всего расписать...

Цитата:

Вы уверены? Разве что если ТТ, неотъемлемая часть ТЗ... Или как?

OxaDesign, абсолютно.
В серьёзной компании разработка выглядит так:
1) Аналитик беседует с заказчиком, выясняя - "что надо". На основе этого "что надо" пишется документ - "Технические требования".
Заказчик под этим документом подписывается.
2) На основе документа "Технические требования", аналитик пишет документ "Техническое задание". В случае возникновения разночтений или неясностей, связывается с заказчиком и решает вопросы. Здесь могут быть внесены изменения в ТТ.
3) Аналитик передаёт Техническое Задание разработчику
4) Разработчик выполняет работу по ТЗ. В случае разночтений, недомолвок - общается с аналитиком.
5) Копия ТЗ и выполненные работы идут на тестирование.
6) По результатам тестирования выполняются исправления.
7) Работа сдаётся заказчику. Заказчик подписывает акт сдачи-приемки.

Так, что "Технические требования" и "Техническое задание" - это два разных документа.
Хотя и похожих.
В ТТ может быть написано "Нужно добавить информацию о контрагенте в договор поставок".
В таком случае в тз будут фразы:
1. а таблицу DOGOVORS добавляются поля:
1.1. ContragentID (Integer)

2. Создаётся справочник контрагентов.
2.1. Создаётся таблица Contragetns, в которую входят поля:
2.1.1. Autokey (Integer) - уникальный номер контрагента
2.1.2. ContrAgentName : String (50) - наименование контрагента
2.1.3. ContrAgentInfo : String (255) - Контактная информация контрагента.

Далее, в ТЗ должны быть скриншоты изменяемых/новых визуальных форм приложения,
описание добавляемых проверок полей и т.д.

Это простой пример.

keymaster, спасибо за подробные разъяснения.
А, что в приведенном Вами случае называют "Спецификацией" и на каком этапе работ она появляется?

Цитата:

А, что в приведенном Вами случае называют "Спецификацией"

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

Я обычно пишу ТЗ по ГОСТ 34.602 "Техническое задание на создание автоматизированной системы" с учетом интернет-специфики и дополняю рядом приложений - структура сайта, прототипы (каркасы) страниц, спецификация CMS и т.п. Все технические детали (структура таблиц, логика работы, форматы файлов импорта/экспорта) выносятся в приложения.

keymaster, спасибо за разъяснения.
На сколько поняла, из приведеноого Вами случая, ТТ не является неотъемлемой частью ТЗ и не факт что разработчик его вообще увидит.
- Из какого же док-та разработчик узнает о "целях, назначении, сферах применения"?
- Чему посвящен вводный раздел ТЗ?

Или "цели, назначение, сфера применения" относятся к стратегической информации, кот.разработчику вообще не положено знать?:huh:

OxaDesign, а почему Вы думаете, что разработчик получает только ТЗ? Я не думаю, что такой формальный подход где-то практикуется. Никто не запрещает показать разработчику ТТ (если в этом есть необходимость), пересказать итоги обсуждения проекта с клиентом, составить дополнительный документ (типа т.н. креативного брифа) и т.д. Тут уже все определяется здравым смыслом.