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

Стандарты и шаблоны для ТЗ на разработку ПО

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

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

Придется сделать такую статейку самому… И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification): • Гост 34 • Гост 19 • IEEE STD 830-1998 • ISO/IEC/ IEEE 29148-2011 • RUP • SWEBOK, BABOK и пр.

Содержание

Гост 34
Гост 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр
А как же agile?
Заключение
Договор на разработку технического задания
Исполнитель Заказчик
Related Posts via Categories
Составление технического задания по 44-ФЗ: особенности и правила
Что такое техническое задание и где оно используется
Правила формирования технического задания
Особенности подготовки технического задания
Антимонопольное законодательство
Техническое задание на разработку приложения
1 шаг. Идея разработки мобильного приложения
2 шаг. Вопросы, с которых начинается ТЗ
3 шаг. Настало время ТЗ!
Начните прямо сейчас!
📹 Видео

Гост 34

Гост 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно Гост 34 техническое задание должно включать следующие разделы: 1. Общие сведения 2. Назначение и цели создания (развития) системы 3. Характеристика объектов автоматизации 4. Требования к системе 5. Состав и содержание работ по созданию системы 6.

Порядок контроля и приемки системы 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие 8. Требования к документированию 9.

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

Гост 19

“Гост 19.

ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.

Согласно Гост 19.201-78 Техническое задание, требования и оформлению техническое задание должно включать следующие разделы:

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

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании: Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS.

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

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

2. Общее описание

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

Детальные требования (могут быть организованы по разному, н-р, так)

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

4. Приложения 5.

Алфавитный указатель

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

https://www.youtube.com/watch?v=P4N0KFosotI

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

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований: • System requirements specification (SyRS) • Software requirements specification (SRS) System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека.

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

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

1. Назначение системы
2. системы (границы системы)
3. Обзор системы
- 1. системы
- 2. Функции системы
- 3. Характеристики пользователей
4. Термины и определения

2. Ссылки 3. Системные требования

1. Функциональные требования
2. Требования к юзабилити
3. Требования к производительности
4. Интерфейс (взаимодействие) системы
5. Операции системы
6. Состояния системы
7. Физические характеристики
8. Условия окружения
9. Требования к безопасности
10. Управление информацией
11. Политики и правила
12. Требования к обслуживанию системы на протяжении ее жизненного цикла
13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3) 5. Приложения

1. Предположения и зависимости
2. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в Гост 19, а по структуре очень напоминает SRS из стандарта IEEE 830. SRS может содержать следующие разделы: 1.

Введение

1. Назначение
2. (границы)
- 3. Обзор продукта
- 1. Взаимодействие продукта (с другими продуктами и компонентами)
- 2. Функции продукта (краткое описание)
- 3. Характеристики пользователей
- 4. Ограничения
4. Термины и определения

2. Ссылки 3. Детальные требования

1. Требования к внешним интерфейсам
2. Функции продукта
3. Требования к юзабилити
4. Требования к производительности
5. Требования к логической структуре БД
6. Ограничения проектирования
7. Системные свойства ПО
8. Дополнительные требования

1. Предположения и зависимости
2. Аббревиатуры и сокращений

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

RUP

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт. • Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases): 1. Введение.

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

2. Обзор системы

1. Обзор вариантов использований.
2. Предположения и зависимости.

3. Детальные требований

1. Описание вариантов использования.
2. Дополнительные требования.
3. Другие функциональные требования.
4. Нефункциональные требования.

4. Вспомогательная информация.

Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.

SWEBOK, BABOK и пр

SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр.

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

А как же agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места. Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Заключение

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

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

https://www.youtube.com/watch?v=QPy9yGcXAi0

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

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

Видео:ТОП-9 советов как написать техническое задание? (ТЗ или техзадание за 9 шагов)Скачать

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

ДОГОВОР

НА РАЗРАБОТКУ ТЕХНИЧЕСКОГО ЗАДАНИЯ

№ 1

Санкт-Петербург

«31» декабря 2014 г.

