Как составлять тз в строительстве

Если вы не понимаете зачем нужно ТЗ – то читайте статью, указанную по ссылке.

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

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

В итоге получится просто “водяное” описание будущего проекта. Если дать программистам такое задание, то в итоге вы скорее всего получите совсем не то, что планировали.

Важная мысль: заплатив за ТЗ, вы экономите.

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

051. Что нужно сделать, прежде чем садиться за ТЗ – Алексей Бородкин

Одно дело – отдать ТЗ на разработку кому-то, и совсем другое – получить хорошее ТЗ.

Что должно содержать хорошее техническое задание:
– структура проекта. Должно быть четкое строение проекта. Все страницы должны быть прописаны максимально конкретно и в достаточной степени.
– макеты в HTML. Макеты должны быть подробными и быть максимально приближенными к будущему сайту.
– отсутствие обобщений. Не должно быть ничего написано: весь каталог, по всему сайту, “и т.д.”. Все эти фразы – это будущие камни преткновения. Из текста ТЗ должно быть четко и однозначно понятно, что надо сделать.
– определены четкие границы, что должно быть сделано. Кто должен заливать первичный контент на сайт? Кто должен настраивать Google WebMaster? Все, что в ТЗ не определено – не входит в рамки задач исполнителя. Поэтому все необходимые работы должны быть обозначены в техническом задании.
– не забудьте что в ТЗ надо описать следующие моменты: настройка среды окружения (сервера), бекапы, первичное продвижение, регистрация в поисковиках, seo аудит, аудит page speed, нагрузочное тестирование, требования дизайна, требования к наполнению, требования к верстке, требования к серверу, обучение персонала, роли системы, описание бизнес-логики, термины бизнес-логики.
Хороший вариант – дать проверку технического задания будущему исполнителю либо другому автору ТЗ. В этом случае он сможет вам подсказать слабые места в документе.

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

И последнее, не воспринимайте ТЗ как мелкую задачу в начале проекта, которую надо побыстрее пройти.

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

Как составить техническое задание (ТЗ)?

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

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

P.S. Если вы только задумываетесь над созданием своего проекта, рекомендуем курс для продукт менеджера и руководителя проекта.

Источник: web-automation.ru

Разработка ТЗ: как составить качественное техническое задание — отвечают эксперты

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

Мое направление в департаменте разработки ПО занимается проектами автоматизации процессов документооборота. Мы разрабатываем и внедряем ECM, СЭД (вендорские решения и систему КСЭД 3.0, собственную разработку, которая включена в реестр российского ПО), электронные архивы, помогаем интегрировать эти системы с ERP, сервисами ЭДО, МЭДО, ССТУ и пр. И входим в пятерку ведущих российских игроков на рынке систем документооборота.

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

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

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

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

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

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

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

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

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

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

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

При составлении ТЗ излагайте свои мысли от общего к частному, от проблемы к решению, от бизнес-требований к системным.

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

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

Не забывайте про оформление: структурированный текст — 50% успеха.

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

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

Типичные ошибки и подводные камни при составлении ТЗ:

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

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

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

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

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

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

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

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

Многие думают, что ТЗ — это пережиток прошлого и атрибут излишней бюрократии в современном IT-мире с agile-подходом ко всему. Но по моему опыту, ТЗ по-прежнему неплохо работает как инструмент для повышения прозрачности на проекте и, кроме того, является неким страховым полисом для участников проекта. А страхует оно от неоправданных ожиданий Заказчика и неправильно трактуемых требований Исполнителем.

Правильное ТЗ должно быть прежде всего таким:

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

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

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

Вот основные пункты, которые точно должно содержать любое ТЗ:

• Цели и задачи, которые должны быть решены в проекте.
• Сроки.
• Рамки проекта (что должно быть сделано, а что не входит в проект).
• Подробное описание состава проекта и требований к нему.
• Требования к результату.
• Порядок сдачи/приемки проекта.

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

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

Основная задача ТЗ – донести до разработчика идею заказчика. При этом важно, чтобы:

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

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

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

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

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

Несколько советов для заказчика:

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

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

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

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

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

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

Использование коробочных систем, например 1С-Битрикс, много таких вопросов снимает. Но при кастомной разработке ничто не может «подразумеваться по умолчанию». Для разработчика не существует того, что не описано в ТЗ и договоре. Хорошо, если при вышеупомянутой оценке разработчик обратил внимание на отсутствие ряда функциональностей и в смету включил.

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

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

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

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

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

