Успешный продукт начинается с озарения, с идеи о том, как сделать лучше жизнь пользователей или как решить существующую проблему. Например, современные программы для работы с таблицами, на которые полагается практически весь бизнес, появились как желание инженера Дэна Бриклина упростить работу с таблицами. В те времена финансистам приходилось чертить финансовые модели на доске и менять целые ряды при изменении одного параметра в расчетах.
Но автор VISICALC, прародителя Excel был первоклассным математиком и программистом и мог примерно представить себе будущий дизайн и особенности разработки программы. Современные продуктовые команды включают в себя не только разработчиков, но и дизайнеров, продакт-менеджеров, бизнес-аналитиков и других специалистов, не обладающих навыками разработки. Кроме того, сейчас, в отличие от конца 1980-х, мнение конечных пользователей является критически важным для успеха продукта.
Но как убедится в том, что первоначальная идея будет воплощена командой именно так, как задумывалось? В этой статье мы раскроем понятие требований. Их также можно назвать своеобразными рулежными дорожками для идей, которые позволяют всей команде прийти к единому мнению, чтобы продукт “взлетел”.
Что такое требования?
Функциональные требования
Как выглядят требования
Нефункциональные требования
На каких стадиях разработки пригодятся требования?
Что такое требования?
Требования, согласно определению свода знаний по бизнес-аналитике BABOK — это полезное представление потребности, представление целей, задач и результатов, которые описывают, почему инициировано изменение и как будет оцениваться успех. В переводе на человеческий язык это способ нетехнических людей выразить свои идеи так, чтобы их поняли программисты и прийти к общей договоренности.
Иначе это можно назвать одним из кирпичиков будущей программы. Стейкхолдеры озвучивают свои пожелания о том, каким должен быть кирпич. Бизнес-аналитик создает необходимые технические задания для производства и установки кирпича, отвечает за его соответствие различным строительным нормам. Для этого он собирает необходимую информацию у стейкхолдеров.
Когда все идет не по плану — лайфхаки для эффективного сбора требований
Дизайнер рисует кирпич, помогает определить правильные размеры, прочность и соответствие его пожеланиям жильцов. Проектный менеджер отвечает за то, чтобы кирпич был создан и установлен в срок. Команда разработчиков решает, с помощью каких технологий создавать и устанавливать кирпич и делает практическую работу. А вот продакт-менеджер в этом случае отвечает за весь кирпич от завода до установки его в здание.
Кроме того, в сфере IT каждый кирпич помечен различными данными, что позволяет проследить его происхождение и цель. Например, бизнес-аналитик фиксирует, кто из стейкхолдеров предложил сделать кирпич белого цвета и откуда поступило это требование, чтобы у разработчиков всегда была четкая связь с источником. Это позволяет успешно управлять требованиями — скажем, приложение надо быстрее запустить на рынок и тогда проектный менеджер будет иметь информацию о том, на какие заинтересованные стороны повлияет сокращение функционала и какую коммуникацию надо вести.
Как не потеряться в IT-команде новичку: зоны ответственности и роли
Мы неслучайно применили аналогию кирпичей в строительстве. Ведь строительство предусматривает не только производство и установку кирпичей, но и множество других действий. Аналогично и программы состоят не только из требований, но и из архитектуры и других компонентов, которые мы рассмотрим в других статьях.
Требования являются частью “языка” на котором разговаривают заказчики, разработчики и тестировщики, и владение этим языком критически важно для обеспечения успеха проекта. Бизнес-аналитик Ануар Адильжан подчеркивает, что умение собирать требования от заинтересованных сторон является основным навыком для таких специалистов.
“Важно задавать правильные вопросы, уточнять детали и не упускать ни одной важной информации. Сбор требований — это фундамент успешного проекта”, — говорит он.
10 наиболее актуальных для бизнес-аналитика навыков
Существует множество видов требований. Чаще всего начинающие бизнес-аналитики будут иметь дело с бизнес-требованиями — высокоуровневые цели и задачи проекта, которые должны быть достигнуты и пользовательскими требованиями — включают пожелания и потребности конечных пользователей, такие как удобство интерфейса. Мы подробно рассмотрим функциональные и нефункциональные требования.
Функциональные требования
Функциональные требования, согласно BABOK, описывают возможности, которыми должно обладать решение с точки зрения поведения и обрабатываемой информации. Иначе говоря, они определяют основные функции и возможности продукта.
Они помогают определить, что именно должно выполнять разрабатываемое решение для удовлетворения потребностей пользователей и достижения целей бизнеса.
Как сформулировать требования, каждая команда решает самостоятельно. Одним из наиболее популярных форматов являются User stories — пользовательские истории. Они представляют собой короткие описания функций или возможностей продукта с точки зрения пользователя и обычно формулируются в формате:
«Как [тип пользователя], я хочу [функциональность], чтобы [достичь определенной цели].».
Для мобильного приложения по заказу еды функциональные требования могут включать:
Возможность просматривать меню (User story: ‘Как пользователь, я хочу видеть список доступных блюд, чтобы выбрать то, что мне нравится).
Возможность добавлять блюда в корзину (User story: ‘Как пользователь, я хочу добавлять блюда в корзину, чтобы оформить заказ).
Возможность оформлять заказ (User story: ‘Как пользователь, я хочу завершить оформление заказа, чтобы получить еду на дом).
Тестируем после тестирования: коротко об UAT
Система управления бизнесом Darlean.kz является примером комплексного решения, которое объединяет функционал более 10 инструментов. Основные функциональные требования включают:
- Возможность управления проектами (модуль управления спринтами).
- Поддержка мобильной версии с полной функциональностью веб-интерфейса. Эти требования формулируются в виде User stories и реализуются командой DAR Tech, которая включает более 200 специалистов.
В данный момент разработчики DAR Tech работают над тем, чтобы пользователям мобильного приложения был доступен тот же функционал, что и на основной программе. Например, добавляется функция управления спринтами. Вот так она выглядит в веб-версии.
Пользовательская история для функции “Список спринтов в проекте” для мобильного приложения сформулирована следующим образом:
“Как участник проекта, я хочу видеть список всех спринтов, чтобы я мог легко управлять каждым спринтом, отслеживать их статус, количество задач и планировать работу”.
Как видно на скрине, сразу же в пользовательской истории сформулированы критерии приемки для будущего UAT. Кроме того, мобильному разработчику поступила необходимая для взаимодействия с основной программой информация, такая как ссылка на API — отсюда приложения будет брать необходимые для пользователя данные.
В данном случае нам известно, что требование сформулировано самой продуктовой командой для того, чтобы максимально увеличить функциональность мобильного приложения для конечных пользователей и освободить их от необходимости пользоваться ПК.
Нефункциональные требования
Нефункциональные требования, согласно BABOK, описывают характеристики производительности или качества, которым должно соответствовать решение. Нефункциональные требования обычно измеримы и действуют как ограничения на проектирование решения в целом. Они определяют характеристики системы, влияющие на её качество, стабильность и производительность. В отличие от функциональных требований, которые описывают, что должна делать система, нефункциональные требования отвечают на вопрос, как она должна это делать.
Эти параметры можно измерить объективно и поэтому зачастую их проверяет команда профессиональных тестировщиков. Именно в этом случае “выявляются баги” и устраняются другие технические проблемы.
В одной лодке. Почему кросс-функциональные команды — это больше, чем набор специалистов
Например, для мобильного приложения по заказу еды:
- Время отклика системы: Время обработки заказа не должно превышать 5 секунд при пиковой нагрузке в 1000 запросов в минуту.
- Безопасность данных: Все персональные данные пользователей должны быть зашифрованы с использованием алгоритма AES-256, а доступ к данным возможен только после успешной аутентификации.
Проверка нефункциональных требований часто осуществляется с помощью инструментального тестирования. Например, производительность системы проверяется с использованием нагрузочных тестов, а безопасность — через тестирование на проникновение (penetration testing). Эти тесты помогают выявить потенциальные проблемы и убедиться, что система соответствует установленным стандартам качества.
А вот для мобильного приложения Darlean было сформулировано требование мгновенной загрузки календаря. Пользователи ожидают, что переход между днями будет быстрым и плавным, но обработка больших объёмов данных может вызывать задержки. Целью было обеспечить моментальный отклик, сохраняя стабильность системы.
Разработчики внедрили стратегию распределённой загрузки данных, которая работает в два этапа:
Мгновенная загрузка первого дня: Данные текущего дня появляются сразу же, без ожидания.
Фоновая предзагрузка: Одновременно загружаются данные для следующих дней, чтобы переходы оставались незаметными.
Нефункциональные требования помогают обеспечить стабильность и эффективность работы системы в различных условиях. Они также играют важную роль в удовлетворении ожиданий пользователей, так как даже самые удобные функции теряют свою ценность, если приложение работает медленно или часто выходит из строя.
На каких стадиях разработки пригодятся требования?
Требования сопровождают проект на всех стадиях разработки. Сначала они формулируются и уточняются на этапе сбора, затем уточняются в процессе анализа и разработки. Функциональные требования становятся основой для проектирования и программирования, а нефункциональные — ориентиром для обеспечения качества системы. На этапе тестирования проверяется выполнение всех требований, чтобы убедиться, что система отвечает ожиданиям как в плане функций, так и в плане качества.
Требование может пройти долгий путь: от первой встречи с заказчиком до проверочного тестирования. Сначала бизнес-аналитик проводит интервью с заинтересованными лицами, затем превращает их идеи в конкретные требования. Эти требования документируются, проходят согласование с командой разработки, после чего становятся основой для проектирования и создания системы.
Устав разработчиков: как “жить” по правилам SDLC
В предыдущих статьях мы рассказывали как правильно собирать требования и что произойдет, если упустить важные детали или недостаточно внимательно отнестись к процессу. Также вы можете почитать о том, какой путь проходят идеи от их формулирования до воплощения в реальной программе.