Стандарты и шаблоны для тз на разработку по. Техническое задание Требования к патентной чистоте

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

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

В данной статье мы пункт за пунктом разберем все требования ГОСТа и попробуем сделать разработку ТЗ по ГОСТ 34 не обременением, а большой помощью в проекте.

1. О чем статья

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

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

ВНИМАНИЕ: ЦЕЛЬ ЭТОЙ СТАТЬИ - НЕ ЗАМЕНИТЬ ГОСТ, А РАЗЪЯСНИТЬ НЕКОТОРЫЕ ЕГО ПОЛОЖЕНИЯ.

2. Характерные особенности Технического задания по ГОСТ 34

2.1. По какому стандарту составляется ТЗ?

Полное наименование стандарта на ТЗ по ГОСТ 34 следующее: ГОСТ 34.602-89 «Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

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

Действительно, в стандарте используется много непонятных терминов. Что, например, имеется в виду под лингвистическим обеспечением? Для прояснения использующихся понятий следует обратиться к ГОСТ 34.003-90 «Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения».

2.2. Зачем нужен ГОСТ на Техническое задание?

Наверное, когда вам нужно составить какой-то новый для вас документ, вы ищете в Интернете шаблон такого документа или просите его у коллег. Так вот, ЛЮБОЙ стандарт на документы или процессы - это шаблон. Причем шаблон очень сильно упрощает разработку документа: за тебя уже продумали структуру и содержание, кроме того, в таком шаблоне учитываются такие моменты, про которые вы бы и не вспомнили.

2.3. Какую роль Техническое задание занимает в проекте?

Согласно пункту 1.7 стандарта РД 50-682-89, «техническое задание является основным документом, в соответствии с которым проводят создание АС и приемку его заказчиком». И это действительно главный документ. В нем должно описываться все, что необходимо для разработки и внедрения системы.

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

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

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

2.4. Насколько ГОСТ 34.602-89 устарел и есть ли более новые стандарты?

Ни насколько не устарел. Мне почти не удалось найти каких-то неактульных вещей. И никто из тех, кто заявляет об устаревании ГОСТ 34, не могут привести ни одного примера (наверное, просто не хватило квалификации для его прочтения?) Дело в том, что ГОСТ описывает общий подход к проекту автоматизации, там не идет речь о программировании, ГОСТ 34 не об этом.

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

• IEEE 830-1998. Методика составления спецификаций требований к программному обеспечению.
• ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.
• ISO/IEC/IEEE 29148-2011. Systems and software engineering - Life cycle processes - Requirements engineering.
• ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом.
• Ну и ГОСТы серии 34.

3. Общие принципы составления ТЗ по ГОСТ 34

3.1. Какой специалист должен составлять Техническое задание по ГОСТ 34?

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

Техническое задание должен составлять бизнес-аналитик, потому что он является «переводчиком» между заказчиком и командой разработки. Задача бизнес-аналитика - разобраться в том, что нужно заказчику и выразить это так, чтобы было понятно команде. И выразить это в виде технического задания. Причем от бизнес-аналитика требуется не просто выслушать заказчика и его сотрудников, а узнать то, о чем они не сказали (а такого обычно более 50%). Поэтому аналитик должен хорошо знать автоматизируемые процессы и за счет своего знания заполнять пробелы, которые остались по результатам обследования.

3.2. Какая сторона должна составлять Техническое задание?

В основном Техническое задание составляется исполнителем? Почему?

Не только потому что так рекомендуется в Приложении 1 к ГОСТ 34-602-89. На самом деле, у заказчика, как правило, отсутствуют соответствующие специалисты. Но ТЗ в обязательном порядке прорабатывается и согласовывается заказчиком. И вот здесь нужно обязательно добиться того, чтобы согласование не было формальным. Я всегда стараюсь настоять на том, чтобы мы вместе с заказчиком подробно разобрали каждый пункт. Ваша цель - вовлечь заказчика в проект. Иначе он так и не сформирует свои ожидания от системы, а значит, во-первых, будет недоволен любым результатом, а, во-вторых, не сможет провести необходимые организационные мероприятия.

3.3. Насколько далеко можно отходить от ГОСТ 34?

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

На самом деле, все не так. Любой процессный стандарт (то есть стандарт не на колбасу, а на какую-либо деятельность) дает только общие указания, канву. Он создан, чтобы помочь не забыть что-то важное, передать вам опыт поколений, а не загнать за флажки.

Не верите? Тогда читайте пункт 2.2 ГОСТ 34.602-89 (кстати, цифры после дефиса - год публикации стандарта или его редакции): «В зависимости от вида, назначения, специфических особенностей объекта автоматизации и условий функционирования системы допускается оформлять разделы ТЗ в виде приложений, вводить дополнительные, исключать или объединять подразделы ТЗ». Также в п. 1.2. РД 34.698-90 указано: «Содержание документов является общим для всех видов АС и, при необходимости, может дополняться разработчиком документов в зависимости от особенностей создаваемой АС. Допускается включать в документы дополнительные разделы и сведения, объединять и исключать разделы».

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

3.4. Зачем в ТЗ по ГОСТ 34 описывается так много требований, напрямую не относящихся к функциям системы?

Действительно, в ТЗ из 30-и страниц может только 7-10 страниц быть посвящено функциям. У этого есть объяснение. Дело в том, что разработчики ГОСТ 34 совершенно по-другому смотрели на проект автоматизации, чем мы. И смотрели более правильно, более комплексно.

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

Во-вторых , составители ГОСТ 34 видели систему в первую очередь как людей, а затем уже как программно-аппаратный комплекс. Вот как ГОСТ 34.003-90 определяет автоматизированную систему: «Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций». Таким образом, информационная система - это обученный персонал, программное обеспечение и аппаратный комплекс, все вместе. И правда, отбери у бухгалтеров компьютеры, они с трудом, но смогут выполнять свою работу, пусть и с бумажными реестрами. А вот 1С без бухгалтера самостоятельно работать не будет. Отсюда и множество разделов ТЗ, посвященных организационным мерам. Как говорят, ИТ-система на 20% - это ИТ, все остальное - организационные мероприятия. То есть ТЗ - это документ, в котором прописывается все необходимое для внедрения системы, от А до Я.

В-третьих , обратите на само название ГОСТа 34.602-89: «Техническое задание на создание автоматизированной системы». ТЗ не на систему, а на создание системы. В чем отличие? Отличие в том, что ТЗ устанавливает не только требования к самой системе, но и регламентирует процесс ее создания, то есть в документе приводятся требования ко всем организационным мерам, выполнение которых необходимо для достижения результата. Ведь при реализации проекта автоматизации зачастую следует перестроить ряд процессов, обучить персонал, подготовить аппаратную часть.

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

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

3.5. Зачем в разных разделах говорится об одном и том же?

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

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

3.6. Нужно ли качественно оформлять ТЗ?

Хотя требования к оформлению ТЗ приводятся в пункте 3 ГОСТ 34.602-89, скажем несколько слов о данном аспекте.

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

Приведем несколько пожеланий к оформлению больших документов, как ТЗ.

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

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

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

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

Заметим, что, по строгим правилам, ТЗ оформляется без рамки (об этом сказано в п. 3), а вот остальные документы - с рамкой. Это установлено в ГОСТ 24.301-80 «Система технической документации на АСУ. Общие требования к выполнению текстовых документов (с Изменениями № 1, 2)». Данный стандарт устанавливает правила оформления всех документов, кроме ТЗ и документов, создаваемых на предпроектных стадиях. Хотя лично мне рамка не нравится ни в каких документах.

4. Раздел 1. «Общие сведения» /п. 2.3 ГОСТ 34.602-89/

Большинство сведений, приводимых в данном разделе, не нуждаются в комментарии, поэтому мы остановимся только на некоторых подразделах.

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

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

5. Раздел 2. «Назначение и цели создания (развития) системы» /п. 2.4 ГОСТ 34.602-89/

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

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

С целью все по-другому. Цель - это ради чего мы затеваем проект. Можно назвать это бизнес-целями. Я выделяю следующие возможные цели проектов автоматизации:

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

В ГОСТе также написано, что необходимо приводить критерии оценки достижения цели, то есть конкретные показатели. Например, у нас 3 человека собирают всего 20 заказов за сутки. А мы после внедрения системы хотим, чтобы каждый собирал по 20 заказов, то есть в три раза больше. Если там такие показатели известны, приводим их в данном пункте.

6. Раздел 3. «Характеристики объекта автоматизации» /п. 2.5 ГОСТ 34.602-89/

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

