Одной из основных функций бизнес-аналитика, как специалиста, есть создание бизнес-требований, но многие заказчики не понимают зачем они собственно говоря нужны и считают лишней тратой времени их оформление.
Я уже не один раз затрагивал этот вопрос в своем блоге, но сейчас хочу поделиться с вами выжимкой материала найденном в интернете. Надеюсь он будет вам полезным.
Источник материала: https://systems.education/biz-req и https://systems.education/biz-req-dev
Роль Бизнес-требований (БТ)
- Бизнес-требования определяют смысл проекта и обосновывают его необходимость
- Бизнес-требования – это удобный инструмент договоренности: они объективны, компактны и понятны стейкхолдерам
- Из бизнес-требований вытекают критерии приемки проекта
- Бизнес-требования используются для определения рамок проекта
- Бизнес-требования помогают принимать решения о приоритетах
- В Scrum бизнес-требования являются (во всяком случае, так должно быть) основным инструментом владельца продукта для управления продуктовым бэклогом и для согласования его с другими стейкхолдерами
Требования в бизнес-анализе
Версия 3 BABOK Guide определяет требования таким образом:
- «пригодное для использования представление потребности», то есть фокусируется на том, что нужно.
- требование любого уровня должно фокусироваться на понимании приносимой пользы: зачем нужно
- форма представления может значительно варьироваться в зависимости от обстоятельств
Для формулирования требования потребность нужно поместить в какой-то контекст. Например потребность «Люди испытывают ежедневную потребность в пище» слишком общая. Если ее поместить в контекст морского путешествия, то требование становится уже более осмысленным: «Продукты питания, используемые в рационе моряков, должны сохранять пригодность для употребления в пищу в течение, как минимум, 30 дней при температуре до +30оС и высокой влажности, поскольку моряки длительное время вынуждены обходиться без поставок продовольствия».
Способы выполнения требования могут быть разными и они называются решениями.
Потребности, требования, решения, контекст
- Голубой блок обозначает контекст проекта и его элементы.
- Красный блок в левой части — потребности бизнеса и стейкхолдеров.
- Желтый блок в центре — бизнес-требования, требования стейкхолдеров и требования к решению.
- Зеленый блок справа — решения, удовлетворяющие требования (бизнес-процессы и информационные системы).
Потребности бизнеса, подлежащие удовлетворению в конкретном контексте, отражаются в бизнес-требованиях.
Решением для бизнес-требования обычно является бизнес-процесс или организация, выполняющая множество бизнес-процессов.
Когда бизнес-процесс реализуется в качестве решения, в нем начинают участвовать конкретные люди (стейкхолдеры), у которых возникают потребности, связанные с участием в бизнес-процессе. Из этих потребностей вырастают требования стейкхолдеров, а из них — требования к решению.
Полное решение состоит из бизнес-процессов и [информационных] систем, поддерживающих и обеспечивающих эти процессы. Системы реализуют требования к решению.
Пример определения бизнес-требования на основе анализа потребности
Потребность — «Торговой компании необходимо постоянно иметь в наличии или оперативно получать нужные товары в нужном количестве.»
Если бизнес-модель компании предполагает поддержание товарных запасов на складе, то бизнес-требование можно сформулировать так:
Для поддержания нужных товарных запасов на складах компании, их необходимо регулярно (BR-INV-01) пополнять через формирование заказов поставщикам.
Размер поддерживаемого запаса каждого товара должен определяться, исходя из оптимизации затрат и минимизации рисков упущенной прибыли (BR-INV-02).»
В тексте этого требования есть две ссылки: BR-INV-01 и BR-INV-02. Здесь BR означает «бизнес-правило» (Business Rule), а INV — Inventory (запас). Это ссылки на бизнес-правила, определяющие то, с какой именно регулярностью нужно пополнять запасы, и каков алгоритм расчета оптимального товарного запаса.
Бизнес-правило — один из типичных артефактов, сопровождающих бизнес-требования.
Артефакты бизнес-анализа, сопровождающие бизнес-требования
По мере определения бизнес-требований появляются:
- Доменные модели — высокоуровневые информационные модели предметной области.
- Глоссарий предметной области.
- Модели состояния объектов управления: на этом этапе мы определяем, какими объектами мы хотим управлять, и какие состояния нас интересуют (или какие состояния мы хотим отслеживать).
- Метрики и показатели этой деятельности, которые говорят нам о том, что важно для бизнеса и как мы оцениваем то, насколько хорошо или плохо, лучше или хуже выполняется его деятельность.
- Бизнес-правила: описания применяемых в данной компании алгоритмов, нормативов, ограничений, проверок, и политик.
Немного слов про бизнес-правила
Как правильно описывать бизнес-правила?
- Бизнес-правило должно быть сформулировано на языке бизнеса. В описании бизнес-правил не должны использоваться технические термины. Язык написания бизнес-правил должен быть понятным представителю бизнеса, не являющимся IT-специалистом. После описания бизнес-правил, постарайтесь абстрагироваться от своих технических знаний, поставьте себя на место представителя бизнеса, руководителя компании, для который вы разрабатываете продукт. Понятен ли вам написанный документ? Не содержит ли документ технических терминов, указания систем и языков программирования?
- Бизнес-правило должно описывать правило бизнеса, а не работу системы. Описание бизнес-правил должно содержать те требования бизнеса, которые должна решить система, но без описания работы системы. Например, у бизнеса есть правило: «Отслеживать время прихода и ухода сотрудников на рабочее место». Бизнес-правило не должно содержать описания, как достичь соблюдения данного правила: будет ли сотрудник записываться в журнал прихода и ухода, или на входе будет стоять автоматическая пропускная система, которая будет фиксировать время.
- Бизнес-правило должно описывать ограничения: какие операции не могут быть выполнены. Ограничительные бизнес-правила могут определять ограничения пользователей. Например: “В полис ОСАГО страховщик может вписать не более 5-ти водителей”; «Оформить заказ-онлайн может только клиент компании».
- Бизнес-правило подчиняется бизнесу: принять, изменить, отменить. Представители бизнеса могут изменять бизнес-правила, вносить поправки или отменять.
Рассмотрим несколько примеров бизнес-правил и требований к системе
| Бизнес-правило | Требование к системе |
| Постоянный посетитель библиотеки может отложить для себя до 10 книг. | Посетитель, имеющий карточку в библиотеке; посещающий библиотеку не менее 1 раза в месяц является постоянным.
Постоянный посетитель должен иметь возможность отложить для себя 10 книг. |
| Клиент компании может оформить заказ с оплатой курьеру. | Клиент компании-пользователь, имеющий учетную запись в интернет-магазине компании. Для оформления заказа, пользователь должен быть авторизован в системе.
Пользователь, должен иметь возможность оформить заказ. Заказ может быть оформлен: с доставкой по указанному адресу; с оплатой наличными при получении; с оплатой банковской картой при получении. |
Требования стейкхолдеров
При проектировании бизнес-процесса, необходимого для выполнения бизнес-требований, необходимо учитывать потребности и требования людей, участвующих в этом бизнес-процессе. Такие люди называются причастными лицами (стейкхолдерами). О них я уже писал в своем блоге.
Предположим, мы проектируем бизнес-процесс поддержания товарных запасов на складах компании. Одной из разновидностей стейкхолдеров будут закупщики — специалисты, которые формируют заказы поставщикам. Если мы придем к такому человеку и попросим рассказать, чем он занимается и в чем нуждается, мы услышим примерно следующее:
Как специалисту, отвечающему за поддержание запасов, мне нужно иметь возможность:
- Автоматически рассчитывать заказ по каждому товару с использованием определенного алгоритма (здесь прозвучит то же самое бизнес-правило, которое упоминалось в бизнес-требовании). Почему автоматически? Потому что мне надо на 4 складах поддерживать 3000 товарных позиций, поступающих от 100 поставщиков — это невозможно или крайне сложно обрабатывать вручную.
- По любой позиции автоматически рассчитанного заказа видеть то, как именно была посчитано это значение и почему оно именно такое — алгоритм может не учитывает какие-то известные мне нюансы. Например, ожидаемое значительное повышение или снижение продаж.
- Менять количество в автоматически рассчитанном заказе — в конечном счете за заказ отвечаю я, а не система. Система не может учесть всё, и если я считаю нужным поменять заказанное количество, у меня должна быть возможность это сделать.
- Смотреть для проверки не на все 3000 позиций, а только на те, где расчеты системы могут быть вызвать сомнения. Например, недостаточная история продаж, высокая волатильность продаж или другие подобные факторы.
Примерно так будет рассказывать нам живой человек. «Пользовательская история» (User Story) — естественная форма представления требований стейкхолдеров, имеющая формат <роль> <задача> <нужная возможность>.
Например:
Как специалисту, отвечающему за поддержание запасов, для формирования заказов поставщикам мне нужно:
- Автоматически рассчитывать заказ по каждому товару с использованием BR-INV-02;
- по любой позиции заказа иметь возможность посмотреть детали расчета и
- вручную изменить заказываемое количество,
- видеть отдельно те позиции заказа, по которым, возможно, требуется моя корректировка (BR-INV-03)
Обычно требованиям стейкхолдеров сопутствуют дополнительные артефакты:
- Карты стейкхолдеров (показывают, кто участвует в процессах)
- Модели и другие описания процессов
- Варианты использования (Use Cases)
- Образцы данных, с которыми работают стейкхолдеры (помогают понять ситуацию и потребности стейкхолдеров)
Функциональные и нефункциональные требования
Нефункциональные требования (НФТ) определяют свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать, не относящиеся к поведению системы. Например, производительность, удобство сопровождения, расширяемость, надежность, факторы эксплуатации.
Из бизнес-требований, помимо функциональных (ФТ) и нефункциональных требований, напрямую могут вытекать ещё и требования причастных сторон. В свою очередь, из требований причастных сторон могут вытекать ФТ и НФТ.
В наглядном виде модель выявления требований представлена на схеме:
Почему бизнес-требования так важны
Бизнес-требования играют важную роль на проекте, поскольку помогают определить смысл проекта и обосновать его необходимость. Именно бизнес-требования, как правило, используются для определения рамок проекта, то есть входят в состав концепции проекта.
Ввиду своей понятности всем заинтересованным лицам, бизнес-требования служат артефактом, на основе которого удобно заключать договоренности. Чем ниже уровень требований, тем больше нюансов, а значит, сложнее договариваться.
Из БТ вытекают критерии приемки и именно на их основе производится оценка результатов разработки ИТ-решения.
Также бизнес-требования часто используются на проекте для приоритизации решений: если есть понимание, как то или иное решение связано с БТ, приоритизировать его не составит труда. Именно БТ являются снованием для принятия решений в ходе проектирования и внесения изменений в реализацию проекта.
Кроме того, бизнес-требования в Agile — это ключевой инструмент Product Owner для управления бэклогом продукта и ведения переговоров со стейкхолдерами.
Какие бывают бизнес-требования?
Согласно концепции Six Sigma, бизнес-требования — это критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от конкретного решения.
Исходя из определения Six Sigma, классификация требований будет опираться на критичные активности, т. е. бизнес-требования могут быть связаны с:
- Определением значимых характеристик продуктов или услуг.
- Распознаванием и обработкой событий.
- Принятием решений (своевременность, правильность).
- Сбором, обработкой, хранением и предоставлением информации.
- Обеспечением возможности выполнения действий (субъект, действие, объект, время, условия, способ).
- Предотвращением возможности выполнения действий (субъект, действие, объект, время, условия, способ
Ниже приведены примеры бизнес-требований по видам критичных активностей.
Вид БТ: Значимые характеристики продуктов или услуг
Примеры БТ:
- Скорость обслуживания — очередь на кассе должна быть не длиннее 4 покупателей.
- Своевременность доставки — клиент должен получить пиццу горячей и не умереть ожидая ее.
- Простота получения услуги — оформление предварительно одобренного кредита должно завершаться за одно посещение клиента.
Вид БТ: Распознавание и обработка событий
Примеры БТ:
- Банк должен своевременно получать оповещения о сбоях в работе банкоматов.
- К моменту начала этапа работ, все нужные материалы и оборудование должны находиться на объекте строительства и быть готовыми к использованию.
- Сотрудники должны быть своевременно проинформированы о назначенных им задачах.
Вид БТ: Принятие решений
Примеры БТ:
- По каждому обнаруженному дефекту, на основе имеющейся информации, должно быть оперативно принято решение о способе его устранения в соответствии с протоколом реакции на аварийные ситуации.
- Решение о выдаче кредита должно приниматься на основании…
- Отпускная цена на товар для конкретного клиента определяется на основании… в зависимости от …
Вид БТ: Сбор, обработка, хранение и предоставление информации
Примеры БТ:
- С момента обнаружения дефекта и до его полного устранения должна регистрироваться и храниться следующая информация.
- Инвестиционный банк в конце каждого рабочего дня должен направлять Регулятору информацию о…
- Для принятия решений об участии в тендере необходимы результаты предварительной оценки себестоимости проекта.
Вид БТ: Обеспечение возможности выполнения действий
Примеры БТ:
- В случае неудовлетворенности качеством обслуживания, клиент должен иметь возможность направить жалобу по телефону, по электронной почте или через сайт компании.
- Клиент должен иметь возможность отказаться от заказа до момента его отправки.
- Покупатели должны иметь возможность оформить и оплатить покупку самостоятельно посредством мобильного приложения.
Вид БТ: Предотвращение возможности выполнения действий
Пример БТ:
- Должна исключаться возможность доступа к защищенным ресурсам лиц, не являющихся сотрудниками компании.
Проблемы в бизнес-требованиях
Можно выделить несколько типичных признаков проблем с бизнес-требованиями.
- Неконкретность (слишком абстрактная формулировка)
- Невозможность проверки (нет понимания, что является индикатором выполнения требования)
- «Магические» числа (приведены какие-то необоснованные данные: «время обработки заявки 14 минут»)
- Непонятная польза (не написано, для чего делаем то, что делаем; действительно ли это необходимо)
- Избыточная детализация (зачастую делает требование слишком жестким и нечитаемым)
- Невыполнимость (например, требование «обеспечить 100%-ую достоверность данных». Для чего это требование? Почему возникают недостоверности? С этой проблемой можно как-то бороться или это просто факт?)
- Несогласованность (противоречивость; с одной стороны Покупатель хочет найти продукт с наилучшими качествами по наименьшей цене, а с другой — Продавец хочет стимулировать покупку продуктов, приносящих наибольшую прибыль)
- Нерелевантность (приведено требование, которое вообще не понятно, какое отношение имеет к данному проекту)
- Привязка к конкретному решению, в том числе — конкретный бизнес-процесс
Примеры некорректных бизнес-требований
Обеспечить высокое качество обслуживания — Как проверить, что качество обслуживания высокое?
- Сократить среднее время обработки заказа до 14 минут — Почему до 14 минут, чем это обосновано? А почему не до 1 минуты? Какую пользу принесет сокращение времени обработки заказа?
- Обеспечить 100% достоверность учетных данных — Как мы узнаем какая достоверность? Как можно определить, что данные достоверны? В результате чего возникает недостоверность? С этим реально можно что-то сделать? Выполнимо ли данное требование?
- Гарантировать правильность принимаемых решений — Что выступает гарантом? Это выполнимо?
- Внедрить ERP — Кому и зачем это нужно? В чем проблема?
Типовые ловушки аналитика
Проблемы с требованиями, как правило, возникают, когда аналитик попадает в одни и те же типовые ловушки. Вот основные ловушки аналитика при работе с бизнес-требованиями:
- Формальность — «пишу, потому что надо здесь что-то написать».
- Узкие рамки анализа — не рассматриваем ничего, что выходит за рамки проекта.
- Превращение в аудит — выясняем все обо всем «на всякий случай».
- Превращение метода в цель — строгое следование определенному шаблону с превращением средств в цель и потерей основной цели проекта.
Что можно сделать с каждой из этих ловушек?
| Ловушка | Описание | Решение |
|---|---|---|
| Формальность | «Пишу, потому что надо здесь что-то написать» | Ставить себя на место читателя (необходимо понимать, что и для кого мы пишем). |
| Узкие рамки анализа | Фокусировка только на том, что относится к проекту, т.е. не рассматриваем ничего, что выходит за рамки проекта | Анализировать область шире, чем те рамки, которые хотим установить для проекта. |
| Превращение в аудит | «На всякий случай» выясняем все обо всем | Постоянно спрашивать себя: «как это связано с проектом?» |
| Превращение метода в цель | Строгое следование определенному шаблону с превращением средств (канва бизнеса, бизнес-процессы, стейкхолдеры) в цель и потерей основной цели проекта | Задать себе вопрос: «можно ли обойтись без э |
Документирование бизнес-требований
В практике бизнес-аналитика присутствует два основных подхода документирования требований:
1. Монолитно
- Все требования описываются вместе в виде структурированного повествовательного текста.
- Возможны ссылки на элементы требований (цели, метрики, предположения, риски и т. п.).
2. Дробно
- Каждое требование описывается отдельно.
- Каждому требованию присваивается уникальный идентификатор.
- Возможна трассировка к конкретному бизнес-требованию.
Шаблон монолитного описания БТ
Карл Вигерс в своей книге «Разработка требований к программному обеспечению. Руководство» предлагает хороший шаблон описания БТ монолитом в рамках документа Scope and Vision (рамки и видение). В этом документе выделяется раздел Бизнес-требования, который включает в себя:
- Контекст.
- Описание возможности.
- Бизнес-цели.
- Метрики успешности.
- Образ результата (Vision).
- Деловые риски.
- Предположения и зависимости бизнеса.
Советы Вигерса по описанию БТ
- Сокращайте шаблон в соответствии с потребностями.
- Заполняйте не сверху вниз, а по мере поступления информации.
- Пустой раздел — признак его ненужности или необходимости дополнительного изучения.
- Не повторяйте то, что уже описано в другом месте — сошлитесь на имеющееся описание.
- Исходите из возможности повторного использования БТ в других проектах.
- Выявляйте конфликты, противоречия и выносите на обсуждение.
- Проводите повторное рассмотрение БТ при каждой смене лиц, принимающих решения, чтобы убедиться, что понимание БТ не изменилось
Шаблон дробного описания БТ
Ниже представлен авторский шаблон дробного описания бизнес-требований. Он состоит из нескольких ключевых элементов:
1. Заголовок, который включает в себя:
- Уникальный идентификатор.
- Краткое описание.
2. Определение, развернутое объяснение, что из себя представляет БТ.
3. Источник, откуда это требование взялось.
4. Зависимости, если они есть между другими требованиями.
5. Обоснование, краткое пояснение мотивации.
6. Комментарий, любые пояснения. В приведенном ниже примере представлено описание диаграммы состояний.
Добавил:
Upload
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:
Системная инженерия ЛЕКЦИЯ 4.doc
Скачиваний:
449
Добавлен:
17.03.2015
Размер:
458.24 Кб
Скачать
Требования к
программной системе часто классифицируются
как функциональные, нефункциональные
и требования предметной области.
Функциональные
требования
задают “что” система должна делать;
нефункциональные
– с соблюдением “каких условий”
(например, скорость отклика при выполнении
заданной операции); часто функциональные
требования представляют в виде сценариев
(вариантов использования) Use Сase.
-
Функциональные
требования. Это перечень сервисов,
которые должна выполнять система,
причем должно быть указано, как система
реагирует на те или иные входные
данные, как она ведет себя в определенных
ситуациях и т.д. В некоторых случаях
указывается, что система не должна
делать. -
Нефункциональные
требования. Описывают характеристики
системы и ее окружения, а не поведение
системы. Здесь также может быть приведен
перечень ограничений, накладываемых
на действия и функции, выполняемые
системой. Они включают временные
ограничения, ограничения на процесс
разработки системы, стандарты и тд. -
Требования
предметной области. Характеризуют ту
предметную область, где будет
эксплуатироваться система. Эти требования
могут быть функциональными и
нефункциональными.
В действительности
четкой границы между этими типами
требований не существует. Например,
пользовательские требования, касающиеся
безопасности системы, можно отнести к
нефункциональным. Однако при более
детальном рассмотрении такое требование
можно отнести к функциональным, поскольку
оно порождает необходимость включения
в систему средства авторизации
пользователя. Поэтому, рассматривая
далее эти виды требований, мы должны
всегда помнить, что данная классификация
в значительной степени искусственна.
Классический
пример (см. рисунок 4.3) высокоуровневого
структурирования групп требований как
требований к продукту описан в работах
одного из классиков дисциплины управления
требованиями – Карла Вигерса.
Рисунок 4.3. Уровни
требований по Вигерсу
-
Группа
функциональных требований-
Бизнес-требования
(Business Requirements)
– определяют высокоуровневые цели
организации или клиента (потребителя)
– заказчика разрабатываемого
программного обеспечения. -
Пользовательские
требования (User Requirements)
– описывают цели/задачи пользователей
системы, которые должны достигаться/выполняться
пользователями при помощи создаваемой
программной системы. Эти требования
часто представляют в виде вариантов
использования (Use Cases). -
Функциональные
требования (Functional Requirements)
– определяют функциональность
(поведение) программной системы, которая
должна быть создана разработчиками
для предоставления
возможности
выполнения пользователями своих
обязанностей в рамках бизнес-требований
и в контексте пользовательских
требований.
-
-
Группа
нефункциональных требований
(Non-Functional Requirements)-
Бизнес-правила
(Business Rules)
– включают или связаны с корпоративными
регламентами, политиками, стандартами,
законодательными актами, внутрикорпоративными
инициативами (например, стремление
достичь зрелости процессов по CMMI 4-го
уровня), учетными практиками, алгоритмами
вычислений и т.д. На самом деле, достаточно
часто можно видеть недостаточное
внимание такого рода требованиям со
стороны сотрудников ИТ-департаментов
и, в частности, технических специалистов,
вовлеченных в проект. Business Rules Group дает
понимание бизнес-правила,
как “положения, которые определяют
или ограничивают некоторые аспекты
бизнеса. Они подразумевают организацию
структуры бизнеса, контролируют или
влияют на поведение бизнеса”.
Бизнес-правила часто определяют
распределение ответственности в
системе, отвечая на вопрос “кто будет
осуществлять конкретный вариант,
сценарий использования” или диктуют
появление некоторых функциональных
требований. В
контексте дисциплины управления
проектами
(уже вне проекта разработки программного
обеспечения, но выполнения бизнес-проектов
и бизнес-процессов) такие правила
обладают высокой значимостью и, именно
они, часто определяют ограничения
бизнес-проектов, для автоматизации
которых создается соответствующее
программное обеспечение. -
Внешние
интерфейсы (External Interfaces)
– часто подменяются “пользовательским
интерфейсом”. На самом деле вопросы
организации пользовательского
интерфейса безусловно важны в данной
категории требований, однако,
конкретизация аспектов взаимодействия
с другими системами, операционной
средой (например, запись в журнал
событий операционной системы),
возможностями мониторинга при
эксплуатации – все это не столько
функциональные требования (к которым
ошибочно приписывают иногда такие
характеристики), сколько вопросы
интерфейсов, так как функциональные
требования связаны непосредственно
с функциональностью
системы, направленной на решение
бизнес-потребностей. -
Атрибуты
качества (Quality Attributes)
– описывают дополнительные характеристики
продукта в различных “измерениях”,
важных для пользователей и/или
разработчиков. Атрибуты касаются
вопросов портируемости, интероперабельности
(прозрачности взаимодействия с другими
системами), целостности, устойчивости
и т.п. -
Ограничения
(Constraints) –
формулировки условий, модифицирующих
требования или наборы требований,
сужая выбор возможных решений по их
реализации. В частности, к ним могут
относиться параметры производительности,
влияющие на выбор платформы реализации
и/или развертывания (протоколы, серверы
приложений, баз данных, …), которые, в
свою очередь, могут относиться, например,
к внешним интерфейсам.
-
-
Системные
требования (System Requirements)
– иногда классифицируются как составная
часть группы функциональных требований
(не путайте с как таковыми “функциональными
требованиями”). Описывают высокоуровневые
требования к программному обеспечению,
содержащему несколько или много
взаимосвязанных подсистем и приложений.
При этом, система может быть как целиком
программной, так и состоять из программной
и аппаратной частей. В общем случае,
частью системы может быть персонал,
выполняющий определенные функции
системы,
например, авторизация выполнения
определенных операций с использованием
программно-аппаратных подсистем.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
Что такое нефункциональные требования, примеры, что в них должно быть
Что такое нефункциональные требования, примеры, что в них должно быть
Миша Ряженка
Founder, Executive Partner
Что такое нефункциональные требования?
Это условия, при которых продукт должен работать, и качества, которыми он должен обладать (например, производительность, надежность, масштабируемость).
Что относят к нефункциональным требованиям?
Технические ограничения, локализация, доступность, производительность и масштабируемость, надежность, доступность, безопасность, удобство использования.
Миша Ряженка
Founder, Executive Partner
Какими должны быть нефункциональные требования?
Они должны быть измеримы. Их можно проверить и протестировать.
Миша Ряженка
Founder, Executive Partner
Нефункциональные требования
Представьте, что вы покупаете мотоцикл. Какие характеристики вам важны? Чтобы он мог ехать со скоростью 150 км в час и не развалиться на части? Или для вас важно, можно ли прикрепить к нему мотоколяску или прицеп? Наконец, он должен быть безопасным? Все эти требования не описывают напрямую основную функцию мотоцикла — доставку человека из пункта А в пункт Б. Это нефункциональные требования, но для водителей они тоже имеют значение.
К сайтам, ПО, приложениям люди тоже предъявляют нефункциональные требования. Это качества, которые удовлетворяют пользователей.
Что такое нефункциональные требования
Нефункциональные требования — это условия, при которых продукт должен работать, и качества, которыми он должен обладать (например, производительность, надежность, масштабируемость).
Если совсем просто, то к нефункциональным относят те требования, которые не описывают функциональность продукта.
Какие бывают нефункциональные требования
Нефункциональные требования описывают эксплуатационные качества к продукту. Например, ваш продукт собирает какие–либо данные пользователей и работает на территории ЕС. Значит, он должен по закону соответствовать правилам GDPR — Общий регламент по защите данных.
Технические ограничения. Операционные системы и их версии, сетевые особенности, браузеры и их версии, устройства и другие аппаратные требования. Например, разработка должна вестись на определенной платформе, пользователь входит по отпечаткам пальцев.
Комплаенс требования. Процессы и стандарты, принятые в компании или стране. Продукт должен им следовать и разрабатываться в соответствии с ними.
Производительность и масштабируемость. Насколько быстро продукт реагирует на определенные действия пользователей при определенной рабочей нагрузке. Например, сколько пользователь должен ждать, чтобы прошла регистрация в личном кабинете, был обработан платеж с банковской карты. Требования к производительности могут описывать фоновые процессы, которые пользователь не видит. Например, резервное копирование. Масштабируемость оценивает самые высокие рабочие нагрузки, при которых система все еще будет справляться.
Надежность, доступность, ремонтопригодность. Как часто в системе происходят критические сбои. Как быстро их можно устранить. Пример требований к доступности: сайт должен быть доступна для пользователей из США 98% времени каждый месяц в рабочие часы.
Безопасность. Как система и ее данные защищены от атак или несанкционированного доступа. Но здесь есть одна загвоздка. Львиная доля нефункциональных требований безопасности может быть переведена в конкретные функциональные требования.
Локализация. Соответствие системы особенностям страны, в которой ее будут использовать: местные языки, законы, валюты, культура, орфография и так далее. Чем больше продукт вписывается в контекст, тем больший успех он должен иметь у местной целевой аудитории. Чтобы документально подтвердить это требование, вы должны опираться на предварительное исследование рынка. Пример требования к локализации: формат даты должен быть следующим: месяц.число.год.
Удобство использования. Удобно ли людям пользоваться продуктом. Nielsen Norman Group предлагают оценивать юзабилити (usability, удобство использования) по пяти параметрам:
-
Обучаемость. Насколько быстро пользователи могут выполнить целевые действия, как только увидят интерфейс?
-
Эффективность. Как быстро пользователи могут достичь своих целей в продукте?
-
Запоминаемость. Могут ли пользователи вернуться к интерфейсу через некоторое время и сразу же начать работать с ним?
-
Ошибки. Как часто пользователи допускают ошибки при использовании продукта?
-
Удовлетворенность. Приятен ли дизайн в использовании?
Как скорость загрузки влияет на отказы пользователей. Чем дольше загружается, тем чаще люди закрывают продукт
Миша Ряженка
Founder, Executive Partner
Нефункциональные требования: производительность
Для пользователей важно, как быстро загружается сайт или приложение. Если слишком долго, они не дождутся загрузки и закроют его.
Есть три метрики для времени отклика, они основаны на том, как работает человеческое внимание:
0,1 секунды — предел, после которого реакция системы не кажется мгновенной;
1 секунда — пользователь заметит задержку, но для него это не критично;
10 секунд — внимание пользователя полностью потеряно.
За скоростью следят и поисковики. Страницы с быстрой загрузкой и качественным контентом будут отображаться на первой странице поисковой выдачи. Если же контент хорош, но сайт долго грузится, то первых строчек ему не видать. Например, исследования Гугл показали, что 50 пользователей из 100 закроют сайт, если он загружается дольше трех секунд.
У Яндекса и Google есть бесплатные сервисы, которые измеряют скорость загрузки сайтов: Яндекс. Вебмастер и Google PageSpeed Insights. Сервисы дают рекомендации, на чем теряется время загрузки и что исправить, чтобы повысить скорость.
Интерфейс Яндекс.Вебмастер
Как сформулировать нефункциональные требования
Сделайте их измеримыми и тестируемыми. Нефункциональные требования следует формировать так, чтобы их можно было измерить и проверить. Например, Wow–эффект у приложения: это требование нельзя измерить и проверить, но если сформировать его как «на юзабилити тесте более 70% респондентов отметили высокое качество интерфейса в опроснике», то отследить приближение такой цели и протестировать ее достижение становится легко.
Обязательно сформулируйте требования количественно: единицы измерения, точные методологии, что считать успехом, а что неудачей.
Устанавливайте требования к компонентам системы, а не к целым продуктам. Подумайте, какие интерфейсы и системы нуждаются в нефункциональных требованиях. Например, пользователи никогда не взаимодействуют с панелью администратора, значит, ограничивать производительность для этого компонента нет смысла.
Связывайте нефункциональные требования с бизнес–целями. Если сайт по каким–то причинам не доступен вместо 30 минут 25, это может не оказать резкого влияния на показатели продаж. Но будет стоить нескольких часов работы инженера.
Учитывайте технические ограничения. Если сторонний API возвращает данные медленнее, чем вам нужно, вы или ваша команда мало что можете с этим поделать. Остается только принять этот факт.
Учитывайте архитектурные ограничения. Устаревшие системы могут накладывать ограничения на качество. Иногда нет другого выхода как полностью переделать текущую архитектуру.
Используйте стандарты и руководства. Вполне вероятно, что многие рекомендации по качеству системы уже были сформулированы раньше. Например, изучите руководства по приложениям для iOS или Android, чтобы понять нефункциональные требования для своего приложения.