Так что же такое «Техническое Задание»? Техническое задание: как уберечь себя от ошибок и рисков.

Разработка и утверждение технического задания на создание АС - этап 3.1 стадии технического задания. Редакция от 20.06.2018.

Разработка и утверждение технического задания на создание АС

Создан 18.05.2018 11:24:34

Из толкового словаря

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

Термины и определения

Утверждение - Официальное удостоверение уполномоченного на это должностного лица или в том, что разработанный вводится в действие. Удостоверение может быть зафиксировано на утверждаемом документе непосредственной или ссылкой на другой документ, содержащий решение об утверждении (акт, протокол, письмо и т.д.) [из п. 1.4.74 Р 50-605-80-93].

Требования стандартов

На титульном листе помещают заказчика, разработчика и согласующих организаций, которые скрепляют гербовой печатью. При необходимости титульный лист оформляют на нескольких страницах. Подписи разработчиков ТЗ на АС и должностных лиц, участвующих в согласовании и рассмотрении проекта ТЗ на АС, помещают на последнем листе. Форма титульного листа ТЗ на АС приведена в. Форма последнего листа ТЗ на АС приведена в [из п. 3.4 ГОСТ 34.602-89].

На 3.1 «Разработка и утверждение технического задания на создание АС» проводят разработку, и и, при необходимости, технических заданий на части АС [из п. 7 прил. 1 ГОСТ 34.601-90].

Связанные документы

ГОСТ 34.602-89 ИТ. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

Техническое задание на АСУТП разрабатывается по ГОСТ 34.602-89 и содержит следующие разделы:

1. Общие сведения
1.1. Полное наименование Системы
1.2. Шифр темы
1.3. Наименование Организаций - разработчиков, проектировщиков, заказчика, и их реквизиты
1.4. Перечень документов, на основании которых создается Система
1.5. Сроки выполнения работ
1.6. Источники и порядок финансирования
1.7. Порядок оформления и предъявления заказчику результатов работы
2. Назначение и цели создания Системы
2.1. Назначение Системы
2.2. Цели создания Системы
3. Характеристика объекта автоматизации
4. Требования к Системе
4.1. Требования к Системе в целом
4.1.1. Требования к структуре и функционированию Системы
4.1.2. Требования к численности и квалификации персонала
4.1.3. Требования к показателям назначения
4.1.4. Требования к надёжности
4.1.5. Требования безопасности
4.1.6. Требования по эргономике и технической эстетике
4.1.7. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению
4.1.8. Требования к защите информации от несанкционированного доступа
4.1.9. Требования по сохранности информации при авариях
4.1.10. Требования к средствам защиты от внешних воздействий
4.1.11. Требования к патентной чистоте
4.1.12. Требования по стандартизации и унификации
4.1.13. Дополнительные требования
4.2. Требования к функциям, реализуемым Системой
4.2.1. Перечень задач РСУ и требования к качеству их выполнения
4.2.2. Перечень и критерии отказов для каждой функции РСУ
4.2.3. Перечень задач системы ПАЗ
4.2.4. Перечень и критерии отказов для каждой функции системы ПАЗ
4.3. Требования к видам Обеспечения
4.3.1. Требования к Прикладному программному обеспечению
4.3.2. Требования к Информационному обеспечению
4.3.3. Требования к Лингвистическому обеспечению
4.3.4. Требования к Стандартному программному обеспечению
4.3.5. Требования к Техническому обеспечению
4.3.6. Требования к Метрологическому обеспечению
4.3.7. Требования к Организационному обеспечению
5. Состав и содержание работ по созданию АСУТП
5.1. Первое организационное совещание
5.2. Обработка исходных данных
5.3. Разработка Технического проекта
5.4. Рассмотрение Технического проекта
5.5. Конфигурация функций контроля и управления
5.6. Конфигурация функций представления информации
5.7. Приемка Рабочего проекта
5.8. Шефмонтаж и пусконаладка
5.9. Пуск АСУТП в эксплуатацию
5.10. Гарантийный срок
6. Порядок контроля и приемки
7. Требования к составу и содержанию работ по подготовке объекта к вводу АСУТП в действие
8. Требования к документированию
9. Источники разработки
10. ПРИЛОЖЕНИЯ
11. СОСТАВЛЕНО
12. СОГЛАСОВАНО

разработки и утверждения технических заданий по подготовке инвестиционных программ организаций коммунального комплекса, осуществляющих эксплуатацию систем коммунальной инфраструктуры и (или) объектов, используемых для утилизации (захоронении) твердых бытовых отходов, на территории муниципального образования «Город Калуга»

I. Общие положения