Давайте сначала определим, что такое «объект автоматизации». Если мы автоматизируем склад или завод, отдел бухгалтерии, то все понятно. А если, например, создаем новую социальную сеть, то объекта как бы и нет. Но на самом деле, под объектом скорее имеются в виду автоматизируемые процессы. И даже в случае со складом мы же автоматизируем не сам склад (как можно автоматизировать хранение коробок?), а складские процессы.

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

В данном разделе следует приводить:

1. Описание заказчика: виды деятельности заказчика, количество филиалов, сотрудников. Конечно, характеризовать заказчика нужно в той части, которая непосредственно касается создаваемой системы.
2. Сведения о пользователях системы: виды пользователей, какую роль играет система для разных пользователей.
3. Описание автоматизируемых объектов. Например, если мы автоматизируем склад, до должны описать, какой он площади, сколько проходов, какая ширина проходов, какие стеллажи, имеется ли отдельная зона сборки, сколько работает человек и какие у них обязанности. Тогда мы поймем, что конкретно автоматизируем, как должен выглядеть складской процесс, и какое оборудование используется.
4. Описание автоматизируемых процессов. Конечно, не стоит в ТЗ расписывать процессы подробно. Но привести общие сценарии - обязательно. Только тогда нам становится ясно, какие должны иметься функции.
5. Перечень документов, в которых приводится подробное описание объекта автоматизации.

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

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

В ТЗ по ГОСТ 34 имеется один гигантский раздел: раздел 4 «Требования к системе». В нем имеется три подраздела:

• Требования к системе в целом.
• Требования к функциям (задачам), выполняемым системой.
• Требования к видам обеспечения.

Эти подразделы мы рассмотрим по отдельности.

7.1. Подраздел 4.1. «Требования к системе в целом» /п. 2.6.1 ГОСТ 34.602-89/

В подразделе 4.1 «Требования к системе в целом» приводят так называемые нефункциональные, общие, требования, которые описывают создаваемую систему с разных сторон.

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

7.1.1. Пункт 4.1.1. «Требования к структуре и функционированию системы» /п. 2.6.1.1 ГОСТ 34.602-89/

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

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

В данном пункте я обычно привожу:

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

Если вы планируете микросервисную архитектуру, то имеет смысл перечень и описание функциональности сервисов.

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

… или так:

2. Требования к способам и средствам связи для информационного обмена между компонентами системы.

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

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

• перечень передаваемых сведений, хотя бы общее описание, чтобы вообще понять, зачем мы интегрируемся с конкретной системой;
• описание протоколов (или ссылки на описание), особенно в случае присоединения устройств;
• структура локальных сетей;
• требуемая скорость передачи данных;
• применение мобильного интернета или WiFi;
• описание неавтоматизированных способов передачи данных.

4. Требования к режимам функционирования системы.
Режимы функционирования могут иметь несколько классификаций:

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

5. Требования по диагностированию системы.

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

6. Перспективы развития, модернизации системы.

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

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

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

7.1.2. Пункт 4.1.2. «Требования к численности и квалификации персонала» /п. 2.6.1.2 ГОСТ 34.602-89/

Как мы уже упоминали раньше, любая автоматизированная система состоит «из персонала и комплекса средств автоматизации его деятельности». Поэтому в ТЗ указываются требования к персоналу и его квалификации.

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

Понятно, что требования к персоналу часто устанавливаются заказчиком, зачем их тогда приводить? Но, во-первых, мы уже говорили, что ТЗ составляется для обеих сторон, а во-вторых, так исполнитель будет защищен: не выполнено условие по подбору персонала, чего же тогда заказчик хочет, если система не внедрена?

7.1.3. Пункт 4.1.3. «Требования к показателям назначения» /п. 2.6.1.3 ГОСТ 34.602-89/

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

Тем не менее, в самом тексте «показатели назначения» определяются как «параметры, характеризующие степень соответствия системы ее назначению». В современных компьютерных системах количественные значения, характеризующие эту систему, в основном относятся к производительности и объему хранения данных.

К показателям назначения можно отнести:

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

Все эти характеристики влияют на выбор серверного оборудования, архитектуры сервера приложения и СУБД, реляционной или нереляционной СУБД, микросервисов и т.д.

7.1.4. Пункт 4.1.4. «Требования к надежности» /п. 2.6.1.4 ГОСТ 34.602-89/

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

Основным понятием, которое можно применить для автоматизированных систем, является коэффициент готовности: 99%, 99,9%, 99,99%. Каждое количество «девяток» обеспечивается определенными мерами.

На выбор каких технических решений могут повлиять данные требования? Это и количество резервных мощностей (они бывают разными), и наличие технического персонала на местах, и применение не только источников бесперебойного питания, но и дизельгенераторов, а также подключение от двух независимых источников (присоединение к электросетям по I или II категории надежности).

7.1.5. Пункт 4.1.5. «Требования к безопасности» /п. 2.6.1.5 ГОСТ 34.602-89/

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

7.1.6. Пункт 4.1.6. «Требования к эргономике и технической эстетике» /п. 2.6.1.6 ГОСТ 34.602-89/

Приведем требования ГОСТа: «В требования по эргономике и технической эстетике включают показатели АС, задающие необходимое качество взаимодействия человека с машиной и комфортность условий работы персонала».

Обычно в этом пункте пишется, что у системы должен быть удобный и красивый интерфейс. Но как измерить удобство и красоту? Поэтому либо данное требование опускаем, либо говорим о том, что интерфейс будет соответствовать разработанному позже дизайн-проекту, либо приводим стандарты, например, так называемые «гайдлайны» для разработки мобильных приложений: Material Design для Android и Human Interface Guidelines для iOS.

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

7.1.7. Пункт 4.1.7. «Требования к транспортабельности для подвижных АС» /п. 2.6.1.7 ГОСТ 34.602-89/

Скажете, какое-то устаревшее требование. Сейчас сервера на грузовиках, как раньше большие ЭВМ, не возят. Тем не менее, представьте себе, у вас какая-то суперзащита, внутренний контур за DMZ и… необходимость удаленной работы через ноутбук. Да, VPN настраивается в любой момент, но лучше, если это будет отражено в Руководстве по администрированию, а сама возможность предусмотрена конфигурацией сети.

7.1.8. Пункт 4.1.8. «Требования к эксплуатации, техническому обслуживанию, ремонту и хранению» /п. 2.6.1.8 ГОСТ 34.602-89/

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

7.1.9. Пункт 4.1.9. «Требования к защите информации от несанкционированного доступа» /п. 2.6.1.9 ГОСТ 34.602-89/

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

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

Так, для финансовых систем следует использовать «Стандарт безопасности данных индустрии платежных карт» (PCI DSS). Для систем, в которых хранятся персональные данные, - Постановление Правительства РФ от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». В вашей предметной области могут иметься и другие стандарты.

В общем и целом, средства защиты можно разделить на следующие типы:

1. Средства, обеспечиваемые создаваемым программным продуктом.
2. Меры, обеспечиваемые системным администратором.
3. Меры физической защиты.
4. Общие организационные меры.
5. Меры, принимаемые в процессе разработки программного обеспечения.

1. Средства защиты, обеспечиваемые создаваемым программным продуктом:

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

2. Меры, обеспечиваемые системным администратором:

• Применение межсетевых экранов (файерволов).
• Документирование и мониторинг используемых служб и протоколов.
• Конфигурирование демилитаризованной зоны (DMZ).
• Контроль выполнения правил использования портативных компьютеров: подключение к внутренней сети, использование межсетевых экранов.
• Отключение учетных записей по умолчанию перед подключением в сеть оборудования и систем.
• Настройка устройств беспроводного доступа: установка паролей и изменение настроек доступа, установленных по умолчанию.
• Установка обновлений, устраняющих выявленные уязвимости оборудования и программного обеспечения.
• Обеспечение безопасности при удаленном доступе в систему (например, использование VPN).
• Установка, обновление и мониторинг работы антивирусного программного обеспечения.
• Проведение периодического сканирования сети и сканирования после внесения важных изменений.
• Назначение каждому работнику уникальной учетной записи, периодические проверки на наличие неудаленных учетных записей уволенных сотрудников, смена паролей. Выдача и учет токенов электронной подписи.
• Настройка ограничения доступа к базам данных.
• Контроль синхронизации времени на всех серверах и рабочих станциях (с целью обеспечения корректности времени, регистрируемого в журналах регистрации событий).
• Настройка журналов регистрации событий.
• Периодическая инвентаризация точек беспроводного доступа и другого оборудования, установленного программного обеспечения.

3. Меры физической защиты:

• Ограничение доступа в критические помещения.
• Отключение сетевых разъемов в общедоступных местах.
• Установка камер видеонаблюдения за критически важными помещениями.

