С чего начать писать тех.задание?
===================================

 как его вообще грамотно составить? ведь от техзадания зависит результат. С плохим ТЗ,результат ХЗ. 

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

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

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

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

 Смотрите ГОСТ 34.602-89 "ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ" - [www.rugost.com/index.php?option=com\_content&view=a...](http://www.rugost.com/index.php?option=com_content&view=article&id=96:gost-34602-89&catid=22&Itemid=53)  

Для начала, прочтите статейку ["Документирование по ГОСТ 34* — это просто"](https://habrahabr.ru/post/122700/).  

Шаблон ТЗ - [www.rugost.com/index.php?option=com\_content&view=a...](http://www.rugost.com/index.php?option=com_content&view=article&id=112:q-q-34&catid=30&Itemid=77)  

Комментарии - [it-gost.ru/content/view/101/51](http://it-gost.ru/content/view/101/51/) 

[protect.gost.ru/v.aspx?control=8&baseC=-1&page=0&m...](http://protect.gost.ru/v.aspx?control=8&baseC=-1&page=0&month=-1&year=-1&search=&RegNum=1&DocOnPageCount=15&id=147258&pageK=4697395B-0322-4488-956A-5591237BFE1C) - 4 странички эти уже прочитали?из них 1 страничка обложки, а вторая пустая. Первые пункты - "Основание для разработки", "назначение разработки". На мой взгляд если вы не можете описать эти 2 пункта - вы не очень понимаете какую проблему вообще решаете, а соответственно написать конкретное тех.задание будет трудно 

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

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

 Если ТЗ на программное обеспечение то ГОСТ 19, если на АС то ГОСТ 34.   

Прочитать тут - [chavalah.ru/?p=526](http://chavalah.ru/?p=526) и тут - <https://habrahabr.ru/post/147858/> 

 Курс на intuit.ru по разработке ПО на основе ГОСТ 34. Очень хороший  

[www.intuit.ru/studies/courses/620/476/info](http://www.intuit.ru/studies/courses/620/476/info) 

 Из личного опыта: большинство заказчиков сами не знают, что им надо. Естественно, в таких случаях ТЗ пишет разработчик. Но, советую, писать на по "казенным" шаблонам, а простым доступным "человеческим" языком - самое главное, чтобы заказчик понял, что ему на самом деле надо, а не "тонул" в ему непонятных терминах. Сначала - попроще, а когда почувствуете, что заказчик хочет и может (!) вникнуть поглубже - дописывать отдельными дополнениями к ТЗ (т.е. от простого к сложному). 

 1. теория: Джой Битти, Карл И. Вигерс "Разработка требований к программному обеспечению"  

2. примеры из практики: [nota.media/yandex](http://nota.media/yandex/) 

 1. Писать должен тот кто разбирается и в ИТ и в бизнес процессах - это идеальный вариант. Но подходит для мелких компаний с технически продвинутым персоналом.  
  

2. На практике - это тандем ИТ-шника и того, кто разбирается в конкретном бизнес-процессе (иногда таковых несколько человек - по каждому процессу - свой). Фактически ИТ-шник допрашивает с пристрастием разных людей, имеющих отношение к бизнес-процессу. И записывает с их слов, интерпретировав в технический язык.  
  

Тут крайне важно, чтобы интервьюироваемые не перекладывали на ИТ-шника. Типа "ты же специалист, должен все знать". Я обычно отвечаю: "Вы хотите чтобы я ваши проблемы решил или свои".  
  

Дело ИТ-шника понять и перевести на технический язык. Но ни в коем случае не самому описывать бизнес-процессы. Бизнес процесс должен описать тот, кто этим занимается.  
  

Причем, важно!!!  

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

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

На самом деле ТЗ не всегда нужно.  
  

Если заказчик согласен вечно платить почасовку - можно без ТЗ.  

Это позволяет сэкономить кучу времени и быстро подстраиваться под изменения бизнеса.  
  

Но это возможно только если заказчик может и согласен платить без ограничений.  

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

Или заказчик безоговорочно доверяет исполнителю (и исполнитель по карману заказчику)  
  

Есть еще вариант -   

делается примитивный прототип MVP  

<https://en.wikipedia.org/wiki/Minimum_viable_product>  

По нему оценивают и тех. задание составляют/уточняют.  

Но делать такие вещи обычные заказчики отказываются,  

только те, кто работает с большими и дорогими вещами - согласны.  

Это серьезно уменьшает их риски.  
  

Не совершайте ошибку - не пишите замороченными словами.  

Нужно писать обычным человеческим языком.  

ТЗ - это намного более простая вещь, чем обычно представляют.  

Это просто описание человеческим языком всех нюансов.