бизнес требования к приложению

Типы требований к ПО с примерами | часть 2

Jan 1, 2019 · 4 min read

Откуда берутся требования? Какие вообще бывают требования? Об этом — читайте в этой статье.

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

🔥 Интересуешься тестированием и хочешь получать актуальную информацию?

👉 Присоединяйся к 3,000+ тестировщикам в Телеграм!

QA_PRO | Тестирование

Информация по обеспечению качества (QA), контролю качества (QC) и тестированию ПО

Источники требований

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

Для выявления требований чаще всего используются следующие техники:

Так же существуют более сложные методы, при котором аналитик должен «сам во всем разобраться», и уточнить собранную информацию у заказчиков:

Типы требований

П о чти в каждом проекте существует 3 заинтересованных стороны:

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

Уровень заказчика (бизнес-требований)

На этом уровне находится только один тип требований – бизнес требования (business requirements).

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

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

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

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

Уровень пользователя

Описывают “взгляд” на продукт глазами пользователя.

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

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

Пример оформления этих же требований в виде User Stories

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

Доступ к инструменту предоставляется только сотрудникам поддержки уровня Main support и выше.

Аналитики не должны иметь возможности изменять полученные отчеты.

Не зависимо от количества заказов, максимальное время открытия списка проверок не должно превышать 5 секунд.

Система должна работать с большими объёмами данных (сотни тысяч записей).

Уровень разработки (продуктных требований)

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

Конечным документом, содержащим все требования уровня разработки является Спецификация требований (software requirements specification, SRS). Часто это объемный документ, содержащий сотни страниц.

К уровню разработки относятся следующие типы требований:

Список проверок должен быть отсортирован по конечной дате выполнения (deadline) заказа.

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

Приложение должно поддерживать работу с мобильных устройств (минимальная ширина экрана – 320 px).

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

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

Основными подгруппами являются:

Приложение должно работать в последних версиях браузеров Chrome, Firefox, Safari.

Приложение должно работать на Raspberry PI 3b+.

Весь трафик между браузером и сервером должен быть зашифрован (HTTPS соединение).

Отправка письма с отчетом на почту аналитиков должно выполняться согласно RFC3207 (SMTP over TLS).

Все данные системы должны храниться в БД под управлением СУБД MySQL.

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

Теперь у вас есть понимание того, что:

Осталось определиться с тем, что такое “качественные” требования, и какими свойствами они должны обладать, чтоб с ними было проще работать в дальнейшем.

Источник

Путаница возникает по трем основным причинам.

Бизнес-требования часто перечислены в документе с бизнес-требованиями или BRD. Акцент в BRD делается на процессе или деятельности точного доступа к планированию и разработке требований, а не на том, как этого достичь; это обычно передается в спецификацию или документ системных требований (SRS или SRD) или другой вариант, такой как документ функциональной спецификации. Путаница между BRD и SRD может возникнуть, если не учитывать различие между бизнес-требованиями и системными требованиями. Следовательно, многие BRD фактически описывают требования к продукту, системе или программному обеспечению.

СОДЕРЖАНИЕ

Обзор

Бизнес-требования часто включают

Темы бизнес-требований

Преимущества

Описание

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

Формат

Полнота

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

Трудности

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

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

Определение потребностей бизнеса

Включает в себя следующие шаги:

Источник

Требования к ПО на пальцах

Пост про основы разработки требований — без сложных схем, терминов и таблиц, зато с гифками.

Если коротко, то основные этапы разработки требований — это:

Если после выполнения просьбы получилось что-то не то — это либо накосячил исполнитель,
либо вы некорректно поставили задачу.

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

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

Так что же такое требования и почему важно уметь их разрабатывать?

Итак, обратимся к истокам:

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

С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.

1. Зачем?

Как бы “ASAP. ” не требовалось что-то сделать — важно найти время и силы выяснить, зачем же это нужно.

Потому что часто, после выяснения цели, меняется или вовсе устраняется задача.