4. Общие организационные меры:

• Утверждение политики безопасности и проведение периодического обучения персонала правилам информационной безопасности.
• Внедрение процедуры реагирования на инциденты, связанные с нарушением безопасности.
• Проверка на вывод в экранных формах или отчеты конфиденциальных данных.
• Выдача бейджей всем посетителям, сопровождение посетителей при нахождении в критически важных помещениях.
• Всесторонняя проверка принимаемых на работу сотрудников.
• Обеспечение безопасности со стороны организаций-поставщиков услуг, связанных с программным и аппаратным обеспечением.

5. Меры, принимаемые в процессе разработки программного обеспечения:

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

7.1.10. Пункт 4.1.10. «Требования по сохранности информации при авариях» /п. 2.6.1.10 ГОСТ 34.602-89/

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

• потеря питания;
• выход из строя сервера;
• выход из строя устройства хранения (жесткого диска).

7.1.11. Пункт 4.1.11. «Требования к защите от влияния внешних воздействий» /п. 2.6.1.11 ГОСТ 34.602-89/

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

7.1.12. Подраздел 4.1.12. «Требования по патентной чистоте» /п. 2.6.1.12 ГОСТ 34.602-89/

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

7.1.13. Пункт 4.1.13. «Требования к стандартизации и унификации» /п. 2.6.1.13 ГОСТ 34.602-89/

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

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

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

7.1.14. Пункт 4.1.14. «Дополнительные требования» /п. 2.6.1.14 ГОСТ 34.602-89/

С данным пунктом следует ознакомиться в самом тексте ГОСТа. В комментариях он не нуждается.

7.2. Подраздел 4.2. «Требования к функциям (задачам), выполняемым системой» /п. 2.6.2 ГОСТ 34.602-89/

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

7.2.1. Структура функционального описания

Сначала рассмотрим структуру функциональных требований к системе: подсистема - комплекс функций - функция - задача. Задача - это часть функции, причем задача может быть описана в виде отдельной функции. Например, для функции входа в систему в качестве одной из задач мы приводим ввод пароля. А процедуру ввода пароля мы можем расписать уже как отдельную функцию: проверка на правильность, восстановление пароля, отображение подсказок и т.д. Комплекс - это то, что объединяет функции. Например, «Учет основных сведений», «Проведение аукциона» и т.д. В Комплексе две и более функции.

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

7.2.2. Виды функций с точки зрения их выполнения

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

• Ввод сведений. Иногда называют также «учет сведений».
• Вывод информации.
• Автоматическая обработка информации.

7.2.3. Виды функций с точки зрения их роли

Функции могут быть общими и специальными. К общим функциям, например, относятся работа со списками объектов, работа с карточкой объекта, работа с интерактивной картой. Эти функции могут относится ко всем специальным или части специальных функций.

7.2.4. Требование, а не сценарий

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

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

7.2.5. Оформление функциональных требований

Приведем некоторые рекомендации по тому, как оформлять описание функций:

1. Требования к функциям и задачам обычно следует выносить в приложение. Таким образом документ органично делится на нефункциональную и функциональную части. Кроме того, приложение всегда можно распечатать и рассматривать отдельно.
2. Избегайте больших абзацев. Лучше всего, если требования разбиты по пунктам и подпунктам: так легче их воспринимать и контролировать их выполнение (галочки ставить). Если приводится перечень требований или сведений, пусть он приводится нумерованным или маркированным списком.
3. Для функций, назначение которых не очевидно из их названия, следует обязательно указать цель и решаемую задачу. В противном случае даже составитель ТЗ рискует забыть, зачем он описывал ту или иную функциональность.

7.2.6. Пример описания функции

5.6. Регистрация транспортного средства в Системе

Предъявляются следующие требования:

1) Система должна позволять учитывать следующие общие сведения:

• государственный регистрационный знак (ГРНЗ);
• ФИО собственника;
• адрес собственника;
• данные от сервиса получения данных о ТС (см. п. 3.3, Приложение Б);
• примечание.

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

• текущий класс ТС (см. п. 3.3, Приложение А);
• текущий тариф (см. п. 5.1, Приложение А);
• текущий договор (см. п. 5.5, Приложение А);
• класс ТС по сведениям из системы МВД РК;
• сведения о лицевом счете и его состоянии (см. п. 3.6, Приложение А);
• сведения о нахождении в реестре ТС с льготным проездом (см. п. 3.5, Приложение А).

3) Система должна позволять регистрировать и изменять сведения о ТС следующими способами:

• вручную оператором;
• при поступлении сведений из системы регистрации RFID-меток (см. п. 1.1, Приложение Б);
• при идентификации ТС с помощью камеры ГРНЗ.

4) При регистрации в системе нового ТС система должна запрашивать данные о ТС от сервиса получения данных о ТС (см. п. 3.3, Приложение Б). Должна иметься возможность обновить указанные сведения отдельного ТС.

7.3. Подраздел 4.3. «Требования к видам обеспечения» /п. 2.6.3 ГОСТ 34.602-89/

Раздел требований к видам обеспечения вообще часто приводят как пример избыточного объема ТЗ по ГОСТу. Когда заходит речь о том, все ли разделы и подразделы следует приводить, вспоминают про математическое обеспечение, для которого в большинстве случаев просто нечего писать.

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

При чтении данного подраздела задаешься вопросом, что имели в виду составители стандарта под «математическим обеспечением», «лингвистическим обеспечением», «информационным обеспечением» и т.д. Ответы следует искать в ГОСТ 34.003-90, где расшифровываются все эти термины.

7.3.1. Пункт 4.3.1 «Математическое обеспечение» /п. 2.6.3.1 ГОСТ 34.602-89/

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

7.3.2. Пункт 4.3.2 «Информационное обеспечение» /п. 2.6.3.2 ГОСТ 34.602-89/

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

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

Таким образом, в данном пункте имеет смысл указать требования к входящей информации и информации, передающейся от компонента к компоненту системы в неавтоматизированном виде. Автоматизированная обработка информации, использование СУБД, информационный обмен внутри системы вполне описываются в других разделах.

7.3.3. Пункт 4.3.3 «Лингвистическое обеспечение» /п. 2.6.3.3 ГОСТ 34.602-89/

В данном пункте приводятся:

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

7.3.4. Пункт 4.3.4 «Программное обеспечение» /п. 2.6.3.4 ГОСТ 34.602-89/

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

7.3.5. Пункт 4.3.5 «Техническое обеспечение» /п. 2.6.3.5 ГОСТ 34.602-89/

Любая информационная система не может работать без «железа», серверов, сети и т.д. Определение конкретных характеристик оборудования обычно целесообразно вынести в технический проект, но в ТЗ можно привести примерный состав, чтобы у заказчика было представление о будущих расходах.

7.3.6. Пункт 4.3.6 «Метрологическое обеспечение» /п. 2.6.3.6 ГОСТ 34.602-89/

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

7.3.7. Пункт 4.3.7 «Организационное обеспечение» /п. 2.6.3.7 ГОСТ 34.602-89/

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

7.3.8. Пункт 4.3.8 «Методическое обеспечение» /п. 2.6.3.8 ГОСТ 34.602-89/

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

7.3.9. Другие виды обеспечения

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

8. Раздел 5 «Состав и содержание работ по созданию (развитию) системы» /п. 2.7 ГОСТ 34.602-89/

Данный раздел организационный и его нередко выносят в договор. Тем не менее, данные сведения в ТЗ могут уточняться.

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

• Наименование этапа (подэтапа).
• Содержание работ (краткое описание, перечень задач).
• Результат работ (утвержденные документы, разработанные и сданные решения).
• Проектная, рабочая или отчетная документация.
• Ответственные (кто выполняет данную работу: заказчик, исполнитель или иное лицо). Если обе стороны должны выдать совместный результат, указываются роли.
• Длительность (сроки, даты, начало отсчетов сроков).

Пример содержания данного раздела приведен в таблице ниже.

Этап	Содержание работ	Порядок приемки и документы	Сроки	Ответственный
1. Составление технического задания (ТЗ)	Разработка функциональных и нефункциональных требований к системе	Утверждение ТЗ	60 дней со дня предоплаты. Заказчик предоставляет первый вариант на согласование через 45 дней	Разработка - Исполнитель; согласование - Заказчик
2. Техническое проектирование (ТП)	Разработка сценариев работы системы и макетов интерфейса веб-приложений	Утверждение документа «Описание автоматизированных функций»	60 дней со дня согласования ТЗ. Заказчик предоставляет первый вариант на согласование через 45 дней	Исполнитель
	Разработка фирменного стиля оформления веб-сайта и мобильных приложений	Утверждение фирменного стиля		Заказчик
	Разработка наполнения сайта (публичное веб-приложение)	Утверждение наполнения		Заказчик
	Разработка дизайн-макета публичного веб-приложения	Утверждение дизайн-макета		Исполнитель
	Разработка дизайн-макетов публичных мобильных приложений	Утверждение дизайн-макета		Исполнитель
	Выбор SMS-агрегатора, подготовка правил обмена с серверным модулем	Утверждение дизайн-макета		Заказчик, по рекомендациям Исполнителя
