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