1.1. Порядок разработки и утверждения технических заданий по подготовке инвестиционных программ организаций коммунального комплекса, осуществляющих эксплуатацию систем коммунальной инфраструктуры и (или) объектов, используемых для утилизации (захоронения) твердых бытовых отходов, на территории муниципального образования «Город Калуга» (далее – Порядок) устанавливает основы организации разработки и утверждения технических заданий по подготовке инвестиционных программ организациями коммунального комплекса (далее - ОКК).

1.2. Понятия и термины, используемые в настоящем Порядке, применяются в значениях, определенных Федеральным законом от 01.01.01 г. «Об основах регулирования тарифов организаций коммунального комплекса».

1.3. Техническое задание разрабатывается на основании действующего законодательства, программы комплексного развития систем коммунальной инфраструктуры (далее - СКИ) и настоящего Порядка.

Организует разработку технических заданий с учетом реального состояния СКИ и определяет перспективу развития СКИ управление городского хозяйства города Калуги (далее – УГХ) совместно с управлением строительства и земельных отношений города Калуги (далее – УСиЗО).

1.4. Техническое задание в части требований к разработке инвестиционной программы организацией коммунального комплекса (далее - ОКК) обуславливает выстраивание системы планов, элементами которой могут быть:

- генеральный план городского округа «Город Калуга»;

Программа комплексного развития СКИ;

Программа выбытия ветхого и аварийного жилищного фонда муниципального образования «Город Калуга»;

Программа модернизации и реформирования жилищно-коммунального хозяйства муниципального образования «Город Калуга».

2. Порядок разработки и содержание технического задания

2.1. Техническое задание разрабатывается индивидуально для каждой ОКК, осуществляющей эксплуатацию СКИ и (или) объектов, используемых для утилизации (захоронения) твердых бытовых отходов (далее - ТБО).

2.2. В техническое задание включаются:

2.2.1. Цели и задачи разработки и реализации инвестиционной программы ОКК по развитию СКИ, которые формируются на основании общих целей, определенных программой комплексного развития. Основными целями программы комплексного развития СКИ, как правило, являются: оптимизация, развитие и модернизация муниципальных систем тепло-, электро-, газо-, водоснабжения и водоотведения для сохранения их работоспособности или обеспечения целевых параметров улучшения их состояния. В качестве цели может ставиться задача снизить параметры износа оборудования. В случае отсутствия программы комплексного развития СКИ цели разработки и реализации инвестиционной программы формулируются непосредственно в рамках разрабатываемого технического задания.

2.2.2. Требования к инвестиционной программе.

2.2.3. Сроки разработки инвестиционной программы.

2.2.4. Порядок и форма предоставления, рассмотрения и утверждения инвестиционной программы.

2.3. Цели разработки и реализации инвестиционной программы определяются таким образом, чтобы они были количественно измерены. Цели определяются в виде целевых индикаторов, представляющих собой доступную наблюдению и измерению характеристику состояния и развития СКИ, условия эксплуатации указанных систем ОКК, которые необходимо обеспечить за счет реализации инвестиционной программы (далее - целевые индикаторы).

2.3.1. В случае отсутствия программы комплексного развития целевые индикаторы разрабатываются на основании:

Прогноза социально-экономического развития муниципального образования «Город Калуга»;

Планируемых на период реализации разрабатываемой инвестиционной программы объемов ввода объектов жилищного и промышленного строительства , а также характеристик вводимых объектов;

Перечня и характеристик земельных участков, обеспечиваемых инженерной инфраструктурой в целях подключения объектов строительства (реконструкции) в период реализации разрабатываемой инвестиционной программы;

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

2.3.2. Информация о планируемых на период реализации разрабатываемой инвестиционной программы объемах ввода объектов жилищного и промышленного строительства, а также характеристики земельных участков, обеспечиваемых инженерной инфраструктурой в целях подключения объектов строительства (реконструкции), представляется УСиЗО по запросу УГХ и должна содержать:

Перечень строительных площадок, а также перечень зданий, строений и сооружений, подключаемых к СКИ, с указанием планируемого адреса;

Предельное количество этажей и (или) предельную высотность застройки каждого из зданий, строений, сооружений в границах строительных площадок;

Максимальную планируемую нагрузку в точке подключения каждой из площадок, зданий, строений и сооружений по каждому виду предоставляемых коммунальных ресурсов;

Красные линии соответствующих территорий;

Границы зон действия установленных и частных сервитутов;

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

Указанная информация может сопровождаться картами и схемами планируемого размещения объектов строительства и иными документами.

2.3.3. Информация о планируемых объемах ввода объектов жилищного и промышленного строительства может формироваться посредством организации и проведения технических совещаний, рабочих встреч и консультаций с организациями-застройщиками.

