Техническое задание

Составление Технического задания по ГОСТ 34 (ТЗ) занятие не только трудоемкое. На самом деле, при грамотном подходе ГОСТ очень сильно помогает не только при разработке ТЗ, но в ходе реализации проекта автоматизации в целом (и не только в госконтрактах, но и для коммерческой разработки). ТЗ — это не первый документ, который разрабатывается в ходе проекта автоматизации. Характерные особенности Технического задания по ГОСТ 34 Полное наименование стандарта на ТЗ по ГОСТ 34 следующее: ГОСТ 34.602-89 «Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». ЛЮБОЙ стандарт на документы или процессы — это шаблон. Согласно пункту 1.7 стандарта РД 50-682-89, «техническое задание является основным документом, в соответствии с которым проводят создание АС и приемку его заказчиком». В нем должно описываться все, что необходимо для разработки и внедрения системы. ТЗ устанавливает общий облик системы, объем работ (рамки разработки), а также порядок разработки и приемки. Все с ТЗ начинается и все им заканчивается. Этот документ идеально подходит для того, чтобы ваш заказчик понял всю важность и сложность задачи и за что он платит деньги. ТЗ составляется как для исполнителя, так и заказчика, поскольку проект автоматизации проводят команды с обеих сторон. В любом ИТ-проекте имеется огромное количество организационных мероприятий, выполнение которых без активнейшего участия заказчика невозможно. Не составляйте ТЗ формально. Если вы не знаете, что писать, значит ТЗ разрабатывать еще рано, у вас нет понимания системы, еще не понятен сам автоматизируемый процесс, объект автоматизации. Техническое задание — это документ, который согласовывается с заказчиком, который постоянно на столе у руководителя проекта. ТЗ отвечает на два вопроса: ЧТО должна делать система, и КАК она должна создаваться. Технический проект отвечает на вопрос: КАК должны быть выполнены требования ТЗ. Например, в ТЗ прописывается, что должна быть авторизация по логину и паролю, а в ТП приводится макеты интерфейса, сценарии, структуру базы данных. Техническое задание должен составлять бизнес-аналитик, потому что он является «переводчиком» между заказчиком и командой разработки. Задача бизнес-аналитика — разобраться в том, что нужно заказчику и выразить это так, чтобы было понятно команде. И выразить это в виде технического задания. Причем от бизнес-аналитика требуется не просто выслушать заказчика и его сотрудников, а узнать то, о чем они не сказали (а такого обычно более 50%). Поэтому аналитик должен хорошо знать автоматизируемые процессы и за счет своего знания заполнять пробелы, которые остались по результатам обследования. В ТЗ из 30-и страниц может только 7-10 страниц быть посвящено функциям. У этого есть объяснение. Дело в том, что разработчики ГОСТ 34 совершенно по-другому смотрели на проект автоматизации, чем мы. И смотрели более правильно, более комплексно. Во-первых, в первой половине ТЗ не просто так приводятся общие сведения о системе и общие требования. Надо понять, зачем система создается, какие процессы автоматизирует, что нужно сделать, чтобы система заработала, какой облик имеет система. Во-вторых, составители ГОСТ 34 видели систему в первую очередь как людей, а затем уже как программно-аппаратный комплекс. Вот как ГОСТ 34.003-90 определяет автоматизированную систему: «Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций». Таким образом, информационная система — это обученный персонал, программное обеспечение и аппаратный комплекс, все вместе. В-третьих, ТЗ устанавливает не только требования к самой системе, но и регламентирует процесс ее создания, то есть в документе приводятся требования ко всем организационным мерам, выполнение которых необходимо для достижения результата. В-четвертых, ненужные подразделы можно исключать, это допускается. Например, если точно знаете, что в ваших разработках не может быть ничего патентованного, то не надо приводить требования к патентной чистоте. Раздел 1. «Общие сведения» /п. 2.3 ГОСТ 34.602-89/ Большинство сведений, приводимых в данном разделе, не нуждаются в комментарии. Однако, некоторые необходимо прокомментировать. «Перечень документов, на основании которых создается система» - имеются в виду законы, распоряжения или договор. Таким документом может являться другое ТЗ, если разрабатывается ТЗ на подсистему. В подразделе «Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы» приводятся общие сведения о приемке работ. Например, то, что передается документация и проводится ряд испытаний системы. Здесь упоминается о порядке передаче результатов работ. Раздел 2. «Назначение и цели создания (развития) системы» /п. 2.4 ГОСТ 34.602-89/ Назначение: приводится именно вид (виды) автоматизированной деятельности. Например, если создается система для производственного учета, то и приводить стоит автоматизируемые виды учета, автоматизируемые операции, а также объекты, автоматизация которых предполагается. Цель — это ради чего создан проект. Можно назвать это бизнес-целями. Выделяют следующие возможные цели проектов автоматизации: 1. Выполнение внешних требований (требования закона, стандарта и 2. Обеспечение т.д.) работы нового технологического процесса (например, создание интернет-магазина, организация нового отдела, новый бизнес). 3. Снижение операционных расходов (уменьшение количества персонала, увеличение выпуска продукции при использовании тех же мощностей, повышение эффективности). 4. Повышение качества работы: снижение количества ошибок, ускорение принятия решений. 5. Снижение рисков, повышение надежности. Это касается не только технической стороны, но также исключения опасности в случае болезни или увольнения ключевых, «незаменимых», сотрудников. Раздел 3. «Характеристики объекта автоматизации» /п. 2.5 ГОСТ 34.602-89/ В данном разделе следует приводить: 1. Описание заказчика: виды деятельности заказчика, количество филиалов, сотрудников. (характеризовать заказчика нужно в той части, которая непосредственно касается создаваемой системы). 2. Сведения о пользователях системы: виды пользователей, какую роль играет система для разных пользователей. 3. Описание автоматизируемых объектов. Например, если автоматизируется склад, до должны описать, какой он площади, сколько проходов, какая ширина проходов, какие стеллажи, имеется ли отдельная зона сборки, сколько работает человек и какие у них обязанности. 4. Описание автоматизируемых процессов. Привести общие сценарии — обязательно. Только станет ясно, какие должны иметься функции. Раздел 4 «Требования к системе» В ТЗ по ГОСТ 34 имеется три подраздела:  Требования к системе в целом.  Требования к функциям (задачам), выполняемым системой.  Требования к видам обеспечения. Подраздел 4.1. «Требования к системе в целом» /п. 2.6.1 ГОСТ 34.60289/ В подразделе 4.1 «Требования к системе в целом» приводят так называемые нефункциональные, общие, требования, которые описывают создаваемую систему с разных сторон. Пункт 4.1.1. «Требования к структуре и функционированию системы» /п. 2.6.1.1 ГОСТ 34.602-89/ 1. Перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы. В данном пункте обычно приводится:  схема внутренней структуры (сервер приложения, модуль хранения данных, толстый клиент в виде нативного приложения, публичное веб-приложение, панель администрирования, мобильные приложения, сервер отчетов) и внешних, смежных систем (другие системы заказчика, почтовый сервер SMTP, сервис SMS-рассылки, банк-эквайер, онлайн-касса, картографический сервис, адресный сервис, сервис проверки адресов электронной почты и т.п.);  требования к элементам приведенной структуры (например, планируется микросервисная архитектура, то имеет смысл перечень и описание функциональности сервисов). Для наглядности желательно приложить структурную схему системы с обозначением ее частей и смежных систем, как показано на примерах ниже. 2. Требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совместимости, в том числе указания о способах обмена информацией (автоматически, пересылкой документов, по телефону и т.п.) В современных условиях большинство взаимодействий производится по протоколу HTTP(S). Вроде, кроме этого, писать нечего. Тем не менее, данные пункты могут быть настолько большими, что выносятся в приложения. В них следует привести следующие сведения:  перечень передаваемых сведений, хотя бы общее описание, чтобы вообще понять, зачем интегрироваться с конкретной системой;  описание протоколов (или ссылки на описание), особенно в случае присоединения устройств;  структура локальных сетей;  требуемая скорость передачи данных;  применение мобильного интернета или WiFi;  описание неавтоматизированных способов передачи данных. 3. Требования к режимам функционирования системы. Режимы функционирования могут иметь несколько классификаций:  по готовности к эксплуатации: штатный режим, аварийный режим, режим технического обслуживания (например, в аварийном режиме должна присутствовать заставка на сайте, нагрузка переводиться на другой сервер, выводиться особые сообщения при обращении к данной системе по API, в режиме технического обслуживания некоторые функции могут быть доступны);  по готовности к эксплуатации частей системы: как должна функционировать система, если, например, недоступен один из внешних или внутренних сервисов;  по графику работы: 24/7 или пятидневка (от этого зависит как минимум работа технической поддержки);  по возможности изменения данных: режим просмотра или редактирования;  по уровню доступа к данным и операциям системы: режим авторизованного пользователя, режим администратора, гостевой режим (для неавторизованных пользователей);  толстый по средству доступа к системе: через веб-приложение, через клиент, через мобильное приложение (согласитесь, что функциональность может несколько отличаться, эти ограничения можно описать здесь); по виду взаимодействия: диалоговый (через интерфейс),  взаимодействие посредством изменения настроек в конфигурационных файлах или иным способом, неавтоматизированный (например, информация передается другому сотруднику, который вносит данные в систему, производится ручной съем показаний); по  степени автоматизации: автоматический или полуавтоматический режим, «режим советчика»;  по видимости приложения: диалоговый или фоновый режим;  по возможному воздействию на систему: штатный, обучающий, тестовый режимы. 4. Требования по диагностированию системы. Требования по постоянному или периодическому диагностированию следует предъявлять к системам, основанным на микросервисной (разнесенной) архитектуре, системам, в состав которых входит оборудование: датчики, системы управления, терминалы и т.д. Если разрабатывается только программное обеспечение, которое работает на одном сервере, указанные требования излишни. 5. Перспективы развития, модернизации системы. В данном разделе можно записать все перспективы модернизации, но особо отметить те, которые точно повлияют на архитектуру. Пункт 4.1.2. «Требования к численности и квалификации персонала» /п. 2.6.1.2 ГОСТ 34.602-89/ Любая автоматизированная система состоит «из персонала и комплекса средств автоматизации его деятельности». Поэтому в ТЗ указываются требования к персоналу и его квалификации. Например, если автоматизируется конкретная производственная линия, то численность персонала известна. Но во многих случаях она зависит от объема выполняемой работы. Следовательно, укажите должности, график работы, описание деятельности (для назначения прав доступа) и приблизительную квалификацию. Как минимум, понадобятся системный администратор и оператор, довольно часто — модератор. Вполне возможно, что придется предусмотреть несколько видов операторов с разным уровнем доступа. Пункт 4.1.3. «Требования к показателям назначения» /п. 2.6.1.3 ГОСТ 34.602-89/ Обратите внимание, что приведенные в ГОСТе «степень приспособляемости», «пределы модернизации» и «вероятностно-временные характеристики», во-первых, указываются для АСУ (автоматизированной системы управления) и, во-вторых, их достаточно сложно измерить. Таким образом, указанные характеристики подойдут не всегда. Тем не менее, в самом тексте «показатели назначения» определяются как «параметры, характеризующие степень соответствия системы ее назначению». В современных компьютерных системах количественные значения, характеризующие эту систему, в основном относятся к производительности и объему хранения данных. К показателям назначения можно отнести:  количество одновременно работающих в системе пользователей;  количество одновременно выполняемых запросов к серверу;  количество проводимых (регистрируемых) за единицу времени транзакций;  время отклика при разном количестве единовременных запросов и работающих пользователей, при разном количестве обрабатываемых данных (особенно при поиске и агрегации в отчетах);  объем хранимых данных (в частности, изображений и видеозаписей);  время подключения дополнительных вычислительных мощностей при достижении предельной нагрузки;  время подключения дополнительных мощностей при значительном увеличении объема хранимых данных. Все эти характеристики влияют на выбор серверного оборудования, архитектуры сервера приложения и СУБД, реляционной или нереляционной СУБД, микросервисов и т.д. Пункт 4.1.4. «Требования к надежности» /п. 2.6.1.4 ГОСТ 34.602-89/ В тексте ГОСТа достаточно подробно описывается, что необходимо указывать в требованиях к надежности. Тем не менее, для понимания подхода к обеспечению надежности, заложенного в данном стандарте, следует изучить ГОСТ 27.002-89. «Надежность в технике. Основные понятия. Термины и определения». Основным понятием, которое можно применить для автоматизированных систем, является коэффициент готовности: 99%, 99,9%, 99,99%. Каждое количество «девяток» обеспечивается определенными мерами. На выбор технических решений могут повлиять: количество резервных мощностей (они бывают разными), наличие технического персонала на местах, применение не только источников бесперебойного питания, но и дизельгенераторов, а также подключение от двух независимых источников (присоединение к электросетям по I или II категории надежности). Пункт 4.1.5. «Требования к безопасности» /п. 2.6.1.5 ГОСТ 34.602-89/ В данном подразделе описываются требования к технике безопасности при обращении с оборудованием (монтаже, пусконаладке и эксплуатации). Сейчас данные требования называются охраной труда и содержатся в ГОСТах 12-й серии (ССБТ — система стандартов безопасности труда). В ТЗ достаточно привести перечень данных разделов. Пункт 4.1.6. «Требования к эргономике и технической эстетике» /п. 2.6.1.6 ГОСТ 34.602-89/ Можно указать, что интерфейс будет соответствовать разработанному позже дизайн-проекту, либо привести стандарты, например, так называемые «гайдлайны» для разработки мобильных приложений: Material Design для Android и Human Interface Guidelines для iOS. Также можно приводить предельное количество переходов (нажатий) при реализации отдельных особо важных для нас функций, среднюю скорость поиска данных и т.д. Пункт 4.1.7. «Требования к транспортабельности для подвижных АС» /п. 2.6.1.7 ГОСТ 34.602-89/ Относительно устаревшее требование. Однако сейчас сервера на грузовиках, как раньше большие ЭВМ, не возят. Тем не менее, представьте, что есть какая-то суперзащита, внутренний контур за DMZ и необходимость удаленной работы через ноутбук. VPN настраивается в любой момент, но лучше, если это будет отражено в Руководстве по администрированию, а сама возможность предусмотрена конфигурацией сети. Пункт 4.1.8. «Требования к эксплуатации, техническому обслуживанию, ремонту и хранению» /п. 2.6.1.8 ГОСТ 34.602-89/ Данные требования относятся к обслуживанию комплекса технических средств (сервера, файерволы, свичи, рабочие станции и т.д.) Если оборудование требует какого-то особого обслуживания, то необходимо это описать в данном разделе. Например, стоит особый прибор, который необходимо раз в месяц калибровать. Пункт 4.1.9. «Требования к защите информации от несанкционированного доступа» /п. 2.6.1.9 ГОСТ 34.602-89/ Тема защиты информации от несанкционированного доступа достаточно обширна, как и меры по ее обеспечению. Если речь идет о доступе в личный кабинет веб-сайта и в панель администрирования данного сайта, то достаточно требований к авторизации, сложности пароля, ролевой модели доступа. Но если создается финансовая система или система для государственных нужд, то появляются особые требования. Важно отметить, что в данном подразделе приводятся не только меры, которые необходимо применить в ходе разработки системы, но и ее эксплуатации. Так, для финансовых систем следует использовать «Стандарт безопасности данных индустрии платежных карт» (PCI DSS). Для систем, в которых хранятся персональные данные, — Постановление Правительства РФ от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». В вашей предметной области могут иметься и другие стандарты. В общем и целом, средства защиты можно разделить на следующие типы: Средства, 1. обеспечиваемые создаваемым программным продуктом:  Требование по наличию пароля для пользователей, особенно для пользователей с ролью администратора.  Реализация ролевой модели доступа.  Требование по применению ключей электронной подписи для выполнения особо важных операций.  Вынесение программных компонентов, ответственных за взаимодействие с внешними системами, в демилитаризованную зону (DMZ).  Обеспечение регистрации событий и действий пользователей. 2. Меры, обеспечиваемые системным администратором:  Применение межсетевых экранов (файерволов).  Документирование и мониторинг используемых служб и протоколов.  Конфигурирование демилитаризованной зоны (DMZ).  Контроль выполнения правил использования портативных компьютеров: подключение к внутренней сети, использование межсетевых экранов.  Отключение учетных записей по умолчанию перед подключением в сеть оборудования и систем.  Настройка устройств беспроводного доступа: установка паролей и изменение настроек доступа, установленных по умолчанию.  Установка обновлений, устраняющих выявленные уязвимости оборудования и программного обеспечения.  Обеспечение безопасности при удаленном доступе в систему (например, использование VPN).  Установка, обновление и мониторинг работы антивирусного программного обеспечения.  Проведение периодического сканирования сети и сканирования после внесения важных изменений.  Назначение каждому работнику уникальной учетной записи, периодические проверки на наличие неудаленных учетных записей уволенных сотрудников, смена паролей. Выдача и учет токенов электронной подписи.  Настройка ограничения доступа к базам данных.  Контроль синхронизации времени на всех серверах и рабочих станциях (с целью обеспечения корректности времени, регистрируемого в журналах регистрации событий).  Настройка журналов регистрации событий.  Периодическая инвентаризация точек беспроводного доступа и другого оборудования, установленного программного обеспечения. 3. Меры физической защиты:  Ограничение доступа в критические помещения.  Отключение сетевых разъемов в общедоступных местах.  Установка камер видеонаблюдения за критически важными помещениями. 4. Общие организационные меры:  Утверждение периодического политики обучения безопасности персонала правилам и проведение информационной безопасности.  Внедрение процедуры реагирования на инциденты, связанные с нарушением безопасности.  Проверка на вывод в экранных формах или отчеты конфиденциальных данных.  Выдача бейджей всем посетителям, сопровождение посетителей при нахождении в критически важных помещениях.  Всесторонняя проверка принимаемых на работу сотрудников.  Обеспечение безопасности со стороны организаций-поставщиков услуг, связанных с программным и аппаратным обеспечением. 5. Меры, принимаемые в процессе разработки программного обеспечения.  Контроль ответственными лицами внесения изменений в программный код, проверка кода на соблюдение правил информационной безопасности (контроль переполнения буфера, корректная обработка ошибок, проверка на межсайтовый скриптинг, на ошибки механизмов доступа и т.п.)  Применение стойкой криптографии.  Применение правил безопасности для общедоступных вебприложений.  Разработка процедуры отмены для каждого изменения.  Документирование внесение изменений. Пункт 4.1.10. «Требования по сохранности информации при авариях» /п. 2.6.1.10 ГОСТ 34.602-89/ В данном разделе приводится перечень возможных аварий и отказов, при которых должна быть обеспечена сохранность информации. К таким событиям могут относиться:  потеря питания;  выход из строя сервера;  выход из строя устройства хранения (жесткого диска). Пункт 4.1.11. «Требования к защите от влияния внешних воздействий» /п. 2.6.1.11 ГОСТ 34.602-89/ Данный раздел будет полезен в случае размещения серверов, рабочих станций и другого оборудования в условиях холодного склада или, наоборот, в производственных помещениях с повышенной температурой, в запыленных местах или местах с повышенной влажностью. Также иногда стоит учесть вибрацию, излучения или иные воздействия. Подраздел 4.1.12. «Требования по патентной чистоте» /п. 2.6.1.12 ГОСТ 34.602-89/ В случае, если есть подозрение, что будут использоваться какие-либо запатентованные в других странах (или в нашей стране) технологии, и владелец патента может подать иск на собственника системы, в данном пункте указывают перечень стран, в которых необходимо выполнить проверку на патентную чистоту. Пункт 4.1.13. «Требования к стандартизации и унификации» /п. 2.6.1.13 ГОСТ 34.602-89/ Данный пункт также редко содержится в Техническом задании в отношении именно программных средств. В нем указывают как требования по использованию конкретных технологий, так и унифицированных форм документов и классификаторов. Данное описание особенно важно, если есть конкретные требования по используемым фреймворкам, плагинам, протоколам, устройствам, математическим алгоритмам, стороннему программному обеспечению и пр. Не забудьте указать, в какой части и для каких целей должны использоваться данные средства. Также иногда в системах некоторых классов принято использоваться определенные протоколы обмена данными. Например, для обмена данными между геоинформационными системами используются стандарты OCG, а для управления зарядными станциями для электромобилей — OCPP. Подраздел 4.2. «Требования к функциям (задачам), выполняемым системой» /п. 2.6.2 ГОСТ 34.602-89/ Данный раздел является центральным для современных компьютерных систем. Структура функционального описания Рассмотрим структуру функциональных требований к системе: подсистема — комплекс функций — функция — задача. Задача — это часть функции, причем задача может быть описана в виде отдельной функции. Например, для функции входа в систему в качестве одной из задач приводится ввод пароля. А процедуру ввода пароля можно расписать уже как отдельную функцию: проверка на правильность, восстановление пароля, отображение подсказок и т.д. Комплекс — это то, что объединяет функции. Например, «Учет основных сведений», «Проведение аукциона» и т.д. В Комплексе две и более функции. Если система состоит из нескольких подсистем, то в основном ТЗ следует привести перечень функций для подсистем, а уже подробно описывать функциональные требования к подсистемам в отдельных ТЗ на подсистемы (их сейчас часто называют ЧТЗ — частное техническое задание). Виды функций с точки зрения их выполнения Все функции (или их задачи; в функции может присутствовать сразу несколько задач) можно разделить на следующие типы:  Ввод сведений. Иногда называют также «учет сведений».  Вывод информации.  Автоматическая обработка информации. Функции могут быть общими и специальными. К общим функциям, например, относятся работа со списками объектов, работа с карточкой объекта, работа с интерактивной картой. Эти функции могут относится ко всем специальным или части специальных функций. Не забывайте, что в ТЗ приводятся требования к системе и процессу ее создания. Не сценарии. ТЗ отвечает на вопрос, ЧТО должна делать система. На вопрос КАК отвечает технический проект. Если начинаете подробно описывать техническую реализацию, то погрузитесь в детали и не сумеете привести полный перечень требований. Структуры функций ТЗ и технического проекта могут сильно отличаться: в одном сценарии могут реализовываться несколько функций, и наоборот. Некоторые рекомендации по тому, как оформлять описание функций: 1. Требования к функциям и задачам обычно следует выносить в приложение. Таким образом документ органично делится на нефункциональную и функциональную части. 2. Избегайте больших абзацев. Лучше всего, если требования разбиты по пунктам и подпунктам: так легче их воспринимать и контролировать их выполнение. Если приводится перечень требований или сведений, пусть приводится нумерованным или маркированным списком. 3. Для функций, назначение которых не очевидно из их названия, следует обязательно указать цель и решаемую задачу. Пример описания функции Регистрация транспортного средства в Системе Предъявляются следующие требования: 1) Система должна позволять учитывать следующие общие сведения:  государственный регистрационный знак (ГРНЗ);  ФИО собственника;  адрес собственника;  данные от сервиса получения данных о ТС (см. п. 3.3, Приложение  примечание. Б); 2) Система должна позволять учитывать следующие сведения, относящиеся к оплате проезда (указанные сведения носят информационных характер, возможность их изменения непосредственно в учетной карточке транспортного средства не обязательна):  текущий класс ТС;  текущий тариф;  текущий договор;  класс ТС по сведениям из системы МВД РК;  сведения о лицевом счете и его состоянии;  сведения о нахождении в реестре ТС с льготным проездом. 3) Система должна позволять регистрировать и изменять сведения о ТС следующими способами:  вручную оператором;  при поступлении сведений из системы регистрации RFID-меток;  при идентификации ТС с помощью камеры ГРНЗ. 4) При регистрации в системе нового ТС система должна запрашивать данные о ТС от сервиса получения данных о ТС (см. п. 3.3, Приложение Б). Должна иметься возможность обновить указанные сведения отдельного ТС. Подраздел 4.3. «Требования к видам обеспечения» /п. 2.6.3 ГОСТ 34.602-89/ Раздел требований к видам обеспечения очень важный подраздел. В нем описываются условия, без выполнения которых невозможно реализовать или разработку, или ввод в эксплуатацию. Эти условия и описываются как «обеспечение». Пункт 4.3.1 «Математическое обеспечение» /п. 2.6.3.1 ГОСТ 34.60289/ Представьте ситуацию, что необходимо создать систему, в которой требуется реализовать автоматический расчет оптимального маршрута. Кнопка «Рассчитать маршрут», может, и выглядит простой, но за ней могут стоять очень сложные математические алгоритмы и вычисления. Брать на себя разработку таких алгоритмов не стоит, этим занимаются профессиональные математики. В случае наличия подобных алгоритмов и прописываются требования к их разработке или использования уже готовых. Пункт 4.3.2 «Информационное обеспечение» /п. 2.6.3.2 ГОСТ 34.60289/ В данном пункте имеет смысл указать требования к входящей информации и информации, передающейся от компонента к компоненту системы в неавтоматизированном виде. Автоматизированная обработка информации, использование СУБД, информационный обмен внутри системы вполне описываются в других разделах. Пункт 4.3.3 «Лингвистическое обеспечение» /п. 2.6.3.3 ГОСТ 34.60289/ В данном пункте приводятся:  требования к использованию языков программирования (если имеются конкретные предпочтения);  язык интерфейса (какие языки, мультиязычный интерфейс);  язык для общения проектных команд, требования к переводу;  иные особенности ввода и вывода данных при их наличии: шифрование, нестандартные методы взаимодействия пользователей с системой. Пункт 4.3.4 «Программное обеспечение» /п. 2.6.3.4 ГОСТ 34.602-89/ В данном пункте приводится перечень покупных программных средств, если они определены на стадии разработки ТЗ. Пункт 4.3.5 «Техническое обеспечение» /п. 2.6.3.5 ГОСТ 34.602-89/ Любая информационная система не может работать без «железа», серверов, сети и т.д. Определение конкретных характеристик оборудования обычно целесообразно вынести в технический проект, но в ТЗ можно привести примерный состав, чтобы у заказчика было представление о будущих расходах. Пункт 4.3.6 «Метрологическое обеспечение» /п. 2.6.3.6 ГОСТ 34.60289/ Если в систему планируется получать данные с датчиков, то необходимо понимать, какие средства измерения будут применяться, какую точность должны обеспечивать измерительные средства, должны ли данные средства быть сертифицированы и аттестованы. Пункт 4.3.7 «Организационное обеспечение» /п. 2.6.3.7 ГОСТ 34.60289/ Пример, создается система на пустом месте. Например, это система управления складом для нового логистического комплекса. Иными словами, есть только стены. Или проводится модернизация системы, и для внедрения изменений требуется модифицировать организационную структуру. В таких случаях следует указать условия касательно организации процессов, при которых поставляемая система будет реально работать. Пункт 4.3.8 «Методическое обеспечение» /п. 2.6.3.8 ГОСТ 34.602-89/ Иногда для управления системой требуется персонал, имеющий какиелибо особые компетенции. В таком случае в ТЗ необходимо привести перечень методик, нормативов и стандартов, с которыми должны быть ознакомлены взаимодействующие с системой сотрудники.