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

Стоит так же отметить что важность имеют и договора по уборке помещений, и их нужно правильно составлять. И о том, Что должно быть в договоре на уборку помещения? вы сможете узнать больше на сайте cleaning-is.ru. Этот вопрос вы сможете решить раз и навсегда, без каких либо проблем, находясь всегда в правовом поле.

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

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

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

Примечание: 1.Все поля обязательны к заполнению. В случае, если заказчик не предъявляет конкретного требования, то в соответствующем поле проставляется запись «Не предъявляется», «Не требуется» или др. в зависимости от контекста.

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

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

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

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

Содержание примера технического задания на разработку сайта

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

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

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

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

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

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

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

Правильным подходом к составлению ТЗ по 44-ФЗ будет внимательная сверка с правилами 44-ФЗ, о том, что можно, и что нельзя включать в описание объекта закупок. Разберем этот момент подробнее. Скачайте в статье формы и образцы технических заданий на любой вкус.

Как подготовить ТЗ по 44-ФЗ

Общие правила составления технического задания по 44-ФЗ, а точнее правила описания объекта закупки установлены ст. 33 Закона о контрактной системе. Приведем основные:

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

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

Какие ошибки в ТЗ можно исправить на разных стадиях закупки

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

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

Правила написания технического задания по 44-ФЗ

Выше мы привели общие требования, сейчас остановимся на нюансах. В силу п. 4 ст. 23 44-ФЗ название объекта закупки должно быть указано в соответствии с каталогом товаров, работ, услуг. КТРУ утвержден постановлением Правительства РФ от 08.02.2017 № 145. Если описание продукции отличается от того, что указано в каталоге техническое задание по 44-ФЗ в 2019 году должно включать в себя письменное обоснование этого.

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

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

Включает ли подготовка технического задания по 44-ФЗ цену? Как правило, расчет начальной цены контракта делается отдельным документом. Включать НМЦК в техзадание или нет, решает госзаказчик.

Правила составления ТЗ по 44-ФЗ

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

У госзаказчика может быть разработано типовое техническое задание по 44-ФЗ, на основе которого формируются уже ТЗ к различным конкурентным процедурам. Типовая форма включает в себя основные пункты, которые должно содержать задание. Оно также может содержать пример технического задания по 44-ФЗ и основные правила оформления.

Кто подписывает техническое задание по 44-ФЗ? Как правило, руководитель организации либо уполномоченное им лицо. Стоит ответственно отнестись к подготовке ТЗ по 44-ФЗ, т.к. изменить его не всегда возможно. В силу ч. 7 ст. 95 изменение ТЗ при выполнении госконтракта в части изменения вида работы, товара, услуги допускается только в том случае, если будут поставлены работы, товары, услуги, обладающие лучшим качеством, характеристиками, по сравнению с теми, что были указаны в первоначальном ТЗ. Как избежать ошибок при работе с техзаданием, разберем на свежих решениях ФАС

Ответы на вопросы

Можно ли при покупке легкового автомобиля ОКПД2-29.10.22.000 написать конкретную марку (Шкода) со словами эквивалент?

Ответ. Да, вы можете указать конкретную марку автомобиля со словами «или эквивалент». При этом добавлять уточнение «или эквивалент» - обязательное требование закона. Помимо этого указывайте диапазоны требуемых характеристик так, чтобы под эти показатели попадали как минимум две модели машин разных производителей (лучше – три или больше). Если укажете параметры так, что будет подходить только та модель Шкоды, которую вы и хотите, это признают ограничением конкуренции.

Если хотим приобрести конкретную марку автомобиля, как тогда описать техзадание и писать ли слово эквивалент?

Ответ. Смотрите ответ на первый вопрос. Вы вправе указать конкретную марку автомобиля, только сопроводив такое указание словами «или эквивалент». Попытка закупить конкретную марку автомобиля без обоснования - нарушение принципа конкуренции контрактной системы.

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

Ответ. Нет, это неправильно. Указывать конкретные характеристики, под которые подходит только одна марка и модель автомобиля - нарушение закона о конкуренции и правил описания объекта закупки. Вы рискуете в случае проверки быть оштрафованными по части 4.1 статьи 7.30 КоАП.

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

Если товар входит в КТРУ, то можно ли дополнить техническое задание требованиями ГОСТов? Только при наличии обоснования? Обоснование дополнительных характеристик можно размещать только в ТЗ или ещё и в плане-графике?