2.3.4. Дополнительной исходной информацией для разработки целевых индикаторов может быть информация, получаемая от потребителей товаров и услуг ОКК посредством проведения запросов, а также посредством анализа жалоб и претензий, поступающих в адрес ОКК, о соответствии количества и качества поставляемых товаров и услуг условиям договоров либо установленным требованиям. Также исходной информацией для расчета целевых индикаторов является информация, отражающая:

Финансовое состояние ОКК (в том числе кредиторской и дебиторской задолженности , плановой и фактической выручки);

Показатели производственной программы ОКК;

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

2.3.5. Для разработки технического задания, в том числе для определения целевых индикаторов, УГХ запрашивает от ОКК в письменной форме необходимую информацию с указанием перечня, формы и сроков ее предоставления.

2.3.6. Целевые индикаторы инвестиционной программы определяются таким образом, чтобы они отражали потребности муниципального образования «Город Калуга» в товарах и услугах ОКК, требуемый уровень качества и надежности работы СКИ при соразмерных затратах и экологических последствиях.

Целевые индикаторы могут быть сгруппированы, в том числе в следующие группы:

Надежность (бесперебойность) снабжения потребителей товарами (услугами) ОКК;

Доступность товаров и услуг для потребителей (в том числе обеспечение новых потребителей товарами и услугами ОКК);

Эффективность деятельности ОКК;

Обеспечение экологических требований.

2.3.7. Целевые индикаторы могут определяться с учетом показателей и индикаторов мониторинга, устанавливаемых Методикой проведения мониторинга выполнения производственных и инвестиционных программ организаций коммунального комплекса, утверждаемой Минрегионом России по согласованию с Минэкономразвития России и Федеральной службой по тарифам Российской Федерации.

2.3.8. Основные требования при определении целевых индикаторов:

Однозначность - изменения целевых индикаторов должны однозначно характеризовать положительную или отрицательную динамику происходящих изменений состояния СКИ, а также не иметь различных толкований;

Измеримость - каждый целевой индикатор должен быть количественно измерен;

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

Достижимость - целевые значения индикаторов должны быть достижимы ОКК в срок и на основании ресурсов, предусматриваемых разрабатываемой инвестиционной программой.

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

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

2.3.11. В целях обеспечения единых подходов к формированию целевых показателей развития СКИ необходимо в максимальной степени обеспечить синхронизацию разработки целевых индикаторов в технических заданиях, разрабатываемых для различных ОКК.

2.4. Требованиями к инвестиционной программе определяются условия, на соответствие которым УГХ будет проводить проверку инвестиционной программы.

2.5. В техническом задании отражать следующие условия, которые необходимо реализовать при разработке инвестиционной программы:

2.5.1. В случае отсутствия в муниципальном образовании «Город Калуга» программы комплексного развития в техническом задании могут быть обозначены приоритеты развития инженерной инфраструктуры муниципального образования «Город Калуга» на среднесрочную перспективу, в рамках которой ОКК разрабатывает технические мероприятия по строительству и (или) модернизации СКИ и объектов, используемых для утилизации (захоронения) ТБО. Обозначение приоритетов развития инфраструктуры может заключаться в определении не только значений целевых индикаторов для всей СКИ, но и для отдельных элементов системы (технологических и производственных этапов производства и реализации товаров и услуг).

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

2.5.2. Разработка плана технических мероприятий по строительству и (или) модернизации СКИ и объектов, используемых для утилизации (захоронения) ТБО. При разработке мероприятий учитывать: существующее состояние указанных систем и объектов и обеспечивать доведение их состояния, а также условий их эксплуатации до уровня, задаваемого целевыми индикаторами технического задания; обеспечивать подключение строящихся (реконструируемых) объектов, указанных в техническом задании, к СКИ, а также обеспечивать земельные участки инженерной инфраструктурой. В случае отсутствия программы комплексного развития перечень указанных объектов и земельных участков с их характеристиками и характеристиками планируемых подключаемых объектов (в том числе нагрузок) рекомендуется проводить в приложении к техническому заданию.

2.5.3. В рамках разработки инвестиционной программы в соответствии с частью 3 статьи 11 Федерального закона от 01.01.01 г. должны быть определены финансовые потребности на ее реализацию, которые определяются на основании финансовых потребностей по реализации каждого из мероприятий программы.

2.5.4. Реализация инвестиционной программы, включая отдельные ее мероприятия, в соответствии с частью 1 статьи 10 Федерального закона от 01.01.01 г. обеспечивается соответствующими источниками финансирования, которые гарантируют своевременность инвестиций в необходимом объеме.

2.5.5. Могут быть сформулированы требования по предварительному расчету надбавок к тарифам и тарифов на подключение.

2.5.6. Может быть сформулировано условие о необходимости подготовки ОКК проекта инвестиционного договора в целях развития СКИ. Реализация инвестиционной программы в соответствии с частью 13 статьи 11 Федерального закона от 01.01.01 г. основывается на договоре, заключаемом Городской Управой города Калуги с ОКК, определяющем условия реализации утвержденной инвестиционной программы.