Примеры ошибок в ТЗ из нашей практики:

1. Не учтено логирование при большом количестве контент-менеджеров: невозможно найти, кто внес то или иное изменение. Здесь же обратный случай: не продуманы группы пользователей и их права, со стороны клиента все ходят в админку под одним логином администратора (и люди, отвечающие за добавление новостей, и seo-специалисты, и бухгалтеры).
2. Не продумано удаление и архивирование элементов и разделов: если на элементы завязана какая-то статистика или заказы и это где-то демонстрируется, надо продумать, оставляем ли мы архив и как мы решаем, что показывается. Это важно и для поискового индекса.
3. Не описан механизм нетиповой интеграции с 1С (endpoint, принципы, пр.) – согласование и выстраивание этой интеграции потребует плотных коммуникаций разработчиков и 1с-специалистов, времени и плотного контроля заказчика.
4. Нет выгрузки товарного каталога и описания хранимых данных в 1С по товарам – все они в итоге отдают одно свойство «характеристики», а в ТЗ предусмотрена фильтрация.
5. Не описана созависимость фильтров.
6. Упущены сортировки как таковые.
7. Административный раздел не описан полностью.
8. В административном разделе не описаны фильтры по заказам по дате, номеру, телефону, вообще какие-либо фильтры, которые будут необходимы администратору.
9. Управление мета-тегами забывают всегда: про то, откуда у страницы берется title – нигде не зафиксировано. Здесь же можно отметить весь пул SEO чек-листа (ЧПУ, 404, хлебные крошки, robots, коды счетчиков, редиректы и т.п.).
10. Не прописаны обязательные по законодательству ссылки в футере (например, СОУТ или «Политика конфиденциальности»).
11. Не описаны почтовые уведомления, которые вообще должны быть (о заказе, регистрации, отправленной форме и т.д.).
12. Не описано управление промо-баннерами. Описано все, но про сквозные картинки в дизайне и про слайдер – забыли.
13. Не продумана и, соответственно, не описана работа с заказами, оплатой и доставкой. Какие будут возможности оплатить заказ? Будет ли работа с юридическими лицами, можно ли им дать возможность сразу выставлять счет или работаем только через менеджера? Какие службы доставки используются, какие данные по заказу и товару нужны для расчета стоимости и сроков доставки? Какие статусы заказов, на каких этапах происходит оповещение пользователя о смене статуса и по каким каналам?
14. Клиент при написании ТЗ не продумал структуру контента, не определил разделы и подразделы. Необходимость вложенного меню с подуровнями может выясниться уже после завершения программирования при внесении контента.

Пишите и читайте ТЗ внимательно. Помните: любые неоплачиваемые доработки проекта вне ТЗ и договора съедают вашу маржинальность.

Источник: tproger.ru

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

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

Назначение

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

Разработка технического задания

При создании продукции для серийного производства ТЗ выполняют в соответствии с ГОСТ 15.016-2016, штучных и мелкосерийных изделий – согласно ГОСТ 15.005-86 (с изм. 1,2,3,4). В других отраслях хозяйственной деятельности существуют свои нормативы. Положения стандартизирующих документов обеспечиваются при разработке и освоении продукции всеми участниками процесса.

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

В общем случае ТЗ содержит требования к:

Разработке (этапы, стадии, документация и т.д.);
Производству;
Контролю и испытаниям;
Комплектности;
Поставке;
Строительной части;
Уровню заводской готовности;
Монтажной технологичности;
Сборке;
Наладке;
Приемке;
ТО и ремонту.

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

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

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

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

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

Структура ТЗ

Рекомендуется предусматривать в ТЗ следующие положения:

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

Возможные разделы технического задания и порядок их расположения:

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

Требования к свойствам сырья.

Упаковка, маркировка, консервация. Сроки и условия хранения.
При необходимости – учебно-тренировочные средства. Макеты, стенды, модели для отработки профессиональных навыков.
Специальные требования. Специальная оснастка для ремонта, ТО. Экспортное исполнение. Патентная чистота изделия и его патентоспособность.
Документация. Конструкторская, технологическая, программная.
Этапы выполнения работы, их порядок и приемка. Сроки выполнения, исполнители. Испытание опытных образцов.
При необходимости – приложения.

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

Техническое задание: простейшие примеры

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

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

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