3. Разработка программной части	Разработка серверного модуля, модуля хранения данных и модуля хранения файлов		100 дней со дня согласования ТП	Разработка - Заказчик. Исполнитель предоставляет данные для наполнения справочников
	Разработка панели администрирования	Приемка осуществляется в процессе испытаний		Заказчик
	Разработка статического веб-сайта (публичное веб-приложение)	Приемка осуществляется в процессе испытаний		Исполнитель
	Разработка интеграции публичного веб-приложения и серверного модуля	Приемка осуществляется в процессе испытаний		Исполнитель
	Разработка мобильных приложений iOS (включая интеграцию с серверным модулем)	Приемка осуществляется в процессе испытаний		Исполнитель
	Разработка мобильных приложений Android (включая интеграцию с серверным модулем)	Приемка осуществляется в процессе испытаний		Исполнитель
	Разработка рабочей и эксплуатационной документации	Утверждение документов: - «Программа и методика предварительных автономных испытаний». - «Программа и методика предварительных комплексных испытаний». - «Программа опытной эксплуатации»		Исполнитель
4. Предварительные автономные испытания	- Проверка соответствия нефункциональным требованиям (дизайн). - Проверка комплекта документации. - Проверка работоспособности системы, без взаимодействия со смежными (внешними) системами.	Утверждение протокола предварительных автономных испытаний	14 дней со дня завершения разработки
5. Предварительные комплексные испытания	- Проверка взаимодействия со смежными внешними системами. - Доработки и повторные испытания до устранения недостатков	Утверждение протокола предварительных комплексных испытаний	14 дней со дня завершения автономных испытаний	Исполнитель - проведение испытаний. Заказчик - подготовка инфраструктуры и организация испытаний
6. Подготовка к опытной эксплуатации	- Разворачивание системы на промышленных серверах. - Выполнение комплекса работ по подготовке (подробнее см. п. 7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие)	Приемка отсутствует	5 дней со дня завершения предварительных испытаний	Подготовка программной части и заполнение справочников - Заказчик. Исполнитель предоставляет данные для наполнения справочников и осуществляет организацию ОЭ
7. Опытная эксплуатация	- Эксплуатация с привлечением небольшого количества участников (несколько аукционов среди знакомых). - Доработки и повторные испытания до устранения недостатков	Протокол опытной эксплуатации (журнал ошибок и итогов их исправления)	30 дней	Исполнитель - устранение недостатков. Заказчик - проведение ОЭ
8. Ввод в промышленную (коммерческую) эксплуатацию	См. этап подготовки к опытной эксплуатации	Приемка отсутствует	Подготовка программной части и заполнение справочников - 10 дней	Подготовка программной части и заполнение справочников - Заказчик. Исполнитель осуществляет организацию промышленной эксплуатации
9. Промышленная (коммерческая) эксплуатация	Промышленная эксплуатация	Приемка отсутствует

9. Раздел 6 «Порядок контроля и приемки системы» /п. 2.8 ГОСТ 34.602-89/

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

9.1. Подраздел 6.1. «Виды, состав, объем и методы испытаний системы и ее составных частей» /п. 2.8.1 ГОСТ 34.602-89/

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

Остановимся подробнее на видах испытаний. Виды испытаний, их состав, требования к документам устанавливаются ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем». Поэтому при разработке данного раздела и технического проекта обязательно обращайтесь к этому стандарту, здесь мы разъясним только основные моменты.

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

1. Испытания делятся на следующие виды:

• Предварительные.
• Опытная эксплуатация.
• Приемочные.

2. Предварительные (а частично и приемочные) испытания в свою очередь делятся на:

• Автономные (без интеграции со смежными системами).
• Комплексные (в комплексе со смежными системами).

Зачем испытания делятся на разные стадии? Во-первых, потому что ГОСТ 34.603-92 не разделяет внутреннюю приемку и внешнюю, часть испытаний может проводиться без заказчика. Во-вторых, описывается последовательный процесс тестирования, часть за частью, а потом уже все в комплексе.

Давайте попробуем описать процесс испытаний простыми словами:

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

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

3. Предварительные комплексные испытания. Система испытывается в комплексном режиме, то есть во взаимодействии со смежными системами. В таком виде система передается заказчику для опытной эксплуатации.

4. Опытная эксплуатация. ОЭ может проходить в разных режимах. Самое лучшее -это эксплуатация на реальных данных, с реальными пользователями и с выполнением реальных задач. Только такой вид испытаний позволит убедиться, что система действительно работоспособна. В ходе опытной эксплуатации устраняются недостатки.

5. Приемочные испытания. Это последний вид проверки. Скажете, а почему опытная эксплуатация после устранения всех недостатков плавно не перейдет в промышленную? Так оно обычно и происходит. Но ведь высоким дядям надо увидеть, что система реально работает, «пощупать» ее. Для них, для высокой комиссии и предназначены приемочные испытания. Таким образом, приемочные испытания отличаются от предварительных в первую очередь статусом комиссии.

Также в этом пункте указываются документы, в которых будут приведены методы испытаний:

• Для предварительных и приемочных испытаний это «Программа и методика предварительных (приемочных) испытаний». Указания для составления документа содержатся сразу в двух стандартах. Вкратце - в ГОСТ 34.603-92 (п. 2.2.2 и 4.1) и более подробно - в РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов».
• Для опытной эксплуатации предусматривается документ «Программа опытной эксплуатации», содержание которого приводится в п. 3.1 ГОСТ 34.003-90. Также следует прописать использование «Журнала опытной эксплуатации» (см. п. 3.2 ГОСТ 34.603-92), в который будут заноситься недостатки и результаты их устранения.

9.2. Подраздел 6.2. «Общие требования к приемке работ по стадиям» /п. 2.8.2 ГОСТ 34.602-89/

В данном разделе я обычно указываю:

1. На чьей территории и на чьем оборудовании будут проводиться испытания: заказчика или исполнителя.
2. Общее описание, каким образом будут проводиться испытания (например, что будут проверяться документы, наличие элементов пользовательского интерфейса, отрабатываться сценарии).
3. Список участников.
4. Перечень документов, которыми оформляют результат испытаний:
   • Для предварительных и приемочных испытаний это протокол испытаний, в котором приводится перечень проверок и их результаты.
   • Для опытной эксплуатации - журнал опытной эксплуатации.

10. Раздел 7 «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» /п. 2.9 ГОСТ 34.602-89/

Процесс, описываемый в данном разделе, часто называют внедрением. Обратите внимание на то, что данные работы также приводятся в разделе . Но, в разделе 5 они лишь кратко упоминаются, здесь же приводится подробное описание.

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

1. Проведение реорганизации, набор нового персонала, в случае необходимости.
2. Обучение персонала.
3. Для веб-приложений: разработка общих разделов сайта и пользовательского соглашения (согласия на обработку персональных данных).
4. Заполнение справочников и иных исходных сведений.
5. Перенос данных из прежней системы.
6. Развертывание системы на промышленных серверах.
7. Настройка интеграции со смежными системами.
8. Настройка системы доступа и создание учетных записей.

Некоторые из данных пунктов следует расписать очень подробно, особенно что касается переноса данных и заполнения справочников.

11. Раздел 8 «Требования к документированию» /п. 2.10 ГОСТ 34.602-89/

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

Документирование проекта автоматизации по ГОСТ 34 регламентируется следующими стандартами:

• ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем.
• РД 50-34.698-90 Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.
• Для Технического задания - ГОСТ 34.602-89, который мы сейчас и обсуждаем.

В первом стандарте (ГОСТ 34.201-89) приводится перечень и структура документации. Во втором - РД 50-34.698-90 - указывается содержание следующих документов:

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

11.1 Особенности структуры документации

При составлении перечня необходимых документов обычно просматривают РД 50-34.698-90 и выбирают требуемые. При этом делается немало ошибок, поскольку документация имеет довольно сложную структуру, которая описывается в ГОСТ 34.201-89.

Давайте попытаемся выявить несколько правил, которые помогут при составлении перечня документов.

1. Для каждого из этапов предназначен свой комплект документации.