2.5.7. Требование о необходимости согласованности разрабатываемой инвестиционной программы с предыдущими и текущими инвестиционными и производственными программами, направленное на исключение возможного двойного учета реализуемых мероприятий в рамках различных программ.

2.5.8. Требование к форме инвестиционной программы, отражающей требования к ее разработке.

2.6. В техническом задании на разработку инвестиционной программы предусматривается срок разработки инвестиционной программы, то есть срок с момента утверждения технического задания, в течение которого ОКК, для которой утверждено указанное задание, должна разрабатывать инвестиционную программу и иные документы, предусмотренные техническим заданием.

2.6.1. Помимо срока разработки инвестиционной программы в техническом задании может указываться срок реализации инвестиционной программы, то есть период, за который необходимо обеспечить достижение установленных целевых индикаторов. В случае отсутствия программы комплексного развития, а также сроков реализации инвестиционной программы в техническом задании рекомендуется отражать требование по определению периода реализации инвестиционной программы непосредственно ОКК.

2.7. По решению УГХ в техническое задание могут быть включены иные требования.

3. Порядок согласования, утверждения

и изменения технического задания

3.1. Техническое задание разрабатывается и утверждается в сроки, учитывающие период подготовки ОКК инвестиционной программы и сроки утверждения данной программы.

3.2. Проект технического задания предварительно согласовывается УГХ с ОКК, разрабатывающей инвестиционную программу.

3.3. Разработанный проект технического задания в случае необходимости рассматривается на рабочей группе, в состав которой входят представители УГХ, УСиЗО, управления архитектуры и градостроительства города Калуги, управления экономики города Калуги, Городской Думы города Калуги, ОКК, а также по согласованию могут входить и заинтересованные организации, планирующие осуществить строительство (реконструкцию) объектов капитального строительства с подключением новой (дополнительной) нагрузки к СКИ.

3.4. Рассмотренный рабочей группой проект технического задания утверждается правовым актом Городской Управы города Калуги.

3.5. Подготовку проекта правового акта Городской Управы города Калуги об утверждении технического задания осуществляет УГХ.

3.6. Пересмотр или внесение изменений в утвержденное техническое задание осуществляется по инициативе Городского Головы города Калуги. Инициатором пересмотра или внесения изменений в утвержденное техническое задание может выступить соответствующая ОКК, разрабатывающая инвестиционную программу.

3.7. В качестве оснований для пересмотра (внесения изменений) в утвержденное техническое задание рекомендуется определять:

Принятие или внесение изменений в программу комплексного развития муниципального образования «Город Калуга»;

Принятие или внесение изменений в программы социально-экономического развития муниципального образования «Город Калуга» и иные программы, влияющие на изменение условий технического задания;

Вынесение органом регулирования муниципального образования «Город Калуга» решения о недоступности для потребителей товаров и услуг ОКК с учетом надбавки к ценам (тарифам), предлагаемой ОКК для обеспечения реализации инвестиционной программы;

Объективные изменения условий деятельности ОКК, влияющие на стоимость производимых ею товаров (оказываемых услуг), и невозможность пересмотра надбавки к тарифам на товары и услуги ОКК и (или) тарифа ОКК на подключение;

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

3.8. Пересмотр (внесение изменений) технических заданий может производиться не чаще одного раза в год.

3.9. При пересмотре или внесении изменений в техническое задание предусматриваются изменение значений целевых индикаторов, определенных в техническом задании, и (или) корректировка перечня подключаемых к СКИ строящихся (реконструируемых) объектов, а также перечня земельных участков, обеспечиваемых инженерной инфраструктурой.

3.10. В случае если пересмотр, внесение изменений технического задания осуществляется по инициативе ОКК, заявление о необходимости пересмотра технического задания направляется ОКК Городскому Голове города Калуги. Заявление ОКК о пересмотре или внесении изменений в техническое задание должно сопровождаться обоснованием причин пересмотра или внесения изменений в техническое задание с приложением необходимых документов.

3.11. Пересмотр или внесение изменений в техническое задание осуществляется в порядке, соответствующем порядку его разработки.

3.12. Решение об утверждении или пересмотре технического задания, внесение изменений в техническое задание доводятся до ОКК, осуществляющей разработку инвестиционной программы, УГХ в письменном виде в недельный срок со дня его принятия.

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

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

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

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

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

Грамотно составленное ТЗ повышает шансы успешного завершения будущего проекта на 50%, а время, вложенное в разработку ТЗ, – одно из лучших вложений, которое заказчик может сделать в проектный период. Поэтому подготовку ТЗ доверяют самым опытным и квалифицированным специалистам, ведь исправление любой ошибки, допущенной на этапе проектирования ТЗ может очень дорого стоить после заключения договора, а в некоторых случаях и вовсе ставить крест на проекте в целом.

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

