ТЗ на разработку программного обеспечения?

Question

[Павел]

Коллеги, поделитесь пожалуйста ссылками на качественные ТЗ на разработку типового SaaS-продукта.

Можно на английском. Спасибо!

Answer 1

[Aisu_Kuge]

Советовал бы взять за шаблон хорошего ТЗ упрощённые рекомендации PMBoK к проекту, а именно:

1. Разработка устава проекта (документация первоначальных требований, экономического обоснования, составление перечня заинтересованных лиц)
2. Разработка плана проекта, т.е. определяем в первом приближении как будет производится разработка и как будет производится контроль.
3. Собираем требования.
4. Определяем содержание, разбиваем его на операции, оцениваем ресурсы и время на каждую операцию.
4.1. Технические подробности, как должна себя вести система в тех или иных случаях, описать требования к дизайну.
5. Оцениваем весь бюджет разработок.
6. Желательно как-нибудь описать качество (какие-нибудь характеристики, вроде времени обрабатывания запроса) итогового продукта.
7. Готовим подробную смету по проекту (включая туда сотрудников, которые будут работать над проектом, и их з/п на время проекта).
8. Перечень лиц, кто отвечает за контроль хода выполнения работы и качества выполненной работы.

Всю информацию сводим в единый документ. Тогда и проблем будет по минимуму.

В PMBoK также советовал бы глянуть раздел про риски и про то, как их грамотно задокументировать, чтобы снизить их возможное наступление и последствия.

Всё это актуально вне зависимости от методологии разработки.

Comments

[Aisu_Kuge]

На хабре есть на сайт ТЗ: habrahabr.ru/post/84422/

Answer 2

[Максим Дьяченко]

Я всегда придерживался принципа, что идеальное сферическое ТЗ в вакууме это такой документ, который в будущем станет документацией на продукт.

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

Инструкцию всегда можно просто и быстро превратить в ТЗ. А если вы не готовы писать инструкцию, то вы не готовы писать ТЗ, т.е. еще не имеете достаточного понимания структуры, задачи и т.п. Может быть она и появится в процессе написания…

Answer 3

[EugeneOZ]

«Шаблон ТЗ» звучит как «шаблон изобретения». Забавно. Усё под подпись, шеф.

Answer 4

[gleb_kudr]

Шаблон примерно такой:

1. Бизнес-задача. Человеческим языком объяснить, зачем это нужно.
2. Бизнес-кейсы. «Зачем» облекаем в «как». Сценарии работы.
3. Дизайн, учитывая п. 2

Можно пользоваться методикой «что, где, когда, как». Просто, последовательно раскрываем эти вопросы.

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

Answer 5

[zarincheg]

Думаю что лучше отходить от этого пресловутого ТЗ, по крайней мере в том виде. в котором оно обычно понимается.
Я бы посоветовал сначала составить списки:
1. Список общих требований к функционалу системы
2. Список бизнес-задач, которые должно решать приложение
3. Список use cases, т.е. то, что смогут делать пользователи на сайте.

После этого сгруппировать пункты наиболее логичным образом. Например use cases можно группировать по страницам сайта. После группировки каждый пункт описываете более подробно, чтобы было понятно что конкретно он из себя представляет.
И в принципе на выходе вы получите вполне годный план работ. Конечно некоторые моменты зависят от специфики проекта.Но такой документ команде разработчиков будет проще анализировать.