Для каждого из этапов предназначен свой комплект документации. Это очень важно уяснить. Не надо прописывать разработку эксплуатационных документов на проектных стадиях и наоборот. Получаются чисто формальные бумаги, на которые вы потратите значительное время. И если «Руководство пользователя» до окончания разработки системы обычно никто не составляет (хотя встречал и таких деятелей), то «Описание автоматизированных функций», в котором обычно приводятся сценарии для программистов, постоянно составляют уже после окончания разработки. Также при чтении РД 50-34.698-90 может создаться впечатление, что у некоторых документов содержание пересекается: это тоже связано с тем, что документы предназначаются для различных этапов.

Поскольку некоторые документы могут разрабатываться либо на одном, либо на другом этапе, в ГОСТ 34.201-89 во избежание повтора отдельно приводится, например, список документов, которые могут выпускаться как на стадии технического проекта, так и рабочей документации, а отдельно - списки документов для каждой из этих стадий отдельно. Таким образом, при составлении перечня документов для одного из этапов приходится просматривать списки документов в нескольких разделах стандарта.

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

2. Документы делятся на темы (части проекта).

В ГОСТе 34 имеются документы, описывающие общесистемные решения, а также организационное, техническое, математическое, программное, информационное обеспечение (о видах обеспечения мы говорили ). В РД 50-34.698-90 данные документы приводятся именно с разбивкой по частям проекта (темам). На это всегда следует обращать внимание, чтобы определить предназначение документа.

3. Документы можно объединять.

В ГОСТ 34.201-89 прямо указывается, в каких случаях один документ включается в состав другого. Это сделано для того, чтобы не оставалось вырожденных документов, с одной или двумя страничками. Если что-то требуется описать, но объем очень маленький, лучше всего включить текст в другой документ. В большинстве случаев имеется такой документ как «Пояснительная записка к техническому проекту», в который можно добавлять разделы.

4. Эксплуатационная и проектно-сметная документация выделены отдельно.

Составители ГОСТ 34.201-89 в отдельных столбцах таблицы с перечнем документов обозначили принадлежность к эксплуатационной и проектно-сметной документации.

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

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

11.2 Особенности оформления списка документов

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

В правилах документирования обычно я привожу таблицу со следующими столбцами:

• Этап.
• Наименование документа.
• Примечание: указывается стандарт разработки, назначение, краткое содержание и основные особенности документа.

11.3 Пример перечня документации

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

12. Раздел 9 «Источники разработки» /п. 2.11 ГОСТ 34.602-89/

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

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

• Материалы с описанием аналогов (прототипов) разрабатываемой системы.
• Материалы, описывающие общую идею системы. Нередко данные документы составляют на предпроектных стадиях и именно на них обычно содержатся ссылки в разделе «Характеристики объекта автоматизации».
• Материалы по разработке проекта: перечень используемых ГОСТов серии 34, используемые стандарты по проектному управлению.
• Материалы, связанные с осуществлением основного процесса: перечень законов, стандартов, внутренних регламентов и приказов, устанавливающие правила осуществления автоматизируемых процессов.
• Материалы и стандарты, содержащие требования к общей и информационной безопасности.

Заключение

Конечно, составление Технического задания по ГОСТ 34 нельзя назвать легким и простым. И не потому, что ГОСТ плохой, - просто ГОСТ заставляет продумывать весь проект целиком, расписать все мелочи. Зато хорошо составленное ТЗ - половина успеха проекта.

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

Павел Молянов

Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика - потратил время впустую.

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

Статья будет полезна:

• Всем, кто имеет отношение к созданию сайтов: разработчикам, дизайнерам, верстальщикам.
• Менеджерам проектов.
• Руководителям диджитал-студий.
• Предпринимателям, которые планируют заказать разработку сайта.

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

Что такое техзадание и зачем оно нужно

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

Главная цель технического задания: убедиться, что клиент и исполнитель правильно поняли друг друга.

Пользы от технического задания много. Для каждой стороны она своя.

Польза для клиента:

• Понять, за что он платит деньги, и каким будет сайт. Можно сразу увидеть структуру, понять, что и как будет работать. Прикинуть, все ли устраивает. Если нет - без проблем поменять еще до начала разработки.
• Увидеть компетентность исполнителя. Если техзадание понятное и четкое - доверие к разработчику повышается. Если там написана каша - возможно, стоит бежать и не оглядываться.
• Застраховаться от недобросовестности исполнителя. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор - можно даже принудить через суд.
• Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может сильно затянуться. Когда есть подробное техзадание, его можно передать новой команде - она втянется в работу в разы быстрее.
• Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание.

Польза для исполнителя:

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

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

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

Техзадание составляет исполнитель

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

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

Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Збс, одобряю». Он тоже должен участвовать в процессе:

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

Пишите однозначно и точно

Этот совет вытекает из главной цели техзадания - «Убедиться, что клиент и исполнитель правильно поняли друг друга».

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

Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:

То же самое - с невнятными формулировками, которые ничего сами по себе не значат:

• Сайт должен понравиться заказчику. А если у него будет плохое настроение?
• Сайт должен быть удобным. Что это значит? Удобным для чего?
• Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
• Качественный экспертный контент. Ну, вы поняли.

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

• Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
• Большие нагрузки → 50 тысяч посетителей одновременно.
• На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
• Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.

С формулировками разобрались, давайте пробежимся по структуре.

Укажите общую информацию

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

А еще стоит указать цель сайта и описать его функционал в двух словах - чтобы не получить интернет-магазин вместо блога.

Поясните сложные термины

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

Опишите инструменты и требования к хостингу

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

Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP - а у клиента сервер на.NET.

Перечислите требования к работе сайта

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

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

Укажите структуру сайта

До начала отрисовки дизайна и верстки вам нужно согласовать с клиентом структуру сайта.

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

Можно показать структуру списком, можно нарисовать блок-схему. Как вам удобнее.

Это один из важнейших этапов работы на сайтом. Структура - это фундамент. Если она неудачная - сайт получится кривой.

Объясните, что будет на каждой странице

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

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

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

Распишите сценарии использования сайта

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

• Действие пользователя.
• Ответное действие сайта.
• Результат.

Конечно, если вы делаете стандартную визитку или лендинг, писать сценарии не нужно. Но если на сайте будут какие-то интерактивные сервисы - очень желательно.

Подробнее о сценариях использования читайте в «Википедии ».

Определите, кто отвечает за контент

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

Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «Качественный, интересный и продающий контент, полезный для целевой аудитории». Это мусор, он никому не нужен.

Указать, что весь контент должен быть уникальный, - это полезно. Еще одна защита клиента от недобросовестных исполнителей.

Опишите дизайн (если сможете)

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

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

Вместо вывода: структура техзадания

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

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

• Правила составления Software Requirements Specification. SRS - следующая ступень эволюции техзадания. Нужна для больших и сложных проектов.
• Стандарты и шаблоны ТЗ на разработку ПО. Описания разных ГОСТов и методологий создания технических заданий.

Это конец той части, которую писал я. Но есть и другая - комментарии специалистов, которые помогали делать гайд. Почитайте, это тоже интересно.

Комментарии разработчиков

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

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

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

Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.

Мы указываем:

• Информацию о компании и цель сайта.
• Требования к дизайну, цветовую гамму.
• Используемые технологии и CMS.
• Кто занимается контентом - мы или клиент.
• Структуру сайта вплоть до каждой страницы.
• Описания каждой страницы. Мы не делаем прототипы, но указываем, какие элементы должны быть на странице, и как они должны работать.

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

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

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

К примеру, у клиента в голове появилось определенное представление, каким бы он хотел видеть сайт, и пытается объяснить это разработчикам. Но разработчики неверно трактовали «на пальцах» пожелания. Плачевный итог – клиент получил совсем не то, что представлял себе. Силы, время исполнителей и клиента были потрачены зря.

В этой статье вы узнаете, как правильно составить техническое задание на создание сайта, чтобы все остались довольны проделанной работой.

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

Техническое задание (ТЗ) – документ, содержащий требования заказчика к сайту. Заказчик и исполнитель должны правильно понимать друг друга, поэтому лучше подробно расписать все требования. Четко составленное ТЗ увеличивает шансы того, что заказчик будет доволен получившимся результатом, а исполнитель не будет переделывать ресурс 2-3 раза.

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

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

• Рассказать подробнее о компании, предлагаемых товарах или услугах, целевой аудитории;
• Уточнить о проблемах, с которыми целевая аудитория (ЦА) будет приходить к клиенту и их решения;
• Узнать, что именно клиент хочет получить от сайта;
• Попросить привести примеры удачных сайтов конкурентов.

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

Чёткость формулировок в ТЗ

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

Главный критерий качества ТЗ - чёткие формулировки, отсутствие двусмысленных трактовок.