В других случаях техническое задание может иметь значительно больший объем

Источник: c-kd.ru

Техническая документация

разработка техдокументации по ГОСТ без бумаги и расстояний

Как писать техническое задание?!

Методика разработки технического задания на автоматизированную систему по ГОСТ 34.602-89 (и не только), практические приемы подготовки содержимого разделов, подразделов, пунктов и подпунктов технического задания. Большая часть уже готовых к применению логических элементов ТЗ приведены в конце статьи. Редакция от 06.01.2022.

Создан 05.02.2005 11:41:19

Кто печаль твою разделит?

«Как писать техническое задание?!» — вопль отчаяния из уст т. н. начинающего «технического писателя», далее по тексту — техписа. Вот она — страшная цена развала Союза и переход российской высшей школы на двухступенчатую систему образования.

Вернемся к вопросу. При «раскладке» получается:

• первый вопрос — «а зачем оно надо»;
• второй вопрос — какова должна быть структура разделов документа «Техническое задание»;
• третий вопрос — какие существуют способы подготовки текстов содержимого разделов технического задания?

Третий — самый сложный, как уборка домов и квартир. Ответы на указанные вопросы появятся в ходе изложения.

Цели и задачи статьи

Цель статьи — облегчить жизнь совсем уж начинающим техписам.

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

• повысить собственный рейтинг;
• или окончательно уронить себя в глазах Большого Босса.

История

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

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

Первым программным изделием, реализованным на «железном носителе», стал, возможно, «музыкальный автомат» с вращающимся диском, утыканным колышками. Колышки в определенное время ударяли по определенному камертону. Таким образом, мелодия оказывалась запрограммированной, «зашитой» на металлическом носителе — настоящее программное изделие по ГОСТ 19.004-80, только что не промышленного, а кустарного производства. Увидеть это чудо чудное можно в Политехническом Музее г. Москвы.

Первой автоматизированной системой, возможно, стала ветряная мельница. Вытащил стопор — «лопасти» вращаются, жернова молотят. «Нажатие одной кнопки» — 100-процентная автоматизация.

Далее — леденящая душу история.

История, леденящая душу

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

Приволокли опричники холопа государева, умепьца местного (разработчика), кинули царю-батюшке в ноги. Бился лбом умелец о пол каменный — дык, оно, конечно! Сделаем, твое величество, все безоговорочно, точно, в срок и в полном объеме!

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

Побагровел царь — что ж, смерд, мельница сия муку непотребно мелет?! (Несоответствие производимой народно-хозяйственной продукции требованиям ГОСТ 7045-90 Мука ржаная хлебопекарная. Технические условия). Схватили мужика опричники, да долбанули по буйной его головушке топором каменным. И кончил жизнь Левша под звуки «Реквиема» Моцарта из музыкального автомата.

Выводы

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

Издавались Указы, Распоряжения — «в университете московском студиозусам надобно на соломе сидеть, сморкаться в кулак, нос утирать пучком соломы. А нарушивших правила сии розгами драть нещадно» (или что-то в этом роде).

Равноправия нет и сейчас — кто платит, тот и заказывает музыку. А платит заказчик.

Примечание от 10.05.2014 г. — Но не все так печально Если действовать с умом, то можно запросто прогнуть любого заказчика, см. Как писать техническую документацию? и Урегулирование разногласий и разрешение споров между заказчиком и исполнителем.

Современное состояние

. и было придумано то, что сделали танк.

из серии «Армейские приколы»

Может быть, все было иначе, но танк, в целом, получился хорош — что подтверждается и представителями ГОССТАНДАРТа, и отзывами опытных разработчиков.

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

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

Для маааааааленького техписа, работающего на Большого Босса, разработка технического задания есть:

• средство заработать себе «таки на покушать»;
• способ показать, что техпис — не тварь дрожащая, а право имеет — способ вырасти в глазах Большого Босса.

Крайнее утверждение — палка о трех концах. Ах, ты умный, умеешь? Так на тебе еще работенки. А жалование поднимем. Когда-нибудь.

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

Считаем, что первый вопрос (в первом же приближении) закрыт.

ГОСТы на технические задания

Куст есть совокупность веток, произрастающих из одной точки.

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

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

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

Что общего в разделах перечисленных выше документов? Любое техническое задание должно содержать разделы, отражающие сведения:

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

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

