Яковлевич Евгений
34 года,
2 сообщения
#12 лет назад
Нужно нормальное ТЗ, уже устал, искать человека, все кто берется, такую ихенею несут, что ужас.
Яковлевич Евгений
34 года,
2 сообщения
#12 лет назад
Ася: 911992
Константин Т.
48 лет, Россия
589 сообщений
#12 лет назад
Техническое задание.
----------------------------

ПОМОГИТЕ!!!!!!
Дмитрий Сотник
39 лет, США
24 сообщения
#12 лет назад
Хи... бооольшой опыт составления ТЗ и спецификаций. Если интересно - пиши в личку, я тебе просто сброшу кусок ТЗ, который смогу выпросить у заказчика, обычно это идет под NDA.

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

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

Спецификация - это уже хуже, это то-же ТЗ но с описанием типов полей, проверок, ограничений и прочей специфической ерунды. Спеку пишет уже разработчик по ТЗ.
Анастасия Бережкова
35 лет, Россия
178 сообщений
#12 лет назад
Зачем всё усложнять? нормальный БРИФ и всё ок
Николай Соловьев
Россия
710 сообщений
#12 лет назад
nezabudkina, ну если на вопросы будет отвечать нормальный и адекватный человек, то бриф поможет. А если такогого не окажется и информацию придется "выдирать клещами"?
Быков Василь
339 сообщений
#12 лет назад
Для любого сложного проекта надо полностью расписывать все мелочи, как и что работает....
Владимир С.
33 года, Россия
581 сообщение
#12 лет назад
1) Цитата ("librarian"):
полностью расписывать все мелочи, как и что работает....

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

2) https://forum.weblancer.net/themes/1449.html
Анастасия Бережкова
35 лет, Россия
178 сообщений
#12 лет назад
Цитата ("SolNikolay"):
nezabudkina, ну если на вопросы будет отвечать нормальный и адекватный человек, то бриф поможет. А если такогого не окажется и информацию придется "выдирать клещами"?
как правило потом "выдирать клещами" приходится и оплату
Павел Лукин
31 год, Россия
233 сообщения
#12 лет назад
Спецификация - это уже хуже, это то-же ТЗ но с описанием типов полей, проверок, ограничений и прочей специфической ерунды. Спеку пишет уже разработчик по ТЗ.

Если по-нормальному, то все типы полей, проверок и т.д. должны быть описаны в ТЗ.
Разработчик не пишет спецификаций. Он разрабатывает софт по ТЗ.
Спорные вопросы решаются с аналитиком, который это тз пишет, получив от заказчика технические требования.
 Oxadesign™
582 сообщения
#12 лет назад
Цитата ("sdvv"):
1. Пишешь что вообще нужно. Т.е. что должен представлять из себя продукт, его назначение и функциональные возможности. Не смейся, иногда приходит такое... Читаешь и не можешь понять что вообще хотят.

Этточно почему то стандартный вводный раздел "Цель и назначение изделия" и "Сфера применения" часто игнорируется тех.писателями.
Павел Лукин
31 год, Россия
233 сообщения
#12 лет назад
почему то стандартный вводный раздел "Цель и назначение изделия" часто игнорируется
Потому что в ТЗ этого быть не должно.

Цель и зазначение - это часть документа с названием "Технические требования".
 Oxadesign™
582 сообщения
#12 лет назад
keymaster, Вы уверены? Разве что если ТТ, неотъемлемая часть ТЗ... Или как?
Алексей Гальченко
34 года, Россия
207 сообщений
#12 лет назад
Мир построен на мелочах, которых нет в ТЗ...)

а вообще в даже самом подробном тз Вы не сможете всего расписать...
Павел Лукин
31 год, Россия
233 сообщения
#12 лет назад
Вы уверены? Разве что если ТТ, неотъемлемая часть ТЗ... Или как?

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) - Контактная информация контрагента.

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

Это простой пример.
 Oxadesign™
582 сообщения
#12 лет назад
keymaster, спасибо за подробные разъяснения.
А, что в приведенном Вами случае называют "Спецификацией" и на каком этапе работ она появляется?
Павел Лукин
31 год, Россия
233 сообщения
#12 лет назад
А, что в приведенном Вами случае называют "Спецификацией"

У нас спецификации пишутся на общие модули системы.
Схема работы с бд, схема работы визуальной части и т.д.
Дмитрий Пленкин
37 лет, Россия
441 сообщение
#12 лет назад
Я обычно пишу ТЗ по ГОСТ 34.602 "Техническое задание на создание автоматизированной системы" с учетом интернет-специфики и дополняю рядом приложений - структура сайта, прототипы (каркасы) страниц, спецификация CMS и т.п. Все технические детали (структура таблиц, логика работы, форматы файлов импорта/экспорта) выносятся в приложения.
 Oxadesign™
582 сообщения
#12 лет назад
keymaster, спасибо за разъяснения.
На сколько поняла, из приведеноого Вами случая, ТТ не является неотъемлемой частью ТЗ и не факт что разработчик его вообще увидит.
- Из какого же док-та разработчик узнает о "целях, назначении, сферах применения"?
- Чему посвящен вводный раздел ТЗ?

Или "цели, назначение, сфера применения" относятся к стратегической информации, кот.разработчику вообще не положено знать?:huh:
Дмитрий Пленкин
37 лет, Россия
441 сообщение
#12 лет назад
OxaDesign, а почему Вы думаете, что разработчик получает только ТЗ? Я не думаю, что такой формальный подход где-то практикуется. Никто не запрещает показать разработчику ТТ (если в этом есть необходимость), пересказать итоги обсуждения проекта с клиентом, составить дополнительный документ (типа т.н. креативного брифа) и т.д. Тут уже все определяется здравым смыслом.