Конкретика в техническом задании - главное условие качества, например:

• Каждая страница должна провериться на GTmetrix или GoogleSpeed с показателем скорости не менее 80/100 по Google Page Speed.
• Ресурс должен выдерживать до 20 тыс. посетителей одновременно.
• На главной должны выводиться новости и ниже отображаться форма с кнопкой «Подписаться» с возможностью отправить e-mail адрес.
• Список партнеров в виде карусели логотипов, отзывы клиентов в слайдере с горизонтальной прокруткой по 1-му отзыву на слайд.

Обязательно согласуйте с клиентом инструменты, которые будут использоваться, движки и требования к хостингу. Пропишите в своём ТЗ, что ваш ресурс должен работать во всех браузерах, быть адаптивным для всех видов устройств, должен быть устойчив к нагрузкам и защищен от хакерских DDoS атак.

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

Пример структуры ТЗ по договору

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

Страница «Главная»

• Секция «Меню» с разделами и выпадающим списком подразделов:
  • Логотип и слоган;
  • «Главная»;
  • «Проекты»;
  • «Каталог продукции» с выпадающим списком разделов «Трубы SML», «Фитинги SML», «Соединительные хомуты»;
  • «Производство»;
  • «О компании»;
  • «Проектировщикам»
  • «База знаний / FAQ»;
  • «Контакты»;
  • Ссылка на скачивание катала продукции в.pdf;
  • Контактный телефон компании;
  • Кнопка «Заказать звонок».
• Секция «Слайдер» с фотографией по ширине экрана и кнопкой обратной связи с запросом на просчёт проекта / запроса на полный прайс-лист продукции.
• Секция «Преимущества» с указанием ключевых выгод для клиентов;
• Секция «Производство» с кратким описанием и информацией про систему контроля качества, со ссылкой на раздел «Производство» и кнопкой с записью на поездку на завод;
• Секция «Продукция» с текстовым описанием преимуществ, ссылками на сертификаты, ссылкой на «Каталог продукции»;
• Секция «Наши проекты» (с переходом в раздел «Все проекты»);
• Секция «Компания в цифрах» с цифрами достижений и ссылкой на раздел «О компании»;
• Секция «Видео-инструкции» с текстовым описанием и ссылкой в раздел «Все видео»;
• Секция «Подвал»:
• Контакты, телефон, адрес, электронная почта;
• Кнопка обратной связи;
• Ссылка на YouTube канал и на социальные сети компании.

Если вы также заказываете уникальный дизайн, то структуру страниц можно строить по предварительному прототипу. Ниже пример прототипа сайта, который можно прикрепить к техническому заданию на разработку. Определите вид главной страницы. Решите, где будет заголовок, пропишите основные элементы, на чём сделать акцент и так далее.

Функционал сайта

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

• CMS система Вордпресс, Битрикс и тп.
• Формы заявок с возможностью оставить заявку
• Модальные окна
• Слайдеры
• Модули галереи
• Модули SEO оптимизации и страниц
• Модули кеширования и сжатия
• Онлайн-карта с гео-метками
• с расчетом цены

К технической части относятся требования хостингу и его настройкам. Советуем выбирать проверенный и быстрого хостинг-провайдера с приемлемыми тарифами на обслуживание. Мы используем в проектах вот этот хостинг. Стоимость всего 2500 в год, домен в зоне.ru можно купить за 179 руб. Вот пример функционального описания для технического задания.

Подключение и настройка CMS системы 1С Битрикс	Исполнитель настраивает CMS систему управления сайтом 1С Битрикс. Лицензия «1С-Битрикс: Управление сайтом» оплачивается Заказчиком самостоятельно.
Наполнение контентом	Наполнение текстом и фотографиями указанных выше страниц. Текст и фотографии предоставляет Заказчик. Исполнитель в праве использовать также контент с сайта заказчика. Расположение блоков на страницах выводится в рамках структуры страниц шаблона.
Настройка ролей доступа	Добавление роли «Администратор» с возможностью администрирования CMS, роли редактора (для отдела закупок) с возможностью добавления информации.
Адаптация для мобильных устройств и планшетов	Широкоэкранная верстка и адаптация под более мелкие разрешения экрана, сайт должен корректно отображаться на экранах шириной от 1920 до 320 пикселей, появление горизонтальной прокрутки недопустимо.
Подключение дополнительных модулей CMS	Исполнитель также вправе добавлять модули CMS и функциональные элементы на своё усмотрение, если они улучшают работоспособность сайта по согласованию с Заказчиком, платные модули оплачиваются Заказчиком.
Подключение домена и хостинга Заказчика	Исполнитель подключает домен и хостинг Заказчика для веб-сайта. Производится парковка домена с указанием адресов ns1, ns2. Включается версия PHP не ниже 7.0.
Настройка базы данных MySQL	Исполнитель создает базу данных MySQL на хостинге заказчика для размещения данных веб-сайта. Доступы к базе данных передаются Исполнителем Заказчику по электронной почте.
Видеофон на главной странице	Вывод подложки с видеорядом Заказчика в первом блоке главной страницы сайта. Должна присутствовать затемняющая подложка для повышения читабельности текста.
Вывод модальных окон и отправка данных	Каждая из кнопок должна вызывать соответствующее модальное окно с формой обратной связи. Данные с формы в корректном виде должны отправляться на почту Заказчика.
Вывод форм обратной связи	Форма обратной связи должна выводиться на каждой странице. В форме обратной связи должны присутствовать: форма поля ввода номера телефона и кнопка «отправить заявку». Данные с формы должны передаваться на электронный адрес администратора, а также дублироваться на адрес [email protected].
Подключение Яндекс карты c ГЕО-метками	На страницах выводится Яндекс.Карта с ГЕО меткой расположения / адреса Заказчика. Заказчик устанавливает метку на собственном аккаунте Яндекс.
Подключение статистики Яндекс.Метрика	Сервис сбора данных о посещаемости и поведении пользователей. Заказчик предоставляет Яндекс почту, на которую Исполнитель подключает сервис.
Настройка целей в Яндекс.Метрика	Исполнитель настраивает цели в Яндекс.Метрика. Цели сообщают в статистике о том, с какой конкретно формы была отправлена заявка.
Вывод H1 и МЕТА-описаний страниц согласно ключевому запросу веб-страницы	Каждая страница веб-сайта должна иметь заголовок и МЕТА-описание в соответствии с содержимым страницы.
Кроссбраузерная оптимизация сайта	Сайт должен корректно открываться в последних актуальных версиях существующих браузеров.
Настройка файлов sitemap.xml	Исполнитель выводит карту сайта в отдельный раздел sitemap.xml с указанием существующих страниц для индексации.
Добавление «хлебных крошек»	Исполнитель выводит в каждый раздел навигационную цепочку («хлебные крошки», англ. Breadcrumbs) с адресом страницы формата: Главная → Раздел → Подраздел → Текущая страница.
Настройка файла robots.txt	Исполнитель настраивает текстовый файл, который содержит параметры индексирования сайта для роботов поисковых систем.
Настройка файла.htaccess	Исполнитель настраивает специальный файл, позволяющий редактировать конфигурации и настройки веб-сервера.
Настройка ЧПУ адресов страниц в формате domen.ru/arenda-sklada	Адрес каждой страницы должен содержать корректное описание для поисковых систем и посетителей на латинице.
Настройка 404 и 303 страниц	Настройка корректной выдачи ошибки 404, настройка 303 переадресации на страницы, которые изменили свой адрес.
Оптимизация программного кода HTML/CSS/PHP и скриптов	Исполнитель выполняет оптимизацию программного кода страниц сайта для повышения скорости загрузки страниц и веб-сайта в целом. При необходимости Исполнитель переносит загрузку.js скриптов в «подвал» сайта, настраивает кеширование страниц и сжатие CSS / HTML.
Оптимизация размера изображений и графического контента	Исполнитель сжимает изображения и видео, размещаемые на страницах веб-сайта для повышения скорости загрузки страниц ресурса.
Тестирование и поддержка в течение 1-го месяца после запуска	После приемки и запуска веб-сайта Исполнитель оказывает услуги по технической поддержке, устраняет технические ошибки и корректирует работу сайта при необходимости.

Отдельно.

Помните, что сайт - это техническое и программное обрамление контента. Если контент (фото и видео) не очень, то и сайт будет таким же.

Отдельно стоит уделить внимание качеству фото и видео. Мы всегда рекомендуем заказать фото и видео съёмку клиентам, если нет презентабельного фото и видео контента для сайта.

