Где можно найти образцы и лучшие примеры ТЗ на разработку софта?

Question

[imperiumcat]

Собсвтенно сабж, можно английский.

P.S.

гугл и яндекс дают какой-то хлам типа:

1. ОБЩИЕ ТРЕБОВАНИЯ
1.1 Техническое задание оформляется в соответствии с ГОСТ 19.106-78 на листах формата А4 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
1.2 Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78. Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.

нет, это не нужно.

Нужно:

1. ТЗ на разработку успешного продукта, например, (простихосподи) Экселя
2. чек-лист, что в хорошем ТЗ должно быть, а что нет.

Comments

[abcyu]

ТЗ на Excel вы не осилите. Оно огромное и скучное.

Answer 1

[eRKa]

Все зависит от того какими методологиями разработки Вы пользуетесь.

Чаще все это выглядит так:
1) Сначала накидываются пользовательские истории (user story), тот функционал, который Вы хотите иметь в программе. Они состоят из одного-двух предложений, кратко описывают одну единственную функцию. Например: хочу, чтобы была авторизация пользователей с подтверждением по email; хочу, чтобы у пользователя с ролью "админ" была собственная страничка для администрирования; и.д. В историях не должно быть никаких технических нюансов, только "хочу" заказчика (ну или Ваши).

2) Затем составляется карта (roadmap), в которой Вы описываете каждый шаг работы этой функции (пользовательской истории) с точки зрения пользователя:
1. Главная страница.
1.1 В правом верхнем углу находятся поля для аутентификации (для логина и пароля). Рядом находится кнопка "войти" и ссылка "зарегистрироваться".
1.2 При удачной аутентификации происходит переход на страницу ... и выводится сообщение "Добро пожаловать ..."

Потом на основе этой карты, делается прототипирование, выделяются задачи, если надо, разбиваются на более мелкие подзадачи.

Чтоб увидеть чужие ТЗ, полазите по чужому коду на гитхабе. Там очень часто люди описывают свой roadmap.

Comments

[imperiumcat]

>Все зависит от того какими методологиями разработки Вы пользуетесь.

думаю, варианты аджайла - уже стандарт в индустрии

Answer 2

[lakegull]

Примерно пару лет назад мне потребовалось структурировать базу контактов с клиентами. Изобрёл немного велосипедное решение для своих нужд. ТЗ по можно скачатьпо ссылке.
Как сейчас помню в то время на его составление у меня ушло часов 25-30 чистого времени. В начале я не знал какие инструменты использовать, чтобы исполнитель понял все нюансы правильно, поэтому многое переписывал. Так-же в процессе написания постоянно появлялись новые идеи, которые , как мне казалось не включить в ТЗ уже нельзя.
В результате после выхода первой версии программы, ушёл ещё месяц её на доработку. Пользовался ею я около полугода, всё это время собирал информацию, что можно было бы улучшить. Затем понабравшись опыта и знаний я написал новое ТЗ, которое составило 20 листов и ещё около десятка дополнительных файлов с картинками и таблицами. На составление второго ТЗ ушло около месяца.

Comments

[Vicom]

lakegull, "Ничего не найдено
Возможно, владелец удалил файлы или закрыл к ним доступ.
А может быть, вам досталась ссылка с опечаткой."

это был текстовый скриншот)) перевыложите, плз

Answer 3

[Растишка]

Мне кажется что успешный продукт можно сделать только по аджайлу, итерациями.
Ни разу не удавалось все распланировать и предусмотреть все мелочи.

Comments

[abcyu]

Это если у вас бюджет резиновый, если нет, а так очень часто - приходится расписывать ТЗ подробно.

[Растишка]

Если бюджет не резиновый, но нужны резиновые разработчики. Или риски закладывать 200%.
Как известно: реальный срок разработки = планируемый срок * PI

Answer 4

[azzzimo]

Мне очень помогло это видео - Как правильно поставить ТЗ на создание сайта

А так же их примеры: Демонстрационный пакет проектной документации

Comments

[Юрий Вискалин]

Благодарю, очень полезное видео и материалы.

Answer 5

[Vov Vov]

Моё мнение, если тебя никто не ограничивает в стандартах выполнения ТЗ, то надо исходить из следующего:

1. Время.

2. Полезность ТЗ для разработчиков и прочих, но прежде всего для разработчиков.

2.1. Полезность это прежде всего описание бизнес-логики.

2.2. Прототип (делаю в Бальзаме).

2.3. Связи с подсистемами и интеграции.

2.4. Структуры данных и нагрузка.

Я пишу ТЗ и по ГОСТам и по корп. стандартам, но эффективней всего получается когда никто не ставит рамки.

Будут вопросы пиши в ЛС.

Answer 6

[Marat Amerov]

могу порекомендовать книжки
www.ozon.ru/context/detail/id/30958003
Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем
www.ozon.ru/context/detail/id/27995134 Разработка требований к программному обеспечению

Answer 7

[Федор]

Была на хабре компания Edison и они в своих статьях делились ссылками на примеры своих ТЗ. В общем, если почитаете https://habrahabr.ru/company/edison/blog/267569/ и https://habrahabr.ru/company/edison/blog/267671/, думаю, для вас не составит труда найти примеры их ТЗ

Answer 8

[Мike Butlitsky]

Гуглите литературу и курсы на тему managing software requirements, agile software requirements

Вот неплохая книга www.amazon.com/Managing-Software-Requirements-Appr...

Все в основном на английском, на русском только хлам либо нормальные переводные книги, типа
www.piter.com/product/iskusstvo-upravleniya-it-pro... (кстати из микрософта чувак).

За исключением может курсов Бескова и отдельных статей, постов разных авторов.

ПС: универсальных чеклистов и схем тут нет и быть не может. Разные типы продуктов, заказчиков, условий требуют разных требований.

Answer 9

[theWaR_13]

На хабре писали ещё. На каком-то фрилансерском сайте уязвимость была, все файлы из личных переписке можно было найти через гугл таким образом: site:freelancer.com filetype:pdf и там выдача из реальных тз. Не уверен правда насчёт сайта.

Comments

[Dimonchik]

там лажа в основном, да и доступно было штук 50 документов всего

Answer 10

[Виктор]

По второму пункту рекомендую ориентироваться на ГОСТ34
www.rugost.com/index.php?option=com_content&view=a...
www.rugost.com/index.php?option=com_content&view=a...

Любой серьезный заказчик всегда работает с оглядкой на ГОСТ, да и самому не надо ничего выдумывать, только необходимо помнить что ГОСТ - это рекомендательный стандарт и, например, все пункты котрые должны быть в ТЗ согласно ГОСТ, не обязательно должны быть в вашем варианте :)

Вот с зарубежными немного сложнее - они не всегда ориентируются на ISO/IEEE (мне не приходилось работать с такими, кто бы требовал соответствие - у всех был свой формат ТЗ)
Поэтому лучше сразу обговорить структуру документа. :)