Заказчик попросит срочно показывать ему все заказы, которые были сделаны в системе. Допустим, мы напряглись и впихнули посреди спринта задачу на отображение всех заказов для администратора. После этого заказчик просит выводить в отдельном окне список всех компаний, чьи заказы он видит. Сделали и это. Потом заказчик просит выводить дополнительно вообще все компании-партнеры. Окей… Через какое-то время мы встречаемся с заказчиком и видим, как он выгружает оба списка в эксель, ВПРит разницу и начинает обзванивать компании, у которых нет заказов, чтобы напомнить им, что нужно делать заказы через нашу систему.

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

Можно воспользоваться методом “Пяти почему” или любым другим. Но обычно люди не сопротивляются: если проявить интерес к их работе — разгадка становится доступной.

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

Процесс заказа материалов считается автоматизированным, если >90% компаний-партнеров делают заказы через систему.

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

И да, не забывайте согласовывать эту красоту с заказчиками. Вообще не забывайте согласовывать требования со всеми заинтересованными сторонами.

2. Что?

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

Чтобы сократить процесс согласования счетов, мы можем:

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

Б. Перейти на электронный документооборот — достоверность счетов и данных в них будет подтверждена оператором ЭДО, подтверждение человеком не потребуется.

В. Автоматически распознавать сканы счетов и сравнивать данные с цифрами из системы закупок. Ручная проверка и согласование не потребуются.

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

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

3. Как?

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

Этот этап — дело техники. И если вы успешно прошли предыдущие два — будет гораздо проще.
Хоть техника и зависит от контекста, полезно двигаться по “чек-листу” Вигерса и других умных людей. Если для вас какой-то тип требований сейчас не актуален — окей, не описываем. Но важно не забыть и проверять себя.

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

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

4. Когда?

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

Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.

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

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

В схематическом и структурированном виде требования нужно приоритизировать — в зависимости от полезности (это вам скажет заказчик и пользователи) и трудоемкости (это вам скажет команда разработки).

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

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

Подробнее про требования рекомендую почитать в книге Вигерса и Битти: “Разработка требований к программному обеспечению”. Хоть книга не всегда простая, но очень полезная. Большинство других материалов по теме — пересказ этих истин с той или иной степенью вольности.

Спасибо за внимание и удачного проектирования.

Источник

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

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

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

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

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

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

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

Функциональные требования: что это такое и зачем они нужны

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

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

Функциональные требования, как правило, состоят из:

User story

User story описывает, что делает пользователь определенной роли для достижения результата, и что нужно сделать разработчику, чтобы воплотить эту задачу в жизнь.

Как правило используется шаблон:

Существуют различные примеры применения этой методологии. Например, так это работает в Trello:

В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.

Например, так выглядит задача об отслеживании NPS для интернет-магазина:

Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.

Use cases

Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.

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

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

Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.

Цель пользователя в том, чтобы хранить изображения в нашей платформе и использовать их для создания email-кампаний.

Примеры use case’ов:

Почему функциональные требования так важны

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

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

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

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

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

А как вы подходите к постановке задач разработчикам?

Источник

Бизнес требования к приложению

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

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

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

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

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

В наглядном виде модель выявления требований представлена на схеме:

Модель выявления требований

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

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

Из БТ вытекают критерии приемки и именно на их основе производится оценка результатов разработки ИТ-решения.

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

Кроме того, бизнес-требования в Agile — это ключевой инструмент Product Owner для управления бэклогом продукта и ведения переговоров со стейкхолдерами.

Согласно концепции Six Sigma, бизнес-требования — это критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от конкретного решения.

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

Вид БТ: Значимые характеристики продуктов или услуг

Вид БТ: Сбор, обработка, хранение и предоставление информации

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

Требование, заданное с позиции «Система должна делать…», задает конкретное направление действиям разработчика, а также дает некоторые ограничения — в отличие от формулировки требований с позиции «Система не должна…»

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

Источник