Что относится к оформлению: оформление кнопок и элементов взаимодействия - ссылки, кликабельные стрелки слайдера, формы заявок и так далее. Продумайте цветовую гамму и пропишите гарнитуры шрифтов. У вас есть брендбук? Отлично, вы можете взять из него основные цвета и стили шрифтов для заголовков и основного текста и прописать всё это в техническом задании. Помните, что хорошее оформление зависит от качества исходного контента. Если у вас будут неказистые фото, то красивые кнопочки не помогут.

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

Структура технического задания

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

• Общая концепция.
• Структура сайта и страниц.
• Требования к хостингу.
• Прототипы страниц.
• Требования к вёрстке и работоспособности.
• Функциональная часть.
• Требования к дизайну и контенту.

Вы можете сами продолжить этот список, ведь каждый проект индивидуальный. Сайт компании всегда зависит от особенностей самого бизнеса и должен передавать его суть через контент и функциональные элементы. Узнайте также, который способен повысить прибыль компании и узнаваемость бренда?

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

Как писать техническое задание на программу по ГОСТ 19.201-78?

Создан 15.02.2010 15:50:53

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

Техническое задание в соответствии с на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения листа. Номера листов (страниц) проставляются в верхней части листа над [из п. 1.1 ГОСТ 19.201-78]

Лист утверждения и титульный лист

Лист и титульный лист оформляют в соответствии с ГОСТ 19.104-78.

Информационную часть (и), лист регистрации изменений допускается в документ не включать [из п. 1.2 ГОСТ 19.201-78]

Указанной возможностью следует воспользоваться. Меньше слов – меньше вопросов.

Изменения и дополнения

Для внесения или дополнений в техническое задание на последующих или выпускают дополнение к нему. и дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания [из п. 1.3 ГОСТ 19.201-78]

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

Состав разделов технического задания

Техническое задание должно содержать следующие:

• введение;
• основания для;
• назначение разработки;
• к или;
• требования к;
• технико-экономические показатели;
• порядок и;
• в техническое задание допускается включать приложения.

В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них [из п. 1.4 ГОСТ 19.201-78]

Любые манипуляции с разделами - строго по с.

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

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

Введение

В разделе «Введение» указывают, краткую характеристику области применения или и объекта, в котором используют программу или программное изделие [из п. 2.1 ГОСТ 19.201-78]

Основное правило работы с – детализация, дробление текста на структурные единицы, - разделы, подразделы, пункты и подпункты, см. статью «» документа будет иметь четкую структуру, способствующую легкому требуемого материала. Текст документа станет структурированным и удобным для чтения. Создаем подразделы:

Наименование программы

Наименование программы – «Текстовый редактор для работы с файлами формата rtf».

Краткая характеристика области применения

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

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

Основания для разработки

В разделе «Основания для разработки» должны быть указаны:

• документ (документы), на основании которых ведется разработка;
• , этот документ, и дата его утверждения;
• и (или) условное обозначение темы разработки.

[из п. 2.2 ГОСТ 19.201-78]

Основание для проведения разработки

Основанием для проведения разработки является Договор (письмо и т.д.) № 666 от 32 мартобря 2004 года (входящий № такой-то от такого-то). Договор утвержден Директором ФГУП «Спецтяжмонтажстройсельхозавтоматика» Ивановым Петром Ивановичем, именуемым в дальнейшем Заказчиком, и утвержден Генеральным директором ОАО «Суперсофт» Блюмкинсом Иваном Ароновичем, именуемым в дальнейшем Исполнителем, такого-то мартобря 2004.

Удобно воспользоваться разделом «Общие сведения» , поскольку разработчик имеет полное право дополнять и удалять разделы технического задания на свое усмотрение. В то же время сведения, указанные выше, содержатся в договоре. Следует ли приводить их в техническом задании – зависит от конкретного случая.

Наименование и условное обозначение темы разработки

Наименование темы разработки – «Разработка текстового редактора для работы с файлами формата rtf». Условное обозначение темы разработки (шифр темы) – «РТФ-007»

Назначение разработки

В разделе «Назначение разработки» должно быть указано и эксплуатационное назначение или [из п. 2.3 ГОСТ 19.201-78]

Функциональное назначение

Функциональным назначением программы является предоставление пользователю возможности работы с текстовыми документами в формате rtf.

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

Эксплуатационное назначение может трактоваться достаточно широко. Где, как, кем, с чем должна эксплуатироваться программа?

Резина одного типоразмера может успешно экслуатироваться на Жигулях и Волгах, но не на КаМАЗе. По причине отсутствия. И наоборот. Но для каждого конкретного типоразмера резины можно определить ее эксплуатационное назначение.

Применим формальный подход:

Эксплуатационное назначение

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

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

Требования к программе или программному изделию

Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:

• требования к функциональным характеристикам;
• требования к;
• требования к составу и параметрам;
• требования к и;
• требования к и;
• требования к и;
• специальные требования.

[из п. 2.4 ГОСТ 19.201-78]

Если существуют стандарты, содержащие общие (технические) требования к программе, или, к примеру, «ГОСТ 12345-67. Автоматизированные информационно-измерительные системы. Общие (технические) требования», разработка технического задания существенно упрощается. Большая часть содержимого указанного стандарта просто переписывается в техническое задание.

Требования к составу выполняемых функций

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

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

Клише «обеспечивать возможность выполнения» применимо к современным программным средствам, разработанным с использованием графического пользовательского интерфейса. Указанные программные средства большей частью «простаивают» (idle), ожидая. Применение клише - шаблонного построения фраз - детально расписано в статье «».

Требования к организации входных данных

программы должны быть организованы в виде отдельных файлов формата rtf, соответствующих RFC... Файлы указанного формата должны размещаться () на локальных или съемных, согласно требованиям операционной системы.

Любой иного, но с расширением rtf, открываться не должен.

Файлы http://domain.net/file.rtf или ftp://domain.net/file.rtf открываться не должны. Если файловая система отформатирована как FAT32, файлы с локального или съемного, отформатированного, к примеру, в формате ext3, открываться не должны.

Требования к организации выходных данных

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

Требования к временным характеристикам

Требования к временным характеристикам программы не предъявляются.

Следует уточнить, предъявляет ли заказчик требования к быстродействию программы, к примеру, за какое время программа должна стартовать, открывать и закрывать файлы заданного объема. Если заказчик укажет конкретные цифры, следует подстраховаться и заложить в требованиях к составу и параметрам технических средств стоимостью от $2500. Правда, такую сумму придется обосновывать. Если временные характеристики для заказчика не принципиальны, следует обязательно написать об отказе от требований к временным характеристикам, см. формулировку выше.

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

В подразделе «Требования к надежности» должны быть указаны требования к обеспечению функционирования (обеспечения, контроль входной и выходной информации, после и т.п.) [из п. 2.4.2 ГОСТ 19.201-78]

– штука тонкая и очень опасная. Но перечень функций и видов их, согласно п. 1.3.2. , обязан составить заказчик и согласовать с исполнителем.

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

Требования к обеспечению надежного (устойчивого) функционирования программы

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

• организацией бесперебойного питания технических средств;
• использованием программного обеспечения;
• регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
• регулярным выполнением требований ГОСТ 51188-98. Защита инфоpмации. Испытания пpогpаммных сpедств на наличие.

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

Возможен более гуманный подход. Под надежностью (правда, системы, по тому же ГОСТу) можно считать выполнение некой i-той функции в течение конкретного интервала времени. Предложим заказчику считать критерием надежной работы программы следующий показатель: заказчик в течение часа 100 раз открывает и закрывает файл. Если в указанном интервале времени программа не даст, считаются выполненными.

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

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

Время восстановления после отказа

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

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

Отказы из-за некорректных действий оператора

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

Условия эксплуатации

В подразделе «Условия эксплуатации» должны быть указаны (, относительная влажность и т.п. для выбранных типов), при которых должны обеспечиваться заданные характеристики, а также, необходимое количество и персонала [из п. 2.4.3 ГОСТ 19.201-78]

Очень опасный подраздел для тех, кто делает первые шаги в разработке технического задания.

Климатические условия эксплуатации

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

Программа будет прекрасно работать от плюс 5 до плюс 35 °C при относительной влажности 90 % и атмосферном давлении 462 мм.рт.ст., поскольку такие условия приблизительно соответствуют условиям эксплуатации современных компьютеров непромышленного исполнения. Но как только в техническом задании окажется конкретика и задание будет утверждено, заказчик получает отличный шанс заставить исполнителя провести в полном объеме за счет исполнителя.

Много лет тому назад автор статьи, в силу молодости и неукротимого желания отстоять свою позицию (в техническом задании, в частности), «попал на климатику», причем «попал конкретно» (так, со слов Путина, выражается просвещенная интеллигенция), на довольно крутом «железе». Автор статьи мигом усвоил, что такое «показать кузькину мать» и «где раки зимуют». Упаси Вас господь «попадать на климатику»!

