Как составить тз на разработку проекта

Техническое задание на проектирование дома

Как составить тз на разработку проекта

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

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

Пример проекта здания

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

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

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

Этот документ является основополагающим элементом проекта, а следственно и самого строительства. Этот документ регулирует взаимоотношения между клиентом и исполнителем.

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

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

Плюсы и минусы строительства с проектом

Для начала следует определиться с минусами – их значительно меньше. А точнее – всего два:

  1. Вам придётся потратить приличную сумму на проектирование дома. В некоторых случаях стоимость проекта доходит до 3-5% от стоимости дома, что отпугивает потенциальных владельцев домов;
  2. Когда задание на выполнение работы по составлению проекта передано специалистам, далеко не всегда вы сможете быстро увидеть результат работы. Некоторые компании, не ценя времени своего клиента, могут предоставить готовый проект лишь спустя несколько месяцев.

Готовый проект здания

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

  1. Вы получаете подробный проект с точными размерами нового дом, что позволит выбрать оптимальное расположение на участке.
  2. Благодаря новейшим технологиям, вы получите 3D проект, созданный в компьютерной программе. Вы сможете увидеть весь дом, каким он будет после завершения строительных и отделочных работ. Опытные дизайнеры подберут оптимальные отделочные материалы, что значительно упростит весь процесс закупок.
  3. При наличии проекта вы без труда решите, какое помещение будет выделено под гостиную, какое – под кабинет, а какие – под детские комнаты.
  4. В пояснительной записке будет записано точное количество материалов, которые понадобятся для строительства и отделки нового дома. Поэтому вы с максимальной точностью сможете просчитать сумму, которую придётся потратить при строительстве, что высоко ценится многими опытными людьми.

    Смета по материалам для строительства

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

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

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

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

В Градостроительном кодексе имеется статья №51, в которой сказано – получить разрешение на строительство можно без готового проекта. Так что, только сам застройщик принимает решение – тратить деньги на проект или нет.

Впрочем, здесь есть определённые ограничения.

Площадь дома должна составлять не более 1500 м2, а в самом доме не должно было больше 3 этажей.

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

Как создаётся проект

Проект может создаваться разными способами. Одни будущие владельцы домов предпочитают выполнять всю работу самостоятельно. Насколько это оправданно и допустимо ли это вообще? Об этом будет сказано чуть ниже.

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

Образец договора о сотрудничестве

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

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

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

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

Обычно вопросы могут быть следующими:

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

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

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

Это позволит добиться нескольких преимуществ:

  1. Вы можете получить определённую скидку, так как заказываете у одной компании целый комплекс услуг (при столь значительных затратах даже экономия в 1-2% составит немалую сумму).
  2. При обнаружении каких-то дефектов во время эксплуатации здания, вы точно знаете, кто стал виновником их возникновения, и можете обратиться в суд. Если же проект был разработан одной компанией, а строительством дома занималась другая, высока вероятность, что представители компаний будут валить вину друг на друга, из-за чего крайнего найти будет практически невозможно.

Создаем проект самостоятельно

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

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

Ошибки самостоятельного проектирования дома

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

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

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

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

Профессиональная гидроизоляция фундамента

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

Доверить работу профессионалам

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

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

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

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

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

В него в обязательном порядке входят:

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

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

Первый вариант обойдётся вам значительно дешевле – чаще всего готовый проект можно приобрести, потратив от 20 до 50 тысяч рублей.

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

Пример проекта дома на две семьи

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

В результате придётся мириться с рядом трудностей – вносить изменения в типовой проект никто не согласится, так как для этого придётся производить ряд расчётов и измерений. Всерьёз подумайте! Ведь вы строите дом, в котором проживёте многие годы, а не несколько недель!

И уж точно не стоит пытаться внести поправки самостоятельно – это чревато разрушением дома, если вы не знакомы со всеми тонкостями сопротивления материалов и теоретической механики.

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

Зато, выбирая этот вариант, вы можете требовать, чтобы проект до мельчайших деталей соответствовал вашим требованиям.

Размеры и расположение комнат, количество окон, вид лестниц, расположение розеток, местоположение санузла – всё это будет учтено в соответствии с вашими пожеланиями.

В видео подробно рассказывается о том, как заказать техническое задание на проектирование дома.

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

Теперь, зная о разных вариантах проектирования дома, вы наверняка сможете принять верное решение, сожалеть о котором не придётся.

Источник: https://Proekt-sam.ru/plans/texnicheskoe-zadanie-na-proektirovanie-doma.html

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

Как составить тз на разработку проекта

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

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

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

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

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

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

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

Грамотное общение заказчика и инженеров позволяет найти «золотую середину» по всем значимым параметрам и обеспечить рентабельность объекта.

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

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

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

Порядок разработки ТЗ

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

Основные параметры, которые определяются на самом первом этапе составления ТЗ: площадь, этажность, форма здания, тип фасадов, применяемые материалы, индивидуальные особенности объекта.

Эти параметры включаются в архитектурно-планировочное задание на проектирование.

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

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

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

Примерный состав задания на проектирование

Общие данные.

  • Вид строительства и основание для проектирования.
  • Полное название организаций заказчика и исполнителя.
  • Объем и стадийность выполнения проектных работ.
  • Стадийность строительства.
  • Категория сложности объекта.
  • Перечень особых условий строительства и эксплуатации объекта.
  • Сроки проектирования и строительства.
  • Исходная документация для проектирования.

Требования к проектированию.

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

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

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

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

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

Источник: https://pnproject.ru/stati/razrabotka-tekhnicheskogo-zadaniya-na-proektirovanie

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

Как составить тз на разработку проекта

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

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

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

Гост 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. Допущения и зависимости

3.

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

  • 1. Требования к внешним интерфейсам
    • 1. Интерфейсы пользователя
    • 2. Интерфейсы аппаратного обеспечения
    • 3. Интерфейсы программного обеспечения
    • 4. Интерфейсы взаимодействия
  • 2. Функциональные требования
  • 3.

    Требования к производительности

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

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

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

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

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

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. Дополнительные требования

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

  • 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.

Заключение

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

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

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

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

Источник: https://habr.com/post/328822/

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

Как составить тз на разработку проекта

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

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

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

Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:

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

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

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

Состав задания на проектирование устанавливается с учетом отраслевой специфики и вида строительства.

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

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

«Назад | Вперед »

Источник: http://sevak-world.web-box.ru/construction/tz

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

Как составить тз на разработку проекта

Написание технического задания — один из первых этапов работы над проектом. Он предваряет разработку самой системы.

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

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

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

Мы используем термины «Бизнес-требования» (BRD — Business requirements document), «Функциональные требования» (FRD – Functional requirements document) и Технико-архитектурные требования (TAD – Technical Architecture document).

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

Документ, который мы в большинстве случаев используем для взаимодействия с заказчиками состоит на 70% — из бизнес-требований, на 20% из функциональных требований и только на 10% — из технико-архитектурных требований. Конечно, эта пропорция варьируется в зависимости от специфики и технической сложности системы.

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

Ведь задача аналитиков состоит в том чтобы фактически произвести операцию brain-dump, и результаты расположить на бумаге в структурированном виде.

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

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

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

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

1. Оглавление 2. История изменений документа 3. Участники проекта 4. Назначение документа 5. Терминология

6. Общий контекст

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

В разделе «Терминология» технического задания на баннерную систему мы определяем такие понятия как Показы, Клики, CTR, Охват, Частота контакта, Файл бронирования и т.

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

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

7. Система размещения баннеров
8.

Взаимодействие с биллингом 9. Banner Engine

10. Техническое описание компонента Banner Engine

Самый объемный раздел описываемого нами технического задания – «Система размещения баннеров»; он посвящён ядру разрабатываемой системы и содержит все требования непосредственно к системе управления рекламными местами.

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

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

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

Каждое техническое задание отличается по размеру, числу иллюстраций, количеству версий. Для примера, документ на баннерку представлен на 44 страницах и содержит 15 иллюстраций. Процесс подготовки этого документа занял около месяца и включал около 8 итераций с заказчиком.

Бизнес vs Функциональные требования

В техническом задании регистрируются как бизнес-требования к системе, так и функциональные требования:

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

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

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

Пример бизнес-требования:

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

Пример функционального требования:

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

Обычно мы включаем

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

Правильное техническое задание на разработку программного обеспечения – секрет успешного проекта

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

Название сценария: Создание рекламного места

Роль: Администратор

Пример функционального требования:

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

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

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

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

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

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

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

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

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

Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.

Основные принципы

При написании ТЗ мы стараемся максимально использовать графические материалы для наглядного и сжатого представления информации. Одна диаграмма зачастую в состоянии заменить несколько страниц текста.

В данном контексте, мы видим своей целью т.н. рисование ТЗ, т.е.

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

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

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

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

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

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

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

Опыт в предметной области

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

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

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

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

Источник: https://steptosleep.ru/%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5-%D0%B7%D0%B0%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BD%D0%B0-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%83/

Судебная защита
Добавить комментарий