Ответ. Любое дополнение позиции КТРУ производите только с обоснованием. Укажите, почему вы дополняете описание из каталога. Такие требования указаны в п. 5 и 6 Правил использования КТРУ (утв. Постановлением Правительства от 08.02.2017 № 145). Также отразите всю дополнительную информацию сверх информации из позиции КТРУ во всех плановых документах.

Скажите, если есть смета (как обоснование НМЦК) на тек. ремонт вентиляцию, там есть материалы (короба металлические) нужно к ним подписывать «или эквивалент»?

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

Должно ли наименование объекта закупки полностью совпадать с ОКПД2 или допустимо использовать более детальное наименование объекта закупки?

Ответ. Если ваш объект закупки есть в КТРУ, используйте наименование продукции из классификатора ОКПД2. Не отклоняйтесь от стандартного наименования и описания закупаемого товара.

Каким отдельным документом подтверждается гарантия?

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

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

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

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

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

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

Если в приказе по нормированию не предусмотрен МФУ, только принтер и сканер. Можно ли купить МФУ?

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

Оригинальный картридж во-первых не портит технику, подлежит неоднократной заправке, а неоригинальные картриджи - одноразовые. Где экономия?

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

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

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

Если в КТРУ название товара, например: Бензин автомобильный АИ-92 экологического класса не ниже К 5, то так и писать это название в плане закупок, плане –графике, документации и т.д. или же можно написать, например Бензин АИ-92?

Ответ. В плановых документах наименования объектов закупок пишите в полном соответствии с названиями из КТРУ.

P.S. Не совсем по теме, но все-таки: в ближайшее время план закупок будет отменен. Следите за новостями и статьями на портале.

Кто проверит, что оборудование новое?

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

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

Если в проекте контракта цена с НДС, а участник работает без НДС, надо ли писать протокол разногласий?

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

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

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

Можно ли в названии закупки писать: «Поставка программного обеспечения Microsoft Windows 10 Pro»?

Ответ. Общее правило по Закону № 44-ФЗ. Так как операционная система Windows 10 является зарегистрированным торговым знаком корпорации Microsoft, по общему правилу при описании объекта закупки следует добавлять слова «или эквивалент». А объект закупки назвать «Поставка неисключительных прав на использование программного обеспечения (операционной системы)». Эквивалентами в данном случае станут ОС того же производителя Windows 7 и Widows 8.1. - это более старые и более дешевые аналоги, обладающие однако тем же функционалом и поддерживающие работу с любыми программами, которые могут быть у заказчика, в том числе с самыми современными.

Ремарка. Отечественные аналоги (все они на основе Linux, если не ошибаюсь) менее эффективны и не могут обеспечить качественную и корректную работу с современным ПО и оборудованием, имеющимся у заказчика. Сам Linux менее дружелюбен для непрофессионального пользователя, сложен в освоении, несовместим с некоторыми программами. Обучение работе с Linux обойдется гораздо дороже покупки Windows 10, то есть покупка Linux будет крайне неэффективной.

Практика. Однако в ЕИС можно найти много закупок, где в названии указано только «Поставка ПО Microsoft Windows 10 Pro» и в документации не говорится об эквивалентности. Судя по всему, эти закупки проходят без проблем и не привлекают внимание контролеров. Дело в том, что эквивалентность больше касается торговой марки в целом, а не различных версий внутри этой торговой марки. Контролеры тоже понимают, что Windows - оптимальный вариант для пользователей. Кроме того, что тоже важно, Microsoft поддерживает, но больше не производит новые лицензии на Windows 7 и Widows 8.1. (но в продаже они еще будут долго). То есть Microsoft Windows 10 - самая современная + единственная актуальная, а значит и самая эффективная ОС для абсолютного большинства пользователей (MacOS не в счет, компьютеры Apple при схожем функционале в разы дороже). Рано или поздно Windows 7 и Widows 8.1 производитель прекратит поддерживать и обновлять; останется только один актуальный продукт Windows 10, домашняя и профессиональная версии.

Итог. Хотя указание в названии объекта закупки «Поставка программного обеспечения Microsoft Windows 10 Pro» формально противоречит требованиям закона, практика показывает, что подобные закупки проводят довольно часто. Указание Windows 10 Pro и требует обоснования из серии «желания идти в ногу со временем»:

1. Необходимость обеспечения взаимодействия с оборудованием и программным обеспечением имеющимся у заказчика;
2. Необходимость совместимости со всеми программами имеющимися у заказчика, а также с версиями программ, которые выйдут в будущем;
3. Другие продукты корпорация Microsoft уже не производит, а через некоторое время прекратит их поддерживать и обновлять для защиты от ежедневно проявляющих новых угроз;
4. Обеспечение технической поддержки от производителя к продукта на долгие годы и т.п.

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

Можно ли требовать соответствие товаров национальным (региональным) стандартам и требованиям, не обязательным в России? Или соответствие требованиям необязательных, коммерческих сертификаций?

Ответ. Такие требования вы можете указать в документации, только если обоснуете их необходимость для своих нужд. Это прямо указано пункте 2 части 1 статьи 33 Закона № 44-ФЗ. По общему правилу заказчики используют показатели, требования, условные обозначения и терминологию, которые предусмотрены техническими регламентами и документами (ГОСТами), применяемыми в национальной системе стандартизации, принятые в соответствии с законодательством РФ о стандартизации (там же: п. 2 ч. 1 ст. 33 Закона № 44-ФЗ).

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

Какие права имеет Исполнитель, если после подписания ГК, выясняется, что при требовании изготовить бланк «график» тиражом 1млн, выясняется что этот тираж включает 500 тыс разных видов этого графика, что в десятки раз увеличило себестоимость услуг?

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

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

Без тех. задания можно проводить котировку?

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

Можно в ТЗ не указывать конкретный ГОСТ, только условие о соответствии действующему ГОСТУ?

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

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

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

1. ГОСТ 10015-87 Бумага гуммированная для переводных изображений;
2. ГОСТ 10119-2007 Консервы из сардин атлантических и тихоокеанских в масле

Помните, что корректное название и актуальность ГОСТов вы всегда можете найти проверить на официальном сайте Ростстандарта → www.gost.ru

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

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

Технические условия регистрируют конкретные производители на конкретные товары. Поэтому указывать в техническом задании реквизиты ТУ недопустимо. Но иногда ТУ носят обязательный характер, в таких случаях их можно указывать в техзадании. Например, если закупают вещевое обеспечение для нужд силовых органов. Когда в описании объекта закупки используют ТУ, ФАС проверит, есть ли они в открытом доступе. Если указываете конкретные реквизиты ТУ в документации, опубликуйте их в ЕИС.

Имеем ли мы право указывать в спецификации конкретный товар или как в ТЗ только характеристики?

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

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

Можно ли отклонить заявку по первым частям, если там указана заведомая ложь?

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

Можно ли закупить конверты и кондиционер, если их вообще нет в нормировании?

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

Если наименование объекта закупки «Трактор Беларус-8.1» без указания эквивалент, а в техзадании указано «эквивалент» - нарушение?

Ответ. Здесь и нарушение (хотя и не большое) и нестыковка. Указывая конкретную марку трактора без указания слов «или эквивалент» и без обоснования, что вам необходима эта конкретная модель трактора, вы нарушаете пункт 1 части 1 Закона № 44-ФЗ. Правила описания объекта закупки действуют по умолчанию на всю документацию, а не только на техническое задание (которого может не быть вовсе, или которое может называться по-другому).

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

Корректнее было бы назвать объект закупки примерно «Трактор для выполнения сельскохозяйственных работ» или «Трактор сельскохозяйственный». Также в наименование можно добавить одну или две ключевых характеристики, например «Класс тяги 4» или «Мощность двигателя 200–250 л.с.»

Указали, что футбольная форма нужна Nike или эквивалент, в ТЗ указали обязательным условием: по технологии Dri-Fit (которые есть только у формы Nike). Нарушение ли это?

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

«Технология Nike Dri-FIT - это ткань на основе высокотехнологичного полиэстера, позволяющая дольше сохранять комфорт при интенсивных нагрузках. Уникальная структура ткани Dri-FIT из высокофункциональной микрофибры поддерживает естественную систему охлаждения твоего тела. Она отводит влагу и равномерно распределяет ее по поверхности одежды, откуда она быстрее испаряется.»

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

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

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

Почему мы ОБЯЗАНЫ покупать совместимые картриджи, если мы хотим использовать ТОЛЬКО оригинал? Ссылку на нормативку можно?