Заказчику:

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

Подрядчику:

Разобраться в сути и деталях поставленной задачи;
Выстроить планы по выполнению работ;
Исключить дополнительные работы, не описанные в техническом задании, или потребовать за это дополнительное финансирование.

Всем сторонам:

Понять суть и облик конечного продукта или услуги;
Проверить выполненные работы, провести приемочное тестирование;
Свести к минимуму число ошибок и неточностей в процессе внесения изменений.

Меня часто спрашивают: «Как правильно разработать техническое задание для автоматизированной системы?». Тема разработки технического задания постоянно обсуждается на различных форумах. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему. В процессе работы над статьей я понял, что уложить все в одной статье не выйдет, т.к. получится под 50 страниц и решил разбить ее на 2 части:

В первой части «Разработка Технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть ?» я подробно попытаюсь ответить на вопросы темы, рассмотрю структуру и назначение Технического задания, дам некоторые рекомендации по формулировке требований.
Вторая часть «Разработка Технического задания. Как формулировать требования ?» будет полностью посвящена выявлению и формулировке требований к информационной системе.

Для начала надо разобраться, какой в действительности вопрос интересует тех, кто спрашивает «Как разработать техническое задание?» Дело в том, что от того, для каких целей это делается, а также кем будет использоваться, будет сильно зависеть и подход к разработке технического задания. О каких вариантах я говорю:

Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной IT-службы и решили поступить так: Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации;
Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную IT-службу. Решили поступить так: разработать Техническое задание, затем согласовать его между IT-службой и заинтересованными лицами, и реализовать собственными силами;
Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.
IT-компания занимается услугами по разработке и/или внедрению автоматизированных систем. Это наиболее сложный случай, ведь приходится работать в самых различных условиях:
Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;
- Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);
- Техническое задание разрабатывается для передачи подрядчику (т.е. группе программистов, находящихся за штатом компании, или отдельному специалисту);
- Между компаний и клиентом возникает непонимание в вопросе полученного результата, и компания вновь и вновь задается вопросом: «Как надо разрабатывать Техническое задание?». Возможно, последний случай кажется парадоксом, но это правда.
- Возможны и другие, реже встречающиеся варианты;

Думаю, сейчас у читателя должны возникнуть вопросы:

А почему нельзя разрабатывать Техническое задание всегда одинаково?;
Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?
Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?
Как понять, хорошо составлено Техническое задание или нет?
За чей счет должно оно разрабатываться, да и нужно ли оно вообще?

Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о Технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Поднимая тему разработки Технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попробую, как говорится «разложить все по полочкам». Те, кто уже знаком с моими статьями знают, что я не пользуюсь «копи-пастом» труда других людей, не перепечатываю чужие книги, не цитирую многостраничные стандарты и прочие документы, которые Вы и сами сможете найти в интернете, выдавая их за свои гениальные мысли. Достаточно набрать в поисковике «Как разработать Техническое задание» и Вы сможете прочитать много интересного, но, к сожалению, многократно повторяющегося. Как правило, те, кто любит умничать на форумах (попробуйте все-таки поискать!), сами никогда не делали толкового Технического задания, и непрерывно цитируют рекомендации ГОСТов по данному вопросу. А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах. Про ГОСТЫ, кстати, мы тоже поговорим. В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам (такой небольшой разведкой). В результате приходилось видеть документацию и по таким монстрам, как ГазПром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов (разбрасывают информацию по интернету). Поэтому сразу говорю: конфиденциальной информацией, которая принадлежит другим компаниям не делюсь, независимо от источников возникновения (профессиональная этика).

Что такое техническое задание?

Первое, что мы сейчас сделаем, так это разберемся с тем, что за зверь такой, «Техническое задание».

Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись. Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели. Возможно, кто-то сейчас подумал, что правда где-то по середине. Я бы ответил словами Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае! Между ними лежит проблема ». Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.

Заметим, что в ГОСТе явно не дано даже определения, сказано лишь: «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации — далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».

Если кому-то интересно, о каких ГОСТах я говорю, то вот они:

ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

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

И так, как следует из определения, основное назначение Технического задания — сформулировать требования к разрабатываемому объекту, в нашем случае к автоматизированной системе.

Именно основное, но единственное. Настало время взяться за главное: разложить все «по полочкам», как и обещал.

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

Требования в функциональности;
Требования к безопасности и правам доступа;
Требования к квалификации персонала;
…. И т.д. Вы можете прочитаете о них в упомянутом ГОСТе (а ниже я их тоже рассмотрю немного подробнее).