Потребовалось разработать техническое задание на изделие — пользуемся ГОСТ 2.114-95, поскольку ГОСТ 15.001 — кривой по жизни, а разделы технических условий (в целом) соответствуют разделам технического задания. Надо ТЗ автоматизированную систему — открываем ГОСТ 34.602-89. На программу — ГОСТ 19.201-78.

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

Практические приемы разработки технического задания

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

Самый первый прием — создание шаблонного документа с ГОСТированной структурой разделов. Если Боссом поставлена задача разработки технического задания, положим, на автоматизированную систему, скачивается ГОСТ 34.602-89 в виде htm-файла, затем просто открывается вордом и сохраняется в формате dot.

Электронные версии ГОСТов, хранящиеся на Интернет-ресурсах, в целом соответствуют официальным бумажным версиям. Сомнительные моменты всегда можно проверить путем сравнения, если не лень, конечно.

Примечание от 25.12.2011 г. — На сайте Ростехрегулирования (protect.gost.ru) не так давно стали публиковать официальные версии ГОСТов, правда, далеко не в редактируемом формате.

Детализация

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

Вспомним родительское — «пока ты не разложишь все по-полочкам, «ничего у тебя не получится (мама)» или «ни хрена у тебя не выйдет (папа)». И мама, и папа, безусловно, были и остаются бесконечно правы. Несложную задачку по физике решить невозможно, пока векторы сил не будут разбросаны по осям координат. Тройной интеграл взять невозможно, пока не будут поочередно взяты интегралы по dx, dy и dz. За исключением случая, когда «интеграл настолько прост, что взять его можно даже без dx».

Произвольно выбранная цитата из ГОСТ 34.602-89:

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

4.3.2.1 Требования к лингвистическому обеспечению системы

4.3.2.1.1 Требования к применению в системе языков программирования высокого уровня

4.3.2.1.2 Требования к языкам взаимодействия пользователей и технических средств системы

4.3.2.1.3 Требования к кодированию данных

4.3.2.1.4 Требования к декодированию данных

4.3.2.1.5 Требования к языкам ввода-вывода данных

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

4.3.2.1.7 Требования к средствам описания предметной области (объекта автоматизации)

4.3.2.1.8 Требования к способам организации диалога

Примечание — Термины «понятность», «понимаемость» (understandability) фигурируют сразу в нескольких ГОСТах. Вот квинтэссенция — «совокупность свойств чего-то, характеризующая затраты усилий человека на понимание логической концепции этого чего-то».

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

Детализация, детализация и еще раз детализация. До приемлемого (атомарного) уровня.

Шаблонное построение фраз

Следует взять на вооружение тот факт, что в каждом вопросе (правильно поставленном) — половина ответа. Допустим, необходимо сформулировать текст подпункта «Требования к применению в системе языков программирования высокого уровня». Итак:

4.3.2.1 Требования к применению в системе языков программирования высокого уровня

В системе должны быть (именно должны — это же требования!) применены перечисленные ниже языки программирования высокого уровня:

• язык C++;
• язык Pascal;
• и т.д.

Для тех, кто не прочувствовал, как построить фразу, слева приведена схема ее построения.

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

4.1.2 Требования к численности и квалификации персонала системы и режиму его работы

(детализируем — создаем подпункты 4.1.2.1, 4.1.2.2 и 4.1.2.3)

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

(правильно формулируем текст подпункта — отвечаем на вопрос, каким требованиям должна удовлетворять численность персонала)

Численность персонала должна удовлетворять требованиям:

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

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

Квалификация персонала должна обеспечивать эффективное функционирование технических и программных средств системы во всех режимах работы системы»

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

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

Режим работы персонала — трехсменный круглосуточный.

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

Пожалуй, не стоит.

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

Формализация при подготовке текста технического задания

Возможно Двести Вариантов

Один из двухсот вариантов расшифровки аббревиатуры «ВДВ»

Вернемся к примеру из предыдущего подраздела статьи.

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

Численность персонала должна удовлетворять требованиям:

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

Лапша полнейшая, но формально все верно. Рекомендуется к применению, если невозможно конкретизировать какой-либо пункт технического задания. Если Большой Босс не будет удовлетворен, можно вежливо попросить его уточнить требования заказчика по данному пункту, дать более точную информацию. Это право техписа, не контактирующего непосредственно с заказчиком.

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

