Пример тз для сайта: полное руководство + шаблон (уникальный)

Еще по теме:

Олег Галеня

Middle PHP Developer

Оцените мою статью: 

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

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

Как сделать простое техническое задание и не потерять деньги и нервы / Хабр

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

Что было раньше

На многих проектах это выливалось в следующие проблемы:

1. Описан внешний вид, но не принцип работы. Простой пример с корзиной интернет-магазина. В ТЗ было написано “Кнопка “Оформить заказ”. Но что должно произойти, когда пользователь нажал на эту кнопку? По каким правилам формируется номер заказа? Какой статус ему присваивается? Куда идет переадресация? А если один из товаров раскупили, пока пользователь оформлял заказ? На эти и многие другие вопросы в ТЗ ответов не было, а ведь это лишь один небольшой элемент. Подобные неописанные моменты приводили к спорам с Заказчиком, сильному выходу из бюджета и прочим неприятным последствиям.
2. Отсутствие переиспользуемых блоков. На многих сайтах есть одинаковые блоки, используемые в разных местах, например, превью товара. Но данный блок в результате описывался в каждой странице. Это очень плохо по нескольким причинам. Во-первых, при необходимости изменения надо вносить сразу в нескольких местах, можно что-то упустить и будет несоответствие. Во-вторых, даже при одинаковых элементах в превью, заказчик может потребовать сделать их по-разному, что влечет за собой дополнительные затраты.
3. ТЗ не коррелирует с задачами для команды. Чем дальше постановка задачи от реальности, тем ниже будет качество на выходе. Это еще одна проблема, которую хотелось решить.
   

Новый подход

ТЗ состоит из следующих разделов:

1. Введение
2. Статика
3. Динамика
4. Задачи
5. Административная панель
6. Общие технические требования

Введение и подготовка к реализации

• Кратко описываем проект, его цели, ЦА, оставляем ссылки на предпроектную аналитику.
• Описываем процесс инициализации проекта: настройку окружения для разработчиков и подход к разработке концепции дизайна для дизайнеров.
• Принципы адаптивности или разбиения на версии. Последнее время в своей работе мы придерживаемся следующего принципа — “адаптивь все, что адаптивится”. Иначе говоря, в начале работы над ТЗ мы понимаем, какой сложный функционал нам нужен (или может понадобиться в ближайшем будущем) и вместе с дизайнером и front-end разработчиком придумываем способы его заадаптивить. При новом подходе отрицательных результатов еще не было, поэтому отдельные версии описывать не приходилось.

Статика

Как мы все знаем, страницы могут содержать либо статическую информацию, либо динамическую, присылаемую с сервера. Подразделы статики — страницы проекта. Каждую страницу мы разбиваем на блоки. Если блок статический, то мы описываем его суть и вид контента. Например, описание одного из блоков страницы “О компании” может выглядеть так. “Основные преимущества компании. 5-6 иконок с описаниями.” Это очень краткое, но достаточное для точной оценки описание блока. При описании статики главная цель — задать четкие рамки. Сделать адаптив иконок не составит труда, а с графиком или таблицей все не так просто и однозначно. Но при этом нам не важно какие именно будут иконки и подписи к ним.

Если же страница содержит блок, который можно “вынести за скобки”, то в месте его интеграции мы пишем “Интегрируется функционал “NAME”, а сам функционал описываем в разделе “Динамика”.

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

Динамика

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

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

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

Административная панель

Здесь описываем структуру, модели и поля. Разбиение идет по разделам, например, “Товары”, “Каталог”, “Заказы” и т.д. Описываем что разные роли пользователей могут просматривать, что редактировать.

Общие технические требования

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

1. SEO-требования к тегам и микроразметке
2. Правила транслитерации
3. Ручное и автоматическое тестирование
4. Поддерживаемые браузеры
5. …

Новые версии

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

Пример

Статика

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

Интегрируется следующий функционал:

1. “Хлебные крошки”
2. “Дерево каталога”
3. “Фильтрация. Общие положения”
4. “Фильтрация. Текст”
5. “Фильтрация. Текст и изображение”
6. “Фильтрация. Диапазон”
7. “Сортировка. По умолчанию”
8. “Сортировка. По возрастанию цены“
9. “Сортировка. По убыванию цены”
10. “Превью товара. Плитка”
11. “Пагинация. Постраничная”
12. “Текстовый блок”. Интегрируется в виде блока для SEO-текста перед подвалом сайта

Динамика

Функционал “Фильтрация. Общие положения”

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

• выпадающий список закрывается, а фильтр применяется. В текущем разделе остаются только товары, соответствующие текущим активным фильтрам
• название кнопки фильтра приобретает вид: “Название фильтра: K”, где K — количество выбранных значений фильтра, если их 2 или больше, или “Название фильтра: значение”, если было выбрано одно значение.
• цвет кнопки фильтра меняется на вид используемого фильтра
• в значениях других фильтров остаются только варианты, удовлетворяющие текущим активным фильтрам. Если в одном из неактивных фильтров остается одно значение, его кнопка приобретает вид неактивной, а название выводится в формате “Название фильтра: значение”
• у всех активных фильтров после названия добавляется крестик, при клике на который сбрасывается только этот фильтр
• пагинация сбрасывается

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

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

Выбранные фильтры добавляются в URL посредством query-параметров.

Функционал “Превью товара. Плитка”

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

1. Цена (целое число в рублях РФ)
2. Название товара
3. Метка “В магазине” или “С витрины”
4. Изображение
5. Размер
6. Кнопка “В корзину” (Интеграция функционала “Добавить в корзину”)
7. Кнопка “В избранное” (Интеграция функционала “Добавить в избранное”)

На одной строке должно помещаться 3-4 плитки с превью товара.

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

Административная панель

Товар

Список всех товаров с фильтрацией. При редактировании/добавлении товара доступны следующие поля:

1. Название (текст)
2. Бренд (радио)
3. Изображения
4. Цена (целое число)
5. Описание (текстовый блок)
6. Тип (магазин/витрина, радио)
7. Состояние. Значение включает в себя Название (текст) и Пояснение (текст).
8. Статус. Возможны варианты:
   
   1. на продаже
   2. на модерации
   3. на доработке
   4. отклонен
   5. продан
   6. не прошел проверку
   7. отменен Продавцом
9. Размер с бирки (необязательное). Текстовое поле без валидации
10. …

Выводы

1. Полнота. Данное ТЗ позволяет однозначно описывать требования, что является основным и необходимым параметром любого ТЗ.
2. Понятность. Около половины наших клиентов не имеют на своей стороне технического специалиста и сталкиваются с разработкой впервые. Поэтому очень важно было сделать ТЗ максимально понятным и читаемым. И у нас получилось! Даже технически не подкованные клиенты понимают, как оно устроено, могут спокойно его читать и давать отличную обратную связь.
3. Молекулярность. ТЗ полностью соответствует нашим требованиям к разбиению на отдельные элементы, что значительно упрощает и решает проблемы, описанные выше. Блоки ТЗ напрямую соответствуют задачам, которые выполняются разработчиками, что было встречено на ура. Также ТЗ отлично ложится на дизайн-систему (про нее статья выйдет уже на следующей неделе).
4. Простота оценки и конфигурации сметы. Хорошо описанные и разбитые задачи стало просто и приятно оценивать. Если во время оценки мы понимаем, что требования неполные, то дописываем их. Под каждый проект (этап) делаем гугл таблицу, в которой заказчик может попробовать разные конфигурации проекта и определить наиболее подходящий для себя вариант по цене/функционалу.
5. Взаимодействие с заказчиками поднялось на новый уровень. Внесенные изменения позволяют четко определить границы проекта. Если необходимо внести изменения относительно ТЗ, это оценивается как новая задача, хотя при старом подходе это вызывало много споров.
6. Рентабельность. Т.к. это в первую очередь бизнес, данный показатель наравне с предыдущим является одним из самых важных. Детальная проработка позволила свести количество плохо оцененных задач к минимуму. Ни по одному из проектов, реализуемых по новому подходу, не было превышения бюджета.

1. Внесение доработок. На одном из проектов было необходимо ввести статусы товаров. В итоге получилось огромное количество доработок по 2-3 строчки. Нельзя это назвать явным минусом, т.к. полното требований в приоритете, но и идеальным данных подход назвать нельзя.
2. Сложность восприятия при автоматизации бизнес-процессов. Если взять бизнес-процессы некоторых компаний от момента продажи до получения товара покупателем, не всегда есть возможность (или необходимость на первых этапах) покрыть весь процесс за счет Статики, Динамики и АП, т.к. многие задачи выполняются вручную, обсуждаются с клиентами по телефону и т.д. Это немного усложняет восприятие ТЗ в чистом виде, и требует дополнительного описания процессов.
3. Стоимость и время разработки. Продавать ТЗ, конечно, стало сложнее, ведь далеко не все при первом контакте с разработкой готовы платить за него 10-20% от проекта при том что многие наши конкуренты берут за него 10-20 тыс. Но подобная работа сполна окупается при реализации, снижая риски проекта и улучшая качество.

Мы настолько довольны результатом, что решили отказаться от стандартных тасктрекеров в пользу доработки Google Docs для полноценной работы с задачами на основе ТЗ. Если опыт будет удачным, напишем об этом отдельную статью. А пока ждем от вас объективную критику и советы, с надеждой, что кому-то эта статья помогла).

Ликбез по техническому заданию / Хабр

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

Время чтения: 7 минут.

Отправная точка — требования

Хочу пирожное, потом морожное!
Вовка в тридевятом царстве

Через полгода вас ожидает нечто в поле и вообще с забором серобуромалинового цвета.

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

Удобный вид требований — ТЗ

Замесить и нарубить!
Вовка в тридевятом царстве

Его также называют ТЗ, SRS, PRD — все это названия документа, в котором в правильной форме зафиксированы требования к продукту.

Подводный камень №2: память человека не безгранична, всегда лучше иметь одно место, где все ваши пожелания и требования зафиксированы (не переписка в telegram или звонок по телефону). Поэтому ТЗ это печатный текстовый документ с приложением схем и инфографики, не написанный от руки или сфотографированный. Лучше всего в формате .PDF или Google Docs.

Рецепт грамотного ТЗ

• Концептуальная модель
• Функциональная карта
• Путь пользователя
• Пользовательский интерфейс
• Программные интерфейсы
• Нефункциональные требования

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

Концептуальная модель

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

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

Стоит рассказать о типах пользователей и их ключевых отличиях.

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

И в завершении расскажите о компонентах вашего продукта.

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

Высшим пилотажем будет сделать так называемый data flow или контекстную диаграмму, в которой будет отражено как пользователи взаимодействуют с продуктом, его компонентами и между собой.

Функциональная карта

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

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

Путь пользователя

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

Путь пользователя — это общий алгоритм работы с продуктом. Также существует еще use cases (варианты использования) — это детализация user flow. В случае мобильного приложения для знакомств вы создали путь пользователя по экранам, а затем описываете, что пользователь может сделать на каждом экране.

Например: на экране регистрации пользователь может:
перейти на экран авторизациизарегистрироваться через соцсети (Facebook, Twitter)может ввести почту, пароль, затем его повторить и подтвердить регистрацию в письме, пришедшем на почту.

Пользовательский интерфейс

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

Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например flat design или material design.

Высшим пилотажем будет добавить wireframes (вайрфреймы) — прототипы интерфейса продукта в виде приближенных схем.

Программные интерфейсы