Думаю, для Вас очевидно, что ключевым фактором успешного Технического задания являются именно хорошо сформулированные требования к функциональности. Именно этим требованиям посвящено большинство работ и методик, о которых я говорил. Требования к функциональности - это 90% сложности работ по разработке Технического задания. Все остальное зачастую является «камуфляжем», который надет на эти требования. Если требования сформулированы плохо, то какой красивый камуфляж на них не натягивай, успешного проекта не выйдет. Да, формально все требования будут соблюдены (по ГОСТу J), ТЗ разработано, утверждено и подписано, деньги за него получены. И что? А дальше начнется самое интересное: что делать-то? Если это проект на ГосЗаказе, то проблем нет - там бюджет такой, что ни в какой карман не влезет, в процессе реализации (если она будет) все и будет выясняться. Именно таким образом и пилится большинство бюджетов проектов на ГосЗаказах (накалякали «ТЗ», слили десяток миллионов, а проект делать не стали. Все формальности соблюдены, виновных нет, новое авто возле дома. Красота!). Но ведь мы говорим о коммерческих организациях, где деньги считают, да и результат нужен другой. Поэтому давайте разбираться с главным, как разрабатывать полезные и работающие Технические задания .

Про виды требований я сказал, а что же со свойствами? Если виды требований могут быть различными (зависит от целей проекта), то со свойствами все проще, их 3:

Требование должно быть понятным ;
Требование должно быть конкретным ;
Требование должно быть тестируемым ;

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

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

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

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

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

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

Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование Техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований. Что, знакомая ситуация? И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ, т.к. много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. и т.п. А потом начинается сериал про сдачу работ. «А вот тут не так как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо?!! Вот и мне знакомо, пришлось набить шишек в свое время.

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

Еще небольшой, но важный момент. Иногда Техническим заданием называют небольшой кусочек требований, простой и понятный. Например, доработать поиск объекта по каким-либо условиям, добавить колонку в отчет и пр. Такой подход вполне себе оправдан, зачем усложнять жизнь. Но применяется не на больших проектах, а на мелких доработках. Я бы сказал это ближе к сопровождению программного продукта. В этом случае в Техническом задании может быть описано и конкретное техническое решение реализации требования. Например, «В алгоритм такой-то внести такое-то изменение», с указанием конкретной процедуры и конкретного изменения для программиста. Это тот случай, когда граница между Техническим заданием и Техническим проектам полностью стирается, т.к. нет никакой экономической целесообразности раздувать бумаготворчество там, где это не нужно, а полезный документ создается. И это правильно.

А нужно ли вообще техническое задание? А Технический проект?

Не перегрелся ли я? Разве такое возможно, вообще без Технического задания ? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий». В них говорится «минимум бумаг», особенно ненужных, ближе к Заказчику, больше конкретики и быстрее к результату. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Просто у некоторых людей так устроено сознание, что если можно что-то упростить, так давайте это упростим до полного отсутствия. Как сказал Эйнштейн «Сделай так просто, как возможно, но не проще этого» . Золотые ведь слова, ко всему подходят. Так что Техническое задание нужно, иначе успешного проекта Вам не видать. Другой вопрос, как составлять и что туда включать. В свете методологий быстрой разработки надо сосредоточиться только на требованиях, а весь «камуфляж» можно отбросить. В принципе, я с этим согласен.

А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ. Должен ли с ним знакомиться Заказчик? Если хочет, почему нет, но настаивать и утверждать данный документ нет никакой необходимости, он будет только сдерживать и мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы и программистами.

Интересная деталь по поводу технического проектирования: некоторые средства разработки, устроенные по принципу предметной ориентированности (типа 1С и аналогичных) предполагают, что проектирование (имеется ввиду процесс документирования) требуется только на действительно сложных участках, где требуется взаимодействие между собой целых подсистем. В простейшем случае, например создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов. Если посмотреть на экзаменационный билет специалиста (именно так он называется, а не «программиста»), то Вы увидите, что там присутствуют лишь бизнес-требования, а как их реализовать на программном языке это и есть задача специалиста. Т.е. ту часть задачи, которую призван решать Технический проект, специалист должен решить «в голове» (речь идет о задачах средней сложности), причем здесь и сейчас, следуя определенным стандартам разработки и проектирования, которые формирует опять же компания 1С для своей платформы. Таким образом, из двух специалистов, результат работы которых внешне выглядит одинаково, один может экзамен сдать, а второй нет, т.к. грубо нарушил стандарты разработки. Т.е заведомо предполагается, что специалисты должны обладать такой квалификацией, чтобы типичные задачи проектировать самостоятельно, без привлечения архитекторов системы. И такой подход работает.

Продолжим исследование вопроса: «Какие требования включать в Техническое задание?»

Формулирование требований к информационной системе. Структура Технического задания

Сразу определимся: мы будет говорить именно о формулировании требований к информационной системе, т.е. предполагая, что работа по выработке бизнес-требований, формализации бизнес-процессов и вся предшествующая консалтинговая работа уже выполнена. Конечно, некоторые уточнения могут выполняться и на этом этапе, но именно уточнения. Сам проект автоматизации не решает проблем бизнеса - помните об этом. Это аксиома. Почему-то некоторые руководители пытаются ее опровергнуть, считая, что если купят программу, то наступит порядок в хаотичном бизнесе. Но ведь аксиома на то и аксиома, что доказательств не требует.

Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий. По экспертным оценкам, стоимость затрат на разработку Технического задания может составлять 30-50%. Я придерживаюсь такого же мнения. Хотя 50 - пожалуй, перебор. Ведь Техническое задание - это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).

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

общие сведения;
назначение и цели создания (развития) системы;
характеристика объектов автоматизации;
требования к системе;
состав и содержание работ по созданию системы;
порядок контроля и приемки системы;
требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
требования к документированию;
источники разработки.

Итого, 9 разделов, каждый из которых тоже делится на подразделы. Разберем их по-порядку. Для удобства представлю все в виде таблицы по каждому пункту.

Раздел 1. общие сведения.

Рекомендации по ГОСТ
полное наименование системы и ее условное обозначение;	Тут все понятно: пишем, как будет называться система, ее краткое наименование
шифр темы или шифр (номер) договора;	Это не актуально, но можно и указать, если требуется
наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;	указывают, кто (какие организации) будут работать над проектом. Можно указать и их роли.Можно вообще удалить этот раздел (достаточно формальный).
перечень документов, на основании которых создается система, кем и когда утверждены эти документы;	Полезная информация. Тут стоит указать ту нормативно-справочную документацию, которую Вам предоставили для ознакомления с определенной частью требований
плановые сроки начала и окончания работы по созданию системы;	Пожелания по срокам. Иногда в ТЗ об этом пишут, но чаще такие вещи описываются в договорах на работы
сведения об источниках и порядке финансирования работ;	Аналогично, как и в предыдущем пункте про сроки. Более актуально для государственных заказов (для бюджетников)
порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.	Не вижу необходимости в этом пункте, т.к. требования к документированию вынесены отдельно, а кроме этого есть целый отдельный раздел «Порядок контроля и приемки» системы.

Раздел 2. назначение и цели создания (развития) системы.

Рекомендации по ГОСТ	Что с этим делать на практике
Назначение системы	С одной стороны с назначением все просто. Но желательно формулировать конкретно. Если написать что-то вроде «качественно автоматизировать складской учет в компании Х», то потом можно долго обсуждать результат при его завершении, даже независимо от хорошей формулировки требований. Т.к. Заказчик всегда может говорить, что под качеством он имел ввиду нечто иное. В общем, нервов можно попортить друг другу много, а зачем? Лучше сразу написать примерно так: «Система предназначена для ведения складского учета в компании Х в соответствии с требованиями, зафиксированными в данном Техническом задании».
Цели создания системы	Цели - это безусловно важный раздел. Если уж его включать, то надо уметь эти цели формулировать. Если у Вас трудности с формулировкой целей, то лучше вообще исключить данный раздел. Пример неудачной цели: «Обеспечить быстрое оформление документов менеджером». Что такое быстрое? Это можно потом доказывать бесконечно. Если это важно, то лучше переформулировать данную цель так: «Менеджер по продажам должен иметь возможность оформить документ «Реализация товаров» из 100 строк за 10 минут». Подобная цель может появиться, если, например, в настоящее время менеджер тратит на это около часа, что слишком много для этой компании и для них это важно. В такой формулировке цель уже пересекается с требованиями, что вполне естественно, т.к. при разворачивании дерева целей (т.е. дробя их на более мелкие связанные цели), мы и так будем приближаться к требованиям. Поэтому, увлекаться не стоит.

Вообще, умение выделять цели, формулировать их, строить дерево целей это тема совершенно отдельная. Запомните главное: умеете - пишите, не уверены - вообще не пишите. А что будет, если не сформулировать цели? Будете работать по требованиям, такое часто практикуется.

Раздел 3. Характеристика объектов автоматизации.

Раздел 4. Требования к системе

ГОСТ расшифровывает перечень таких требований:

требования к структуре и функционированию системы;
требования к численности и квалификации персонала системы и режиму его работы;
показатели назначения;
требования к надежности;
требования безопасности;
требования к эргономике и технической эстетике;
требования к транспортабельности для подвижных АС;
требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;
требования к защите информации от несанкционированного доступа;
требования по сохранности информации при авариях;
требования к защите от влияния внешних воздействий;
требования к патентной чистоте;
требования по стандартизации и унификации;

