@greenhorn

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

0

@CheshireCat

ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
http://www.specgost.ru/
http://vsegost.com/

0

@greenhorn

Спасибо за ответ. Про ГОСТ я знаю. Хотелось бы узнать существует ли какая-нибудь лит-ра или статьи кроме ГОСТа.

0

@Phantom

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

Так что посмотрите ссылку, которую я привел, там можно многое почитать.

1

@CheshireCat

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

1

@greenhorn

Абсолютно согласен с Phantom - все что я находил через Google - и без того понятная вода. Просто хотелось бы уточнить - уточняются ли в реальном ТЗ требования к пользовательскому интерфейсу? И если да, то насколько подробно? Просто написать, что приложение содержит n форм, с такими то полями для ввода достаточно? Или интерфейс оговаривается максимально детально (например какого цвета должен быть задний фон, какие элементы используются для выбора конкретных опций итд)? Также хотелось бы посмотреть на примеры реальных ТЗ на разработку ПО. Согласен что в инете можно найти множество примеров, но все они в основном на разработку сайта.

0

@CheshireCat

Что именно будет написано в реальном ТЗ - зависит от того человека, который его (ТЗ) разрабатывает. Обычно, разрабатывает ТЗ - исполнитель, а согласует и утверждает - заказчик. Вот поэтому и пиши так, как тебе выгодно и нужно. Останется только убедить заказчика, что это правильно. А тут у тебя есть железный аргумент - ГОСТ, который описывает содержание этого документа достаточно общо. А раз ТЗ не противоречит требованиям ГОСТа - значит, оно написано правильно ))

Добавлено через 13 минут
Классика жанра о разработке и управлении требованиями к ПО: http://www.proklondike.com/boo... vaniy.html

1

@greenhorn

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

0

@CheshireCat

А зачем тебе требования "согласовывать" с заказчиком? Заказчик должен более-менее связно изложить свои бизнес-процессы и требования ("хотелки"), а аналитик - эти требования выявить, задокументировать и проанализировать. Затем - только ключевые (а их не может быть очень много) требования внести в ТЗ, оформить его согласно ГОСТу (чтобы комар носа не подточил) и вот его-то - уже согласовывать с заказчиком. Обрати внимание, что полный перечень требований вытекает из списка требований, изложенных в ТЗ, но - не ограничивается (ни в коем случае!) ими.

1

@Laba

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

Стандарты (типа ГОСТ) и прочие рекомендации в разных-всяких методологиях - это "вода", которую большинство используют для надувания щёк и прикрытия всяких мест. Знать надо, но руководствоваться не стоит.

Причина проста. Структура и содержание ТЗ - это область _корпоративных_ стандартов.

"Внутреннее" ТЗ нужно ВАМ, а не заказчику. И его разрабатывают с учетом требований ВАШИХ аналитиков, проектировщиков, кодеров и т.д. (В каждом монастыре свой устав)

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

Сами видите, литература по разработке корпоративных стандартов - это далеко от программерства,
а в книгах о продажах продавцов не учат "педантично прорабатывать ТЗ"

Добавлено через 8 минут
Случаи, конечно, бывают разные, но мне чаще встречаются заказчики, которые, в лучшем случае, говорят какую проблему они хотят решить или как заработать больше денег. Они не особо готовы рассказывать все! подробности своих бизнес-процессов и рассуждать о требованиях к программе. Причина - они мало знают детально "свои бизнес процессы" и про требования к программе тоже не слыхали. Но почему-то деньги у них есть.

Спорно - кто и что кому должен. Реально есть продажа услуги и есть процесс её оказания. Где здесь место ТЗ писал выше.

0