###
  • Интернет
  • Программы
  • Игры
  • Проблемы
  • Windows
  • Социальные сети
  • Android
  • Ios

    • Обоснование технического задания. Стандарты и шаблоны для тз на разработку по

    08.09.2019 Android

    Вопрос «Нужно ли вообще составлять техническое задание (ТЗ)?» может возникать только у тех, кто никогда в жизни не заказывал разработку сайта, поскольку необходимость в нём возникает после первого же общения заказчика с исполнителем.

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

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

    Из чего состоит ТЗ?

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

    Общие сведения (описание)

    Здесь указываются:

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

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

    • Подготовительный этап;
    • Проработка концепции сайта;
    • Проектирование;
    • Создание дизайн-макета;
    • Разработка дизайна страниц;
    • Вёрстка;
    • Программирование;
    • Наполнение контентом;
    • SEO-оптимизация;
    • Тестирование;
    • Запуск.

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

    Назначение и цели

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

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

    • Реклама и привлечение новых клиентов;
    • Поддержка заказчиков и партнёров;
    • Демонстрация выполненных работ;
    • Ознакомление со списком услуг;
    • Создание и поддержание имиджа компании.

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

    Целевая аудитория . Кто будет пользоваться сайтом, для кого он создаётся?

    • Веб-мастера, блогеры;
    • Владельцы интернет-магазинов;
    • Владельцы информационных порталов;
    • Рекламные студии;
    • Представители присутствующих в онлайн-пространстве фирм и компаний.

    Требования

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

    Тип . К какой категории принадлежит веб-ресурс?

    • Посадочная страница;
    • Сайт-визитка;
    • Корпоративный сайт;
    • Информационный портал;
    • Интернет-магазин.

    Требования к оформлению . Они могут быть следующего вида:

    • Сайт должен быть минималистичным и при этом отражать род деятельности компании.
    • Основные цвета: зелёный и белый, по брендбуку или на усмотрение дизайнера.
    • В оформлении нельзя использовать анимацию, всплывающие окна, Flash-элементы, дизайнерские излишества.
    • Нельзя использовать шрифты с засечками (можно применять стандартные: Verdana, Arial, Tahoma и т. д.). Кегль должен обеспечивать максимальное удобство чтения (12-16 пт.).

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

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

    • Русский;
    • Английский;
    • Эсперанто.

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

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

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

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

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

    Структура и навигация . Какие разделы, подразделы и отдельные страницы будет содержать проект?

    • Главная страница
    • Услуги
    • Копирайтинг
    • Рерайтинг
    • SEO-коперайтинг
    • Корректура
    • Транскрибация
    • Контент-менеджмент
    • Контент-маркетинг
    • Портфолио
    • О нас
    • Контакты

    Сделайте и краткое описание каждой страницы, дайте определения. Например, что подразумевается под страницей «Контакты»? Она должна содержать адрес, телефон и электронную почту в текстовом виде? Или там должна присутствовать форма обратной связи? А может, нужно встроить код Яндекс Карт? Или же на странице контактов должно размещаться всё перечисленное, да ещё и ссылки на представительства в социальных сетях?

    Желательно контент или хотя бы его наброски приготовить еще до начала работ с подрядчиком. Это будет способствовать более эффективной коммуникации.

    Дополнительные требования . Всё, что не вошло в другие пункты раздела.

    Описание разделов сайта

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

    Главная страница . Формулировка задачи может быть в следующем виде.

    Основная часть главной страницы должна быть выполнена в виде Landing Page . На ней сверху вниз должны располагаться следующие элементы:

    • Шапка - логотип, название фирмы;
    • Меню навигации;
    • Информация об акциях и скидках;
    • Кнопка заказа;
    • Рекламный текст;
    • Блок с пятью лучшими работами и ссылкой на раздел портфолио;

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

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

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

    Твой мир пуст...

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

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

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

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

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

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

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

    Задачи статьи:

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

    История

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

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

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

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

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

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

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

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

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

    Выводы

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

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

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

    Примечание от 10.05.2014 г. - Но не все так печально Если действовать с умом, то можно запросто прогнуть любого заказчика, см. и.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Военная мудрость

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

    Примечания:

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

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

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

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

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

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

    Практические приемы

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

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

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

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

    Детализация

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

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

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

    Для системы приводят требования к применению в системе, языков взаимодействия и технических средств системы, а также требования к и декодированию, к языкам -, средствам описания (объекта автоматизации), к способам организации [из п. 2.6.3.3 ГОСТ 34.602-89]

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

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

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

    (текст требования)

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

    (текст требования)

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

    (текст требования)

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

    (текст требования)

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

    (текст требования)

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

    (текст требования)

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

    (текст требования)

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

    (текст требования)

    Увеличился объем технического задания? А стоит ли экономить бумагу? Имеется и еще одна военная мудрость, как бы грубо и двусмысленно она ни звучала: «больше бумаги - чище з@@@@ца». Требования к лингвистическому обеспечению стали выглядеть понятнее?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Уходят от вас...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Итак, пример.

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

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

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

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

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

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

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

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

    Случай первый.

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

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

    Случай второй.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    2.1.2.2 Назначение

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

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

    2.1.2.3 Состав

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

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

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

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

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

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

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

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

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

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

    • прежде всего - . Для таким является;
    • , например и;
    • , например;
    • и, например;
    • ряд других.

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

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

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

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

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

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

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

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

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

    Заключение

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

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

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

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

    Заказать ООО «Техническая документация» можно по эл. почте admin @ tdocs . su (без пробелов), тел. 8-910-468-09-28 или в форме.

    Copyright © ООО «Техническая документация» 2018. Заимствуйте наши материалы с блеском! При воспроизведении материалов портала обязательна установка активной гиперссылки на источник - страницу с этой публикацией на сайт.

    От автора : Как написать техническое задание на разработку сайта ? Тема достаточно обширная, и в рамках одной статьи ее сложно разобрать на все 100% (если вообще это возможно). Но общие положения, то, что нужно учесть, на что следует обратить внимание при составлении ТЗ, я постараюсь достаточно подробно изложить в данной статье.

    Итак, ТЗ

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

    Давайте проанализируем такой пример:

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

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

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

    Что мы имеем. Исполнитель пункт ТЗ выполнил, а вы хотели совсем другой календарь. Вроде все в соответствии с ТЗ, никто не виноват, до конфликта не дошло, но самое главное потеряны время и деньги .

    Это пример всего-то банального календаря.

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

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


    Из каких пунктов обычно состоит ТЗ?

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

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

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

    Поехали по пунктам.


    Описание сайта

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

    для кого – целевую аудиторию сайта :

    • потенциальные покупатели
    • продавцы продукции (магазины, интернет-магазины)
    • сервисные центры
    • партнеры (фирмы)
    • потребители продукции (тот, кто уже купил)

    Для чего нужен сайт :

    • Для повышения имиджа компании
    • Для увеличения продаж
    • Для удобства клиентов

    Тип сайта :

    • Корпоративный
    • Сайт – визитка
    • Интернет магазин

    Языковые версии :

    • Английский
    • Русский


    Сайт должен решать какие-то задачи. Соответственно далее двигаемся по целям и задачам сайта.

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

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

    Потенциальные покупатели продукции .

    Цель : привлечь больше покупателей и убедить сделать первую покупку, помочь сделать выбор.

    Необходимо решить задачи :

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

    • Дать информацию о салонах-магазинах
    • Дать информацию о розничной торговой сети

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

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


    Теперь перечисляем модули сайта.

    Функционал сайта

    Для того чтобы перечислить функционал сайта, нужно решить что ему необходимо:

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


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

    Описание функционала сайта

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

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

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

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

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

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

    О компании

    • история компании
    • контакты
    • отзывы

    Новости

    • события
    • акции
    • новое на сайте

    Продукция

    • каталог продукции
    • релизы
    • отзывы о продукции

    Сервис

    • служба сервиса
    • гарантийное обслуживание
    • послегарантийное обслуживание

    Потребителю

    • покупка и доставка
    • пользование
    • о сервисе

    Магазинам и интернет магазинам

    • фотографии продукции
    • Часто задаваемые вопросы

    Сервисным центрам

    • Как стать сервисным центром
    • Часто задаваемые вопросы

    Партнерам

    • приглашение к сотрудничеству
    • часто задаваемые вопросы


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

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


    Главное теперь описать логику работы.

    Логика работы

    Я описывать буду исходя из рисунка выше.

    Верхняя часть сайта остается неизменной на каждой странице сайта. Новостная лента видна только на главной странице. На второстепенных страницах слева показываем подпункты меню того пункта, в котором в данный момент находимся (например если мы на странице «служба сервиса», то показываем ссылки на «гарантийное обслуживание», «послегарантийное обслуживание»). Соответственно и переходы по этим ссылкам ведут на соответствующие страницы. Здесь же, под подпунктами слева отображаем данные для связи с он-лайн консультантами (Skype, ICQ). Блок акции и релизы остаются на каждой странице. Подвал сайта отображается один и тот же на каждой странице.

    Примерно так описывается общая логика работы.

    Теперь подробно описываем каждый блок. Например «Новостная лента».

    «Новостная лента» из 10-ти последних новостей. Каждая новость должна состоять из заголовка новости, даты публикации, краткого начала новости (4-5 строк) и ссылки «читать полностью». При нажатии на ссылку «читать полностью» попадаем на страницу новостей. Новость, на которую попали, отображается на месте основного содержимого. Включает также заголовок новости, дату публикации. Слева так же отображается новостная лента. Новости за прошлые месяцы и года попадают в архив. То есть под новостями за текущий месяц отображаем «архив за (такой-то месяц или год)». При нажатии на ссылку «архив за (такой-то месяц или год)» вниз выпадает список новостей за соответствующий месяц/год.

    Примерно так описываем работу каждого блока. Не забываем про случай с календарем. И самое главное нужно расписать работу каталога товара. Здесь я даю вам задание : попробуйте продумать и описать, как будет работать каталог. Свои варианты присылайте на e-mail. Лучший мы опубликуем.


    Что еще должно быть? Неплохо было бы указать совместимость.

    Совместимость

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

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


    Заключение

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

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

    И не забывайте про задание!

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

    Что такое техническое задание

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

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

    Его применяют в своей работе строители, мастера, выполняющие ремонтные работы, программисты, дизайнеры и многие другие специалисты.

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

    Особенности техзадания

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

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

    Назначение технического задания

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

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

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

    Состав ТЗ: требования к функциональности

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

    Образцом требований различных видов становится большинство ГОСТов. Они регулируют процесс составления ТЗ для строительства крупных объектов и других ответственных работ. В них обычно перечисляют такие требования:

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

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

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

    Характеристика требований

    В отличие от многочисленных видов требований, свойств для их характеристики намного меньше:

    • Понятность.
    • Конкретность.
    • Тестируемость.

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

    Техническое задание - это не технический проект

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

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

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

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

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

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

    Как правило, вначале, в вводной части, излагают цель и назначение проекта. Далее следует перечисление разделов, требований и их расшифровка. Чтобы понять, как выглядит ТЗ для автоматизированной системы, можно рассмотреть структуру, рекомендуемую ГОСТом 34.602-89:

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

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

    Зачем составлять ТЗ для ремонта комнаты

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

    По этой причине техническое задание на ремонт становится одним из важнейших этапов, так как позволяет:

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

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

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

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

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

    2. Характеристика пола: объем работ, которые нужно выполнить на этом участке. Здесь можно подробно указать, что именно необходимо выполнить мастерам:

    • Демонтировать пришедшее в негодность покрытие, плинтуса и черновые полы (тип и квадратура).
    • Нанести выравнивающую, разделительную стяжку и термоизоляцию (площадь и высота материалов).
    • При необходимости установить систему «теплый пол» (тип и высота конструкции).
    • Нанести стяжку над нагревательными кабелями (около 30-50 мм).
    • Подготовить поверхность к укладке плитки, ламината, ковролина или другого материала (характер расположения элементов).
    • Установить плинтус (указывают количество погонных метров, а также все внутренние и внешние уголки).

    3. Работы с потолком:

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

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

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

    5. Параметры окна:

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

    6. Характеристики двери:

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

    7. Работы с электрическими сетями:

    • Перечень работ (установка, замена,
    • Необходимость прокладки телефонных или интернет-кабелей.
    • Приложить схему.

    8. Мероприятия по монтажу отопительных систем и кондиционеров:

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

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

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

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

    При обследовании комнаты обращают внимание на главные параметры и выполняют следующие действия:

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

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

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

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

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

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

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

    Общие положения

    Техническое задание оформляют на листах формата А4 и/или А3, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
    Для внесения изменений и дополнений в техническое задние на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
    Техническое задание должно содержать следующие разделы:
    • наименование и область применения;
    • основание для разработки;
    • назначение разработки;
    • технические требования к программе или программному изделию;
    • технико-экономические показатели;
    • стадии и этапы разработки;
    • порядок контроля и приемки;
    • приложения.
    В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них.

    Раздел: Наименование и область применения

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

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

    • документ (документы), на основании которых ведется разработка;
    • организация, утвердившая этот документ, и дата его утверждения;
    • наименование и (или) условное обозначение темы разработки.
    Например, Применительно к специфике учебного процесса основанием может служить задание на курсовое проектирование, приказ по институту от __.__. за N ___., договор __.__. за N ___., и т.п.

    Раздел: Назначение разработки

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

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

    Раздел: Технические требования к программе или программному изделию

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

    Раздел:Требования к функциональным характеристикам.

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

    Например : Программа должна позволять … вычислять … строить… создавать …

    Исходные данные: текстовый файл с заданной …

    Выходные данные: графическая и текстовая информация - результаты анализа системы…; текстовые файлы - отчеты о … диагностика состояния системы и сообщения о всех возникших ошибках.

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

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

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

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

    С этим пунктом сложностей обычно не возникает. К сожалению, пункт о профессиональности пользователя Заказчиком подразумевается обязательно. Это, конечно, лишний повод придраться к вашей программе. Впрочем, здесь можно ограничиться фразами вида "Условия эксплуатации программы совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК", "Программа должная быть рассчитана на непрофессионального пользователя." и т.п.

    Требования к составу и параметрам технических средств. Указывают необходимый состав технических средств с указанием их технических характеристик.

    Здесь главное – ничего не забыть и все предусмотреть, с одной стороны (а то подсунут какой-нибудь IBM PC/XT с монохромным дисплеем и без мыши), а с другой – не переборщить с повышенными требованиями, иначе Заказчик найдет более покладистого Исполнителя.

    Например: Необходимо наличие IBM PC - совместимого ПК с графическим адаптером EGA (VGA). Необходимое дисковое пространство – не менее 600 Кб, объем свободной оперативной памяти - не менее 400 Кб. Желательно наличие драйвера EMS и манипулятора типа "мышь".

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

    Например: Программа должна работать автономно под управлением ОС MS DOS версии не ниже 3.3. Базовый язык программирования - Turbo Pascal 6.0.

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

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

    Например: Специальных требований к временным характеристикам программы не предъявляется. Специальных требований к емкостным характеристикам программы не предъявляется.

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

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

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

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

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

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

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

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

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

    Oтекст программы;

    Oописание программы;

    Oпрограмма и методика испытаний;

    Oописание применения;

    Oруководство пользователя.

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

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

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

    Oтехнико-экономические показатели;

    Oструктура программы;

    Oформат представления входных данных программы;

    Oобщая схема алгоритма (2 листа);
    oосновные вычислительные алгоритмы;
    oпример работы программы.

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

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

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

    Другие источники разработки.