Про бизнес-требования — Личный опыт на vc. ru
Пример написания функциональных требований к Enterprise-системе
Недавно мой друг, программист, рассказал, что он не читает требования, а вместо этого приглашает аналитика на чашку чая, они вместе садятся, и аналитик рассказывает, что должно быть реализовано. Мой друг — умный человек и хороший программист, и причина, почему он получает знания о требованиях именно так, не в том, что ему лень читать документацию, а в том, что, даже прочитав ее, он до конца не разберется, что же надо сделать. В данной статье я хочу рассказать, как можно написать требования к программному продукту так, что программисты не просто используют требования, но и участвуют в их написании; на основе собственно опыта я хочу показать, каким образом можно описать требования, чтобы эти описания были достаточными для реализации системы.
Целью нашей разработки было создание с нуля учетной системы для одной из крупных российских компаний. Система была призвана заменить текущую, написанную в конце 90-х. В результате были реализованы платформа и один из бизнес-модулей. В реализованной части было порядка 120 объектов, 180 таблиц, около 30 печатных форм.
Хочу оговориться, что подход, описанный ниже, не универсален для написания любого ПО. Он подходит для систем уровня предприятия, которые строятся на основе объектно-ориентированного подхода: учетных, CRM-, ERP-систем, систем документооборота и т.п.
- Общая часть
• Список терминов и определений
• Описание бизнес-ролей - Требования
• Бизнес-требования- Общие сценарии
- Сценарии использования
- Алгоритмы и проверки
Бизнес-требования описывали то, что необходимо бизнес-пользователям. Например, им вовсе не нужен объект системы Пользователь, но зато им нужно иметь возможность поменять стоимость товара в счете и распечатать его. Бизнес-требования состояли из общих сценариев, сценариев использования (use cases) и описания алгоритмов обработки данных. Подробно о разработке подобного рода требований можно узнать из книги Карла И. Вигерса и Джоя Битти Разработка требований к программному обеспечению.
Системные требования описывали свойства и методы всех объектов системы.
Нефункциональных требований в данной статье мы касаться не будем. Могу лишь отослать вас к отличной книге Architecting Enterprise Solutions авторов Paul Dyson, Andrew Longshaw.
Требования к интеграции описывали низкоуровневый интерфейс взаимодействия новой системы с несколькими другими системами компании. Здесь мы их рассматривать не будем.
Требования к пользовательскому интерфейсу – отдельная большая тема, возможно, для другой статьи.
Также здесь я не буду касаться других разделов документации, которые относятся к реализации, тестированию, руководствам и управлению.
Давайте рассмотрим подробнее, что такое список терминов и зачем он нужен.
Список терминов и определений
Очень часто при обсуждении функциональности системы разговор заходит в тупик. Еще хуже, если стороны расходятся, думая, что обо всем договорились, но в результате имеют разное понимание того, что надо сделать. Это происходит не в последней степени из-за того, что изначально участники проекта не смогли договориться о том, что значат те или иные термины. Бывает, что даже самые простые слова вызывают проблемы: что такое пользователь, чем отличается группа от роли, кто является клиентом. Поэтому в отличие от описания бизнес-ролей для терминов необходимо давать как можно более точные определения.
Поясню это на примере термина Пользователь. Википедия дает такое определение:
Пользователь — лицо или организация, которое использует действующую систему для выполнения конкретной функции.
Но нас оно не устраивало по нескольким причинам. Во-первых, в систему может зайти только человек, но не организация. Во-вторых, для нашей системы некорректно настоящее время глагола «использует» — система хранит данные о неактивных или удаленных пользователях, т.е. о тех, которые использовали систему ранее, но не могут в настоящее время. И наконец, у нас есть данные о потенциальных пользователях. Например, мы регистрируем сотрудника компании-клиента, который в дальнейшем может получить (а может и не получить) доступ в систему. Наше определение:
Пользователь — человек, который имеет, имел, или, возможно, будет иметь доступ в систему для совершения операций.
Теперь программист, прочитав определение, сразу поймет, почему свойство Логин в объекте Пользователь не обязательное.Термины связаны друг с другом. В термине Пользователь используется «операция», поэтому приведу и ее определение:
Операция — совокупность действий, составляющих содержание одного акта бизнес-деятельности. Операция должна соответствовать требованиям ACID (Atomicity, Consistency, Isolation, Durability). Совокупность операций одного модуля представляет интерфейс взаимодействия клиент-сервер этого модуля.
Как видите, это определение очень важно для всей системы – оно не только связывает пользователя и его бизнес-действия с тем, что должно быть реализовано, но и накладывает требования на то, КАК должна быть реализована система (это КАК было определено ранее при разработке архитектуры) – бизнес-действия внутри операции должны быть внутри транзакции.
Работа над списком терминов происходила постоянно. Мы поддерживали его полноту, т.е. старались, чтобы в документации не было термина, который бы не был определен в этом списке. Кроме того, были случаи, когда мы меняли термины. Например, по прошествии нескольких месяцев с начала написания требований мы решили заменить Контрагент на Компания. Причина была проста: оказалось, что никто не в состоянии в речи, при разговоре, использовать слово «контрагент». А если так, то он должен был быть заменен на что-то более благозвучное.
Часто бывали случаи, когда приходилось прерывать обсуждение и лезть в требования, чтобы понять, подходит ли обсуждаемая функциональность под существующие определения. И для того, чтобы поддержать непротиворечивость требований, мы в итоге должны были или изменять реализацию, или корректировать описания терминов.
В итоге в списке у нас оказалось порядка 200 бизнес- и системных определений, которые мы использовали не только во всей документации, включая, например, и технический дизайн, разрабатываемый программистами, но и в разговоре, при устном обсуждении функциональности системы.
Второй частью, на которую опиралась вся документация, было описание бизнес-ролей.
Описание бизнес-ролей
Все знают, что используют систему пользователи. Но даже в небольшой системе они обладают разными правами и/или ролями. Наверное, самое простое деление – это администратор и рядовой пользователь. В большой системе ролей может быть несколько десятков и аналитику необходимо заранее об этом подумать и указывать роли при описании общих сценариев (смотри ниже) и в заголовках сценариев использования. Список бизнес-ролей используется для реализации групп и ролей пользователей, назначения им функциональных прав, он необходим тестировщикам, чтобы тестировать сценарии под нужными ролями.
Бизнес-роли пользователей нам не пришлось выдумывать, поскольку в компании были устоявшиеся отделы, роли, функции. Описание ролей было дано на качественном уровне на основе анализа основных функций сотрудников. Окончательное наделение ролей конкретными правами происходило ближе к концу разработки, когда набор функциональных прав стал устойчивым.
Пара примеров:
Уровни требований
Одной из важных концепций, которую мы применяли при разработке требований, было разделение их на уровни. Алистер Коберн в книге Современные методы описания функциональных требований к системам выделяет 5 уровней. Мы использовали 4 – три уровня бизнес-требований плюс системные требования:
- Общие сценарии (соответствует уровню очень белого у Коберна)
- Сценарии использования (соответствует голубому)
- Алгоритмы и проверки (скорее черный)
Кроме того наши требования представляли из себя дерево (с циклами). Т.е. общие сценарии уточнялись сценариями использования, которые, в свою очередь, имели ссылки на проверки и алгоритмы. Поскольку мы использовали wiki, физическая реализация такой структуры не представляла проблем. Сценарии использования, алгоритмы и проверки использовали объекты, их свойства и методы, описанные на системном уровне.
Такая методология позволяла нам с одной стороны описывать текущий сценарий настолько подробно, насколько нужно на данном уровне, вынося детали на нижний уровень. С другой стороны, находясь на любом уровне можно было подняться выше, чтобы понять контекст его выполнения. Это так же обеспечивалось функциональностью wiki: сценарии и алгоритмы были написаны на отдельных страницах, а wiki позволяла посмотреть, какие страницы ссылаются на текущую. Если алгоритм использовался в нескольких сценариях, то он в обязательном порядке выносился на отдельную страницу. Такие фрагменты программисты обычно реализовывали в виде отдельных методов.
На картинке ниже представлена часть нашей иерархии (о содержании речь пойдет дальше).
Важно отметить, что если системный уровень описывал все без исключения объекты системы, то сценарии были написаны далеко не для всех случаев поведения пользователя. Ведь многие объекты, по сути, являлись справочниками, и требования к ним более-менее очевидны и похожи. Таким образом мы экономили время аналитика.
Интересен вопрос, кому в проектной команде какой из уровней нужен. Будущие пользователи могут читать общие сценарии. Но уже сценарии использования для них сложны, поэтому аналитик обычно обсуждает сценарии с пользователями, но не отдает их им для самостоятельного изучения. Программистам обычно нужны алгоритмы, проверки и системные требования. Вы однозначно можете уважать программиста, который читает сценарии использования. Тестировщикам (как и аналитикам) нужны все уровни требований, поскольку им приходится проверять систему на всех уровнях.
Использование wiki позволяло работать над требованиями параллельно всем членам проектной команды. Замечу, что в один и тот же момент разные части требований находились в разных состояниях: от находящихся в работе до уже реализованных.
Бизнес-требования
Общие сценарии
Корневая страница нашего дерева требований состояла из общих сценариев, каждый из которых описывал один из 24 бизнес-процессов, подлежащих реализации в данном модуле. Сценарии на странице располагались в той последовательности, в которой они осуществлялись в компании: от создания объекта с проданными товарами, до передачи их клиенту. Некоторые специфические или вспомогательные сценарии помещались в конце в отдельном разделе.
Общий сценарий – это последовательность шагов пользователя и системы для достижения определенной цели. Описания общих сценариев были значительно менее формальны по сравнению со сценариями использования, поскольку они не предназначались для реализации. Основная цель общего сценария – это обобщить сценарии использования, подняться над системой и увидеть, что же в конечном итоге хочет сделать пользователь, и как система ему в этом помогает. Хочу заметить, что общие сценарии также содержали шаги, которые пользователь осуществлял вне системы, поскольку надо было отразить его работу во всей полноте, со всеми этапами, необходимыми для достижения бизнес-цели. На этом уровне хорошо видна роль системы в работе сотрудника компании, видно какая часть этой работы автоматизирована, а какая нет. Именно здесь становилось ясно, что некоторая последовательность действий, которую мы предлагали выполнить пользователю в системе, избыточна, что часть шагов можно сократить.
- упорядочение знаний о работе пользователей и системы
- согласование бизнес-процессов с будущими пользователями
- основа для понимания того, что требования полны, что ничего не упущено
- входная точка при поиске нужного сценария или алгоритма
Как видите, только половина шагов автоматизирована, да и те описаны как можно более кратко. Также из первого шага видно, что ручной перевод задания на печать в статус ‘В работе’ в принципе лишний, можно упростить работу пользователя и автоматически переводить задание в этот статус при печати.
Ссылка «Задание на печать», указывающая на описание объекта в системных требованиях, лишняя, поскольку никому не требуется перепрыгнуть на него из общего сценария. А вот ссылка «пакетная печать документов на груз» важна – она ведет на сценарий использования, формально описывающий действия пользователя и системы.
- Заголовок со следующими полями:
• статус (В работе | Готов к рецензированию | Согласован)
• пользователи (по описанию бизнес-ролей)
• цель
• предусловия
• гарантированный исход
• успешный исход
• ссылка на описание пользовательского интерфейса (разработанного проектировщиком интерфейсов)
• ссылка на сценарий тестирования (заполнялось тестировщиками) - Основной сценарий
- Расширения сценария
Сценарии использования
Сценарий использования содержал пронумерованные шаги, которые в 99% случаев очевидным образом начинались со слов Пользователь или Система. Нумерация важна, поскольку позволяла в вопросах и комментариях сослаться на нужный пункт. Каждый шаг – это обычно простое предложение в настоящем времени. Проверки и алгоритмы выносились на следующий уровень и часто на отдельные страницы, чтобы упростить восприятие сценария, а также для повторного использования.
Приведу сценарий использования, на который ссылается общий сценарий выше.
Часто аналитики рисуют пользовательский интерфейс и на его основе пишут сценарии, объясняя это тем, что так нагляднее. Доля истины в этом есть, но мы придерживались позиции, что интерфейс – это дело проектировщика интерфейса. Сначала аналитик описывает, что должно происходить, а затем проектировщик интерфейса рисует эскиз web-страницы или диалога. При этом бывало так, что сценарий приходилось менять. В этом нет ничего страшного, ведь наша цель — спроектировать все части системы так, чтобы было удобно пользователю. При этом каждый участник проектной команды, будь то аналитик или проектировщик интерфейса, обладая специфическими знаниями и внося свой вклад в общее дело, оказывает влияние на работу других членов команды проекта. Только вместе, объединив усилия, можно получить отличный результат.
Алгоритмы и проверки
Интересная проблема возникла при написании алгоритмов. Аналитик пытался их описать как можно более полно, т.е. включать все возможные проверки и ответвления. Однако получившиеся тексты оказывались плохо читабельны, и, как правило, все равно какие-то детали упускались (вероятно, сказывалось отсутствие компилятора -). Поэтому аналитику стоит описывать алгоритм настолько полно, насколько это важно в плане бизнес-логики, второстепенные проверки программист сам обязан предусмотреть в коде.
Например, рассмотрим простой алгоритм ниже.
В алгоритме указана всего одна проверка, но очевидно, что при написании кода метода программист должен реализовать проверки на входные параметры; выбросить исключение, если текущий пользователь не определен и т.д. Также программист может объединить данный алгоритм с алгоритмами переходов в другие статусы и написать единый непубличный метод. На уровне API останутся те же операции, но вызывать они будут единый метод с параметрами. Выбрать лучшую реализацию алгоритмов – это как раз компетенция программиста.
Системные требования
Как известно, программирование – это разработка и реализация структур данных и алгоритмов. Таким образом, по большому счету, все, что надо знать программисту – это структуры данных, необходимые для реализации системы, и алгоритмы, которые ими манипулируют.
При разработке системы мы использовали объектно-ориентированный подход, а поскольку в основе ООП лежат понятия класса и объекта, то наши структуры данных – это описания классов. Термин «класс» специфичен для программирования, поэтому мы использовали «объект». Т.о. объект в требованиях равен классу в объектно-ориентированном языке программирования (в скобках замечу, что в паре разделов требований пришлось изгаляться, чтобы в тексте разделить объект-класс и объект-экземпляр этого класса).
- Определение объекта (копия из списка терминов)
- Описание свойств объекта
- Описание операций и прав
- Данные
- Дополнительная информация
Первая таблица каждого объекта описывала признаки его свойств, необходимые для того, чтобы программист смог создать структуры данных в БД и реализовать объект на сервере приложения:
Название
Названием свойства оперирует как пользователь (например, «я изменил номер счета», Номер – свойство объекта Счет), так и проектная команда. Повсеместно в документации использовались ссылки на свойства в виде простой нотации Объект.Свойство, очевидной для любого участника проекта.Тип
Мы использовали Datetime, Date, Time, GUID, String, Enum, Int, Money, BLOB, Array(), Float, Timezone, TimeSpan. Тип имел отражение на всех уровнях приложения: на уровне БД, сервера приложения, в пользовательском интерфейсе в виде кода и графического представления. Каждому типу было дано определение, чтобы их реализация не вызывала вопросов у программистов. Например, было дано такое определение типу Money: содержит вещественное число с точностью до 4-го знака после запятой, число может быть отрицательным и положительным; одновременно со значением система хранит валюту; валюта по умолчанию — российский рубль.Признак редактируемости
Да или Нет в зависимости от того, позволяет ли система пользователям менять значение этого свойства в операции редактирования. В нашей системе это ограничение реализовывалось на сервере приложения и в пользовательском интерфейсе.Признак наличия нуля
Да или Нет в зависимости от того, может ли поле не содержать значения. Например, поле типа Bool должно содержать одно из возможных значений, а поле типа String обычно может быть пустым (NULL). Это ограничение реализовывалось на уровне БД и на сервере приложения.Признак уникальности
Да или Нет в зависимости от того, является ли это поле уникальным. Часто уникальность определяется на группе полей, в этом случае у всех полей в группе стояло Да+. Это ограничение реализовывалось на уровне БД (индекс) и на сервере приложения.Комментарий
Описание поля: что означает, для чего нужно, как используется. Если значение свойства вычисляемое, то это указывается явно с описанием алгоритма расчета этого значения.- Название свойства объекта в программном интерфейсе.
- Название поля в БД.
Хочу еще раз обратить внимание, что в написании требований принимали участие программисты. Это важно по многим причинам. Во-первых, таким образом программисты лучше осознавали требования, более того, требования становились «ближе к телу», а не просто неким куском бумаги, написанным каким-то аналитиком. Во-вторых, автоматически формировалась документация для API. В-третьих, поддерживалась трассируемость (traceability) требований, т.е. всегда было понятно, реализовано ли то или иное свойство, что особенно становилось важным при модификации требований. Безусловно, такая методология требовала большей дисциплины от программистов, что на самом деле являлось положительным фактором.
Кроме того благодаря этим колонкам, программистам, работающим над разными уровнями приложения, всегда можно было найти общий язык, т.е. понять соответствие между свойством объекта в требованиях, полем в базе данных и свойство в API.
Как я уже писал, табличный вид очень удобен для расширения. Например, для описания начальной миграции у нас была колонка с именем свойства старой системы или алгоритмом преобразования данных. Также мы использовали специальные значки для описания того, как выглядит объект в пользовательском интерфейсе. Одно время у нас была колонка для имени индекса в БД, чтобы программисты не забывали их создавать для уникальных полей. При необходимости вы можете добавить колонку с размерностью типов данных для каждого свойства.
Вот типичное описание свойств нашего объекта.
Вторая таблица объекта содержала описание его операций и их прав. Каждая операция в системе имела уникальное название (колонка Операция), но в пользовательском интерфейсе (в меню) операции отображались под краткими названиями (Краткое название). Для выполнения любой операции надо было обладать определенным правом (Право). Колонка Комментарий для сложных методов содержала описание алгоритма или ссылку на него или на более общий сценарий использования. CRUD операции над всеми типами объектами у нас были стандартизированы, поэтому для них алгоритмы обычно не требовались.
Колонка Название в коде опять заполнялась программистом что, как и при описании объекта, было нужно для документирования API, повышения вовлеченности программистов в написание требований и трассируемости. Ниже – пример описания операций объекта:
В этом разделе были также таблицы, описывающие переход по статусам.
В ячейках стоит краткое название операции, которая переводит исходный статус в целевой. Для более сложных случаев приходилось рисовать полноценные диаграммы.
После инсталляции системы в ней должны присутствовать определенные данные. Например, пользователь с администраторскими правами или список стран согласно общероссийскому классификатору стран мира. Эти данные описывались в разделе Данные.
Все, что не уложилось в стандартные разделы выше, шло в раздел Дополнительная информация. Например, у нас это была информация по связям данного объекта со старой системой.
Подытоживая, можно сказать, что системные требования для объекта содержали всю необходимую информацию для его реализации программистом: структуру данных в БД, описание доменного объекта, ограничения на данные и методы, алгоритмы реализации методов, данные, которые должны быть при инсталляции системы. Структура описания проста для понимания и расширяема.
Многие скажут, что такая детализация требований отнимает много времени и не нужна. На что я возражу – а как программист догадается, что конкретно необходимо реализовать? Разве фразы «Необходимо реализовать объект Пользователь» достаточно, чтобы через некоторое время получить работающий код? Сколько надо выпить чая с аналитиком, чтобы вытащить из него данные по 40 (столько было у нас) свойствам пользователя? Кто, как не аналитик или проектировщик, должен приложить усилия и описать все объекты?
Постановка задач программистам
После описания того, как выглядят требования, рассмотрим интересный вопрос: как должны быть сформулированы задачи для программистов (ограничимся серверной частью многозвенного приложения)? Оказывается, большинство задач (не дефектов) сводится к трем вариантам:
- создать структуры в БД (таблица, ключи, индексы, триггеры и т.д.);
- реализовать доменный объект;
- реализовать создание начальных данных.
Типовая задача 2
Заголовок: Реализовать такую-то операцию такого-то объекта и права на нее
Текст задачи — ссылка на страницу с системными требованиями к объекту.
Программист находит на странице название операции и права, а по ссылке в колонке Комментарий – алгоритмы, проверки, сценарий использования.Типовая задача 3
Заголовок: Скорректировать объект и/или операцию.
Данная задача необходима в случае изменений требований. Текст задачи содержит описание изменений или ссылку на страницу сравнения версий требований.Инструмент для написания и управления требованиями
- Удаленная работа. Собственно, как и у любой wiki.
- Ссылки. Как вы видели выше, ссылки для нас – один из основных инструментов для связывания отдельных частей требований.
- Возможность дробить требования на части (каждая часть – на своей странице).
- Оповещения при изменении. Это одно из важнейших средств совместной работы. Например, получив такое оповещение по одному из сценариев, руководитель разработки может ставить задачи разработчикам, а тестировщики знает, что надо скорректировать сценарии тестирования.
- Комментарии. Многие страницы требований у нас обрастали развесистыми иерархиями комментариев. В Confluence работать с ними достаточно удобно, поскольку иерархия не плоская, а в виде дерева. Кроме того есть возможность использовать полноценный редактор, а не просто текст.
- Наличие мощного текстового редактора. Не буду здесь подробно останавливаться, отмечу лишь, что на всем протяжении нашей работы Atlassian совершенствовал редактор, и если вначале было достаточно много глюков, то затем подавляющее большинство из них было исправлено.
- Хранение истории, сравнение разных версий страниц, возможность отката на старую версию.
- Просмотр иерархии страниц в виде дерева.
- Поскольку все требования используют одни и те же названия объектов и их свойств, то было бы очень удобно иметь инструмент, который при изменении названия менял его во всей документации. А при удалении – находил все, уже недействительные, ссылки на него.
- Не было возможности сбора статистики. Например, каждое требование имело статус, но мы не могли автоматически собирать статусы всех требований и иметь динамическую картину процесса разработки требований. Но, кажется, на данный момент что-то подобное в Confluence уже появилось.
- Диаграммы приходилось рисовать в другой системе, сохранять в PNG и уже картинку помещать на страницу Confluence. При этом еще надо было приложить исходник, чтобы через пару месяцев его можно было найти и поправить.
- Я не нашел способа экспортировать иерархию страниц в MS Word. Экспорт в XML и PDF очень часто глючил (возможно, дело в размере иерархии).
В конце хочу выразить благодарность Вадиму Лободе и Артему Каратееву за ценные советы и тщательное рецензирование данной статьи.
Про бизнес-требования
В сухом остатке, концепция проекта содержит цель проекта, обычно очень верхнеуровневое описание шагов для её достижения и описание целевой аудитории. Если вы не знакомы с концепцией (scope) проекта и не знаете как её разрабатывать или ищите пример, от которого можете оттолкнуться для разработки концепции для своего продукта, то смело скачивайте документ «Scope проекта».
Если вы ознакомились с документом «Scope проекта», то увидели там раздел «Бизнес-требования».
Бизнес-требования, представленные в концепции, определяют назначение продукта, а также преимущества, которые можем получить и риски, с которыми можем столкнуться в реализации проекта.
Когда продукт находится в стадии разработки, возникает необходимость разработки конкретного функционала, под который в концепции, разумеется если и сказано, то очень обтекаемо.
В таком случае, руководитель продукта самостоятельно или, поставив задачу аналитику, разрабатывает бизнес-требования к конкретному функционалу продукта.
Делюсь с вами примером того, как бизнес-требования могут быть оформлены, но хочу отметить, что данный пример оформления бизнес-требований не панацея, он может быть проработан глубже, но из практики разработки бизнес-требований, такого формата достаточно, как минимум, для старта разработки функциональных требований.
Важные шаги до постановки ТЗ на разработку сайта: собираем функциональные и бизнес-требования правильно
Александр Майфет Редакция «Текстерры»
Перед постановкой технического задания (ТЗ) на разработку заказчик должен четко понимать, какие задачи будет решать его сайт и как взаимодействовать с посетителями. На языке разработчиков это называется «собрать функциональные и бизнес-требования». В таком случае заказчик сможет точно оценить бюджет и время выполнения, а разработчику не придется переделывать свою работу.
В этой статье расскажу, что такое функциональные и бизнес-требования и почему их нужно собрать перед постановкой ТЗ.
Что такое функциональные требования
Функциональные требования – это особенности сайта, которые должен воплотить в жизнь разработчик. Они описывают то, как система будет работать при выполнении определенных действий пользователя. Например, как проходит регистрация в личном кабинете, покупка товара или оформление подписки.
Само слово «функционал» подводит к тому, что мы задаем вопрос: как работает этот сайт, какие у него будут функции. Сюда относится все, что касается логики работы.
Если заказчик хочет интернет-магазин, то сразу возникает куча вопросов: есть ли в магазине личный кабинет, есть ли в корзине возможность оплаты через эквайринг, существует ли какая-то система лояльности и еще множество нюансов.
Примеры того, как выглядят функциональные требования в техзадании
Кроме функциональных требований, есть еще нефункциональные. Это атрибуты сайта, которые нужны для его устойчивой работы, при этом не связанные с основным функционалом.
Нефункциональных требований очень много. Вот основные:
- Производительность. Например, скорость загрузки страницы или время реакции на определенные действия.
- Удобство для пользователя. Насколько интуитивное меню, сколько времени уходит у пользователя на поиск нужной информации.
- Безопасность. Персональные данные должны быть защищены от взломов, хакерских атак, вирусов.
- Совместимость. Как сайт смотрится на различных браузерах и устройствах. Возможно, с экрана телефона часть картинки не видно.
- Локализация. Если компания сотрудничает с иностранными клиентами, нужно адаптировать сайт под их запросы. Например, перевести контент на английский язык, добавить другую валюту или часовые пояса.
Нефункциональные требования могут касаться, например, визуальной части – красивых картинок, эффектов, шрифтов. Другими словами, всего того, что мы называем user interface (UI) – внешнего вида сайта. Также сюда относится user experience (UX) – удобство пользователя.
Чтобы объяснить отличие функциональных требований от нефункциональных, приведу такое сравнение. Функциональные требования – это авто или телега, у которых есть 4 колеса, место, где сидеть, и тягловая сила (двигатель или лошадь). А нефункциональные – это кузов мерседеса, с красивыми лампочками и шильдиками. Большинство людей покупают этот значок мерседеса на капоте, но это не отменяет и того, что под капотом все должно хорошо работать.
То же самое с сайтом. Функциональные требования касаются начинки, содержимого, которое не видно пользователю, это шестеренки внутреннего механизма, а нефункциональные пользователь видит сразу, как только заходит на сайт.
Что такое бизнес-требования
Бизнес-требования – это общие задачи, которые должен решать сайт. Ключевое отличие бизнес-требований от функциональных в том, что они должны быть понятны руководителю компании, который не знаком с техническими тонкостями веб-разработки.
- Информацию о компании: название, год основания, сфера деятельности, товарный знак, список клиентов, преимущества перед конкурентами.
- Данные о целевой аудитории. Нужно примерно представлять, кто будет посетителем сайта: его пол, возраст, регион проживания, привычки и увлечения. Еще нужно понимать, зачем людям вообще приходить к вам на сайт. Например, купить товары, узнать стоимость дизайн-проекта или почитать новости.
- Цель создания сайта: что вы хотите получить в итоге. Например, увеличить количество продаж или повысить узнаваемость бренда.
Каждую задачу можно решить несколькими способами, важно расставить нужные акценты изначально. Например, если компания заказывает сайт и целью является подтвердить статусность, акцент при разработке будет делаться на эргономичность, фирменный стиль клиента и удобство коммуникации. Если в бизнес-требованиях стоит «получить прибыль» – в первую очередь важно будет показать заказчику возможности получения дополнительной прибыли с помощью сайта, хотя одно другому не мешает.
Зачем нужны функциональные и бизнес-требования
Функциональные и бизнес-требования решают такие задачи:
- Упрощают взаимодействие между заказчиком и разработчиком. Они помогают избежать недопонимания, определяют общие термины и роли.
- Сокращают срок реализации проекта. Благодаря четким требованиям разработка сайта займет меньше времени.
- Экономят бюджет. Когда заказчик понимает что ему нужно, он может более точно спланировать бюджет. Размытые требования приводят к неопределенной стоимости разработки, которая впоследствии может вырасти.
- Выявляют возможные ошибки. Выявление ошибок на начальном этапе поможет сократить время и деньги на их исправление.
- Помогают предвидеть итоговый результат. С помощью требований разработчик понимает, что двигается в правильном направлении. Они не дают увлечься и отойти от первоначальной идеи, выступая некими границами проекта.
Выполнение функциональных и бизнес-требований – готовые критерии, по которым заказчик принимает и оценивает работу команды разработчика.
Кто занимается сбором требований
Когда заказчик до конца представляет себе, каким должен быть сайт на выходе, собирать требования должен именно он. Кроме владельца бизнеса никто не понимает, как нужно продавать услуги, какие инструменты нужны для продвижения, в чем заключаются боли клиентов.
Сбором функциональных требований занимаются, прежде всего, отдел маркетинга и IT-отдел. Для максимальной конверсии главная страница сайта должна содержать ответы на все потенциальные вопросы клиентов, снимать их возражения, страхи. Поэтому нелишним будет собрать такую информацию у отделов продаж и клиентского сервиса.
Если компания небольшая, где нет штатных маркетологов, аналитиков, программистов, стоит привлечь стороннее агентство для проведения конкурентного анализа и разработки digital-стратегии. Как вариант, можно доверить сбор требований компании, которая будет непосредственно разрабатывать сайт.
Заказчик может собирать требования в паре с маркетологом. Иногда подключается специалист от разработчика. Но все равно, продумывание логики работы сайта висит на заказчике. Это не тот вопрос, где можно откупиться деньгами.
Так что, если вы не знаете, каким должен быть ваш сайт, хотя бы в общих чертах, то, скорее всего, он вам и не нужен.
В нашем случае требования собирает менеджер, который выстроил диалог с клиентом и может полностью понять его.
Перед сбором требований менеджер просматривает сайты конкурентов, подробно изучает бизнес заказчика, чтобы при встрече задать ему наводящие вопросы и предложить сайт, который будет решать основные задачи.
При сборе функциональных требований заказчик начинает понимать, как будет выглядеть его сайт, как и что будет расположено, какие процессы будут происходить.
Мы часто заказываем сайты для региональных отделений.
В нашем случае все делали силами своих отделов, но подрядчик – маркетинговое агентство – вносил и свои предложения. Если компания совсем небольшая, рекомендую привлечь агентство, консультанта, маркетолога на аутсорсинге на время реализации проекта (это гораздо дешевле штатного сотрудника), но не надеяться, что подрядчик сделает все. Необходимо предоставить ему полную информацию о продукте, клиентах, задачах компании.
Необходимы хотя бы минимальные маркетинговые компетенции в рамках компании, чтобы можно было оценить результаты: возможностей для самообразования сейчас немало, есть курсы, вебинары, статьи, в том числе ориентированные на собственников бизнеса.
Как проходит сбор требований
Методы сбора функциональных и бизнес-требований:
- бриф на разработку сайта;
- личное интервью;
- изучение документации компании (например, регламентов, спецификаций продукта, инструкций);
- участие представителя от компании-заказчика;
- мозговой штурм;
- общее совещание.
Требования собираются в отдельный документ, на основе которого уже составляется техническое задание разработчику. Он выглядит в виде брифа и не содержит технической информации.
Для удобства документ обычно разбит на несколько разделов:
- Бизнес-требования. Это самые приоритетные требования, которые определяют цель создания сайта и задачи.
- Дизайнерские требования. Здесь описаны цвета, шрифты, стилистика будущего сайта. Они должны совпадать с идеей или фирменным стилем заказчика.
- Требования пользователей сайта. В данном блоке прописано, какую информацию может просматривать/добавлять/редактировать пользователи сайта. Например, менеджеру по продажам в интернет-магазине нужен только доступ к заказам, а бухгалтеру – к счетам и отчетам.
- Требования посетителей сайта. Здесь описан путь посетителя на сайте. Если проект очень крупный, составляется полноценная концепция поведения аудитории – Customer Journey Map.
По нашей практике, функциональные требования чаще всего формулируются в процессе работы над проектом. Иногда заказчик приходит с примером «хочу как у них», иногда – рассказывает, как он хочет, чтобы сайт работал. Бывает, что заказчик не знает всех возможностей и просто описывает их своими словами.
Наши менеджеры в любом из случаев поймут, что из функционала поможет конкретным задачам и после одного-двух созвонов уже могут в резюме прописать приблизительный список возможностей.
Одно время для сбора требований мы пытались создать универсальную анкету, которую высылали потенциальным клиентам. Она делала свое дело, но в графе «Примечание» всегда была информация, которая отличалась. Так как ее было достаточно много, мы пришли к тому, что вместо анкеты при первом-втором звонке наши менеджеры задают некий список важных для нас вопросов.
Чаще всего данные, по которым составляется техническое задание, собираются именно в процессе разговора: менеджер слушает, фиксирует и прописывает итоги разговора. После согласия заказчика он формирует документ, который передается главному менеджеру проекта. Этот процесс кажется долгим, но разработка программных решений – непростая область, и так как мы выбрали для себя разрабатывать продукты по индивидуальным пожеланиям, этот способ кажется нам оптимальным.
Мы скидываем бриф на заполнение, где заказчик своими словами рассказывает, что у него должно быть на сайте и как это все будет работать, а также пожелания по внешнему виду. Если этого недостаточно, подключаются наши сотрудники: маркетологи и программисты.
Иногда в процессе работы выясняется, что заказчику вообще не нужен сайт, вся его аудитория обитает в социальных сетях. Ну не нужен девочке-маникюрщице продающий лендинг, все ее заказчицы сидят в Instagram.
Зачастую клиент очень поверхностно представляет, какой дизайн хочет увидеть. Поэтому на предварительной встрече мы подробно обсуждаем и предлагаем различные идеи, чтобы понять, какая стилистика больше подойдет и в какую сторону двигаться нашему дизайнеру.
Но для многих клиентов сложно визуализировать эти идеи. Поэтому приходится подбирать множество различных и разносторонних сайтов, примеров стилистики, концепции и дизайнерских решений, которые могут как-то определить вектор направления.
Если клиент затрудняется на встрече или просто не желает подробно расписывать бизнес-процессы в его компании, то менеджер пытается разговорить его и получить нужную информацию, например, предлагая те или иные решения на сайте, которые будут полезны пользователям.
Например, при разработке сайта по продаже напольных покрытий можно взглянуть на будущий продукт глазами покупателя и сказать: «Мне здесь было бы удобно рассчитать стоимость продукции, указав площадь моей комнаты, или получить комплексное предложение сразу с монтажом».
Для нашей компании сайт – ключевой канал продаж. Поэтому при формировании техзадания важно было учесть блоки для повышения доверия к компании, в том числе социальные доказательства, размещение различных CTA, форм захвата и т.д.
При подготовке ТЗ нового сайта мы изучали сайты конкурентов, анализировали данные метрики по поведенческим факторам, WebVisor, чтобы максимально устранить все препятствия в клиентском путешествии и сформировать воронку продаж.
Если вы рассматриваете продвижение сайта в поисковых системах, необходимо до подготовки техзадания собрать семантическое ядро, которое будет влиять как на структуру сайта (разделы), так и на контент.
Как правило, делают наоборот: сначала запускают сайт, затем начинают заниматься продвижением. Также сайт должен соответствовать техническим требованиям поисковиков, и эти моменты нужно прописать в ТЗ. Еще нужно учесть поведенческие факторы, например, включить элементы для удержания посетителей, чтобы увеличить время нахождения на сайте.
Пример брифа компании. Из него станет понятно, чем занимается предприниматель и в чем ключевые преимущества его продукта
Ошибки при сборе функциональных и бизнес-требований
Функциональные требования нужно указывать корректно: без непонятных формулировок и субъективных оценок, которые нельзя проверить, а значит использовать при разработке сайта. При этом важно соблюдать баланс между подробностью и избыточностью. Если слишком уходить в детали, техзадание получится перегруженным и разработчику потребуется много времени на его изучение.
Форма регистрации должна быть удобной и простой.
Форма регистрации должна содержать три поля: имя и электронную почту. Кроме это, пользователь может зарегистрироваться через соцсети.
Страница должна быстро загружаться.
Время загрузки сайта – 3 секунды. Сохранение работоспособности при посещаемости 100 тысяч человек в сутки.
Сайт не должен содержать уязвимостей. Копии ПО хранятся на внешнем носителе.
Обеспечение защиты от межсайтового скриптинга (XSS), SQL-инъекций, CSRF-уязвимостей. Хранение копии ПО и файла базы данных на внешнем носителе.
Окончательной версии требований не существует. Можно определиться с техническими требованиями и структурой, однако некоторые элементы необходимо постоянно тестировать и выбирать наиболее эффективные. Например, визуализацию первого экрана или формы заявок.
Если предположить ситуацию, что функциональные и бизнес-требования будут собираться после составления технического задания, итогом станет увеличение срока работы, так как от требований зависит, что будет в приложении/сайте, как это будет работать. Придется заново пересчитывать стоимость проекта с учетом новых вводных и снова согласовывать то, какие функции будут закрывать новые потребности заказчика. Сбор полной информации по запросу заказчика логически происходит до составления технического задания, и чем качественнее он пройдет, тем быстрее и лучше получится результат.
Какие ошибки чаще всего допускают при сборе ФТ и БТ?
Если менеджер не подготовился к очной встрече, не проанализировал другие сайты, не до конца понял специфику бизнеса, то впоследствии могут возникнуть трудности.
Бывает такое, что в процессе обсуждения не учли какую-нибудь роль пользователя, который будет взаимодействовать с сайтом.
Например, полностью обсудили все процессы и требования для интернет-магазина, но совсем забыли про бухгалтера, который должен просматривать отчет по продажам и формировать накладные и счета, в случае если клиент юридическое лицо. В дальнейшем делается дополнительное соглашение и продукт дорабатывается.
Макет будущего сайта на основе функциональных и бизнес-требований заказчика
Выводы
- Собрать функциональные и бизнес-требования нужно перед постановкой техзадания на разработку сайта. Это сэкономит бюджет заказчика, сократит время создания и исключит недопонимание сторон.
- Чем конкретнее поставлены требования в ТЗ, тем больше вероятность создания сайта, который будет решать все поставленные задачи.
- Принимать участие в сборе требований должен непосредственно заказчик, так как именно он понимает всю специфику бизнеса. Но если компания небольшая, стоит привлечь к проекту специалистов на аутсорсе или доверить сбор требований команде разработчика.
Мы в TexTerra тоже начинаем разработку сайта со сбора функциональных и бизнес-требований. Это помогает нам выполнить работу в точности так, как это необходимо клиенту. При этом заказчик во время проработки требований сам лучше понимает, что получит на выходе. Если вашему бизнесу нужен сайт – обращайтесь за разработкой в TexTerra.
В Google и «Яндексе», соцсетях, рассылках, на видеоплатформах, у блогеров
Источник https://habr.com/ru/post/245625/
Источник https://vc.ru/life/60112-pro-biznes-trebovaniya
Источник https://texterra.ru/blog/vazhnye-shagi-do-postanovki-tz-na-razrabotku-sayta.html
