Добрый день! Посоветуйте методичку или книгу как правильно писать ТЗ на разработку.

Сразу ищи методичку для того кто будет читать твое тз, написанное по методичке

http://www.swrit.ru/gost-34.html

спасибо!

(2) послал так послал...

Кстати говоря, ближайшие вещи, которые мне как разрабу напоминают ТЗ, это любые юридические документы

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

(5) Идеал, по факту задача звучит двояко, по большей части напоминает "Сделать кнопку 'Работать хорошо'"

Хочу научится писать ТЗ, чтоб разработчики 1С четко понимали что им нужно делать.

(0) Можно ручкой писать. Особо продвинутые в текстовом редакторе набирают.

(7) Для этого достаточно ясно выражать свои мысли.
Для лучшего понимания прикладывать картинки и формулы.

(8) ща волшебнику на тебя пожалуюсь, он где то тут был :)

(0) В виде набора тестов.

(5) "любые юридические документы" - если бы. Даже поговорка есть: "два юриста - три мнения".

(7) то есть ты, разговаривая с пользюками и трансоируюя это посредством ТЗ для кодеров 1С - лелешь мысль что ты ничего не исказил...
смишно...

(7) чтобы научиться так писать ТЗ надо стать программистом

Чтобы хорошо написать ТЗ на разработку, надо иметь хорошо написанные технические требования.

(0) ГОСТ 34.602
но с разбегу ни у кого не получается. Люди обычно читают ГОСТ, думают, что надо форму соблюсти, и теряют к херам содержание. Надо понимать, о чем именно, писать в каждом разделе ГОСТа

(15) обычно требования как раз и прорабатываются в процессе написания ТЗ. Если требования, тем более **технические** детально описаны до ТЗ, то ни в каком ТЗ нет необходимости

+(16) еще в IEEE 830 преамбулу прямо надо внимательно прочесть, особенно "характеристики хорошего SRS". Прямо надо, чтобы в голове это осело.

(16) Ну что вы, как же без связки "служебка + техтребования + техпроект + акт"? Тогда раздутый бюрократический аппарат с голоду умрет!

(0)Как и для всякой писательской деятельности тут талант нужен.:-)

(1) :)

(19) Этому можно научить и в условиях отсутствия таланта. Я пробовал. Результат получаются примерно, как речь глухонемого, то есть несколько коряво и сильно упрощенно, но разработку по таким ТЗ можно вести не хуже, чем - по хорошим ТЗ. Ну, может, чуть больше итераций - в пределах стат. погрешности.

самое лучше ТЗ пишется так

1. Краткое описание конечного результата (как должно получится)
2. Описание процедуры тестирования и приемки (как и по каким критериям будет приемка)
3. Описание интерфейсов (где должна быть кнопка и каких размеров)
4. Описание технической архитектуры (какие регистры и метаданные добавляем/меняем)


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

(7) А разработчик в любом случае сделает то, что умеет, из того, что возможно, из того, что запомнил.
ТЗ нужно для приемки результат в большей степени, чем для разработчика.

(22) 4 должен разработчик придумывать. Всегда. Иначе это будет пять параллельных красных линий прозрачного цвета

(24) не всегда, иногда это делает архитектор

(25) я об этом и говорю. Пункт 4 не для ТЗ. Он появляется на основании ТЗ в голове у архитектора или лица, им считающегося.

(26) ты не прав... распишу как и когда рождаются эти пункты

п. 1 - это функциональные требования заказчика, рождаются в диалоге РП и заказчиков. ТЗ еще нет
п. 2 - рождается на основании ФТ, его предлагает РП а принимает и дополняет заказчик
п. 3 - Рождается на основание ФТ, иногда согласуется с заказчиком а иногда и нет.  
п. 4 - Рождается на основании ФТ, и как правило ни как не согласуется с заказчиком

и вот когда все 4 пункта есть - пишется ТЗ ...

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

Чтобы писать хорошие ТЗ, нужно побыть в шкуре программиста, а чтобы просто писать ТЗ, достаточно фантазии)

(0) Судя по веткам на мисте, среднестатистический специалист не читает постановки задачи

