Когда вы создаете или обновляете продукт, создание многих необходимых документов планирования может показаться бессмысленным документооборотом. Разработка документа проекта, структуры разделения работ и документа бизнес-требований может показаться потраченным впустую временем. Очевидно, что в зависимости от объема и необходимых усилий, не каждый документ может быть необходим для каждого нового начинания. Однако один из этих документов может направить наши команды в нужное русло и построить единый подход к работе — это документ функциональной спецификации (Functional Specification Document, далее FSD).
В мире используется множество методологий и стандартов ведения проектов и проектной документации, такие как российский ГОСТ 34.602-89 или западные стандарты “ IEEE STD 830-1998”, “RUP”, “ISO/IEC/IEEE 2011”, “Robertson и Robertson (2013)” . В нашей статье мы не будем привязываться к определенной методологии и постараемся описать кратко структуру шаблона документа функциональной спецификации и его наиболее важные разделы необходимые к заполнению, а в конце статьи предложим шаблон, который мы сможете скачать и использовать для ваших нужд.
Как составить техническое задание на закупку?
Что такое шаблон функциональной спецификации или шаблон документа функциональных требований?
Документ функциональной спецификации (Functional Specification Document, сокращенно FSD), также известный как документ функциональных требований (Functional Requirements Document, сокращенно FRD), по мнению многих специалистов по управлению проектами и разработке программного обеспечения, является важным инструментом для упорядочения путаницы и неправильного направления в проекте (чтобы читатель не путался в понятиях FSD или FRD, в нашей статье мы будем придерживаться FSD). Не смотря на то, что FSD часто ассоциируются с программным обеспечением и веб-разработкой, они должны играть определенную роль в любом проекте, будь то запуск нового продукта, обновление, разработка программного продукта или реальной вещи, или создание процесса или организационных изменений. Документы функциональной спецификации (FSD) представляют собой как деловые, так и инженерные ожидания. Все заинтересованные стороны рассматривают и утверждают этот документ. Результатом является справочный документ для предлагаемого продукта, который обращен ко всем участникам организации, от кодеров до дизайнеров и торгового персонала.
Вы можете принять и использовать свой шаблон документа функциональной спецификации (FSD), чтобы гарантировать, что вы включаете всю необходимую информацию о разработке в документ. Кроме того, шаблоны гарантируют, что с каждой новой инициативой команды, ее силы сосредотачиваются на требованиях к продукту, а не тратят время на определение дизайна спецификации документа. Шаблоны должны быть настроены в соответствии с уникальными потребностями каждой команды или компании.
Документы функциональной спецификации (FSD) традиционно имеют тенденцию быть длинными, сухими и часто техническими. Такие документы могут быть не нужны и даже бесполезны. Поскольку цель документа о функциональных требованиях состоит в том, чтобы охватить проект для всех заинтересованных сторон, то FSD избегает длительных технических обсуждений.
ТОП-9 советов как написать техническое задание? (ТЗ или техзадание за 9 шагов)
Хотя вы можете включить много типов требований и вспомогательной информации (см. список ниже), рекомендуется в FSD описывать только основные намерения. По своей сути этот документ должен описывать контекст, а также специфичность и функции, которые должны быть разработаны. Например документ технического дизайна (Technical Design Document) создается на основе принятой спецификации функциональных требований. FSD не должен дублировать никакие другие требования или документы процесса.
Спецификация функциональных требований служит справочным документом для всей команды. Он показывает, какие продукты должны разрабатывать разработчики, какие тестировщики должны тестировать, какие авторы должны документировать и какие продавцы будут продавать. Написанная функциональная спецификация (FSD) показывает, что проект и намерение были тщательно рассмотрены до начала разработки. Это также иллюстрирует, что после утверждения спецификации все заинтересованные стороны находятся на одной стороне. Также не следует писать документ спецификации после того, как продукт был закодирован.
Некоторые бизнес-аналитики и разработчики отделяют функциональные спецификации от функциональных требований, говоря, что требования описывают то, что программное обеспечение должно делать, и что спецификации описывают, как программное обеспечение должно это делать. На практике обычно совмещают эти две роли.
Шаблоны функциональных спецификаций (или требований) также могут принимать несколько форм. Выбранный формат зависит от того, что лучше всего подходит для наших команд:
- Функциональные требования (Functional Requirements): Это традиционная форма для программного обеспечения и других технологий, которые использует метод разработки водопада (waterfall). Функциональные требования перечисляют характеристики и функции как чего продукт “должен” сделать. Например: «пылесос должен собирать частицы размером менее пяти мм.”
- Варианты использования (Use Cases): Варианты использования часто используют отдельно. Однако организации, которые ценят пользовательский опыт, обычно включают варианты использования в функциональные требования. Варианты использования задают функции и свойства в контексте действий пользователя. Например: «пользователь дважды касается экрана телефона. Экран подсвечивается. Пользователь проводит пальцем по экрану вправо, чтобы разблокировать телефон и телефон готов к работе.”
- Пользовательские истории (User Stories): Пользовательские истории формируют основу методологии Agile разработки, потому что они описывают дизайн продукта как то, что пользователь должен делать. Этот лаконичный подход помогает командам наиболее эффективно выдавать результат наиболее оптимальным путем. Пользовательские истории происходят от: «как пользователь, я могу сделать что-то так, что я создам некоторую выгоду.”
Почему функциональная спецификация вместо технического задания?
Техническое задание это постановка от заказчика. В то время как функциональная спецификация составляется бизнесом (заказчиком) и техническими специалистами (исполнителем) совместно, что дает возможность более детально описать каждую деталь (спецификацию) и исключить ошибки и недочеты проектирования.
Если говорить о ГОСТе по составлению технических заданий, несомненно это качественный и проработанный стандарт и в нем есть много полезной информации, но:
- Он устарел и имеет в своем содержании устаревшую терминологию, сущности и средства, которые в наше время уже не используют. Например: “Чертеж формы документа (видеокадра)”;
- Иностранные заказчики о ГОСТе ничего не знают.
В нашей компании мы предпочитаем использовать гибкие подходы в управлении проектами, поэтому мы рекомендуем использовать документ функциональной спецификации вместо технического задания.
Кто использует шаблоны функциональных спецификаций?
Как правило, бизнес-аналитики и технические руководители создают шаблоны функциональных спецификаций, которыми они делятся с деловыми и техническими заинтересованными сторонами, которые оценивают их, чтобы гарантировать, что ожидаемый результат соответствует цели.
Вы можете использовать функциональные спецификации при разработке нового программного обеспечения и обновлений. Вы также можете использовать их для организационных и системных инженерных изменений, веб-разработки и многого другого. Спецификациями пользуются следующие группы пользователей:
- Разработчики, которые кодируют продукт
- Проектировщики, создающие пользовательский интерфейс для программного обеспечения, устройства или веб-сайта
- Тестировщики, которые гарантируют, что код работает правильно и в соответствии со спецификацией
- Маркетологи, которые готовят документы, формирующие спрос, вокруг новой функциональности
- Команды продаж, которые продают функциональность и продукт
- Специалисты по технической поддержке или помощи пользователям, которые документируют работу продукта для администраторов, конечных пользователей и других ролей
В чем разница между документом функциональной спецификации и документом бизнес-требований?
Хотя существует много комбинаций и перестановок документов, документы функциональной спецификации (FSD) и документы бизнес-требований (Business Requriments Document, далее BRD) иногда разделяются.
BRD описывает бизнес-требования более высокого уровня для продукта (что продукт делает). BRDs избегает технической детализации в пользу детального обоснования для продукта. Четкое понимание того, что продукт предлагает и почему это необходимо, часто может помочь направлять развитие продукта через споры о направлении продукта. FSD может сосредоточиться на описании функций и функциональных возможностей продукта, которые необходимы для достижения конечной цели.
Как шаблоны функциональных требований соотносятся с другими документами спецификаций
Создание продукта, будь то материальный или операционный, может включать в себя создание многих документов. Шаблоны функциональной спецификации можно использовать в сочетании с любым из следующих вариантов:
- Пользовательские требования (User Requirements): Этот документ представляет то, что пользователь ожидает от продукта. Некоторые считают, что требования пользователя является частью документа о функциональных требованиях. Если этот документ существует, он должен быть включен в общий процесс разработки. В Agile разработке требования пользователей (выраженные в виде пользовательских историй User stories) рассматриваются как основа функциональных требований;
- Требования к продукту (Product Requirements): Используется взаимозаменяемо с документом рыночных требований (Market Requirements Document), в этом документе подробно описывается назначение продукта;
- Документы бизнес-процесса (Business Process Documents): Этот документ содержит сведения о бизнес-процессе;
- Оценка потребностей бизнеса (Business Needs Assessment): Этот документ описывает разрывы между текущими условиями и желаемыми условиями ведения бизнеса;
- Спецификация технического дизайна (Technical Design Specifications): Документ описывает (с самой точной детализацией) элементы программирования требуемые для предложенной конструкции;
- Документы проверки (Validation Documents): Документы проверки могут включать матрицу прослеживаемости (которая отслеживает функции на протяжении всего процесса разработки), планы тестирования и требования к эксплуатации. Это процесс демонстрации соответствия системы или процесса определенному набору требований.
- Системные требования (Systems Requirements): Этот документ описывает высокоуровневые ожидания для системы или продукта;
- Бизнес-требования (Business Requirements): Документ описывает высокоуровневые причины для создания продукта или обновления;
- Примеры использования (Use Cases): Этот документ предлагает функциональные сведения и контекст для функций с точки зрения пользователя;
- Пользовательские истории (User Stories): Этот документ используется в основном для Agile разработки. Он передает намерение продукта, подробно описывая, что пользователь будет делать с ним.
В чем разница между функциональными и нефункциональными требованиями?
Требования могут быть классифицированы как функциональные и нефункциональные спецификации (“как” и “что”):
- Функциональное требование (Functional Requirement): это описание поведения, действия или ожидаемого результата от продукта или системы. Например, “фильтровать частицы из воды” или “печатать страницу”. Общие функциональные требования включают в себя функции администрирования, авторизации и аутентификации, отслеживания аудита и отчетности, а также бизнес-правила. Если формулировка требования отвечает на вопрос “что должен делать/сделать?”, то требование функционально.
- Нефункциональное требование (Nonfunctional Requirement): Описывает, как что-то работает, что также может рассматриваться как ограничение, атрибут или параметр. Если формулировка требования, отвечает на вопрос “что должен иметь?”, оно нефункционально. Примеры включают в себя удобство использования, ремонтопригодность и безопасность, в дополнение к производительности и нормативным требованиям.
Пример функциональных требований
Как минимум, раздел функциональных требований должен включать следующую информацию:
- Для кого предназначен данный продукт
- Кто уполномочен использовать продукт
- Входные данные в систему
- Что должен делать каждый экран
- Системные рабочие процессы (workflows)
- Выходные данные
- Нормативные требования, предъявляемые к продукту
- Конкретные бизнес-требования вашей компании
Как выбрать или создать шаблон функциональных спецификаций
Письменное описание желаемых функций является важной частью разработки продукта, но форма, которую принимает шаблон функциональных требований, также должна определяться тем, “что работает” в наших командах. При разработке шаблона или даже при рассмотрении вопроса об усовершенствовании существующего процесса разработки спросите каждого, кто заинтересован в результате разработки продукта, что он хочет в шаблоне. Каждый формат имеет свои преимущества и недостатки:
- Формулировки “должны” в традиционных функциональных требованиях, как правило, лишены контекста и в большей степени подвержены интерпретации разработчиком;
- Варианты использования (Use Cases) предлагают контекст и детализацию, но в этих самых деталях может быть засада — границы могут расползаться, когда объясняются пользовательские требования для понимания. Слабые требования могут быть потеряны среди вариантов использования.
- Пользовательские истории (User Stories) предоставляют описания потребностей пользователей в контексте бизнес-требований. Однако они могут потребовать дополнительных усилий (например, исследования подходящей реализации). Разработчики и другие пользователи также могут быть настолько сосредоточены на отдельных историях, что они исключают более широкий контекст продукта.
Что включить в шаблон функциональных требований
Хотя некоторые требования являются основными и существенными для передачи цели вашего продукта, другие могут и не быть полезными для разработки вашего продукта. Выбранный вами формат также может зависеть от того, что вы разрабатываете. Вот список, который можно использовать в качестве руководства при подготовке функциональных требований:
- Введение
- Инструкции авторов
- История изменений
- Блок согласований
- Список рассылки
- Терминология
- Соглашения, принятые в документах
- Общий взгляд на продукт, бизнес-процесс
- Обзор бизнес-требований
- Описание текущей системы
- Предлагаемые методы решения
- Взаимодействие пользовательских ролей
- Предположения, допущения, зависимости
- Границы проекта
- Ссылки
- Функциональные требования
- Варианты использования (Use Cases)
- Пользовательские истории (User Stories)
- Внутренние рабочие процессы системы
- Перечень особенностей («фитч») или описания функций
- Функциональность администратора
- Обработка ошибок
- Взаимодействие продукта (с другими продуктами и компонентами)
- Логическая модель данных (дата модель)
- Словарь данных (глоссарий терминов данных)
- Отчеты
- Получение
- Целостность
- Хранение и утилизация данных
- Пользовательские интерфейсы
- Прототипы дизайнов
- Контуры или наброски
- Настройка
- Инсталляция
- Портативность
- Производительность
- Безопасность
- Расширяемость
- Интернационализация
- Поддержка и техническое обслуживание
- Справка и документация
- Надежность
- Доступность
- Требования к удобству использования
Шаблоны функциональных спецификаций для разработки по Agile методологии
Agile фокусируется на поиске наиболее эффективного способа получения полезного продукта для пользователя. При Agile разработке традиционные функциональные требования к документам и процессам иногда считаются финансово необоснованными. Тем не менее, захват более детальных планов и эскизов может повысить четкость.
Одним из наиболее распространенных инструментов описания Agile требований является пользовательские истории (User stories). Пользовательские истории предоставляют возможности (Features) в контекст того, что пользователь должен достигнуть. Вы можете сгруппировать похожие истории пользователей для формирования гибких эпических произведений (Epic). Как и в традиционных спецификациях функциональных требований, пользовательские истории описывают задачу или функцию, но не то, как разработчики должны ее реализовать.
В пользовательских историях используется следующий синтаксис: «как пользователь, я хочу иметь что-то, чтобы из этого вытекала какая-то польза”. Вот несколько примеров:
- Как водитель, я хочу знать, когда моя батарея нуждается в замене;
- Как повар, я хочу, чтобы экран планшета был активным, пока я завершаю рецепт;
- Как кошка, я хочу, чтобы моя порция еды была представлена в мою миску в 4 часа дня каждый вечер.
Чтобы проверить, хорошо ли сформирована история пользователя, оцените:
- Независимость: Может ли история выполнена независимо от других?
- Оборотность: Можно ли изменить или удалить эту историю, не затрагивая остальную часть проекта?
- Ценность: Имеет ли эта история ценность для конечного пользователя?
- Измеряемость: Можете ли вы оценить размер этой истории?
- Минимальность: Достаточно ли мала история пользователя?
- Тестируемость: Вы можете проверить эту историю?
Для целей управления проектами в средстве отслеживания можно присвоить историям имя и нумерованный идентификатор. Кроме того, вы можете отметить приоритет разработки, спринт (sprint) и статус истории. Истории назначаются на Agile доску (backlog) продукта.
Шаблоны пользовательских историй обычно довольно просты: они фокусируются на определении роли пользователя, его задачи и того, что эта задача должна достигать результата.
Шаблон функциональной спецификации
Итак, предлагаем вашему вниманию наш вариант шаблона функциональной спецификации. Это обобщенный документ, в который включены все разделы для максимального охвата описания.
Вы можете скачать шаблон функциональной спецификации и сформировать полноценную функциональную спецификацию.
Источник: roksdevelopment.ru