Как написать техническое задание для программиста образец

Как составить ТЗ для программиста

Как написать техническое задание для программиста образец

Бывает, что сайт уже готов, но нужно добавить на него какую-нибудь программу:

  • онлайн-калькулятор;
  • программу рассылки;
  • анализатор статистики;
  • парсер и так далее.

Или вы хотите создать какой-то уникальный сервис для пользователей.

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

Составление вакансии и ТЗ для программиста

Чтобы оставить объявление о поиске программиста-фрилансера, нужно сузить круг поиска. Для этого пишется объявление такого вида:

Требуется программист, чтобы добавить функцию X на готовый сайт на WordPress.

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

Когда вы определитесь с выбором исполнителя и обговорите все важные моменты, можно отправлять ТЗ. В нем должно быть:

  1. Сроки, обговоренные с исполнителем, и ситуации, когда дедлайн можно подвинуть.
  2. Способ и вариант оплаты. Например, на банковскую карту после принятия заказа.
  3. Штрафы и правки.
  4. Подробное описание того, как вы видите результат работы.
  5. Техническая информация.
  6. Тестирование

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

Желаемый результат

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

Допустим, вам нужен сервис проверки орфографии. Опишите все ваши представления:

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

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

Техническая информация

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

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

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

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

«Информационная безопасность: защита и нападение», Бирюков А. А.

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

Программа должна отображаться на странице page.php, а исполнительный файл в файле core.php. Взаимодействие между файлами с помощью ajax. Все обработанные данные нужно записывать в таблицу data_table (My_SQL) со столбцами id, name и url.

Нельзя создавать функции и переменные с названиями: generate, crop и analyze. Иначе возможен конфликт.

Стандарты оформления кода

Разные люди по-разному пишут. Хороший пример – наш блог. В нем несколько авторов, у каждого из которых свой стиль. То же самое и с программистами.

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

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

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

Переменные можно называть по-разному: $aB, $ab, $a_b, $A и так далее. Если это незначительно, добавлять комментарии критически важно. Без них в коде тяжело ориентироваться, даже если его писали вы, но отложили на неделю.

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

Подключение и тестирование

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

Заключение

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

kak-sostavit-tz-dlya-programmista

Источник: https://texterra.ru/blog/kak-sostavit-tz-dlya-programmista.html

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

Как написать техническое задание для программиста образец

О чём вы думаете, когда видите по городу или на сайтах (в рекламных блоках) баннеры с заголовками: «Сайт за 500 грн.», «Сайт за 1000 руб.»?

Я, как разработчик, долго думала — развод! Но количество подобных объявлений наводит на мысли:

  • А возможно ли такое вообще?
  • Какое качество будет у сайта в таком случае?
  • Можно ли будет его потом продвигать?
  • Займёт ли он достойные позиции?
  • Будет ли он удобным и будет ли возможность его редактировать?

Конечно, порой приемлем и простой набор HTML-файлов: если страниц немного, их редко меняют из-за тематики и владелец сайта (или контент-менеджер) знает HTML.

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

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

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

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

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

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

Тз по разработке сайта

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

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

Вы можете составить ТЗ, а владелец сайта (который вы приведёте в пример) к тому моменту, когда ТЗ перейдёт к исполнителю, поменяет вёрстку.

Тогда вам снова придётся искать пример и объяснять, что вы имели в виду.

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

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

Десктопная версия

Общая информация

Ширина сайта – 1140 px (пример –vizaua.com).Шапка и футер растягиваются по ширине экрана и одинаковы для всех страниц.Семейство шрифтов: Cambria (предпочтительно), Century, Georgia. Можно указать и другие популярные шрифты с засечками.Размеры шрифтов (для Cambria):Текст под логотипом в шапке – 15pxСсылки в шапке – 14px

Текст в футере – 16px

страница – home.png

Текст над строкой поиска – 25px

Текст под строкой поиска – 14px

Описание элементов:

1, 2 – цифры с реальным числом магазинов и отзывов. Можно пересчитывать один раз в 24 часа.3 – категории. Располагаем вручную в таком порядке, как на макете.4 – ссылки на магазины. Рядом с названием магазина выводим число отзывов. Если отзывов ещё нет, ничего не выводим.

Под каждой категорией выводим 6 самых популярных по количеству отзывов магазинов. Если в категории есть ещё магазины, на неё ведёт ссылка «Ещё N», где N – число магазинов. Если больше магазинов нет, на категорию ведёт ссылка «Показать всё».

5 – список низкопопулярных категорий.

Выводим их тут.

Страница с описанием магазина и отзывами – shop-page.png

Заголовок H1 – 30px
Заголовок H2 – 22px

Описание элементов:1, 2, 3 – место под рекламные блоки. Нужно отметить это место при вёрстке и закрыть к индексации.4 – контент страницы.

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

5 – заголовок формы. Нужно проставить «».

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

Страница категории – category-archieve.png

Ссылки на магазины – 18 px, цвет # 336699
Текст в анонсах – 14px

Описание элементов:1,2 – место под рекламные блоки.3 – контентная часть. Нужно удалить все описания категорий (тексты сохранить в отдельном .doc-файле и загрузить этот файл на сервер).

4 – ссылка на отзывы. Во всех шаблонах ТЗ слово «комментарии» меняем на «отзывы».

Служебная страница – page.png

Размер шрифта – 15pxРекламные блоки не выводим.

В меню справа выводим только поиск и ссылки на категории. Отзывы не выводим.

404 ошибка – 404.png

404 – шрифт 80pxТекст под ним – 20px

Наклонный текст – 15px

Ссылки навигации:– на главную – 16px

– на служебные страницы– 14px

Активные элементы:Все ссылки подчёркнутые, убираем подчёркивание при наведении, цвет ссылки на несколько оттенков темнее (на усмотрение исполнителя).

Цвет кнопки #ddd, при наведении появляется курсор в виде руки.

Рекомендую делать отдельные макеты и описывать поведение всех ссылок, кнопок, выпадающих меню, всплывающих окон.

Мобильная вёрстка

Сейчас лучше ставить мобильную вёрстку главной и от неё «плясать». Не зря же вся справка и блог Google пестрят «Mobile first» (сначала мобильные или мобильность). Мы говорим вам об этом с 2014 года (статьи «3 способа быстро адаптировать сайт под мобильные устройства» и «Мобильная адаптация сайта — ответы на вопросы» ).

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

  • Контактам. Номера телефонов должны быть кликабельными – при нажатии должна открываться панель ввода номера с уже набранным номером и кнопкой вызова.
  • Меню. Опишите, как оно должно открываться: выезжать сбоку, сверху и т. д.
  • Не должно быть горизонтальной прокрутки на страницах сайта (это само собой разумеется, но я всё же решила напомнить).

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

Основные требования:
– меню-бургер – раскрывается вниз при касании значка меню:

– сайдбар опускаем под основной контент:

– все элементы в футере находятся друг под другом:

страница

Все элементы выводятся друг под другом:

  • краткое описание;
  • форма поиска;
  • подробное описание;
  • списки магазинов, разделённые по категориям.

На этом примере, кстати, действительно всё предельно ясно, можно обойтись без описания.

Страница категории

Страница магазина

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

Информационная страница

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

P.S.

Еще по теме:

Есть вопросы?

Задайте их прямо сейчас, и мы ответим в течение 8 рабочих часов.

Источник: https://siteclinic.ru/blog/technical-aspects/tz-na-razrabotku-sajta-primer/

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

Как написать техническое задание для программиста образец

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

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

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

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

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

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

1. Цель/Задача. Сформулировать то, что должно быть реализовано в конечном итоге.

2. Описание. Вкратце изложить содержание планируемых доработок.

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

4. Оценка работы. Данный пункт очень важен – в нем нужно описать трудозатраты.

Еще два важных момента: есть утвержденные стандарты к написанию ТЗ — ГОСТы. Сейчас они редко используются, но некоторые клиенты могут по старинке просить использовать и их.

И второе, когда сдается работа может возникнуть и такое – «а мы же вроде как просили Вас сделать то-то и тогда-то…». Есть вероятность, что придется все начать делать с самого начала.

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

Техническое задание 1С на доработку внешней обработки


Цель
 
Необходимо настроить выгрузку данных из 1С в АРМ банка.


Описание

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

Выгрузка данных должна основываться на документах «ЗаявкаНаОткрытиеЛицевыхСчетовСотрудников» и «ВедомостьНаВыплатуЗарплатыВБанк».

Исходные данные

Имеющаяся обработка к конфигурации 1С «Зарплата бюджетного учреждения», осуществляющая выгрузку данных из документа «ЗаявкаНаОткрытиеЛицевыхСчетовСотрудников» и других справочников и регистров в файл DBF обмена данными с АРМ банка установленного образца.

Обработка выгружает данные в поля TAB_N, NAME, SERNUM, PASSCODE, PDAT, PWHR, BIRTHDAY, POSTINDEX, COUNTRY, CITY, STREET, REGION, BUILDING, CORP, FLAT, BPLACE, CITIZEN соответствующую информацию из конфигурации 1С, предварительно занесённую в указанный документ и другие учётные таблицы. Выгружаются табельный номер, ФИО сотрудника, его паспортные и адресные данные, день рождения и гражданство.

Способ реализации

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


Оценка работы

Потребуется 5 рабочих дней работы программиста.

Отзывы о компании

  • Сивелькина С. В. 20 марта 2017 ПАО “НИКО-БАНК” выражает свою благодарность за оперативную и грамотную работу. В условиях постоянно меняющегося законодательства Банк заинтересован иметь полную и актуальную номативную базу. Это обеспечивается использованием Банком справочно-нормативной системы “Гарант”.  Безусловным плюсом в работе компании “МастерСофт” является быстрое реагирование сотрудников при предоставлении документов по запросу Банка, принятых до обновления справочно-правовой системы.
  • Мордвинцев С. П. 25 сентября 2016 Коллектив компании “АЭРОПОРТ ОРЕНБУРГ” выражает благодарность за взаимовыгодное сотрудничество с МастерСофт-ИТ. Оперативная поставка антивирусных программ Dr. Web обеспечила надежную защиту нашей компьтерной сети. Особая благодарность сотрудникам Департамента продаж СЦ ИТ за профессиональный подход в решении всех возникающих задач.
  • Ряховская Н. А. 19 июня 2017 ООО “Орский Вагонный Завод” выражает искреннюю благодраность за качество обслуживания вашими специалистами. Консультации и поставка антивирусов всегда проходят оперативно и на высоком профессиональном уровне. Уверены, что и в дальнейшем наше сотрудничество на взаимовыгодных условиях продолжится.
  • Кетерер Т. М. 19 февраля 2018 Главный бухгалтер муниципального бюджетного учреждения дополнительного образования “Дворец творчества детей и молодёжи” Кетерер Татьяна Михайловна выражает благодарность специалистам МастерСофт: “Я хотела бы объявить благодарность вашим сотрудникам. Работает с нами по программе “1С: Бухгалтерия бюджетного учреждения 8” непосредственно Шевлягина Юлия. Так же огромная благодарность за отзывчивость, терпение и квалифицированную, своевременную помощь Набокиной Олесе и Ерёменко Татьяне (они нас сопровождают по программе “Зарплата и Кадры”). Им очень с нами тяжело, но они терпеливо продолжают сотрудничать. С вами очень надёжно. Конечно же наши ошибки есть и без вас мы бы вообще о них не знали и в суде, наверное, судились бы. А сейчас мы решаем вопросы…”.

Источник: https://mastersoft.ru/blog/kak-sostavit-tz-dlya-programmista/

Как писать техзадание для интеграции с сервисом email-рассылок

Как написать техническое задание для программиста образец

Советы Как интегрировать сайт и сервис email-рассылок

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

Вещи, которые по началу кажутся сложными, мы лучше понимаем на простых примерах.

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

3 способа связать сайт с сервисом рассылок

Прежде всего, нужно решить, как связать сервис email-рассылок с вашим или CRM-системой.

Вы можете использовать:

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

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

Что за зверь такой – API?

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

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

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

Я в работе использую такую схему:

Пример работы этой схемы легко понять на известном меме:

А теперь разберём первую схему детальнее.

1. Источник

Источник – это система, откуда мы берём данные.

Например, какой-либо сайт example.com или ваша CRM-система.

2. Триггер

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

Например, могут быть такие триггеры:

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

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

3. Данные

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

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

Например, на сайте есть форма заявки с такими полями:

  • Ваше имя.
  • Ваш email.
  • Телефон.
  • Город.

И мы хотим, чтобы данные автоматически попадали в группу «Заявки».

В системе рассылки поля «имя», «email» и «телефон» уже существуют по умолчанию. А вот поле «Город» нам некуда передавать, поэтому для начала его нужно создать в системе рассылки.

В сервисе UniSender это делается так:

Новое поле мы создаем, перейдя в меню «Контакты — Дополнительные поля».

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

4. Приёмник

В нашем случае это система рассылок UniSender.

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

Этот ключ вы должны сами посмотреть в личном кабинете системы и прислать программисту:

Посмотреть API-ключ можно в меню «Настройка аккаунта» (раздел «Интеграция и API»)

Копируем цифры и буквы с вкладки «Интеграция и API» личного кабинета и передаём их программисту.

5. Реакция

Что система рассылки должна сделать, получив данные.

Примеры реакции системы рассылки:

  • отправить письмо с названием «N»
  • отправить письмо с подтверждением подписки
  • добавить контакт в группу с названием «N»
  • отправить SMS с текстом «N» контакту
  • отписать пользователя от всех рассылок

Рекомендую просмотреть список методов API перед отправкой задачи программисту.В этом документе описано всё, что может сделать система рассылок, получив по API команду от вашего сайта или CRM-системы.

Например, вам нужно отправить письмо с благодарностью за регистрацию на мероприятие. При этом double opt-in (двойное подтверждение подписки) мы не хотим использовать.

Такую задачу можно выполнить двумя способами:

Способ 1. Использовать метод sendEmail, то есть автоматическую отправку одного письма конкретному пользователю, который заполнил форму.

Способ 2. Использовать метод Subscribe, то есть просто добавить пользователя в группу. А саму отправку письма настроить непосредственно в системе рассылки за три шага:

  • Создаем письмо, которое будет отправлено в момент попадания email-адреса в список «Заявки».
  • Переходим в меню «Рассылки — Письма и черновики — Создать email», заполняем все нужные поля и создаем письмо для нового подписчика.
  • На этапе «Отправка» нажимаем кнопку «Запланировать письмо по событию». Выбираем условие «При попадании в список подписчиков».

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

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

Итог

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

“>

Источник: https://www.unisender.com/ru/blog/sovety/developer-tz

Как грамотно составить ТЗ для программиста. Основы взаимопонимания

Как написать техническое задание для программиста образец

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

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

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

По своему объему ТЗ может быть достаточно большим документом. Web-компании часто предлагают помощь по составлению ТЗ отдельной услугой, как правило 10-20% от стоимости всей разработки сайта.

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

Чем детализированнее ТЗ (в разумных пределах конечно), тем лучше для обеих сторон — как для клиента, так и для исполнителя работы.

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

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

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

Общие рекомендации по написанию ТЗ

  • Простая истина — чем сложнее проект, тем детализирование должно быть ТЗ.
  • Среди возможных вариантов можно назвать ТЗ, описывающее главные страницы интерфейса со всей совокупностью элементов на ней и описанием их поведения. Или же это может быть лаконичное описание нескольких страниц для сайта-визитки и т.п.
  • В ТЗ для программиста не должен упоминаться дизайн элементов или звучать пожелания по дизайну. Задание все-таки для программиста..
  • Описания задач в отдельных частях ТЗ должны быть граничными. Что это значит?  Нужно четко обозначать конец конкретного пункта задания. В ТЗ не должно быть абстрактных фраз типа «должна быть удобная навигация». Это все субъективные признаки – одним удобно, другим не удобно  и понять выполнен ли данный пункт бывает сложно из-за нечеткости положений ТЗ. Т. е. это необходимо контролировать.
  • Для несложных сайтов, где нужно описать какой-нибудь функциональный модуль, чтобы заново не изобретать велосипед, нужно проанализировать сайты с похожим функционалом, так сказать, провести  анализ конкурентов; сохранить гиперссылки на страницы с требуемыми элементами интерфейса и функциями, и включить их в ТЗ с расширенными пояснениями о том, что именно делать. Также необходимо в обязательном порядке снять скриншоты с нужных страниц на случай, если сайт через время будет не доступен. При этом можно ставить свои пометки на изображениях ( благо средств сейчас много для этого — Clip2net, Joxi, Awesome Screenshot и прочие).
  • Если дизайна для страниц нету или он не так важен в рамках какого-то проекта, скажем, заказчик решил сэкономить на дизайне админ-панели сайта, в этом случае программист вполне может использовать прототипы.

Справка

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

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

Из популярных можно выделить:— среди бесплатных: iPlotz, MockFlow, Mockup Builder, Cacoo;

—  среди платных: Creately, ProtoShare, Adobe Fireworks,Axure . Возможностей в общем много — выбирай, осваивай, рисуй…

Общая структура ТЗ. От абстракции к конкретике

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

  1. Общая информация о сайте.
  2. Функциональное назначение сайта.
  3. Понятия и термины
  4. Описание модулей сайта
  5. Функциональные характеристики
  6. Описание страниц.
  7. Резервирование и надежность.
  8. Хостинг для сайта.

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

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

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

4. Описание модулей сайта
Этот раздел включает список модулей, которые используются на сайте. Это вполне например может быть упоминаемая выше форма обратной связи (ФОС). Но, что очень важно — нельзя просто писать «Должна присутствовать ФОС». Каждая сущность требует определения своих атрибутов! В данном случае атрибуты могут быть такими:

  • Поле «Ваш имя»;
  • Поле «Ваш е-mail»;
  • Поле «Ваш вопрос»;
  • Поле ввода капчи для защиты от спам-роботов.

И все это должно быть четко прописано, что бы потом не возникло вопросов: «…а где перечень выбора категории вопроса?» или что-то в этом роде.

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

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

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

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

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

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

Источник: https://siteclinic.ru/blog/technical-aspects/tz-dlya-programmista/

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

Как написать техническое задание для программиста образец

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

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

Придется сделать такую статейку самому… И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или 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/ru/post/328822/

Служитель закона
Добавить комментарий