(29) Найди хотя бы одну ветку на мисте, где постановка задач без доп вопросов заканчивалась бы ответом

(22) по WMS:
"1. Краткое описание конечного результата (как должно получится) "
.
Описание:
"сейчас - хреново, будет - хорошо".
если писать более развернуто, то получится общее описание работы склада под управлением WMS. Ничего конкретного.

(32) по WMS нельзя написать ТЗ, но можно написать ПРЕКТ, который будет состоять из кучи разных ТЗ и кучи итераций внедрения....


декомпозицию никто не отменял :)


точно так невозможно написать ТЗ например на ракету для полета на Луну...

как всегда vde69 несет бред

(0) Используйте Scram. Там вместо ТЗ пишут пользовательские истории. :-) Если не научишься писать понятно для программисте и заказчика, то хоть руку набьешь. Станешь сказочником. ;-)

(35) пишется Scrum

(36) как всегда ИТ директор вообще ничего кроме критики не несет, его даже на бред не хватает.

(37) ЛОЛ, ты же вроде начальник типа да? Мне очень странно объяснять тебе прописные истины что в ТЗ содержатся требования к функциям, а то как они будут реализовываться называется "технический проект". Описанное п.3 и п.4 в (22) можно было бы списать на неграмотность, но после таких яростных убеждений в (27) все твои повествования кроме как бредом назвать нельзя.

(16) не 34, а 19. Есть разница между автоматизированной системой и софтом.

(0) ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению

(38) я описываю не абстрактное ТЗ а тот комплект бумаг который должен попасть к разработчику и который он (разработчик) понимает как ТЗ.

А правильно или не правильно написано ТЗ - разработчику пофиг, ему главное, что бы оно было понятное. А указанные пункты и дают это ясность...

Я вот весело посмеюсь как разработчик будет писать по строго оформленному по ГОСТУ ТЗ, вот я буду угорать....

(38)>>>что в ТЗ содержатся требования к функциям

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

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

(41) судя по твоей орфографии ТЗ тебе не доверил бы писать ни один даже самый захудалый франч, поэтому всё что ты здесь пишешь это какие-то твои влажные фантазии

(43) Вам шашечки или ехать?

да, к сожалению для франча главное - шашечки, по этому я для них действительно не подойду в роли писателя ТЗ. И я этому очень даже рад :)

зы
вот сейчас прислали ком предложение на внедрение срм, вода, водой... но зато все оформлено правильно... Лично я такие предложения сразу отдаю менеджерам проектов, пусть у них голова пухнет :)

(0) > Посоветуйте методичку или книгу как правильно писать ТЗ на разработку.

Главное, что надо знать: ТЗ пишется на языке предметной области и содержит перечень изменений объектов системы и описание получаемого после работы специалиста результата.
Все остальное - буквоедство и шлак.

Как-то мыслится что сначала тех проект, а потом ТЗ

Или не?

Пиши по-русски.

(42) Ну это же рабство какое-то. Понимают два подписанта, а кодеру ни#уя не понятно. Бабки летают туда и сюда, только ему не понять никогдааа )

(49) потому что интересы кодера меньше всего кого то волнуют)

(49) Почему ты думаешь что кодер сам не может написать понятное Заказчику ТЗ в терминах предметной области? Среди 1С-ников самое обычное явление.

Более того умный 1С-ный кодер будет писать в ТЗ только то что понимает как сделать.

(51) Потому что правильный ответ в (50).

(53) ЛОЛ, ты не думал что кодер может быть ЛПР со стороны Исполнителя?

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

(39) научи меня, ага. Почитай тот и другой, - это раз. Два - на чем основывается твое категоричное "не то, а это"?

(46) нет. ТЗ - это ЧТО мы хотим, ТП - это КАК мы это будем делать.

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

(58) отсутствие содержание как раз бывает, когда за дело берется светлая голова с победитовым наконечником. К самому по себе артефакту разработки под названием "техническое задание" это не имеет отношение. То, что ты сказал - это характеристика чукчей-писателей, а не результата ими написанного

(57) как-как... руками...

(0) Лучше всего писать ТЗ в виде корректно работающего кода. :)))
А программист пусть оптимизирует, приводит к стандартам и т.п.