Примечание от 17.04.2018 г. — В ОКПДТР должность технического пейсателя тоже отсутствует. А должность укладчика текста так и осталась с прежних времен

Штампы и унификация при подготовке текста технического задания

Вы, бабы, красивы,

А я — без прикрас

Но, все же, мужчины

Ю. Рыбчинский, «Две сестры»

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

Положим, разрабатывается универсальный преобразователь энергии солнечного излучения в энергию человеческого разума (Существование человеческого разума сомнительно. Разумно ли вешать на свою шею работу по созданию такого преобразователя? А вот рефлексы существуют объективно). Следует сразу, в разделе «Наименование изделия» обозвать этот самый преобразователь Изделием:

Наименование изделия — преобразователь энергии солнечного излучения в энергию человеческого разума (далее по тексту — Изделие).

И, в тексте — Изделие, Изделие, Изделие.

Тоже самое относится к программным изделиям и автоматизированным системам. Наименование АС — автоматизированная система раздачи грубых кормов для крупного рогатого скота (далее по тексту — Система).

И, в тексте — Система, Система, Система. Программа, Программа, Программа.

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

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

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

• назначение системы — система предназначена для решения перечисленных ниже задач:

• задачи такой-то (первой);
• задачи сякой-то (второй);
• и так далее.

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

Любая цель всегда подразумевает положительную динамику, изменение каких-либо показателей в лучшую сторону. К примеру, цель — повышение благосостояния всего советского народа (но не коммунизм: коммунизм — это мишень!). Цель — повышение удовлетворенности заказчика. Исключение составляют:

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

Встречаются еще и не такие фокусы. Пример из практики одного из самых маститых техписов (пример привел он сам, без всякого принуждения, в одном из техписовских форумов) — «программа позволяет. программа выполняет. программа делает. ». Милостивый государь, технический писатель! Программы еще нет, она еще не разработана, не проверена, не отлажена, не настроена, не испытана и не сдана заказчику, поэтому еще ничего не позволяет, не делает и не выполняет. Что за непобедимая совковая привычка выдавать желаемое за действительное?!

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

• в рамках первой задачи — выполнение функции такой-то, такой-то и еще какой-то;
• в рамках второй задачи — выполнение функции такой-то и пр.

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

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

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

В ГОСТ 34.003-90 функция поставлена впереди задачи, задача является как бы частью функции. И это странно: еще в школе все решали задачки, вычисляя внутри них значения различных функций. И представьте себе, как дико звучала бы декларация: «Цель партии и правительства — повышение благосостояния всего советского народа.

Ради достижения цели партия ставит перед собой функцию обеспечения к 2ххх году каждой семьи отдельной квартирой». (Кстати, заниматься уборкой домов и квартир> самостоятельно сейчас уже не модно и некогда особенно — для этого есть клининговые компании). Таким образом, функция является частью задачи, а не наоборот. Пусть даже вопреки священному ГОСТ 34.003-90.

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

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

И из предыдущего подраздела:

• должны быть. ;
• должна удовлетворять требованиям..

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

Перечни и нумерация разделов

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

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

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

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

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

1. автоматизированной функции добавления записей в таблицы базы данных;
2. автоматизированной функции удаления записей из таблиц базы данных;
3. автоматизированной функции сортировки записей в таблицах базы данных. ;»

Отличия, казалось бы, невелики. Но!

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

Во втором случае, всего-навсего — «методика проверки выполнения п. 4.3.2.1(1) технического задания».

В протоколе испытаний, в первом случае — «требования технического задания к выполнению автоматизированной функции добавления записей в таблицы базы данных выполнены». Во втором случае — «требования п. 4.3.2.1(1) технического задания выполнены». Есть разница?

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

По ГОСТ 2.105 списки следует «нумеровать» не цифрами, а буквами:

а) функция такая-то;

б) функция еще какая-то;

Вопрос принципиальный, поскольку ТЗ на АС (дополнение к ТЗ) до передачи его на утверждение должно быть проверено службой нормоконтроля организации — разработчика ТЗ и, при необходимости, подвергнуто метрологической экспертизе [из 8 прил. 1 ГОСТ 34.602-89]. Ведь если техническое задание разработано криво (по форме и по существу), кривыми будут проектные и эксплуатационные документы.

Чуть-чуть о метрологической экспертизе. Если в ТЗ имеется подраздел «Метрологическое обеспечение. », то метрологическая экспертиза должна быть проведена по полной программе. Если указанный подраздел отсутствует, то метрологическая экспертиза сводится к проверке сокращений физических величин согласно ГОСТ 8.417. И только.