Общество с ограниченной ответственностью «Компания 1» (сокращенное наименование ООО«Компания 1»), именуемое в дальнейшем Заказчик, в лице генерального директора Братчикова Станислава Вячеславович, действующего на основании Устава, с одной стороны, и Общество с ограниченной ответственностью «Компания 2» (сокращенное наименование ООО «Компания 2»), именуемый в дальнейшем Исполнитель, в лице генерального директора Иванова Ивана Ивановича, действующего на основании Устава, с другой стороны (далее по тексту договора по отдельности именуемые – «Сторона», а совместно – «Стороны»), заключили настоящий Договор (далее по тексту – «Договор») о нижеследующем:

1. ПРЕДМЕТ ДОГОВОРА

1.1.

Заказчик поручает и оплачивает, а Исполнитель обязуетсясогласно требованиям Заказчика разработать Техническое задание на разработку системы X (далее СX) согласно серверной архитектуре указанной в Приложении №1, включающее: web-сайт системы, программный комплекс системы мониторинга, взаимодействие модулей системы, интеграция с внешними системами, мобильные приложения под Android, iOS.

1.2. Перечень и стоимость работ представлены в Приложении № 3 к настоящему Договору.

2. ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТ

2.1. Исполнитель приступает к выполнению работ после подписания Заказчиком настоящего Договора.

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

2.3. Обязательства Исполнителя по Договору считаются выполненными после подписания Сторонами Акта сдачи-приемки работ.

Заказчик в течении 5 (пяти) рабочих дней со дня получения Акта сдачи-приемки работ по настоящему Договору обязан направить Исполнителю подписанный Акт сдачи-приемки работ или мотивированный отказ от приемки работ.

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

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

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

2.6. Договор считается выполненным после подписания Актов сдачи-приёмки работ.

2.7. Акт сдачи-приёмки работ предоставляется Заказчику в течение 5 (Пяти) рабочих дней с момента предоставления Исполнителем результатов работ.

2.8. Если в течение 5 (пяти) рабочих дней с момента получения Акта сдачи-приёма, данный Акт не будет подписан Заказчиком, и не будут отправлены в адрес Исполнителя мотивированные возражения, работы считаются выполненными надлежащим образом и принятыми.

2.9. Право собственности на результат работ, выполненных Исполнителем, становится собственностью Заказчика, в момент подписания Сторонами Акта сдачи-приемки работ.

2.10. Вместе с подписанным Сторонами Актом сдачи-приемки работ, Заказчик получает от Исполнителя все необходимые материалы, которые являются результатом проведения работ Исполнителем.

3. Стоимость работ и порядок оплаты

3.1 Сумма настоящего Договора соответствует Перечню и стоимости работ, указанных в Приложениях № 2,3, и включает в себя сумму НДС 18%.

3.2 Оплата работ по Договору производится на условиях 100% постоплаты в течение не более 5 рабочих дней со дня подписания Заказчиком Акта сдачи-приемки работ.

3.3 В платёжных документах сумма НДС (18%) выделяется отдельной строкой.

3.4 В случае просрочки оплаты счета Заказчиком, срок исполнения работ по настоящему Договору увеличивается на соответствующее число дней просрочки.

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

4. СРОК ДЕЙСТВИЯ ДОГОВОРА

4.1. Настоящий Договор вступает в силу с момента подписания и действует до исполнения Сторонами принятых на себя обязательств.

5. ОТВЕТСТВЕННОСТЬ СТОРОН

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

5.2. За просрочку оплаты Исполнитель вправе потребовать от Заказчика уплатить неустойку в размере 0,1% от неуплаченной суммы за каждый день просрочки, но не более 10% от размера неуплаченной суммы.

5.3. За неисполнение работ в срок Заказчик вправе потребовать от Исполнителя неустойку в размере 0,1% от стоимости настоящего Договора за каждый день просрочки, но не более 10% от стоимости настоящего Договора.

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

5.5. Оплата неустойки не освобождает Сторону от исполнения обязательств по настоящему Договору.

6. КОНФИДЕНЦИАЛЬНОСТЬ

6.1.

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

6.2. Обязательства конфиденциальности продолжают действовать в течение 1 (Одного) года после истечения срока данного Договора на предоставление услуг.

7. ФОРС-МАЖОР

7.1. Исполнитель не несет ответственности за частичное невыполнение своих обязанностей по настоящему Договору, если оно явилось последствием обстоятельств непреодолимой силы.

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