Ответ. Вы не обязаны закупать только совместимые картриджи. Но ваши желания должны быть в рамках закона, по которому вы работаете: по закону вы обязаны соблюдать принцип конкуренции. Конкретно - первое предложение п. 1 ч. 1 ст. 33 Закона № 44-ФЗ. Также помните, что обеспечение конкуренции - один из принципов, на которых основывается контрактная система в сфере закупок (статья 6 и статья 8 Закона 44-ФЗ).

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

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

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

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

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

Ответ. Да, если не ограничите конкуренцию. Многие магазины электроники предлагают дополнительные услуги по повышенной гарантии, стоит такая услуга 5-15% от стоимости товара. В маркетинге и продажах такие услуги (зачастую навязываемые) называют «расширением чека». Помните, что дополнительные гарантия – это увеличившиеся риски поставщика понести возможные затраты на гарантийный ремонт, это стоит учитывать при обосновании НМЦК.

В описание объекта закупки Заказчик устанавливает так же требования к гарантийному сроку при поставке товара (ст. 33 Закона 44-ФЗ). Часть 5 статьи 6 Закона от 7.02.1992 № 2300-1 «О защите прав потребителей» гласит, что Изготовитель (исполнитель) вправе устанавливать на товар (работу) гарантийный срок, а также вправе принять обязательство в отношении недостатков товара, обнаруженных по истечении установленного им гарантийного срока (дополнительное обязательство). Установление гарантийного срока – это право изготовителя (продавца), а не обязанность и законом не ограничивается возможность установления также различных гарантийных сроков.

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

Вес пачки бумаги д.б. 2,24532кг, при взвешивании всегда меньше (с учетом обертки пачки), что делать, отклонять?

Ответ. Надо смотреть документацию. Судя по всему, принимать… Но это не точно… Вы установили требование к весу пачки бумаги с точностью до сотой доли грамма (!) . Как вы это обосновали? Как вы высчитали этот вес с такой точностью? На основе взвешивания пачки из прошлой партии? Или посчитали вес одного листа из расчета количество листов в листе 1 кв. м. (около 16), а затем перемножили на количество листов в пачке? Даже две одинаковые пачки бумаги из одной коробки по весу будут различаться на пару-тройку процентов и это нормально и допустимо. И это все по-прежнему по ГОСТу.

Ни ГОСТ, ни КТРУ не содержит требования к весу пачки бумаги, он говорит о весе листа такой бумаги площадью 1 кв. метр - 80 грамм (самая распространенная и стандартная офисная бумага), 100 грамм и т.д. в зависимости от плотности, которая требуется. То есть в ГОСТе вес упаковочной бумаги не учитывается в принципе.

Таким образом, заказчик уже установил требование, которое не регламентирует ГОСТ (это уже повод для жалобы со стороны участников). А с учетом точности веса до сотой доли грамма это требование крайне жесткое…

Корректное измерение веса бумаги по ГОСТу должно выглядеть примерно так: заказчик должен вскрыть пачку наугад и наугад вытащить оттуда 17 листов бумаги. Затем заказчик должен обрезать некоторые и склеить листы так, чтобы получился один большой квадратный лист со сторонами равными 1 м. Взвесить этот лист и вычесть массу потраченного клея. Результат должен равняться 80 грамма +/- 3 грамма. Согласитесь, что для такого нужны крайне точные, чуть ли не ювелирные весы. Кроме того, результат все равно нельзя считать репрезентативным, так как такой лист площадью 1 кв.м. измеряют на специальных испытаниях. И испытания эти проводят также по ГОСТ Р ИСО 536-2013 «Бумага и картон. Определение массы»… В несколько этапов, определенными методами, с несколькими пробами, обработать результаты по спецметодике…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.

ГОСТ 34

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

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

ГОСТ 19

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

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

IEEE STD 830-1998

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

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

1. Введение

• 1. Назначение
• 2. Область действия
• 3. Определения, акронимы и сокращения
• 4. Ссылки
• 5. Краткий обзор

• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователя
• 4. Ограничения
• 5. Допущения и зависимости

• 1. Требования к внешним интерфейсам
  • 1. Интерфейсы пользователя
  • 2. Интерфейсы аппаратного обеспечения
  • 3. Интерфейсы программного обеспечения
  • 4. Интерфейсы взаимодействия
• 2. Функциональные требования
• 3. Требования к производительности
• 4. Проектные ограничения (и ссылки на стандарты)
• 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
• 6. Другие требования

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

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

• Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
• Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
• (читать вместе с комментариями)
• Примеры ТЗ и другой документации по разработке АС для МЭР
• ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
• Шаблоны документов для бизнес-аналитиков из