Несмотря на то, что основным, безусловно, будет раздел с конкретными требованиями (функциональными), данный раздел тоже может иметь большое значение (и в большинстве случаев имеет). Что может оказаться важным и полезным:

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

Все остальные требования менее важны и можно их не описывать. На мой взгляд, они только утяжеляют документацию, и практической пользы несут немного. А Требования к эргономике описывать в виде общих требований очень сложно, лучше их перенести к функциональным. Например, может быть сформулировано требование «Получить информацию о цене товара нажав только одну кнопку». На мой взгляд, это все-таки ближе к конкретным функциональным требованиям, хоть и относится к эргономике.Требования к функциям (задачам), выполняемым системойВот он, тот самый главный и ключевой пункт, который будет определять успех. Даже если все остальной сделать на отлично, а этот раздел на «3», то и результат по проекту будет в лучшем случае на «3», а то и вообще проект провалится. Именно эти мы и займемся более детально во второй статье, которая войдет в 5-й выпуск рассылки. Именно к этому пункту относится «правило трех свойств требований», о которых я говорил.Требования к видам обеспечения

ГОСТ выделяет такие виды:

Математическое
Информационное
Лингвистическое
Программное
Техническое
Метрологическое
Организационное
Методическое
и другие…

На первый взгляд может показаться, что эти требования не важны. В большинстве проектов это действительно так. Но не всегда. Когда стоит описывать данные требования:

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

Раздел 5. Состав и содержание работ по созданию системы

Раздел 6. Порядок контроля и приемки системы

Общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;Настоятельно рекомендую с ответственностью отнестись к порядку сдачи работ и проверке системы. Именно для этого и нужны тестируемые требования.Но даже наличие тестируемых требований может оказаться недостаточно при сдаче системы, если четко не прописан порядок приемки-передачи работ. Например, распространенная ловушка: система сделана, вполне работоспособна, но Заказчик по каким-либо причинам не готов в ней работать. Причины эти могут быть любые: некогда, поменялись цели, кто-то уволился и т.п. И говорит: «Поскольку мы еще не работаем в новой системой, значит и не можем быть уверены, что она работает». Так что учитесь правильно выделять этапы работ, способы проверки результатов по этим этапам. Причем Заказчику такие способы должны быть понятны изначально. Если они зафиксированы на уровне Технического задания, то всегда можно при необходимости к ним обратится и подвести работы с передаче.

Раздел 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

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

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

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

Возможно, что-то упрощалось, а теперь требуется учитывать более детально, соответственно кто-то должен собирать информацию по определенным правилам.

Этот перечень может быть длинным, смотрите на конкретный случай своего проекта.Создание необходимых для функционирования системы подразделений и служб;

Сроки и порядок комплектования штатов и обучения персоналаПро это мы уже говорили ранее. Возможно, система разрабатывается под новую структуру или вид деятельности, которого раньше не было. Если не будет соответствующего персонала, да еще и обученного, то система не заработает, как грамотно ее не строй.

Раздел 8. Требования к документированию

Подумайте, как будут представлены руководства пользователя.

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

Игнорирование требований к документации очень часто приводит к самым неожиданным последствиям на проектах. Например, все сделано и все работает. Пользователи тоже умеют работать. Про документацию вообще не договаривались и не разговаривали. И вдруг при сдаче работ кто-то из топ-менеджеров Заказчика, который даже не участвовал в проекте, но участвует в приемке работ, Вас спрашивает: «А где руководства пользователя?» И начинает Вас убеждать, что о наличии руководств пользователя договариваться было и не нужно, это «само собой» якобы подразумевается. И все, не хочет принимать у Вас работу. За чей счет будете разрабатывать руководства? На этот крючок попадали уже многие команды.

Раздел 9. Источники разработки

Рекомендации по ГОСТ

Что с этим делать на практике

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

Если честно, это ближе к лирике. Особенно, когда говорят об экономическом эффекте и пр. вещах, которые объективно посчитать практически невозможно. Т.е. можно конечною, то это будет скорее на бумаге, чисто теоретически.

Поэтому, лучше сослаться просто на отчет об обследовании, требования ключевых лиц.

И так, мы рассмотрели все разделы, которые могут быть включены в Техническое задание. «Могут», а не «Обязаны» именно потому, что любой документ должен разрабатываться для достижения результата. Поэтому, если для Вас очевидно, что какой-то отдельный раздел к результату не приблизит, значит он Вам не нужен и не надо тратить на него время.

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

Во второй статье будем говорить только о разделе 4 «Требования к системе», а конкретно мы будет формулировать требования из соображений понятности, конкретности и тестируемости.

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

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

Вид требования

Неправильная формулировка