Также Исполнитель не несет ответственности за работоспособность средств связи Заказчика.

8. ПРОЧИЕ УСЛОВИЯ

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

Оставшиеся неурегулированными разногласия передаются на рассмотрение Арбитражного суда Санкт-Петербурга и Ленинградской области на основании ГПК РФ или АПК РФ на русском языке и на основании настоящего Договора.

8.2. Недействительность какого-либо из условий Договора не влечет за собой недействительности всего Договора в целом.

9. РЕКВИЗИТЫ СТОРОН

ИСПОЛНИТЕЛЬООО «Компания 1»ИННКППИндекс, Страна, Город,АдресОГРНр/счв Ст.-Петербургском ф-леОАО «банк» г.Санкт-ПетербургБИКК/с_____________________/ Петров П.П. М.П.

ЗАКАЗЧИКООО «Компания 2»ИННКППИндекс, Страна, Город,АдресОГРНр/счв Ст.-Петербургском ф-леОАО «банк» г.Санкт-ПетербургБИКК/с______________/ Иванов И.И. М.П.

Приложение N1 к Договору

№ 1 от «31»декабря 2014 года

Архитектура системы X

Описание…

Исполнитель Заказчик

________________/ Петров П.П. ______________/ Иванов И.И.

М.П. М.П.

Приложение N2 к Договору

№ 1 от «31»декабря 2014 года

Описание компонентов архитектуры системы указанной в Приложении №1

База данных – в качестве СУБД используется MySQL.
Модуль безопасности – данный компонент обеспечивает авторизацию и аутентификацию пользователей в системе. В модуль входит такие сущности как «Роли», «Пользователь», «Права». Модуль имеет только локальный API, для обеспечения доступа к нему только локальным подсистемам.
Модуль оповещения – данный компонент обеспечивает посылку сообщений пользователям, платежным системам и т.д. Поддерживает протоколы E-mail, SMPP, SMTP, HTTP. Модуль имеет только локальный API, для обеспечения доступа к нему только локальным подсистемам.
Аналитика и отчеты – компонент обеспечивает подготовку и демонстрацию отчетов. Анализ данных, поиск зависимостей, поиск аномалий и т.д. Оповещение администрации об аномалиях. Модуль имеет только локальный API, для обеспечения доступа к нему только локальным подсистемам.
Web приложение – компонент обеспечивающий связь пользователя и функциональными компонентами. Получает запросы по протоколу HTTP, обрабатывает их, при необходимости обращается к функциональным компонентам, формирует ответ и отправляет его по HTTP. Состоит из разделов, которые соответствуют функциональным компонентам.
Интеграция – компонент обеспечивает передачу финансовой информации в 1С-Бухгалтерию на уровне проводок.
Сервер приложений – .
Web сервер-1 – Apache
Web сервер-2 – Apache
CMS – сайт компании, включает в себя новости, блог и т.д. Используется язык PHP, framework yii.
CMS DB – Maria DB

Видео:Техническое задание и другие права заказчика по Закону № 223-ФЗСкачать

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

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

Что такое техническое задание и где оно используется

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

Термин «техническое задание» — не единственно возможный, а лишь наиболее часто используемый. Другие допустимые названия: «техническая часть», «спецификация», «проектно-сметная документация» и т.п. Федеральный закон от 5.04.2013 № 44-ФЗ раздел документации о закупке, в котором заказчик описывает объект закупки, определяет как «описание объекта закупки».

Независимо от употребляемого термина, важно, чтобы требования к закупаемым товарам, работам и услугам были конкретными, понятными и не противоречили законодательству — 44-ФЗ, 223-ФЗ и 135-ФЗ.

Техническое задание используется:

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

В соответствии с ч. 2 ст. 33 Федерального закона от 05.04.2013 № 44-ФЗ в техническом задании должны быть указаны показатели, позволяющие определить соответствие закупаемых товаров, работ, услуг установленным заказчиком требованиям. При этом указываются максимальные и (или) минимальные значения таких показателей, а также значения показателей, которые не могут изменяться.

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

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

Эксперт по тендерам и ведущий вебинара «Правила составления технических заданий в рамках закона 44-ФЗ и требования к их содержанию» Олег Бируля рассказывает, на что заказчику следует обратить внимание при составлении технического задания:

Особенности подготовки технического задания

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

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

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

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

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

https://www.youtube.com/watch?v=PxeKoAO1QJ4

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

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

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

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

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

Есть ряд исключений, когда слова «или эквивалент» не пишутся:

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

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

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

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

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

Поставляемый товар должен быть новым.

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

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

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

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

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

https://www.youtube.com/watch?v=g7OApqc5d2Y

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

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

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

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

Специфические вопросы регулируют другие законы. Так, например, при закупке пищевых продуктов госзаказчик должен ориентироваться на Федеральный закон от 02.01.2000 №29-ФЗ. Особенности описания объектов закупок по государственному оборонному заказу могут устанавливаться Федеральным законом от 29.12.2012 № 275-ФЗ.

Антимонопольное законодательство

В ст. 17 Федерального закона от 26.07.2006 № 135-ФЗ говорится, что при проведении торгов, запроса котировок цен на товары, запроса предложений запрещаются действия, которые приводят или могут привести к недопущению, ограничению или устранению конкуренции. Это следующие действия:

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

Видео:Техническое задание в госзакупкахСкачать

Техническое задание на разработку приложения

ТЗ на разработку — а оно нам надо?

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

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

Он тоже заинтересован в успехе вашего сотрудничества.

1 шаг. Идея разработки мобильного приложения

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

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

И если вам удастся найти эту прореху в нише, заполняйте ее смело и не теряйте драгоценных секунд — конкуренты не дремлют.

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

Возможно, что-то вы сможете сделать сильно лучше, и как итог — переманить клиентов у конкурентов.

2 шаг. Вопросы, с которых начинается ТЗ

Чтобы составить ТЗ, для начала нужно ответить на несколько вопросов:1. Для кого это приложение? Для ваших клиентов, будущих или потенциальных, или для всех сразу? Или для ваших сотрудников?2.

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

В устройствах каких марок вы планируете поселить ваше приложение? От этого зависит, какую платформу для приложения вы выберите — iOS, Android, Windows.5. Когда вы хотите получить готовое приложение? То есть сроки.6.

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

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

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

3 шаг. Настало время ТЗ!

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

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

1. Терминология.

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

2. Цель создания системы, то есть приложения. Здесь вы подробно описываете, что пользователь сможет делать в приложении, какие действия и какой результат он получает. В общем, для чего ваше приложение будут скачивать люди в свои смартфоны. Если у вас приложение для магазина, то вы должны решить, к примеру —пользователь будет просто просматривать каталоги, узнавать о наличии товаров в магазинах или сразу покупать и заказывать доставку?
3. Требования к приложению. Самая сложная часть техзадания, где технические термины льются как из рога изобилия. Написать это самому нереально. Но важно понимать, что каждый шаг будущего пользователя должен быть продуман до технических мелочей. К примеру, из тз должно быть четко ясно, что случится, если нажать на вот эту красную кнопочку.
4. Сценарии использования. Что происходит, когда человек впервые заходит в приложение? Нужно ли регистрироваться? А что произойдет, когда он зайдет повторно? Все эти пути важно описать в тз, ведь это поможет выявить, какие функции нужны приложению и что именно должно в нем происходить.
5. Описание экранов. Некоторые тз содержат прототипы экранов, если они уже готовы. В некоторых есть даже первичный дизайн. В любом случае описать экраны хотя бы словами просто необходимо. Ведь для многих пользователей приложение – это и есть экран. Именно с ним он имеет дело, и что толку от функции регистрации, к примеру, если ни на одном экране нет такой кнопки?
6. Требования к платформе, CMS, архитектура системы… и еще много страшных слов, если вы не разработчик или технический писатель.
Ваше ТЗ может не содержать тех или иных разделов только в том случае, если это не существенно именно для вашего проекта. Но узнать, что именно существенно, а что нет, вы сможете только от разработчика.

Начните прямо сейчас!

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

А значит, в составлении ТЗ должны принимать участие обе стороны и… та-дам! Основные технические трудности мы берем на себя!
Как говорится, глаза боятся — а руки-то вот они. Тут важно начать. Часто, это главная заминка в начале успешного проекта.

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