Сервер декомпозируется на модули: базы данных, аутентификации, чата и т.д.Клиент связывается с сервером через API (интерфейсы передачи данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать методы, ответы и обработку ошибок.

Данные обычно хранятся в базе данных в виде специальных структур, чаще всего таблиц (для реляционных БД) и json структур (для нереляционных). Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля, с указанием их типов данных (string, int и т.д), ключей (primary, foreign), обязательности (required) и пустого значения (nullable).

Нефункциональные требования

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

Советы

1. Создавайте текстовый документ в онлайн офисе или PDF, который легко будет прочесть. Это гораздо лучше переписки в чате или голосового сообщения, его всегда можно будет посмотреть с любого устройства.
2. Соблюдайте последовательность, переходите от общих требований к частным, приведенная выше структура не идеальна, но может служить хорошей основой.
3. Все требования должны быть в одном документе или вики-структуре, не храните их отдельно, они должны быть всегда доступны из одного источника.
4. Давайте четкие и разумные указания, избегайте неточностей, пишите максимально простым языком.
5. Описывайте ваши требования максимально подробно. Лучше один раз все продумать, чем постоянно уточнять различные детали и нюансы.
6. Приготовьтесь потратить больше нескольких дней или обратитесь к профессионалу для составления документа. Грамотное техническое задание спасет вас от долгих обсуждений деталей с разработчиками и обозначит четкие критерии сдачи проекта. Например, полноценное ТЗ по стандарту IEEE-830, приложенное к договору на разработку, является аргументов в суде в случае невыполнения требований.

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

Во-первых, прежде чем вы спросите: «Зачем мне нужно техническое задание для моего бизнеса», вы можете спросить: «Что вообще такое техническое задание для проекта?»

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

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

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

К вашему сведению: Хотите узнать стоимость вашей веб-разработки? Попробуйте наш веб-калькулятор.

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

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

• Это сокращает время разработки и, в конечном итоге, удешевляет разработку. Над макетом работать быстрее и, как следствие, не тратить время, особенно при интеграции. Спецификации никогда не должны заканчиваться. Вместо этого их должно быть в избытке.
• Масштабируемость рабочих групп проста, поскольку процесс уже описан, а новые разработчики без напряжения понимают технические требования. Вся команда может работать над большим проектом без недоразумений и проблем.
• То же самое касается масштабируемости вашего продукта — процесс намного проще, когда все работают на одной странице. Кроме того, если вы планируете большой проект, масштабируемость будет для него встроенным требованием, и поэтому вся инфраструктура будет создана таким образом, чтобы ее можно было легко масштабировать.
• Он предлагает разработчикам четко определенный план действий в непредвиденных обстоятельствах, так что вы не получите плакат с надписью «невыполнение плана ведет к провалу». Шансы на сбой сводятся к минимуму, поскольку разработчик знает требования и, следовательно, работает в рамках плана.

Подробнее о назначении ТЗ читайте в нашей статье.

Создание документов технических спецификаций: шаги и формат

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

Таким образом, ваш документ TS должен включать следующее:

• Оглавление: обычно техническая документация представляет собой объемный документ, поэтому оглавление помогает сориентироваться в нем.
• Написание актуальных спецификаций
• Присвоение титулов (подписные блоки для органов власти)
• Определение используемых терминов

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

Оценка

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

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

Требования

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

Стиль письма имеет решающее значение при подготовке.

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

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

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

Сборка документа

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

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

10 ключевых пунктов о том, как написать спецификацию веб-сайта

Мы знаем два разных типа спецификаций: один — это то, что клиент предоставляет при заказе нового веб-проекта, а другой — техническая проектная документация, которая создается агентством веб-дизайна при получении спецификации клиента.

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

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

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

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

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

Необходимые элементы и вопросы для создания спецификации:

1. Общая информация о компании или физическом лице / покупателе

Общая информация представляет собой элементарное введение для спецификации и предоставляет соответствующую информацию о:

• Какая компания это ( Название компании)
• Деятельность компании
• Количество сотрудников
• Конкурс (ссылка на веб-сайты конкурса)

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

2. Это полностью новый проект или это редизайн / перепрограммирование существующего?

Конкретные вопросы, на которые клиент должен дать ответ:

• Есть ли у вас в настоящее время веб-сайт?
• Какой у этого веб-сайта адрес?
• Вы хотите изменить дизайн сайта или полностью новый сайт?

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

3. Что конкретно вы ожидаете от веб-сайта?

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

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

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

4. К какому типу относится ваш веб-сайт?

Типы веб-сайтов:

• Корпоративная презентация компании
• Персональная страница
• Интернет-магазин (сайты электронной коммерции)
• Веб-приложение
• Социальная сеть
• Портфолио
• Блог
• Веб-сайт с особыми функциями

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

5. Структура веб-сайта

• Какое количество веб-страниц?
• Карта сайта очень полезна
• Сколько разных типов страниц / макетов (Домашняя страница, О нас, Портфолио / Галерея, Контактная страница)
• Это одноязычный или многоязычный веб-сайт, и какое количество языков?

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

Веб-пакеты — не лучшее решение для клиентов.

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

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

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

Домашняя страница является доминирующей страницей, но она необходима, чтобы уделять внимание всем остальным страницам.

6. Статический или динамический веб-сайт

• Кто будет импортировать контент на веб-сайт (покупатель или агентство)?
• Нужна ли сайту система CMS, чтобы покупатель мог импортировать контент?
• Как часто вы планируете изменения на сайте и какие элементы вы бы изменили?

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

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

7. Функциональность веб-сайта

Это один из важнейших пунктов.

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

Пример 1:

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

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

Для функциональности важно указать, является ли это интернет-магазином, социальной сетью, сайтом аукциона, порталом для недвижимости или поиском туристических направлений…

Пример 2:

Необходимо указать 10 компаний / Депутаты на сайте, и для каждой компании есть 3 категории и 2 подкатегории.Я также хочу, чтобы вы создали полную функциональность, категории и подкатегории, а мы добавим продукты. Оплата будет производиться доставкой, кредитной картой, PayPal…

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

8. Бюджет

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

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

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

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

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

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

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

9. Сроки

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

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

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

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

10. Дополнительная информация

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

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

• Скачать бланк заявки / проектной документации —
• Скачать заполненный заказ / проектную документацию —

Основатель PopArt Studio d.o.o.

5 шагов к созданию технической документации, которая (на самом деле) полезна

Джори МакКей

Джори — писатель, контент-стратег и отмеченный наградами редактор Unsplash Book. Он вносит свой вклад в Inc., Fast Company, Quartz и другие.

15 ноября 2018 г. · 11 мин чтения

🎁 Бонусный материал: шаблон технической документации

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

Напишите свой? Вот бесплатный шаблон и контрольный список!

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

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

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

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

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

Но сначала краткий обзор этой статьи:

Когда, почему и как правильно использовать техническую документацию

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

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

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

• Поддержка конечных пользователей: Это означает такие вещи, как руководства пользователя, примечания к выпуску, интерактивные справочные системы, программы обучения или рабочие процедуры — все, что помогает пользователям использовать ваш продукт.
• Маркетинговая поддержка: Все, что ориентировано на продукт и используется для продвижения вашей компании (например, поясняющие видеоролики, презентации или технические целевые страницы)
• Поддержка разработки: Это могут быть функциональные и технические спецификации, руководства по разработке программного обеспечения или просто процедуры и инструменты, которые помогут вашим разработчикам выполнять свою работу.
• Поддержка организации: Информация о вашей компании, структуре, процедурах, рабочих процессах, политиках и все остальное, что необходимо знать товарищам по команде для выполнения своей работы.

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

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

Итак, как же создать эти четкие, краткие и удивительно полезные документы?

Напишите свой? Вот бесплатный шаблон и контрольный список!

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

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

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

Шаг 1: Проведите исследование и создайте «План документации»

Как гласит старая пословица: «Напишите то, что вы знаете».

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

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

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

• Цели: Проще говоря, что вы хотите, чтобы люди могли делать? Это для использования вашего продукта? Находите справочные документы быстро и легко? Узнайте, как использовать определенные аспекты вашего инструмента? Разрешить товарищам по команде запрашивать ресурсы или заказывать оборудование? Наличие и знание четкой цели необходимо для написания хорошей технической документации и поможет информировать обо всем, что вы делаете.
• Существующие ресурсы: Что сейчас доступно? Вы обновляете или объединяете текущие ресурсы или начинаете с нуля? Есть ли старые, устаревшие версии, которые нужно убить? Сделайте быстрый аудит и найдите все, что поможет вам писать или запутать аудиторию, если они это найдут.
• Руководства по стилю: В некоторых отраслях требуется, чтобы вы писали техническую документацию определенным образом (например, рекомендации на простом языке для правительственных сайтов или упрощенный технический английский для аэрокосмических, авиационных или оборонных компаний).В других случаях у вашей компании может быть руководство по стилю, в котором объясняется, какой язык использовать, как разговаривать с пользователями и даже грамматические стили.
• Описание тем: Какие темы и подтемы вы будете освещать в своей технической документации? Думайте об этом как о содержании и попытайтесь перечислить все основные разделы и подразделы, которые, по вашему мнению, вам понадобятся.
• Инструменты и управление: Какое программное обеспечение, инструменты или веб-сайты будут использоваться для создания и управления документацией? Ссылка на соответствующие руководства по стилю.
• Срок и окончательные результаты: Когда он должен быть и в каком формате он будет? Техническая документация касается не только содержания, но и структуры и доставки. А знание того, как будет представлен контент, перед тем, как вы начнете, расскажет вам, что вам нужно и куда приложить усилия.

Шаг 2: Структура и дизайн

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

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

Вот несколько быстрых советов для каждого:

Используйте шаблоны или «схемы» для согласованного дизайна на странице

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

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

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

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

• Название: Что это?
• Подзаголовок: Дополнительная информация
• Обзор : Что вы узнаете
• Содержание: Внутренняя навигация
• Функции: Каждый раздел документа
• Читать далее: Связанные документы, которые могут помогите пользователю

Вот пример использования Planio wikis:

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

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

Создайте простую логическую структуру навигации

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

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

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

Шаг 3. Создайте контент

Хорошо! Имея план документации и структуру , пора серьезно заняться созданием технической документации.

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

Начните с черновика

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

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

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

Несколько простых советов по хорошему письму:

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

1. Пишите как человек : используйте простой, ясный язык, когда это возможно. Мы все читали те документы, которые звучат так, будто Google Translate пошел не так, как надо. Если вы замечаете, что произносите неловкие предложения или сложный язык, отойдите на несколько минут. Иногда возвращение к письму после короткого перерыва — это все, что нужно, чтобы освежить сознание.
2. Помните, ваши читатели — это не вы: Золотая заповедь технического письма — , не принимайте . Вам может показаться, что вы слишком очевидны, но вы должны четко осознавать уровень знаний вашей аудитории. Не думайте, что они знают даже наполовину меньше вас.

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

3. Напишите столько, сколько нужно, чтобы быть полезным, и ни слова больше: Короткое письмо — хорошее письмо.Используйте форматирование, чтобы разбивать большие фрагменты текста и сохранять четкость в центре внимания. Как пишет технический писатель Amazon Том Джонсон: «Хороший технический писатель сокращает количество слов до нужной краткости, не делая ничего неясного».
4. Помните о силе визуальных эффектов: Это еще одно клише, но изображения действительно говорят тысячу слов. По возможности визуализируйте то, что вы говорите, а не пытайтесь это объяснить.

Используйте правило 30/90, чтобы получить обратную связь

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

Если вы не являетесь экспертом в той теме, о которой пишете, неплохо было бы, чтобы эксперт по предмету (SME) пришел на рассмотрение после первого и окончательного черновиков. Обратная связь — это уже само по себе умение. Что касается технической документации, то один из лучших способов ее оформления — это то, что Джейсон Фридман называет «обратной связью 30/90».

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

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

Получите экспертные оценки и внесите исправления

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

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

Редактировать, редактировать и еще раз редактировать

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

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

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

Шаг 4: Доставка и тестирование

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

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

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

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

Наконец, проверяет удобство использования / проблемы с UX . Пользователи теряются или сбиваются с толку? Разве они не получают ответы, которые искали (или думали, что получали на основе заголовков или навигации?). Опыт пользователя сводится к большему, чем просто то, что вы написали. Найдите время поработать со сторонними тестировщиками, чтобы убедиться, что, когда реальные пользователи приходят к вашим документам, они уходят довольными.

Шаг 5. Составьте график обслуживания и обновления

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

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

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

4 дополнительных качества отличной технической документации

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

1. Эффективность разработки и использования: Дублированный контент, неорганизованная структура и нечеткие процессы могут убить техническую документацию. Используйте такой инструмент, как wikis от Planio, чтобы сохранять организованный и эффективный контент.
2. Актуальная информация: Нет смысла предоставлять пользователям неточную информацию или показывать им устаревшие скриншоты, которые не похожи на то, с чем они имеют дело.Поддерживайте актуальность вашей технической документации.
3. Единый дизайн и структура: Каждый раз, когда вы вступаете в контакт с вашими пользователями, наступает время для создания вашего бренда. Придерживайтесь своего дизайна, стиля и тона во всей онлайн-документации.
4. Доступен где угодно : Мобильная связь захватывает мир. Ваша техническая документация, как и остальная часть вашего веб-сайта или приложения, должна быть гибкой и обеспечивать удобство для пользователей на всех устройствах.

Технические документы могут воодушевить или расстроить — выбор за вами

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

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

Напишите свою собственную техническую документацию, используя наш шаблон!

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

Что такое функциональная спецификация?

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

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

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

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

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

• Требования . Это формальное заявление о том, что, по мнению специалистов по планированию продукта, исходя из своих знаний о рынке и конкретного вклада существующих или потенциальных клиентов, необходимо для нового продукта или новой версии существующего продукта. Требования обычно выражаются в виде повествовательных утверждений и в относительно общем виде.
• Цели . Цели пишутся дизайнерами продукта в соответствии с требованиями. Они более конкретно описывают, как будет выглядеть продукт. Цели могут описывать архитектуры, протоколы и стандарты, которым будет соответствовать продукт. Измеримые цели — это те, которые устанавливают некоторые критерии, по которым можно судить о конечном продукте. Измеримость может выражаться в показателях удовлетворенности клиентов или в терминах возможностей и времени выполнения задач. Цели должны учитывать ограничения по времени и ресурсам.График разработки часто является частью или следствием целей.
• Функциональная спецификация . Функциональная спецификация (называемая функциональной спецификацией или просто спецификацией для краткости) является формальным ответом на цели. В нем описаны все внешние пользовательские и программные интерфейсы, которые должен поддерживать продукт.
• Запросы на изменение конструкции . На протяжении всего процесса разработки, когда признается необходимость изменения функциональной спецификации, формальное изменение описывается в запросе на изменение конструкции.
• Логическая спецификация . Структура программирования (например, основные группы модулей кода, которые поддерживают аналогичную функцию), отдельные модули кода и их отношения, а также параметры данных, которые они передают друг другу, могут быть описаны в формальном документе, называемом логической спецификацией. Спецификация логики описывает внутренние интерфейсы и предназначена для использования только разработчиками, тестировщиками и, позднее, в некоторой степени, программистами, которые обслуживают продукт и предоставляют исправления кода на местах.
• Пользовательская документация . Как правило, все предыдущие документы (кроме спецификации логики) используются в качестве исходного материала для технических руководств и онлайн-информации, например, страниц справки, которые подготовлены для пользователей продукта.
• План испытаний . Большинство групп разработчиков имеют формальный план тестирования, в котором описаны тестовые примеры, которые будут использовать написанное программирование. Тестирование выполняется на уровне модуля (или единицы), на уровне компонентов и на уровне системы в контексте других продуктов.Это можно рассматривать как альфа-тестирование. План также может допускать бета-тестирование. Некоторые компании предоставляют раннюю версию продукта избранной группе клиентов для тестирования в «реальной» ситуации.
• Готовый продукт . В идеале конечный продукт представляет собой полную реализацию функциональной спецификации и запросов на изменение дизайна, некоторые из которых могут быть результатом формального тестирования и бета-тестирования.

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

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

Как написать документ функциональных спецификаций

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

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

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

Форматы функциональной спецификации

Существует несколько форматов документа функциональной спецификации:

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

Преимущества функциональных характеристик

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

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

Инструменты, используемые для функциональных спецификаций

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

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

Разница между функциональными характеристиками и техническими характеристиками

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

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

Пример функциональной спецификации

Ниже приводится пример функциональной спецификации:

Диаграмма вариантов использования — помогает изобразить взаимодействие

.

No related posts.