Posted  by  admin

Образец Технического Задания На Разработку Программы

Технического Задания на программное обеспечение. Входное тестирование: Разработка ТЗ на простую программу/приложение/веб-сервис. Техническое задание на программу (ПО). Техническое задание (ТЗ) — исходный документ,который является основанием для разработки и испытания программы или автоматизированной системы. Техническое задание на программу и программное обеспечение разрабатывается в соответствии с требованиями ГОСТ 19.201-78. Основанием для разработки ТЗ чаще всего является договор. ТЗ на программу разрабатывается, прежде всего, для тех людей, которые в последствии будут разрабатывать программный продукт.

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

Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):. ГОСТ 34. ГОСТ 19. IEEE STD 830-1998.

ISO/IEC/ IEEE. RUP. SWEBOK, BABOK и пр. ГОСТ 34 регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы. Согласно ГОСТ 34 техническое задание должно включать следующие разделы: 1. Общие сведения 2.

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

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

Этот стандарт относится к разработке именно ПО. Согласно техническое задание должно включать следующие разделы: 1. Основания для разработки; 3. Назначение разработки; 4. Требования к программе или программному изделию; 5.

Требования к программной документации; 6. Технико-экономические показатели; 7. Стадии и этапы разработки; 8. Порядок контроля и приемки; 9.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. IEEE STD 830-1998 Достаточно хорошее определение стандарта дано в самом его описании: Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS. Данная рекомендуемая методика имеет своей целью установление требований к разрабатываемому программному обеспечению, но также может применяться, чтобы помочь в выборе собственных и коммерческих программных изделий. Согласно стандарту техническое задание должно включать следующие разделы: 1.

Введение. 1. Назначение. 2. Область действия. 3.

Пример Технического Задания На Разработку Программы 1с

Определения, акронимы и сокращения. 4.

Краткий обзор 2. Общее описание. 1. Взаимодействие продукта (с другими продуктами и компонентами). 2.

Функции продукта (краткое описание). 3.

Характеристики пользователя. 4. Ограничения. 5. Допущения и зависимости 3. Детальные требования (могут быть организованы по разному, н-р, так).

1. Требования к внешним интерфейсам. 1. Интерфейсы пользователя.

2. Интерфейсы аппаратного обеспечения. 3. Интерфейсы программного обеспечения. 4. Интерфейсы взаимодействия. 2.

Функциональные требования. 3. Требования к производительности. 4. Проектные ограничения (и ссылки на стандарты).

5. Нефункциональные требования (надежность, доступность, безопасность и пр.). 6. Другие требования 4.

Шаблон Технического Задания На Разработку Программы

Приложения 5. Алфавитный указатель На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который., правда, на англ. Мне же больше нравится, который я использую при разработки ТЗ для коммерческих компаний. И вообще дедушка Вигерс предоставляет (куда идут деньги при покупке этих рекомендаций, читайте в начале красным). Ну а вы уже несколько раз, надеюсь, перечитали. ISO/IEC/ IEEE обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения.

Он приходит на смену стандартов 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. Системные требования. 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. Детальные требования. 1. Требования к внешним интерфейсам. 2.

Функции продукта. 3. Требования к юзабилити.

4. Требования к производительности. 5. Требования к логической структуре БД. 6.

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

Приложения. 1. Предположения и зависимости.

2. Аббревиатуры и сокращений Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ. RUP Структура SRS в представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований. Адаптирован из стандарта IEEE STD 830 и содержит два варианта:. Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт. Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases): 1.

Краткая сводка возможностей. Определения, акронимы и сокращения. Краткое содержание. Обзор системы. 1.

Обзор вариантов использований. Предположения и зависимости. Детальные требований. 1. Описание вариантов использования. Дополнительные требования. Другие функциональные требования.

Нефункциональные требования. Вспомогательная информация. SWEBOK, BABOK и пр., а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты. Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией. А как же Agile? Я скажу одной фразой из: “Working software over comprehensive documentation”.

Поэтому в Agile документации отводится совсем мало места. Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile. Заключение Как говорится, каждому проекту свое техническое задание.

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

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

(читать вместе с комментариями). для МЭР. Шаблоны документов для бизнес-аналитиков из Автор: bas.

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

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

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

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

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

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

Разработать план последовательности действий;. Не принять предложение вовсе или отказаться от тех работ, которые не указаны в ТЗ или их невозможно выполнить. С обеих сторон:. Сократить количество неточностей и ошибок;. Прийти к общему виду готового объекта;. Совершить согласование работ после каждого пункта. Заказчик всегда несет ответственность за достоверность данных, которые были предоставлены им при составлении технического задания.

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

Экономические данные;. Порядок приемки работ и сдачи всего заказа. Кроме этого в ТЗ могут добавляться пункты о подготовке и вводе в эксплуатацию, индивидуальные требования, не противоречащие стандартным нормам. Обратите внимание! Если индивидуальные разработки позволят улучшить показатели эффективности объекта, то их нужно согласовать с Госстандартом РФ и получить разрешение на применение. Но здесь речь не идет о тех требованиях, которые касаются охраны здоровья и природы, а также отвечают за безопасность – их менять нельзя! Структура и состав документа будут утверждаться на основе типа проектируемой продукции.

Пример технического задания на проектирование (реконструкция объекта незавершенного строительства) Образец формы Для наглядности мы представили образец технического задания на проектирование сооружения. № Перечень требований и основных данных Описание 1. Основа для создания и проектирования Целевая программа на федеральном уровне Программа субъектов РФ Программа муниципалитетов Создание по решению Президента РФ, правительства РФ и других уполномоченных органов По инициативе компании-застройщика 2. Разновидность постройки Новое строение Реконструируемое Предназначенное для капитального ремонта или текущего 3. Этапы проектирования Здесь перечисляются стадии работ по проектированию: создание проекта требуемая документация рабочий макет эскизный макет и т.д. Рассматриваемые варианты работ Прописывается информация о работах для сравнения или проводимых конкурсах по выбору проектных решений 5. Финансовые источники Средства из федерального бюджета Регионального Муниципального Внебюджетные средства 6.

Условия работ, требующие особого внимания Описать такие условия или дать рекомендации по их преодолению 7. Технические параметры объекта Предоставляется подробная информация о возможностях здания, назначения, технических характеристиках (этажность, кол-во подъездов) и т.д. Все что требуется для понимания социально- экономической значимости 8. Данные по встроенным помещениям Если площади жилых домов планируется частично отдать под общественные или другие организации, то этот пункт нужно заполнить 9. Качественные показатели здания, говорящие об экологической безопасности, конкурентоспособности и целесообразности Здесь указываются все данные о постройке технически значимых объектов производства, размещения его отдельных блоков, технологии их постройки, расстановки оборудования 10.

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

Требования по предоставлению условий для отдельных групп граждан Данные по элементам конструкций, предназначенных для инвалидов, стариков и детей. Требования по безопасности и охране труда Расписываются материалы по теме охраны труда и здоровья работников будущего строения. Подходит для зданий промышленного назначения. Требования по санитарно- эпидемиологическим нормам Описать документы для проверяющих организаций: Роспотребнадзор, СЭС и т.д. Требования по противопожарной безопасности Описание соответствия номам пожарной безопасности 19. Требования по материалам для демонстрации Заполняется в случае использования 3D макетов и презентаций 20. Дополнительные требования Специальные требования, внесенные самим заказчиком по необходимости, но в рамках существующих норм В соответствии с этим образцом можно создать техническое задание для любого проекта, добавив или исключив какие-то пункты.