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

20 ответов на вопрос “Что такое техническое задание и как его составить?”

  1. LIVER Ответить

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

    Рекомендуем прочитать: «Что такое вендинговый бизнес и как его начать?»

    У меня был случай, когда отсутствие понимание в терминах привело к срыву сроков более чем на месяц. В результате заказчик понес определенные убытки, но проблема была исключительно на его стороне. Поэтому, не допускайте разногласий. Определитесь с терминологией еще до начала разработки проекта.
    Цели проекта
    Обязательно в техническом задании нужно указать, какие цели у Вашего проекта, для чего он создается, как будет работать, что должно быть в конечном результате. Даже если исполнитель работает над малой частью проекта, то он должен полностью понимать его структуру, задачи, цели, технические решения. Для чего? Не всегда исполнитель может получить консультацию и разъяснение от заказчика, да и просить толковать какие-то мелочи нет смысла, если можно обратиться к целям, понять для чего проект, и исходя из этого делать свое дело.
    Приведу пример. Недавно разрабатывали большой интернет проект, и заказали дизайн. Дизайнеру описали, о чем будет сайт, какие на нем будут функции, что он должен делать, как сайт будет помогать людям. В общем, разжевали все до мелочей, а не только то, что касается дизайна. В результате получили макет практически не требующий доработок, а также «в нагрузку» десяток идей как улучшить сайт, что добавить, как сделать его более привлекательным.
    Функциональные требования
    Все требования к заказчику можно разделить на два типа: функциональные и специальные. Функциональные требование – это те варианты исполнения, которые вы хотите видеть у себя. Если говорить на примере интернет сайта, то вы должны предоставить исполнителю примеры функциональных решений с других проектов, которые Вам нравятся, и которые вы хотите видеть у себя. Например, увидели технически понравившейся элементы, описали его, и сразу дали ссылку, чтоб человек наглядно понимал, о чем речь, и мог взять это за основу.

    Рекомендуем прочитать: «Как составить правильный бизнес план: пошаговые рекомендации»

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

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

    Как составить техническое задание: советы из личного опыта

  2. Jensen_Ackels Ответить

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

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

    Советы по написанию

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

  3. Delajurus Ответить

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

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

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

    Также рекомендую почитать

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

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

    Я пообщался с несколькими разработчиками, чтобы узнать, как они составляют техзадания. Передаю микрофон им.
    Аша Саакян, веб-дизайнер, фрилансер
    Техзадание должен писать менеджер проекта, тимлид или сам разработчик (если он фрилансер и работает один). Клиент не разбирается в сайтах — он не сможет учесть все важное.
    Я пишу ТЗ, чтобы оно было понятным для заказчика. Поясняю термины, описываю структуру, дизайн, функционал, используемые технологии. Часто прикладываю прототипы страниц, чтобы клиент понял, как будет выглядеть его сайт. Потом составляю отдельное задание для верстальщика — с техническими деталями и пояснениями, которые помогут в его работе.
    Чем сложнее задача, тем подробнее должно быть ТЗ. Когда я участвовала в больших проектах, я видела техзадания и на 30 страниц.
    Гурам Сипки, основатель диджитал-студии Udix Media
    В первую очередь ТЗ нужно клиенту — чтобы он понял, каким будет его сайт, и на что уходят деньги. Если что-то сделано не так — он может сослаться на ТЗ и попросить переделать.
    ТЗ составляет менеджер проекта после общения с клиентом и обсуждения задачи с дизайнером.
    Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.
    Мы указываем:
    Информацию о компании и цель сайта.
    Требования к дизайну, цветовую гамму.
    Используемые технологии и CMS.
    Кто занимается контентом — мы или клиент.
    Структуру сайта вплоть до каждой страницы.
    Описания каждой страницы. Мы не делаем прототипы, но указываем, какие элементы должны быть на странице, и как они должны работать.
    Последние 2 раздела — самые важные. Именно они обеспечивают понимание, какие будет сайт и как он будет работать.
    Очень важный момент — нельзя просто отдать техзадание разработчикам и надеяться, что они все сделают хорошо. ТЗ — это список требований к сайту, оно не может заменить общение. Важно убедиться, что каждый член команды понимает общую цель, а не просто выполняет задачи на потоке. Если что-то непонятно — надо объяснить, обсудить, дать подробные комментарии.
    Дмитрий Кузьмин, менеджер проектов
    Писать техзадание должен разработчик или менеджер проекта. Нужно указывать только конкретные завершенные формулировки, которые невозможно оспорить. И избегать оценочных прилагательных: красивый, эффективный и прочее.
    Если что-то не указано в ТЗ — надо или уточнить у клиента или реализовать на усмотрение разработчика. Но отдельно сообщаем об этом моменте клиенту. Это нужно обсудить заранее, а еще лучше прописать в конце техзадания.
    А еще нужно нарисовать примерные эскизы того, что должно получиться. С подробными комментариями.
    Александр Курочкин, основатель студии Etalon Idea
    Техзадание есть всегда, без него не бывает работы. «Мне нужен интернет-магазин» — это уже техзадание. Проблема в том, что это очень расплывчатое ТЗ, оно не дает практически никакого понимания.
    Задача проект-менеджера — собрать всю необходимую информацию, продумать решение, создать сайт у себя в голове. А потом описать его в документе. Фактически, ТЗ — это уже полпути к готовому продукту.
    Техзадание — это эталон, с которым вы и ваши клиенты будете сравнивать сайт. Оно нужно всем:
    Разработчик равняется на вещи, описанные в ТЗ.
    Тестировщик проверяет, все ли работает так, как задумано.
    Клиент понимает, что получит в итоге.
    Менеджер проекта может оценить стоимость и сроки разработки.
    С сайтом-визиткой или магазином все просто. На нем вряд ли будет что-то новое, поэтому оценить его стоимость легко еще на этапе обсуждения. Если мы делаем что-то подобное, то можем обойтись вообще без ТЗ. Обсудили задачу, написали формальность в договоре, сделали. Все довольны.
    Если клиенту нужен сложный продукт, никто не сможет сходу оценить сроки и стоимость. Сначала надо разобраться, что именно нужно. Затем, как все будет работать. Потом прикинуть, как это сделать. И только после этого станет ясно, сколько человекочасов уйдет на реализацию.
    В ТЗ мы указываем:
    цель сайта;
    требования к серверу;
    описание работы сайта и отдельных его элементов;
    используемые технологии и библиотеки;
    макет дизайна интерфейса;
    структуру и логику внутренних переходов;
    роли и сценарии работы с сайтом для каждой из них;
    архитектуру базы данных (опционально).
    Мой совет читателям — в первую очередь наладьте коммуникацию. Если члены команды не могут понять друг друга и клиента — никакое техзадание вам не поможет.
    Юрий Кетов, фронтенд-разработчик, фрилансер
    Я не люблю работать по ТЗ. Большинство ТЗ, которые я видел, чрезмерно громоздки и неэффективны. Для меня идеальна ситуация, когда клиент в одном абзаце формулирует задачу сайта и контекст, в котором он будет использоваться.
    Например, так:
    Сайт для Кукольного театра. Задача — рассказать посетителям о театре и репертуаре, предоставить возможность заказать билет онлайн.
    В этом случае для меня главное — референсы. Я посмотрю, что сделали в этом тематике Студия Лебедева, Nimax, RedCollar, ONY, Сибирикс и еще примерно 10 компаний, выберу 2-3 наиболее удачных проекта, согласую с клиентом и буду ориентироваться на них.
    Или так:
    Промостраница для продажи хны для биотатуажа.
    Здесь главное сделать сайт, с помощью которого можно достигнуть нужных KPI. Смотрим, какие сайты делают IT-Agency и Convert Monster и делаем также, не надо ничего изобретать.
    Чем больше контента дает клиент, тем лучше. Если вы дадите мне 1000 фотографий, 20 видео, 50 страниц текста — супер. Я сам все отфильтрую и выберу то, что нужно. Я немного утрирую, но, в общем, это так. Чем больше контента на входе, тем лучше, но оставьте за мной право выбирать.
    Александр Белов, проект-менеджер «Текстерры»
    Техническое задание нужно любому проекту. В каждом ТЗ обязательно должны быть указаны:
    Цели и задачи, которые будет выполнять сайт.
    Целевая аудитория.
    Проработанная до мелочей, структура сайта.
    Интерфейсные элементы сайта.
    Клиент должен четко представлять свой сайт в законченном варианте, его внешний вид и дальнейшую стратегию развития.
    Техническое задание не должно указывать разработчикам «как им делать, что делать и какой код вставить» — это в корне неправильно. В общих чертах, нужно описывать какой сайт должен быть, а не как его делать. Это необходимо учитывать как минимум потому, что заказчик, чаще всего, не обладает должной экспертизой.
    Что касается подхода, то мы всегда прислушиваемся к мнению клиента, но бывают моменты, когда понимаем, что так делать не стоит. В этом случае стараемся переубедить заказчика, опираясь на экспертные данные. В целом мы приветствуем любое видение клиентов.
    Как мы готовим техзадание:
    Анализируем ТЗ, присланное клиентом.
    Изучаем прототип и дизайн-макет сайта.
    На основе полученных данных начинаем подбирать функциональные модули для сайта, которые будут использоваться 100 % и которые, возможно, потребуется использовать.
    Прописываем элементы, которые будут нужны при работе с интерфейсом.
    Исходя из этих данных и оценки «веса» сайта, вычисляем подходящие системные требования к хостингу сайта.
    После этих базовых пунктов начинаем расписывать ТЗ более детально по каждой странице.

  4. VKшник Ответить

    В большинстве крупных организаций внутрифирменные отношения «пользователь-отдел IT» неизбежны, особенно при создании рабочих приложений, необходимых пользователю на постоянной основе. Сложность этих отношений может быть обусловлена многими факторами, но чаще всего это непонимание, возникающее из-за того, что стороны говорят на разных «языках» с различной терминологией. Пользователь понимает, что он хочет, но не может это сформулировать, IT-специалист понимает пользователя, но опасается, что результат выйдет иным, чем видит это первый. Чаще всего проблема начинается с того, что именно пользователь не готов к диалогу: он требует «чтобы работало», «отчет одной кнопкой», «чтобы за минуту выводилось», «чтобы даты в Excel не вылезали» и прочее. При этом его совершенно не интересует, каким образом это делается и какие механизмы работают. На заявления о нагрузке на сервер, просьбы нарисовать схему желаемого результата, обсудить пути решения пользователь не реагирует, полагая, что настоящий профессионал со всем справится. Результаты такого непонимания вредят всему производственному процессу: затягиваются сроки решения задач, возникают ошибки и пробелы в системах, которые нужны пользователю, страдает перегруженный неверными действиями сервер, скорость работы снижается.
    Одним из способов разрешения такого конфликта является написание задания на проект – технического задания, которое предполагает полное и точно изложение требований внутрифирменного заказчика и является своеобразной инструкцией для IT -специалиста. Однако не каждый пользователь способен изложить свои мысли грамотно и доходчиво.
    Приведу несколько советов для написания корректного задания пользователем, по которому можно работать и которое ложится в основу отношения между заказчиком решения и специалистом.
    1. Прежде, чем составлять техническое задание, пользователь должен понять, что именно он хочет получить. Следует определить цель задания, ключевые особенности желаемого результата, нарисовать (написать, создать таблицу) для себя желаемый выход работы.
    2. Собрать документацию, согласно которой вы выполняете работу, для которой необходимо приложение (программа). Прочитать ее внимательно, с карандашом, отмечая особенности и тонкости.
    3. Следует понять, какие параметры следует задавать на входе, какова периодичность работы с желаемой программой (отчетом, приложением, утилитой), сколько данных примерно будет получаться на выходе и все ли они нужны (к примеру, если вам нужна сумма выручки от продаж пяти категорий изделий по категориям без наименований, не стоит требовать создания отчета в миллион строк с указанием каждой продажи с детальными характеристиками). Далеко не каждому специалисту необходима максимально детализированная информация, обработка которой создает значительную нагрузку для вычислительных систем.
    4. Подробно описать необходимую информацию, указать ее особенности, исключения, необходимый уровень детализации. Следует продумать все мелочи: формат чисел, округление, доли, ставки и проч.
    5. Избавиться в техническом задании от расплывчатых описаний, лишних слов, слов-паразитов. Проверить пунктуацию – зачастую ошибки в ней искажают смысл задания. Задание на проект – это документ и лексика в нем должна быть соответствующая. Однако не следует стараться написать все на техническом языке, если вы не владеете терминологией на должном уровне.
    6. Обсудить написанное задание с непосредственным исполнителем, попытаться разрешить все вопросы, внимательно прислушиваясь к мнению собеседника. Не стоит забывать, что вы свою сферу деятельности знаете лучше и только вы можете точно объяснить, какой инструмент вам необходим для эффективно работы. IT-специалист знает свое дело и не обязан знать нюансы работы каждого отдела в организации.
    7. Передать задание в работу за разумный срок до окончательной реализации, чтобы была возможность протестировать результат и исправить возможные ошибки.
    8. Если ваши подчиненные также будут пользоваться созданным приложением, постарайтесь им самостоятельно объяснить особенности работы с приложением – это избавит IT-специалиста от необходимости сто раз объяснять одно и то же.
    9. Помните, что ваше задание будет служить справочником для вас — в нем всегда можно посмотреть описание информации, вспомнить забытое требование.
    Конечно, только лишь умение писать техническое задание не избавит от всех проблем, но оно позволит отношениям с IT-отделом перейти в серьезную плоскость сотрудничества, позволит пользователю повысить свою техническую грамотность и получить требуемое, а специалиста по IT избавит от ряда проблем и ненужных вопросов.

  5. ПЬЯНЫЙ Ответить

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

    1. Обоснование необходимости ТЗ

    А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.
    Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

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

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

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

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

    2. Что в нем должно быть и чего нет. Формулировки

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

    3. Разделы ТЗ

    3.1 Общие слова
    Этот раздел вводит в курс дела. Исходите из того, что вам нужно отдать ТЗ стороннему программисту, и вас не будет на связи всё время работы над проектом вплоть до сдачи. Т.е. программист должен взять ТЗ, и у него не должно возникнуть ни одного вопроса, а первый вопрос, который он мог бы задать — это: «а про что сайт делать будем?» Раздел «Общие слова» в вольной форме и отвечает на этот вопрос.
    3.2 Эксплуатационное. назначение
    Коротко говоря, эксплуатационное назначение — это выгода, которую должен принести сайт. Вообще, чаще всего, выгода сводится к деньгам (если сайт как-то завязан на коммерции, а таких большинство), и в разделе можно было бы всегда ограничиться написанием того, что эксплуатационное назначение сайта — подзаработать деньжат, но мы не будем столь циничными. Остановимся на шаг раньше, непосредственно перед «подзаработать деньжат». Для интернет магазина это будет продажа товара (с которого мы получим деньги), для скидочного сайта это состыковать клиентов и продавцов или поставщиков услуг (чтоб с этого получить свой процент денег), для сайта визитки — это прорекламироваться в инете (а реклама нужна для получения денег) и т.д.
    3.3 Функциональное назначение
    Этот пункт уже ближе к делу. Тут краткий перечень того, какими техническими средствами мы хотим получить профит, описанный в предыдущем пункте. Например, для интернет магазина это каталог товаров, корзина заказа, страницы с информацией о доставке, возврате и о компании.
    Очень часто на фрилансерских сайтах публикуются документы с гордым названием «Техническое задание», в которых содержатся вышеописанные три пункта. Однако, на самом деле, это только вводная часть ТЗ.
    3.4 Термины и определения
    Этот раздел дает уверенность, что заказчик и исполнитель говорят об одном и том же.
    Термины могут «вводится» с двух сторон: от вас к заказчику, например вы ему втолковываете, что такое хостинг и SMTP-сервер, и от заказчика к вам.
    Во втором случае, как правило, не нужно описывать термины специфичные для предметной области, но не имеющие отношения к реализации проекта. Например, для магазина торгующего запчастями для парусных судов, не стоит выносить в термины такое, как стаксель и ванты. Здесь нужны расшифровки терминов, которыми оперирует заказчик и вкладывает в них некий смысл, который может быть нами истолкован неверно. Какие-то простые слова, но в данном контексте, принимающие особое значение. Например, заказчик говорит: «Сеанс работы с сайтом стоит 100 тугриков». Фраза «сеанс работы с сайтом» — претендент на описание. Этот термин может означать продолжительность времени от входа на сайт до выхода, или же период работы пока на счету пользователя не закончатся деньги. Т.е. нам нужно точно знать, что такое «Сеанс работы». Ошибочное понимание такого простого термина может создать реальную проблему.
    3.5 Данные и списки
    Ключевой раздел ТЗ. Можно сказать его сердце. Это не самый многословный, но самый важный и трудный пункт ТЗ. Если он сделан как надо, можно быть уверенным, что автор задания понимает, что именно нужно сделать. Наличие этого пункта накладывает очень сильные ограничения на создаваемый продукт. Один только этот пункт, думаю, «весит» больше половины всего ТЗ.
    Данные
    Этот раздел содержит перечень сущностей, которые используются в проекте. Это очень близко к описанию таблиц в базе данных или моделей, если говорить о фреймворках с MVC. Например, у нас на сайте есть новости. А что такое новость? Как гласит военное определение, куст — это совокупность веток и листьев торчащих из одного места. Так и новость, это совокупность заголовка, текста и даты публикации. Для чего нужно это определение? Как и всё в ТЗ — прояснить, что делать и подстраховаться от хотелок.
    Перечисление атрибутов сущности позволяет заметить мелочи, которые, оставшись незамеченными, могли бы привести к осложнениям.
    Для примера, та же самая новость:
    Заголовок
    Текст
    Дата публикации
    Предположим, в процессе работы выясняется, что забыли анонс новости (коротенький текст, который отображается в списке новостей). Добавить его не проблема: нужно в таблицу добавить поле «анонс» типа «текст» и дополнительное поле ввода в создании/редактировании новости. Доработка несложная.
    А теперь, допустим, выясняется, что забыли добавить атрибут «Категория новости». Просто добавить одно поле в таблицу базы данных, как это было с анонсом, уже недостаточно. Придется добавлять еще одну сущность, таблицу категорий и соответствующий раздел в админке по управлению категориями новостей. Вот такого рода пункты, оставаясь незамеченными при оценке проекта, приводят к неверным результатам и, как следствие, к срыву сроков. И именно этот пункт ТЗ позволяет выявлять подобные проблемы. Т.е. лучше заметить нехватку «Категорий» на этапе написания ТЗ, чем в процессе работы.
    Списки
    Как подсказывает Кэп, новость — это новость, а список новостей — это список новостей.
    Зачем это описывать? Допустим мы должны отобразить на главной странице «последние новости». Вот последние новости, это как раз такой список. А что есть «последние новости»? Это уже можно понять по разному, это могут быть последние 5 новостей, а может это новости за последние 24 часа? Приведенный пример прост, его недорого исправить и при сдаче проекта. Но есть более тяжелые случаи.
    Например, заказчик хочет свой сайт с коллективными блогами, типа своего хабра. И он хочет, что бы на странице, где отображается одна статья, сбоку был список «похожих статей». Что такое похожие статьи? Этот вопрос требует отдельного разбирательства и описания. И не обратив внимания на этот список мы рискуем уже достаточно серьёзно. Т.е. тут нужно подробно описывать алгоритм по определению сходства статей. Пропустив этот пункт на этапе оценки сроков можно промахнуться достаточно сильно.
    3.6 Страницы с описанием
    Раздел с описанием всех страничек и того, что на них должно быть. В большинстве случаев это достаточно короткое описание, т.к. мы можем использовать отсылки к данным и спискам. Например, «на странице отображается список последних новостей». Что такое новость, мы уже описали, что такое последние новости — тоже. Если нужно, можем уточнить, что отображаются не все данные новости, а только название и анонс.
    Тут будет уместно описать не только, что отображается, но и как. Не в том смысле, что мы описываем дизайн: «Большими красными буквами отображается название новости», а в смысле, как работает: «Слева плавно выезжает окошко с предложением ввести логин и пароль». Или так: «при нажатии кнопки „Отправить комментарий“, комментарий появляется на странице без перезагрузки, с помощью AJAX».
    Нужно ли тут описывать контент страницы? Нет не нужно. Мы пишем техническое задание. Описывая каталог, мы же не описываем все товары в нем? Наша задача описать функционал, который позволит заказчику самостоятельно заполнить контентом страницу. Если планируется наполнение сайта контентом исполнителем, это лучше вынести в отдельный документ.
    Естественно, будет очень здорово добавить к каждой странице эскиз вроде такого:

    Стоит следить, чтобы текстовое описание не вступало в противоречие с тем, что нарисовано в эскизе.
    Т.е. если на иллюстрации новость имеет «Категорию новости», а в разделе «Данные и списки» новость не имеет ее, то это проблема. Очень высока вероятность, что изучая ТЗ, заказчик запомнит именно картинку с эскизом новостей, в которой есть категория, и если в готовом проекте не будет категории (в соответствии с текстовым описанием новости), он расстроится.
    Возможно, стоит в тексте документа прямо указать, что первичен текст, а иллюстрации просто для облегчения понимания. Хотя этот вопрос спорный.
    Для сайтов с четко выраженным разделением на админку и публичную часть, имеет смысл сгруппировать все страницы в две большие категории: публичная часть и админка. Если четкого разделения нет, нужно указать права доступа для каждой страницы.
    3.7 Требования к надежности
    Если планируется сайт с высокой нагрузкой, об этом стоит сказать заранее, чтоб не было конфуза. Высоконагруженный сайт вполне может потребовать специфические действия по настройке серверов или написанию кода. И выяснить, что сайт должен держать огромную нагрузку в момент сдачи проекта, не лучшее развитие ситуации.
    Стоит отдельно сказать, что для надежности, необходимо настроить бэкапы, т.к. «случаи разные бывают» и никто не застрахован от злобных хакеров которые могут попортить базу данных или хостеров, которые могут сгореть синим пламенем, как это уже бывало.
    3.8 Требования к хостингу
    Очевидно, что вполне может возникнуть, например, такая ситуация. Наша веб-студия делает красивые сайты, но пишет исключительно на Django. Заказчик нашел наш сайт, увидел красивые дизайны и сделал заказ. Приходит пора выкладывать сайт на хостинг, к другим десяти сайтам заказчика, а там, естественно PHP. И начинается, «а я думал что все на PHP делают…, у меня другого хостинга нет, надо переделывать на PHP».
    Помимо таких очевидных проблем есть проблемы и потоньше. Например, для нормальной работы нужен cron, а хостер его не предоставляет (абсолютно реальный случай из моей практики). Или, скажем, специфический сайт, который не может работать на shared хостинге, ему нужен только VPS или VDS.
    Сюда стоит включить требования к интерпретаторам, библиотекам, пакетам, гемам, требования к дисковому пространству, памяти, smtp, pop, ftp, внешним программам и прочему, что имеет значение для работы проекта.
    3.9 Наполнение контентом
    Этот пункт оговаривает объем наполнения контентом. Как минимум, мы должны создать тот контент, который позволит заказчику начать эксплуатацию сайта. Ну хотя бы создать учетную запись для администратора сайта и сказать заказчику логин и пароль.
    Если мы должны, например, залить в каталог 500 фотографий, предварительно их обработав, то это следует описать именно тут.
    Описание этого раздела предостережет нас от разного понимания того, кто должен залить 500 фотографий и наполнить каталог товарами.
    3.10 Сдача и приемка
    Описание тех условий, при наступлении которых должен состояться расчет за работу.
    Возможны варианты, например, перенос на хостинг заказчика после 100% оплаты. Или же оплата после переноса на сайт заказчика плюс неделя на обкатку.
    Кстати, 100% оплата, я думаю, не должна означать окончание исправления багов. На мой взгляд, на баги должна даваться пожизненная гарантия, и исправляться они должны всегда и бесплатно. Хотя, думаю, тут будут и иные взгляды на эту проблему.

    Заключение

    Конечно, это ТЗ не охватывает все стороны сайта, но для очень большого числа проектов оно станет хорошим описанием.
    Да, это ТЗ имеет пробелы, например, не сказано, как быть если у сайта должно быть API. Однако, имея хороший раздел «данные и списки», расширить ТЗ на эту область будет достаточно просто.
    Буду рад услышать критику и, особенно, описание случаев, когда подобное ТЗ не подходит.

  6. мечтающий пацан Ответить

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

  7. Mr_BeriMir Ответить

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

    Кому-то такой дизайн нравится
    Также в ТЗ надо исключить формулировки наподобие:
    Сайт должен понравиться заказчику. А это будет зависеть от того, что заказчик с утра съел горькую кашу?
    Сайт должен быть удобным. Для кого?
    Сайт должен выдерживать большие нагрузки. А большие это какие? 10 тысяч? 100 тысяч? Миллион?
    Качественный экспертный контент. А какие критерии экспертности?
    Поэтому постарайтесь заменить все неоднозначности как можно более точными формулировками. Например:
    Как не надо

    Как надо
    Сайт должен быстро грузиться
    Любая страница должна получить более 90 баллов в Google PageSpeed Insights
    Сайт должен выдерживать большое количество пользователей
    Сайт должен выдерживать 70 тысяч посетителей одновременно
    На главной странице выводятся статьи
    На главной странице выводится список последних 8 опубликованных статей
    Стильный и приятный интерфейс подписки
    Поле «Оставьте e-mail» и кнопка «Подписаться» с утвержденным дизайном

    Структура техзадания

    Общая информация

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

    Глоссарий терминов


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

    Рекомендуем писать пояснения в инфостиле

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

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

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

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

    Структура сайта

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

    Наполнение каждой страницы

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

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

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

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

    Контент

    Заранее решите кто будет отвечать за наполнение контентом. Сделает ли разработчик все сразу без дополнительной платы; потребует ли он за тексты деньги или заказчик сам будет писать туда заголовки и статьи.
    Распишите, кто за какой контент отвечает
    Критерии оценки качества текстов довольно разнятся. Есть объективные, наподобие воды, количества ключевых слов или повторов. А есть необъективные – наподобие красоты или стиля. Чтобы лучше понимать, что считать хорошим текстом, рекомендуем вам почитать посты про копирайтинг в наших группах в социальных сетях.

    Описание дизайна

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

    Дополнительные соглашения

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

    Резюме

    Для каждого конкретного сайта структура может немного различаться. Какие-то пункты добавляться, а какие-то можно убрать (например, сценарии). Но в целом в каждом ТЗ на разработку сайта необходимо указывать:
    Блок информации о компании, ЦА, цели и задачи сайта.
    Расшифровку терминов.
    Технические требования к верстке и работе сайта.
    Указание инструментов и технологий, с помощью которых будут работать, а также список требований к хостингу.
    Описание структуры сайта.
    Эскизы страниц или описания элементов, которые там будут.
    Список контента, который делает разработчик.

  8. RomikTV Ответить

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

    4.1.4.1. Состав показателей надежности для системы в целом
    Например:
    Уровень надежности должен достигаться согласованным применением организационных, организационно-технических мероприятий и программно-аппаратных средств.
    Надежность должна обеспечиваться за счет:
    – применения технических средств, системного и базового программного обеспечения, соответствующих классу решаемых задач;
    – своевременного выполнения процессов администрирования Системы КХД;
    – соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;
    – предварительного обучения пользователей и обслуживающего персонала.
    Время устранения отказа должно быть следующим:
    – при перерыве и выходе за установленные пределы параметров электропитания – не более X минут.
    – при перерыве и выходе за установленные пределы параметров программного обеспечением – не более Y часов.
    – при выходе из строя АПК ХД – не более Z часов.
    Система должна соответствовать следующим параметрам:
    – среднее время восстановления Q часов – определяется как сумма всех времен восстановления за заданный календарный период, поделенные на продолжительность этого периода;
    – коэффициент готовности W – определяется как результат отношения средней наработки на отказ к сумме средней наработки на отказ и среднего времени восстановления;
    – время наработки на отказ E часов – определяется как результат отношения суммарной наработки Системы к среднему числу отказов за время наработки.
    Средняя наработка на отказ АПК не должна быть меньше G часов.
    4.1.4.2. Перечень аварийных ситуаций, по которым регламентируются требования к надежности
    Например:
    Под аварийной ситуацией понимается аварийное завершение процесса, выполняемого той или иной подсистемой КХД, а также «зависание» этого процесса.
    При работе системы возможны следующие аварийные ситуации, которые влияют на надежность работы системы:
    – сбой в электроснабжении сервера;
    – сбой в электроснабжении рабочей станции пользователей системы;
    – сбой в электроснабжении обеспечения локальной сети (поломка сети);
    – ошибки Системы КХД, не выявленные при отладке и испытании системы;
    – сбои программного обеспечения сервера.
    4.1.4.3. Требования к надежности технических средств и программного обеспечения
    Например:
    К надежности оборудования предъявляются следующие требования:
    – в качестве аппаратных платформ должны использоваться средства с повышенной надежностью;
    – применение технических средств соответствующих классу решаемых задач;
    – аппаратно-программный комплекс Системы должен иметь возможность восстановления в случаях сбоев.
    К надежности электроснабжения предъявляются следующие требования:
    – с целью повышения отказоустойчивости системы в целом необходима обязательная комплектация серверов источником бесперебойного питания с возможностью автономной работы системы не менее X минут;
    – система должны быть укомплектована подсистемой оповещения Администраторов о переходе на автономный режим работы;
    – система должны быть укомплектована агентами автоматической остановки операционной системы в случае, если перебой электропитания превышает Y минут;
    – должно быть обеспечено бесперебойное питание активного сетевого оборудования.
    Надежность аппаратных и программных средств должна обеспечиваться за счет следующих организационных мероприятий:
    – предварительного обучения пользователей и обслуживающего персонала;
    – своевременного выполнения процессов администрирования;
    – соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;
    – своевременное выполнение процедур резервного копирования данных.
    Надежность программного обеспечения подсистем должна обеспечиваться за счет:
    – надежности общесистемного ПО и ПО, разрабатываемого Разработчиком;
    – проведением комплекса мероприятий отладки, поиска и исключения ошибок.
    – ведением журналов системных сообщений и ошибок по подсистемам для последующего анализа и изменения конфигурации.
    4.1.4.4. Требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.
    Проверка выполнения требований по надежности должна производиться на этапе проектирования расчетным путем, а на этапах испытаний и эксплуатации – по методике Разработчика, согласованной с Заказчиком.

    4.1.5. Требования к эргономике и технической эстетике

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

    4.1.6. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

    Например:
    Условия эксплуатации, а также виды и периодичность обслуживания технических средств Системы должны соответствовать требованиям по эксплуатации, техническому обслуживанию, ремонту и хранению, изложенным в документации завода-изготовителя (производителя) на них.
    Технические средства Системы и персонал должны размещаться в существующих помещениях Заказчика, которые по климатическим условиям должны соответствовать ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды» (температура окружающего воздуха от 5 до 40 °С, относительная влажность от 40 до 80 % при Т=25 °С, атмосферное давление от 630 до 800 мм ртутного столба). Размещение технических средств и организация автоматизированных рабочих мест должны быть выполнены в соответствии с требованиями ГОСТ 21958-76 «Система “Человек-машина”. Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования».
    Для электропитания технических средств должна быть предусмотрена трехфазная четырехпроводная сеть с глухо заземленной нейтралью 380/220 В (+10-15)% частотой 50 Гц (+1-1) Гц. Каждое техническое средство запитывается однофазным напряжением 220 В частотой 50 Гц через сетевые розетки с заземляющим контактом.
    Для обеспечения выполнения требований по надежности должен быть создан комплект запасных изделий и приборов (ЗИП).
    Состав, место и условия хранения ЗИП определяются на этапе технического проектирования.

    4.1.7. Требования к защите информации от несанкционированного доступа

    4.1.7.1. Требования к информационной безопасности
    Например:
    Обеспечение информационное безопасности Системы КХД должно удовлетворять следующим требованиям:
    – Защита Системы должна обеспечиваться комплексом программно-технических средств и поддерживающих их организационных мер.
    – Защита Системы должна обеспечиваться на всех технологических этапах обработки информации и во всех режимах функционирования, в том числе при проведении ремонтных и регламентных работ.
    – Программно-технические средства защиты не должны существенно ухудшать основные функциональные характеристики Системы (надежность, быстродействие, возможность изменения конфигурации).
    – Разграничение прав доступа пользователей и администраторов Системы должно строиться по принципу “что не разрешено, то запрещено”.
    – …
    4.1.7.2. Требования к антивирусной защите
    Например:
    Средства антивирусной защиты должны быть установлены на всех рабочих местах пользователей и администраторов Системы КХД. Средства антивирусной защиты рабочих местах пользователей и администраторов должны обеспечивать:
    – централизованное управление сканированием, удалением вирусов и протоколированием вирусной активности на рабочих местах пользователей;
    – централизованную автоматическую инсталляцию клиентского ПО на рабочих местах пользователей и администраторов;
    – централизованное автоматическое обновление вирусных сигнатур на рабочих местах пользователей и администраторов;
    – ведение журналов вирусной активности;
    – администрирование всех антивирусных продуктов.
    4.1.7.3. Разграничения ответственности ролей при доступе к
    Требования по разграничению доступа приводятся в виде матрицы разграничения прав.
    Матрица должна раскрывать следующую информацию:
    – код ответственности: Ф – формирует, О – отвечает, И – использует и т.п.;
    – наименование объекта системы, на который накладываются ограничения;
    – роль сотрудника/единица организационной структуры, для которых накладываются ограничения.

    4.1.8. Требования по сохранности информации при авариях

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

    4.1.9. Требования к защите от влияния внешних воздействий

    Приводятся требования к радиоэлектронной защите и требования по стойкости, устойчивости и прочности к внешним воздействиям применительно к программно-аппаратному окружению, на котором будет эксплуатироваться система.
    Применительно к программно-аппаратному окружению Системы предъявляются следующие требования к защите от влияния внешних воздействий.
    Требования к радиоэлектронной защите:
    – электромагнитное излучение радиодиапазона, возникающее при работе электробытовых приборов, электрических машин и установок, приёмопередающих устройств, эксплуатируемых на месте размещения АПК Системы, не должны приводить к нарушениям работоспособности подсистем.
    Требования по стойкости, устойчивости и прочности к внешним воздействиям:
    – Система должна иметь возможность функционирования при колебаниях напряжения электропитания в пределах от 155 до 265 В (220 ± 20 % – 30 %);
    – Система должна иметь возможность функционирования в диапазоне допустимых температур окружающей среды, установленных изготовителем аппаратных средств.
    – Система должна иметь возможность функционирования в диапазоне допустимых значений влажности окружающей среды, установленных изготовителем аппаратных средств.
    – Система должна иметь возможность функционирования в диапазоне допустимых значений вибраций, установленных изготовителем аппаратных средств.

    4.1.10. Требования по стандартизации и унификации

    В требования к стандартизации и унификации включают: показатели, устанавливающие требуемую степень использования стандартных, унифицированных методов реализации функций (задач) системы, поставляемых программных средств, типовых математических методов и моделей, типовых проектных решений, унифицированных форм управленческих документов, установленных ГОСТ 6.10.1, общесоюзных классификаторов технико-экономической информации и классификаторов других категорий в соответствии с областью их применения, требования к использованию типовых автоматизированных рабочих мест, компонентов и комплексов.
    Разработка системы должна осуществляться с использованием стандартных методологий функционального моделирования: IDEF0, DFD и информационного моделирования IE и IDEF1Х в рамках рекомендаций по стандартизации Р50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования».
    Моделирование должно выполняться в рамках стандартов, поддерживаемых программными средствами моделирования ERWin 4.х и BPWin 4.х.
    Для работы с БД должнен использоваться язык запросов SQL в рамках стандарта ANSI SQL-92.
    Для разработки пользовательских интерфейсов и средств генерации отчетов (любых твердых копий) должны использоваться встроенные возможности ПО , а также, в случае необходимости, языки программирования .
    В системе должны использоваться (при необходимости) общероссийские классификаторы и единые классификаторы и словари для различных видов алфавитно-цифровой и текстовой информации.

    4.1.11. Дополнительные требования

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

    4.1.12. Требования безопасности

    В требования по безопасности включают требования по обеспечению безопасности при монтаже, наладке, эксплуатации, обслуживании и ремонте технических средств системы (защита от воздействий электрического тока, электромагнитных полей, акустических шумов и т. п.) по допустимым уровням освещенности, вибрационных и шумовых нагрузок.
    При внедрении, эксплуатации и обслуживании технических средств системы должны выполняться меры электробезопасности в соответствии с «Правилами устройства электроустановок» и «Правилами техники безопасности при эксплуатации электроустановок потребителей».
    Аппаратное обеспечение системы должно соответствовать требованиям пожарной безопасности в производственных помещениях по ГОСТ 12.1.004-91. «ССБТ. Пожарная безопасность. Общие требования».
    Должно быть обеспечено соблюдение общих требований безопасности в соответствии с ГОСТ 12.2.003-91. «ССБТ. Оборудование производственное. Общие требования безопасности» при обслуживании системы в процессе эксплуатации.
    Аппаратная часть системы должна быть заземлена в соответствии с требованиями ГОСТ Р 50571.22-2000. «Электроустановки зданий. Часть 7. Требования к специальным электроустановкам. Раздел 707. Заземление оборудования обработки информации».
    Значения эквивалентного уровня акустического шума, создаваемого аппаратурой системы, должно соответствовать ГОСТ 21552-84 «Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспортирование и хранение», но не превышать следующих величин:
    – 50 дБ – при работе технологического оборудования и средств вычислительной техники без печатающего устройства;
    – 60 дБ – при работе технологического оборудования и средств вычислительной техники с печатающим устройством.

    4.1.13. Требования к транспортабельности для подвижных АИС

    КСА системы являются стационарными и после монтажа и проведения пуско-наладочных работ транспортировке не подлежат.

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

    В данном подразделе приводят:
    1) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;
    при создании системы в две или более очереди – перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях;
    2) временной регламент реализации каждой функции, задачи (или комплекса задач);
    3) требования к качеству реализации каждой функции (задачи или комплекса задач), форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования к одновременности выполнения групп функций, достоверности выдачи результатов;
    4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

  10. VideoAnswer Ответить

Добавить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *