Разработка технического задания (ТЗ) на сайт по ГОСТ
Техническое задание (ТЗ) на сайт – документ, содержащий набор требований к сайту (порталу) и порядок их исполнения. ТЗ является основополагающим документом, в соответствии с которым осуществляется разработка и приёмка сайта.
В отличие от ТЗ на АСУ или на программу, нет ГОСТов предъявляющих требования к структуре и содержанию технического задания на изготовление сайтов. Однако, исходя из лучших практик, требования ГОСТов (34.602 и 19.201) очень часто учитывают при оформлении ТЗ. В частности требования ГОСТ 34.602 учитывают при создании ТЗ на портал, интернет-магазин, а ГОСТ 19.201 при разработке ТЗ на сайт-визитку.
ТЗ на сайт является, своего рода, инструкцией по разработке, которая утверждается и согласуется Заказчиком и Исполнителем. Как правило, техническое задание содержит достаточно большой объём информации, тем самым, минимизируя риски, которые могут возникнуть в процессе выполнения работ по его созданию.
Разработка технического задания на сайт – командная работа, очень важно чтобы в написании ТЗ на создание сайта принимали участие все заинтересованные стороны (программист, дизайнер, Заказчик и т.д.).
Для чего нужно техническое задание
Опыт создания сайтов нашими специалистами подтверждает, что техническое задание помогает решить следующие задачи:
систематизирует и упорядочивает рабочий процесс.
всю информацию необходимую для разработки интернет ресурса.позволяет создать продукт, максимально соответствующий Вашим ожиданиям.позволяет юридически закрепить процесс разработки и приёмки создаваемого продукта.Если вы решили создать собственный веб-проект (интернет-магазин, портал и т.д.), но не знаете, как приступить к выполнению поставленной задачи – начните с разработки технического задания (ТЗ). Наши специалисты имеют богатый опыт в создании технических заданий на сайты, а в последствии и самих веб ресурсов самой разной сложности и структуры.
С некоторыми примерами ТЗ на сайт, разработанных нашими специалистами согласно ГОСТ, Вы можете ознакомиться в соответствующем разделе.
Заказать ТЗ на сайт
Для оформления заявки и получения бесплатной консультации можете позвонить по телефону или оставить онлайн-заявку на нашем сайте. Готовы выполнить проект любой сложности в короткий срок.
Так что же такое «Техническое Задание»? / Хабр
Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы — могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»
Проблема
Дело в том, что когда существует конкретный формат, а также четкое и внятное определение какого-либо термина, то все манипуляции и подмены его на собственные брифы, прототипы, на ходу придуманные опросники, описания и просто входящие заявки — выглядят, по меньшей мере, непрофессионально. Поэтому с научного определения нашего понятия и начинаем:
Техническое задание — исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Техническое задание является юридическим документом — как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет. Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков. Техническое задание, как термин в области информационных технологий – это юридически значимый документ, содержащий исчерпывающую информацию, необходимую для постановки задач исполнителям на разработку, внедрение или интеграцию программного продукта, информационной системы, сайта, портала либо прочего ИТ сервиса.
Переводим на понятный язык
1) ТехЗадание — оно ставит задачу. А значит оно должно идти перед прототипом, скетчем, тестом, дизайн-проектом, потому что любой майндмеп, диаграмма потоков данных, архитектура — это уже выполнение некой задачи, это ответ на вопрос. А до того, как сам вопрос еще не задан, не сформулирован и не подписан всеми сторонами — любой ответ будет априори неправильным, не так ли? Итак, начало любой работы над любым проектом — это постановка задачи, а не судорожный поиск набросков десятка вариантов ее решения.
2) Собственно из первого пункта логично вытекает и новый — сам текст ТЗ обязан начинаться с главы «Цели и задачи», четко формулирующей, какие бизнес-цели преследует вся эта очередная попытка повысить энтропию в мире. Бесцельное задание, которое не решает никаких проблем, не достигает ничего и делается «от скуки» — официально не считается Техническим Заданием, а с этого момента находится в статусе «обычная бумажка».
3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт — вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия — быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.
Отсюда делаем вывод, что в настоящем ТЗ обязательно должна быть глава «Порядок приемки и оценки», когда эти самые показатели берутся, замеряются, и стороны либо пожимают друг другу руки, либо отправляют проект на переделку.
4) ТехЗадание должно обязательно согласоваться с общим бизнес-планом заказчика, с его стратегией развития бизнеса и анализом сегмента рынка. Именно все это позволит установить правильные цели, вывести точные метрики, по которым затем адекватно провести приемку готового инфопродукта. Отсутствие у заказчика бизнес-плана автоматически гарантирует непрофессиональное выполнение Технического Задания.
Знает ли студия на аутсорсе бизнес-цели и измеримые показатели бизнеса лучше его владельца? Очевидно, что нет, а значит правильное ТЗ должно писаться представителями Заказчика, а не наемными работниками Исполнителя. Абсурд, когда исполнитель сам себе ставит задачу, затем сам себе придумывает способы ее оценки, и в конце сам же выставляет себе итоговую отметку за сделанную работу. В идеале такой «самодеятельности» быть не должно, хотя на практике повсюду именно так и происходит, в результате чего ТехЗадание и не оказывает нужной помощи проекту, слишком часто являясь по сути фиктивным документом. Не надо так.
5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.
Кстати, по идее точно также каждая правка в дизайне или внесение изменений в список страниц или функций должна иметь четкую цену, которая оплачивается заранее, до начала внесения данного изменения. Лично я предлагаю любую редактуру утвержденного ТЗ оценивать в 30% от всего бюджета проекта, но вы можете поступать иначе.
Стоит ли упоминать, что в ТЗ просто необходимо заранее указывать сроки и общий бюджет на разработку, а также список всех существующих ресурсов и ограничений? — Нет, это будет уж слишком очевидно.
Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? — написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.
Контрольные вопросы
А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:
1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? — Да, даже несколько.
2) А что, в ТехЗадание не входит описание нужных страниц, количества кнопок, используемых библиотек, гайдлайнов и т.д.? — В само ТЗ нет, но в Приложения вы можете все это поместить, разумеется скорректировав все это с вышеописанными целями, ограничениями и способами дальнейшей оценки достигнутого результата. Размещайте хоть весь будущий контент, хоть описание типовых персонажей — но не вместо четкой постановки задачи, а уже после нее.
3) Так может оно мне такое и не нужно? — Возможно, сегодня тысячи сайтов делаются вообще без ТЗ, также, как тысячи людей в мире прекрасно живут, будучи слепыми от рождения. Но если вы хотите видеть — куда вы вообще движетесь, осознанно принимать решения и самостоятельно оценивать полученные результаты — то без ТЗ тут не обойтись.
4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? — Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.
5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? — Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) — то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL — уже нет.
6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? — Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» — установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь — обязательно.
Как написать техническое задание на создание сайта
Мы считаем, что заказчик сайта не обязан писать подробное техническое задание. Нам вполне достаточно, если вы напишите на почту зачем вам нужен сайт 2-3 предложениями.
- Как за 600 секунд получить смету на сайт
Обычное ТЗ
Часть технических заданий, которые приходят на нашу почту, — подробные описания каждой мелочи на будущем сайте. Часто присылают чужие заполненные брифы. Чтобы сделать продуктивнее нашу с вами работу, пишу эту инструкцию. Прочитав статью, вы убедитесь, что техническое задание по моему рецепту — это просто!
Корпоративный сайт
Корпоративный сайт — представительство (офис) компании в интернете и основной инструмент интернет-маркетинга. Самое главное — какие задачи вы возлагаете на свой интернет-офис. Цель нашей работы — улучшить ваш бизнес с помощью сайта. Опишите простыми словами в письме зачем вам нужен сайт. Этого достаточно, чтобы завязать диалог. Мы обязательно обсудим с вами остальные детали будущего сайта на переговорах.
- Сайты 5-го поколения: поисковое продвижение сайта без SEO и контекстной рекламы
- Как сделать сайт, который продаёт
Вот живой пример переписки, каждая пара «вопрос-ответ» порождает новый вопрос и таким образом выясняется задача сайта:
Вопрос: — Зачем нам сайт? Ответ: — Мы хотим больше клиентов.
Вопрос: — В интернете есть наши клиенты? Ответ: — Судя по сайту конкурентов и статистике запросов, есть.
Вопрос: — Если у нас будет сайт, придут ли к нам клиенты с сайтов конкурентов? Ответ: — Да, если наш сайт будет удобнее, чем у них.
Вывод: — Делаем сайт удобнее, чем у конкурентов.
Как видите, первоначальная причина создания сайта была размыта, — ведь все хотят больше клиентов. Постепенно мы пришли к конечной цели. Зыбкая неохватная задача «хотим больше клиентов» превратилась в осязаемую «сайт должен быть удобнее, чем у конкурентов». Удобнее, значит пользователи на таком сайте решают свои проблемы быстрее и затрачивают при этом меньше усилий, чем на другом сайте. Для веб-студии такая задача понятна и выполнима. А бизнесу она даст требуемых клиентов.
Такой логической цепочкой можно проверить каждую первичную цель. На переговорах это отнимает совсем немного времени. Первые переговоры будут продуктивнее, если мы заранее поняли что от нас требуется и подготовились.
Интернет-магазин
Напишите, пожалуйста, что вы продаёте. Опишите ассортимент и его величину. Круто, если набросаете структуру каталога. Обозначьте географию рынка сбыта. Детали оплаты, доставки, гарантии, возврата и наполнения желательно обдумать до первого диалога с нами. Но если затрудняетесь, можем обсудить сообща.
Главное в интернет-магазине для покупателя — удобство покупки. Главное для продавца — чтобы посетители не уходили с пустыми руками. Гармония, когда оба интереса уравновешены. Если вы придумали специфический функционал — полезно будет описать его работу в виде алгоритма.
Landing Page
Бытует мнение, что лендинг — это «дёшево». Это ошибка. Маркетологу и дизайнеру нужно упаковать в одну страницу всё то, что обычный сайт содержит на десятке страниц. Так, чтобы результат не вызывал тошноту при скроллинге.
- Какие бывают посадочные страницы
- Как сделать простой лендинг самому и бесплатно
Нужен креатив, крутой дизайн, классные фотографии. Хороший лендинг сопоставим по цене с обычным сайтом, отличается от него только задачами. Техническое задание на landing page не отличается от корпоративного сайта. Просто напишите чего нужно добиться от посетителей вашей посадочной страницы.
Веб-сервис
Веб-сервисы — это функциональные сайты. В сервисах бесполезно в качестве технического задания прислать пример другого сайта. К сожалению, с сервисами чаще всего так и получается. К примеру, просят сказать сколько стоит копия Bla-Bla-Car. По внешнему виду сайта этого сказать невозможно. У Bla-Bla-Car есть административная панель, через которую ведут бизнес. И сделать её — главная задача в таком сайте. То, что видно на front-end — это вершина айсберга. Техническое задание на сервис — самое «техническое» из всех. Начинайте с описания сервиса и его возможностей. Нужно последовательно описать алгоритм действия пользователя, чтобы достигнуть требуемого. Прикиньте, что нужно в админ-панели для управления бизнесом. Для первичных переговоров этого хватит.
Остальное
У нас заказывают сайты-визитки, довольно часто требуются промо-сайты. С визитками лучше не к нам. Во-первых, мы не верим в существования таких сайтов. А во-вторых, там не о чем думать: чаще всего клиенту нужен готовый шаблон на популярной CMS. А в промо-сайтах техническое задание бессмысленно, нужно изучать продукт. Техническое задание на промо-сайт — это как рассказ о том, чего никогда не видел. Попробуйте описать, каково держать в руках iPhone.
Мы разрабатываем недорогие сайты на Tilda. Для простых сайтов без функционала это отличная платформа.
Вывод
В большинстве случаев для корпоративного сайта не требуется подробное техническое задание. Мы облегчаем жизнь своим клиентам и пишем для себя руководящую документацию после переговоров. Если вы просто скажете что ждёте от будущего сайта, нам будет вполне достаточно.
- Как мы делаем меньше и сохраняем с клиентами хорошие отношения
- Проектирование ради конверсий
Вам нужен сайт? Отправьте нам заявку.
Состав технического задания (ТЗ) на разработку сайта
Представляю вашему вниманию содержание и пример-шаблон технического задания на разработку сайта.
Предлагаемый ниже под скачку документ — основа, НЕ ИСТИНА В ПОСЛЕДНЕЙ ИНСТАНЦИИ!!! Для каждого проекта состав ТЗ может варьироваться. Главное — вы должны понимать, что написано в этом документе, что значит, каждое слово!
Если у вас есть проблемы с составлением ТЗ, то я к вашим услугам. В моем портфеле более 100 составленных ТЗ 🙂
Содержание:
1. ТЕРМИНЫ, ИСПОЛЬЗУЕМЫЕ В ТЕХНИЧЕСКОМ ЗАДАНИИ
2. ОБЩИЕ ПОЛОЖЕНИЯ
2.1.Название сайта
2.2.Наименование предприятий разработчика и заказчика сайта и их реквизиты
2.3.Перечень документов, на основании которых создается сайт
2.5.Состав и содержание работ по созданию сайта
2.5.1.Очередность работ
2.5.2.Порядок производства работ
2.6.Плановые сроки начала и окончания работ
3. Порядок оформления и предъявления заказчику результатов работ
4. НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ САЙТА
4.1.Цели создания сайта
4.2.Задачи, решаемые при помощи сайта
4.3.Целевая аудитория сайта
5. ТРЕБОВАНИЯ К САЙТУ И ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
5.1.Требования к программному обеспечению сайта
5.2.Общие требования к оформлению и верстке страниц
5.3.Требования к численности и квалификации персонала обслуживающего сайт
5.4.Требования к системе администрирования
6. ЯЗЫКОВЫЕ ВЕРСИИ САЙТА
7. ГРУППЫ ПОЛЬЗОВАТЕЛЕЙ
8. ДИЗАЙН САЙТА
9. СТРУКТУРА САЙТА
10. НАВИГАЦИЯ ПО САЙТУ
10.1.Основное навигационное меню
10.2.Дополнительная навигация по сайту
11. ОПИСАНИЕ СТРАНИЦ САЙТА
11.1.Описание статических страниц
11.2.Описание динамических страниц
12. ФУНКЦИОНАЛ САЙТА
13. КОНТЕНТ И НАПОЛНЕНИЕ САЙТА
13.1. ФОРМАТ ПРЕДОСТАВЛЕНИЯ МАТЕРИАЛОВ ДЛЯ САЙТА
14. ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ
15. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РАБОТ
16. РЕКВИЗИТЫ И ПОДПИСИ СТОРОН
17. TZ_bitrix_korp
Скачать шаблон ТЗ на разработку сайта
Стандарты и шаблоны для ТЗ на разработку ПО / Хабр
Введение
Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…
И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или 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).
Также рекомендую ознакомиться со следующими материалами:
Как написать понятное ТЗ на веб-разработку и ускорить запуск проекта — CMS Magazine
Компания Ratio составила три шаблона технических заданий: для дизайнеров, программистов и веб-разработчиков полного цикла. Можно скачать и заполнить их — исполнитель точно поймёт, какой сайт вам нужен.
Больше не нужно искать и обзванивать каждое диджитал-агентствоСоздайте конкурс на workspace.ru – получите предложения от участников CMS Magazine по цене и срокам. Это бесплатно и займет 5 минут. В каталоге 15 617 диджитал-агентств, готовых вам помочь – выберите и сэкономьте до 30%.
Создать конкурс →
Без ТЗ вы получите не то, чего ожидали
ТЗ в строгом значении слова — это документ, закрепляющий критерии, по которым будет приниматься работа. Но на практике под техзаданием часто понимается целый комплект документов: концепция проекта («что это такое?»), спецификация («каким проект должен быть?»), описание разделов и модулей будущего сайта.
Мы понимаем под ТЗ подробную формулировку задачи, которую заказчик составляет вместе с подрядчиком. В шаблонах от Ratio учтена вся информация, которая требуется нам для начала работы. Можете разбить документ на части и согласовывать их отдельно — так или иначе, к началу проекта информация по списку будет готова.
Если сайт или приложение действительно необходимы, то не жалейте времени на подробное ТЗ — оно закрепляет принятые решения и позволяет обойтись без повторных обсуждений. Техзадание гарантирует, что вы и исполнитель мыслите в одном направлении: на бумаге ваши требования к проекту что-то значат, их не получится забыть или проигнорировать.
Кроме того, ТЗ — это возможность проверить проект на слабые места. Составив техзадание, вы увидите скрытые ошибки и устраните их до того, как они превратятся в проблему.
Составляйте ТЗ от общего к частному
Техзадание начинается с одного предложения — например, «нужно добавить функцию X на готовый сайт интернет-магазина». В дальнейшем это предложение раскрывается подробнее.
Структура ТЗ на веб-разработку:
-
Описание проекта: концепция, гипотезы, целевая аудитория, критерии успеха.
-
Исходные данные: чеклист контента, полное описание разделов проекта с примерами
-
Задание на дизайн: механика работы блоков и дизайн-прототип со ссылками на psd-исходники
-
Задание на разработку: структура разделов проекта, их описание, а также технические требования и ссылки на готовый дизайн
Описание разделов составляйте развёрнуто: не просто «раздел Работа у нас», а структура страницы, контент, нужна ли форма обратной связи и какие поля должны в ней быть.
Сроки и штрафы в ТЗ лучше не упоминать, они закрепляются в более значимых документах — договоре и дополнительных соглашениях. Правки тоже прописываются отдельно, в листе возражений к приёмке.
Отформатируйте ТЗ, чтобы его было удобно читать и редактировать
Разбираться в чужих мыслях трудно, можно запутаться и что-то пропустить. Постарайтесь облегчить жизнь подрядчикам — это поможет им сделать работу быстрее.
На что обратить внимание:
-
Составляйте списки (вместо сплошного текста)
-
Оформляйте заголовки через стили h2, h3 и так далее (для автоматического оглавления в Google Документах)
-
Выделяйте ключевые фразы (для чтения по диагонали)
-
Нумеруйте страницы, пункты и подпункты (чтобы во время обсуждения легко понимать друг друга)
-
Пользуйтесь внутренними ссылками
Из-за внутренних ссылок документ приходится листать туда-сюда, но они необходимы — ТЗ редко получается с первого раза, обычно туда вносят правки. Если повторять одну и ту же информацию несколько раз, корректировать ТЗ будет неудобно: в одном месте поправили, а ещё два забыли.
ТЗ на комплексную разработку сайта или веб-приложения
Техзадание на комплексную разработку — это ТЗ дизайнера и программиста в одном флаконе. К этому документу часто обращается менеджер, ведь ему нужно видеть полную картину, чтобы направлять команду.
Конечно, универсальной формы для техзадания не существует. Мы просто делимся нашими наработками, поэтому используйте шаблон как основу, но не бойтесь изменять или дополнять его.
Шаблон ТЗ для веб-подрядчика
Отдельное ТЗ на дизайн
Если вам нужен только дизайн, то воспользуйтесь этим шаблоном. Но учтите, что для начала работы понадобится контент: тексты, фотографии, логотипы и иллюстрации.
Шаблон ТЗ для дизайнера
Отдельное ТЗ на бэкенд/фронтенд
Если вам нужны только услуги программиста, значит у вас есть готовый дизайн — без него приступать к разработке нет смысла. В техзадании обязательно укажите ссылки на правильно подготовленные макеты под все поддерживаемые устройства.
Шаблон ТЗ для программиста
От идеи до реализации. Часть третья — создаем ТЗ (техническое задание) / Хабр
Данилевский КириллПрошу прощения у читателей за долгий перерыв. Сейчас работаю на крупном проекте, времени ни на что не хватает. Итак, пишу продолжение к циклу статей «От идеи до реализации.» Вот предыдущая статья: «От идеи до реализации. Часть вторая — рождение идеи»
Сегодня я хочу немного поговорить о том, как сократить свой путь от голой идеи до получения инвестиций. Здесь есть два важных момента. Для себя нужно решить, кто будет выступать инвестором. Если вы в состоянии сами себя финансировать, то это очень хорошо. Но если у вас с финансами проблемы, то без внешнего привлечения денег вам не обойтись.
Но для того, чтобы заинтересовать инвестора, вам необходимо предоставить ему достаточно подробные документы. Так как разговор с объяснением, грубо говоря, на пальцах, не дает инвестору возможность увидеть картину целиком. А следовательно и о деньгах тоже не может быть никакой речи.
И наша главная задача — это подготовить такие документы, которые помогут вам получить финансирование и смогут вам самому прояснить картину с будущим вашего проекта.
Самое первое, что необходимо сделать — четко сформулировать бизнес идею. Это должна быть не просто интересная мысль, а некое законченное и замкнутое решение, которое поможет достигнуть поставленной цели. Для того, чтобы не заниматься словоблудием, то возьмем за основу некий пример, на базе которого и будем строить нашу документацию.
Например, есть некая частная лаборатория, где работает несколько сотрудников. Эти сотрудники являются специалистами в области физики, имеют собственное оборудование, которое позволяет им проводить некоторые сложные опыты и выдавать результат. Все исходные данные заносятся в базу данных, а полученные результаты также сохраняются в виде неких статистических данных. При проведении n-количества опытов, сформировывается уже некая поведенческая модель, благодаря которой можно предсказать результат с достаточно высокой вероятностью, при этом уже без проведения лабораторного опыта.
И в какой-то момент приходит понимание того, что спрос на проведение опытов не так велик, лаборатория ограничена своей пропускной способностью, получать заказы из разных стран достаточно сложно, каждый раз необходимо проводить большое количество переговоров, заключать договора и т.д. Основная мысль проблемы в том, что не получается прыгнуть выше головы. А те «прыжки» что есть, достаточно сложные, не мобильные и дорогостоящие.
И тут у специалистов рождается интересная идея. А что, если весь наш опыт и огромные массивы данных применить в программе, которая будет являться неким искусственным интеллектом. Имея эту программу можно будет, с большой долей вероятности, получить верный результат при введении своих параметров. Таким образом, программа рассчитает правильный результат без задействования лаборатории, а только опираясь на данные опытов, которые были уже проведены ранее. Это очень сильно сэкономит накладные расходы, и поможет быстро получить новых клиентов со всего мира.
Идея интересная, уже более-менее сформированная. Начинаются поиски инвестора, который готов вложить в эту идею финансы. Но первый вопрос — сколько нужно вложить денег в этот проект? И ответа на этот вопрос нет. И второй момент — это если инвестор не разбирается в физике, то он вообще не поймет того, что ему будут пытаться объяснить. А вкладывать деньги в то, чего инвестор даже примерно понять не может, он уж точно не будет.
И тут приходит понимание того, а как вообще можно оценить необходимый объем финансов? Ведь отличные специалисты в физике ничего не понимают в ИТ и финансах, отличные программисты ничего не понимают в физике и финансах, а отличные финансисты ничего не понимают в физике и ИТ. Получается замкнутый круг, который, для многих, часто замкнутым и остается.
Для того, чтобы выйти из этой непростой ситуации, нужен человек, который будет посредником между бизнесом и ИТ, который хорошо разбирается в финансах, процессе разработки программного обеспечения и может очень быстро разобраться в сути бизнеса заказчика. Как правило, этим занимаются системные аналитики.
Теперь переключимся на работу системного аналитика. Есть задача — разобраться в принципе работы бизнеса, создать документацию, которая сможет оценить время, необходимое на разработку программного обеспечения. Оценка времени, как правило, может быть либо грубой, либо более-менее детальной. В первом случае не будет создано подробное техническое задание, а будет только создана модель архитектуры. Во втором случае будет разработано детальное ТЗ, которое уже будет готово для старта процесса разработки.
Естественно, зная количество времени, которое потребуется для разработки, зная платформу, на базе которой будет производится разработка, уже можно более-менее рассчитать сумму вложений для проекта. А когда есть цифра, которая рассчитана и обоснована, то уже есть о чем говорить с инвестором.
Следующий шаг в расчетах — это попытка оценить возможную прибыль при монетизации проекта. Как правило, многие этого не делают. Но для инвестора этот момент тоже очень важен. Так как для того, чтобы он решился вложить деньги, ему необходимо знать, что он с этого сможет в итоге заработать.
СОЗДАЕМ ТЗ ДЛЯ ПРОЕКТА
Я не буду очень подробно останавливаться на этом вопросе, но пройдусь по основным моментам, которые помогут понять что к чему.
1. Очень подробно описывается идея проекта. Аргументируется эта идея. Почему она должна сработать. Какие конкуренты уже присутствуют на рынке. Какая у них доля рынка. Насыщен ли данный рынок или испытывает голодание на подобное решение.
2. Каким образом планируется монетизация проекта. Этот пункт также можно связать и с выбором платформы. Это будет онлайн приложение или десктоп версия. Анализ того, какая версия лучше, более гибкая и масштабируемая. Каким образом будет происходить оплата за приложение. Например, платная программа с индивидуальным ключом. Онлайн доступ к программе (сайту) на определенное время (лимитированный доступ) и т.д. Это важный момент и его нужно продумывать сразу. Так как ошибка в этом вопросе, может в будущем поставить крест на всем проекте.
3. Выяснив во втором пункте, какая будет платформа, можно уже строить архитектуру. Архитектуру нужно продумывать очень и очень внимательно. Если сделать грубую ошибку, то можно в последствии прийти к тому, что дальнейшее наращивание функционала будет невозможно. А значит все время и деньги были потрачены впустую. Архитектура должна быть максимально модульной со слабо связанными компонентами. Это поможет легко добавлять новый функционал и изменять старый.
4. Нужно продумать, каким образом будут хранится данные в базе данных. Продумать таблицы для данных и их связи. Если проект будет большим, сразу нужно думать не об одной базе, а о большем их количестве, где и как их размещать (на разных серверах). И как они будут связаны в едином проекте. Часто сталкиваюсь с такой картиной, что базы раздуты до терабайтов, и уже сделать с ними что-либо просто нереально.
5. Если предполагается, что будет много разных проектов на базе одной платформы, то нужно продумать, как им лучше работать. Не стоит пихать весь функционал в один гигантский сайт. Лучше разнести все по разным серверам. Но тогда придется делать промежуточный сервер, где будет происходить авторизация и т.д.
6. Нужно сразу предусмотреть то, что сейчас вам может и не нужно. Так как когда вам это понадобится, вы потратите финансов в десятки раз больше! Я имею ввиду не сразу создавать функционал, а грубо говоря, построить фундамент для возможного функционала. Как правило, таким фундаментом является свой АПИ, благодаря которому, можно делать разные вещи. Например, подключить лабораторное оборудование, которое будет записывать результаты экспериментов сразу в базу проекта. Или, к примеру, можно будет продавать для разных партнеров доступ к вашим данным.
7. После того, как были изучены тонны документов по физике, понятна суть проекта и на основании этого создана модель базы данных, то самое время подумать над тем, как эти данные будут записываться в базу, и как они будут получаться из базы. А значит, требуется продумывать интерфейсы, через которые будут заноситься данные. Речь сейчас идет именно о статистических данных, на основании которых будет коррелироваться результат расчетов.
8. Нужно продумать независимую модульную систему для формул, которые будут производить расчет. Формулы должны быть не связаны друг с другом и полностью независимы. А уже в самом проекте, когда и где это необходимо, то обращаться к формуле, отдавая ей данные и получая от нее результат. Это вам позволит, в случае каких-либо изменений, сделать изменения только в маленьком и отдельном модуле. При этом ничто другое не пострадает и не повлияет на работу самого проекта.
9. Для подобных сложных проектов просто необходима система самодиагностики. Она должна быть разбита на две части. Первая — это диагностика базы данных, на корректность данных. Ведь речь идет о сложных математических расчетах. А значит, даже маленькая ошибка (например, некий коэффициент в базе равен не 0.5, а 0.6) может привести к фатальным последствиям. Для этого нужно иметь некие эталонные данные, которые будут сверятся с реальными в базе. И если реальные данные вышли за предел допустимого порога, то администратор должен это знать и сам принять решение, что с этим делать. Тоже касается и формул вместе с входными параметрами. Параметры должны быть только в рамках допустимой погрешности.
10. Пользовательский интерфейс. Этот вопрос тоже очень важен. Система должна быть интуитивно понятна, легка в использовании и очевидна.
11. Система защиты данных и общая взломоустойчивость. Об этом моменте тоже не стоит забывать. Если какой-то хакер сможет обрушить ваш сервер или украсть ваши данные, то не о каком бизнесе тогда вести речь будет нельзя.
12. Автоматизированная система оплаты и доступа к системе. Этот процесс должен быть полностью автоматизирован. Должны строиться понятные и подробные отчеты. Нужна система анализа данных по платежам (что-то типа финансового отчета). Автоматические уведомления пользователей и администраторов.
13. Система подробного анализа пользователей. Производимых ими расчетов и действий в системе. Это поможет находить узкие места в проекте и улучшать качество вашего приложения.
14. Лицензирование. Защита авторских прав. Ну тут без комментариев. Если вы хотите получить серьезного корпоративного клиента, то вы должны позаботиться о том, что ваше программное решение имеет международную лицензию, которой можно доверять.
Конечно, это не все пункты. Но для понимания процесса, этого вполне достаточно. Каждый из этих пунктов дробится на более мелкие задачи. Те в свою очередь также дробятся. В итоге получается огромное дерево процессов (листики на дереве). И каждый мелкий процесс (задачу) уже можно достаточно точно просчитать по временным затратам.
Также к этому времени нужно прибавлять затраты на производственные мощности, на рекламу и раскрутку, и еще множество разных факторов, которые невозможно сразу просчитать, но которые обязательно возникнут.
В финале, этого тяжелого и кропотливого труда, появится приличный пакет документации, из которого можно оценить уровень сложности проекта, его амбициозность, масштабы и конечную стоимость реализации. И порой бывает так, что тот, кто придумал интересную идею, думает, что для ее реализации понадобится пару тысяч долларов, а на самом деле она может обойтись в сотни тысяч, а то и миллионов долларов.
Естественно, то о чем я сказал выше, касается сугубо профессионального подхода. Если делать это на тяп-ляп, типа «и так сойдет», то получим примерную картину того, почему большая половина интернета представляет из себя помойку, а не технологический шедевр.
Всем спасибо и до новой встречи.
BRELA
УВЕДОМЛЕНИЕ ДЛЯ ОБЩЕСТВЕННОГО ОБЩЕСТВА (TAARIFA KWA UMMA) => Исключение зарегистрированных компаний с ограниченной ответственностью, не имеющих уставного капитала, цели которых
Читать далее
Программа магистра интеллектуальной собственности (MIP)
Программа MIP в UDSM предоставляет студентам платформу для углубленного обучения и исследований по широким аспектам и взаимодействию политики интеллектуальной собственности и нормативным вопросам, поскольку они применяются в широком спектре проблем развития общества.Основное внимание уделяется разработке индивидуального
Читать далее
MAHITAJI YA USAJILI KWA NJIA YA MTANDAO
Вакала я Усаджили ва Биашара на Лесени (БРЕЛА) инапенда кууарифу умма
кува имэкамилиша мфумо ва усаджили ва макампуни ч
Читать далее
Программа MIP в UDSM предоставляет студентам платформу для углубленного обучения и исследований по широким аспектам и взаимодействию политики интеллектуальной собственности и нормативным вопросам, поскольку они применяются в широком спектре проблем развития общества.Основное внимание уделяется разработке индивидуального
Читать далее
УВЕДОМЛЕНИЕ ДЛЯ ОБЩЕЙ ОБЩЕСТВЕННОСТИ (TAARIFA KWA UMMA)
УВЕДОМЛЕНИЕ ДЛЯ ОБЩЕСТВЕННОГО ОБЩЕСТВА (TAARIFA KWA UMMA) => Исключение зарегистрированных компаний с ограниченной ответственностью, не имеющих уставного капитала, цели которых
Читать далее
Программа магистра интеллектуальной собственности (MIP)
Программа MIP в UDSM предоставляет студентам платформу для углубленного обучения и исследований по широким аспектам и взаимодействию политики интеллектуальной собственности и нормативным вопросам, поскольку они применяются в широком спектре проблем развития общества.Основное внимание уделяется разработке индивидуального
Читать далее
Агентство по регистрации и лицензированию предприятий (BRELA) хотело бы улучшить предоставление услуг своим клиентам. Если у вас есть общие или особые проблемы, зарегистрируйте их по электронной почте [email protected] или по следующим номерам мобильных телефонов, которые будут доступны круглосуточно ,
Узнать больше
УВЕДОМЛЕНИЕ ДЛЯ ОБЩЕСТВЕННОГО ОБЩЕСТВА (TAARIFA KWA UMMA) => Исключение зарегистрированных компаний с ограниченной ответственностью, не имеющих уставного капитала, цели которых
Читать далее
Программа магистра интеллектуальной собственности (MIP)
Программа MIP в UDSM предоставляет студентам платформу для углубленного обучения и исследований по широким аспектам и взаимодействию политики интеллектуальной собственности и нормативным вопросам, поскольку они применяются в широком спектре проблем развития общества.Основное внимание уделяется разработке индивидуального
Читать далее
Имена и никнеймы для TZ
꧁ ༺ J꙰O꙰K꙰E꙰R꙰ ༻ ꧂
༄ ᶦᶰᵈ᭄✿ Gᴀᴍᴇʀ ࿐
Sᴋ ᭄ Sᴀʙɪʀᴮᴼˢˢ
꧁ ༺ J꙰O꙰K꙰E꙰R꙰ ༻ ꧂
『sʜʀᴋ』 • ᴮᴬᴰʙᴏʏ ツ
꧁ঔৣ☬✞𝓓𝖔𝖓✞☬ঔৣ꧂
༄ ᶦᶰᵈ᭄✿ Gᴀᴍᴇʀ ࿐
ᴹᴿ メ Й а ч М а т и ☂️
꧁ ☆ ☬κɪɴɢ☬ ☆ ꧂
꧁ ༒ ☬☠Ƚ︎ÙçҜ ყ☠︎☬ ༒ ꧂
꧁ঔৣ☬✞𝓓𝖔𝖓✞☬ঔৣ꧂
❖Mʀ ᭄ נ o κ ᴇ ʀᴮᵒˢˢ
꧁ঔৣ☬✞𝓓𝖔𝖓✞☬ঔৣ꧂
Sᴋ ᭄ Sᴀʙɪʀᴮᴼˢˢ
꧁ ༒ ☬ ₣ ℜøźєη • ₣ ℓα ₥ є ֆ☬ ༒ ꧂
★ 彡 [ᴅᴇᴀᴅ ᴋɪʟʟᴇʀ] 彡 ★
🅑🅛🅐🅒🅚🅟🅐🅝🅣🅗🅔🅡
Sᴋ ᭄ Sᴀʙɪʀᴮᴼˢˢ
༄ ᶦᶰᵈ᭄✿ Игры ࿐ ᴮᵒˢˢ
꧁ ༒ 𓆩 ₦ ł ₦ ℑ ₳ 𓆪 ༒ ꧂
꧁ ༒ ☬ᤂℌ໔ℜ ؏ ৡ☬ ༒ ꧂
꧁ ༺ ₦ Ї ₦ ℑ ₳ ༻ ꧂
꧁ ༺ ₦ ༏ ₦ ℑ ₳ ༻ ꧂
꧁ ༒ ☬ℜ؏ α Ꮮ_Ꮶ ιηGs☬ ༒ ꧂
꧁ ༒ 𝕱𝖎𝖌𝖍𝖙𝖊𝖗🅜 ༒ ꧂
Fɪɴᴀʟ 乂 Sᴛʀɪᴋᴇ
꧁ ༒ Ǥ ₳ ₦ Ǥ ֆ Ƭ Ꮛ Я ༒ ꧂
,