Связка «общие сведения, назначение и состав» в техническом задании

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

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

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

2.1 Назначение системы

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

Система должна обеспечивать решение (возможность решения) перечисленных ниже задач:

1. задачи сбора данных с каких-то, допустим, датчиков;
2. задачи обработки, хранения, отображения и пр. информации в центре сбора.

Вот и все. Немного фантазии, и раздел готов:

Система должна обладать иерархической структурой и включать в себя перечисленные ниже уровни иерархии:

1. 1-й уровень — уровень сбора данных;
2. 2-й уровень — уровень консолидации данных (централизованная обработка, хранение и пр.).

Снова оба зайца — и наповал. И уровни иерархии перечислены, и степень централизации. А что дальше?

Дальше — применение связки.

2.1.1 Уровень сбора данных

2.1.1.1 Общие сведения

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

Уровень сбора данных предназначен (еще один штамп):

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

В состав уровня сбора данных должны входить:

1. датчики такие-то;
2. датчики еще какие-то.

В чем удобство использования связки «общие сведения, назначение и состав»? А невольно получается хорошо структурированное техническое задание — древовидное и иерархическое.

2.2.2.3.1 Датчики такие-то

2.2.2.3.1.1 Общие сведения (о таких-то датчиках)

2.2.2.3.1.2 Назначение (таких-то датчиков)

2.2.2.3.1.3 Состав (таких-то датчиков)

Главное — вовремя остановиться.

Предостережение

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

• прежде всего — стандарты на термины и определения. Для автоматизированных систем таким стандартом является ГОСТ 34.003-90; , например ГОСТ 34.602-89 и РД 50-34.698-90; ; , например ГОСТ 34.601-90; ; и контроля, например ГОСТ 34.603-92;
• ряд других основополагающих стандартов.

Не следует особенно увлекаться подобными «тематическими» ГОСТами, содержащими очень уж конкретные требования к компонентам системы. Характерная ошибка начинающих — «каналы связи должны удовлетворять требованиям ГОСТ такому-то». Это фатальная ошибка. Известно, что приемке-сдаче работ по созданию системы, изделия, программного изделия всегда предшествует проведение испытаний.

Допустим, Большой Босс, пораженный глубокими познаниями техписа, доверился оному, читать ничего не стал и черканул на титульном листе технического задания утверждающую подпись (под УТВЕРЖДАЮ, в правом верхнем углу титульного листа). Заказчик, с гнусной ухмылкой, аккуратно поставил свою (под УТВЕРЖДАЮ, в левом верхнем углу). Все, техническое задание утверждено и внести в него изменения или корректировки возможно только по дополнительному соглашению с заказчиком. Вот тут-то техпис и попал.

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

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

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

Короче, писать надо примерно так, русским по белому:

«В качестве каналов связи могут быть применены (использованы):

1. каналы связи Интернет-провайдеров;
2. каналы операторов сотовой связи;
3. каналы операторов спутниковой связи;
4. коммутируемые телефонные линии общего пользования; объекта заказчика;
5. и так далее»

Ни в коем случае нельзя указывать скорость обмена данными канала связи, т.е. конкретику. Если канал связи будет реализован на базе Ethernet, а в техническом задании будет явно указана скорость обмена не ниже 1200 бит/с, заказчик имеет полное право заставить исполнителя провести испытания по полной программе. Даже в такой, явно абсурдной ситуации.

Заключение

Итак, вспомним еще разок ключевые моменты:

1. подготовка шаблона технического задания импортом электронной версии требуемого ГОСТа;
2. детализация — дробление больших по объему разделов технического задания на короткие простые подразделы;
3. шаблонное построение предложений в разделах (подразделах и пр.) технического задания так, чтобы «в ответе оказывалась половина вопроса»; содержимого тех разделов, где невозможно (или опасно) давать конкретику;
4. применение штампов;
5. применение перечней (маркированных или нумерованных списков);
6. применение связки «общие сведения, назначение и состав»;
7. минимальное применение «тематических» ГОСТов.

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

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

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

Заимствуйте наши материалы с блеском! При воспроизведении материалов портала tdocs.su установка активной гиперссылки на источник (адрес веб-страницы с заимствованной публикацией) обязательна ☠

Источник: tdocs.su