Примечание от 10.02.2011 г. - По иронии судьбы специалисты «Технической документации» не так давно снова «попали на климатику», а точнее - провели разработку программы и методики испытаний на воздействие внешних факторов , по и подготовили, открыв для себя еще одно. Не зря говорят, что история развивается по восходящей спирали...

Требования к видам обслуживания

Программа не требует проведения каких-либо видов.

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

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

Требования к численности и квалификации персонала

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

Системный администратор должен иметь высшее профильное образование и компании-производителя операционной системы. В перечень задач, выполняемых системным администратором, должны входить:

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

Пользователь программы (оператор) должен обладать практическими навыками работы с операционной системы.

Персонал должен быть аттестован на II квалификационную группу по электробезопасности (для работы с конторским оборудованием).

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

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

Требования к составу и параметрам технических средств

В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав с указанием их основных технических характеристик [из п. 2.4.4 ГОСТ 19.201-78]

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

В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:

• процессор Pentium-1000 с тактовой частотой, ГГц - 10, не менее;
• материнскую плату с FSB, ГГц - 5, не менее;
• оперативную память объемом, Тб - 10, не менее;
• и так далее…

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

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

При необходимости должна обеспечиваться и [из п. 2.4.5 ГОСТ 19.201-78]

Требования к информационным структурам и методам решения

Иформационная структура файла должна включать в себя текст, содержащий, предусмотренную спецификацией формата rtf.

Требования к информационным структурам (файлов) на входе и выходе, а также к методам решения не предъявляются.

Требования к исходным кодам и языкам программирования

Исходные коды программы должны быть реализованы на C++. В качестве интегрированной программы должна быть использована среда Borland C++ Buider.

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

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

Требования к защите информации и программ

Требования к и программ не предъявляются.

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

Требования к маркировке и упаковке

В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке, варианты и способы упаковки [из п. 2.4.6 ГОСТ 19.201-78]

Программа поставляется в виде программного изделия - на дистрибутивном (внешнем) носителе (компакт-диске). Речь идет, разумеется, о маркировке и упаковке дистрибутивного.

Требование к маркировке

Программное изделие должно иметь маркировку с обозначением компании-разработчика, типа (наименования), номера версии, порядкового номера, даты изготовления и номера Госстандарта России (если таковой имеется). Маркировка должна быть нанесена на программное изделие в виде наклейки, выполненной полиграфическим способом с учетом требований ГОСТ 9181-74.

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

Требования к упаковке

Упаковка программного изделия должна осуществляться в упаковочную тару ().

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

Условия упаковывания

Упаковка программного изделия должна проводиться в закрытых вентилируемых помещениях при температуре от плюс 15 до плюс 40 °С и относительной влажности не более 80 % при отсутствии агрессивных примесей в окружающей среде.

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

Порядок упаковки

Подготовленные к упаковке программные изделия укладывают в тару, представляющую собой коробки из картона гофрированного (ГОСТ 7376-89 или ГОСТ 7933- 89) согласно чертежам предприятия-изготовителя тары.

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

Для заполнения свободного пространства в упаковочную тару укладываются прокладки из гофрированного картона или пенопласта.

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

На верхний слой прокладочного материала укладывается - упаковочный лист и ведомость упаковки.

Потребительская тара должна быть оклеена лентой клеевой 6-70 по ГОСТ 18251-87.

Упакованные в потребительскую тару программные изделия должны быть уложены на поддон, стянуты лентой для предотвращения потери формы груза и упакованы в полиэтиленовую пленку М 0,2 для защиты от попадания влаги.

В коробку поддона должна быть вложена товаросопроводительная документация, в том числе упаковочный лист согласно ГОСТ 25565-88.

Габариты грузового места должны быть не более 1250 820 1180 мм.

Масса НЕТТО - не более 200 кг.

Масса БРУТТО - не более 220 кг.

Приведен порядок упаковки из ранее разработанного документа на какие-то технические средства. Выглядит несколько необычно в контексте программного изделия. Говоря простым русским языком - полнейший стёб, но требования есть и остаются требованиями.

Требования к транспортированию и хранению

В подразделе «Требования к транспортированию и хранению» должны быть указаны для условия, места, условия хранения, условия складирования, в различных условиях [из п. 2.4.7 ГОСТ 19.201-78]

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

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

Условия транспортирования и хранения

Допускается транспортирование программного изделия в транспортной таре всеми видами транспорта (в том числе в отапливаемых герметизированных отсеках самолетов без ограничения расстояний). При перевозке в железнодорожных вагонах вид отправки - мелкий малотоннажный.

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

• температура окружающего воздуха, °С - от плюс 5 до плюс 50;
• , кПа - такое-то;
• относительная влажность воздуха при 25 °С - такая-то.

Специальные требования

Программа должна обеспечивать взаимодействие с пользователем () посредством, разработанного согласно рекомендациям компании-производителя операционной системы.

Разработчики настоящего стандарта смотрели в будущее. Не существовало в те годы программ с графическим пользовательским интерфейсом.

Требования к программной документации

В разделе «Требования к программной документации» должен быть указан предварительный состав и, при необходимости, специальные требования к ней [из п. 2.5а ГОСТ 19.201-78]

Предварительный состав программной документации

В состав программной документации должны входить:

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

Допускается объединять отдельные виды эксплуатационных документов (за исключением и). Необходимость указывается в. Объединенному документу присваивают и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ [из п. 2.6 ГОСТ 19.101-77]

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

Технико-экономические показатели

В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами [из п. 2.5 ГОСТ 19.201-78]

Ориентировочная экономическая эффективность не рассчитываются. Предполагаемое число использования программы в год – 365 сеансов работы на одном рабочем месте.

Положим, заказчик оснащает программой десяток рабочих мест. Исполнитель потребовал за разработку $1000. Заказчик мог бы установить на рабочие места программный продукт третьей фирмы, стоимостью $500 за дистрибутив и по $100 за лицензию на каждое рабочее место.

Экономические преимущества разработки

Экономические преимущества разработки в сравнении с лучшими отечественными и зарубежными аналогами составит:

На стадии «Технический (и рабочий) проект» должны быть выполнены перечисленные ниже этапы работ:

• разработка программы;
• разработка программной документации;
• испытания программы.

На стадии «Внедрение» должен быть выполнен этап разработки «Подготовка и передача программы».

На этапе разработки техзадания должны быть выполнены перечисленные ниже работы:

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

На этапе разработки программы должна быть выполнена работа по (кодированию) и.

На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями ГОСТ 19.101-77.

На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:

• разработка, согласование и утверждение программы (в ГОСТ, похоже, опечатка – «порядка») и методики испытаний;
• проведение приемо-сдаточных испытаний;
• корректировка программы и программной документации по результатам испытаний.

На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах заказчика.

Порядок контроля и приемки

В разделе «Порядок контроля и приемки» должны быть указаны виды и общие требования к приемке работы [из п. 2.7 ГОСТ 19.201-78]

число рабочих мест		разработка	экономические преимущества

Виды испытаний

должны проводиться на объекте заказчика в сроки…

Приемосдаточные испытания программы должны проводиться согласно разработанной (не позднее такого-то срока) исполнителем и согласованной заказчиком «Программы и методики испытаний».

Ход проведения приемо-сдаточных испытаний заказчик и исполнитель документируют в.

Общие требования к приемке работы

На основании протокола испытаний исполнитель совместно с заказчиком акт приемки-сдачи программы в эксплуатацию.

Приложения

В приложениях к техническому заданию, при необходимости, приводят:

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

[из п. 2.8 ГОСТ 19.201-78]

Если есть, почему не привести. И обязательно выложить перечень ГОСТов, на основании которых должна проводиться разработка. Например:

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

Выводы

Настоящий стандарт, несмотря на свой немалый возраст, позволяет разработать полноценное техническое задание на современную программу с графическим пользовательским интерфейсом. Разработчики ГОСТ 19.201-78 смотрели в будущее и учли практически все аспекты, касающиеся разработки программных средств.

Что осталось неучтенным? Сроки, объемы и этапы финансирования? Техническое задание всегда разрабатывается на основании Договора, письма, и т.д. Указанные сведения должны быть отражены в Договоре.

Каковы спорные моменты? Отсутствие в стандарте конктретных требований, положим, к пользовательскому интерфейсу? Разработчиками стандарта предусмотрен раздел «Специальные требования», возможность добавления новых разделов, допустим, разделов «Дополнительные требования» или «Требования к интерфейсу».

• ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению