Что такое нефункциональные требования
Нефункциональные требования к программному обеспечению. Часть 1
Введение
Разрабатывая новую информационную систему или внедряя уже существующую, вы неизбежно сталкиваетесь с необходимостью определить нефункциональные требования к вашей системе.
Нефункциональные требования: какие они бывают
Начнем с того, что требования к программным продуктам или информационным системам можно разделить на две большие группы. Это функциональные требования (описывающие, что необходимо реализовать в продукте или системе, в т.ч. какие действия должны выполнять пользователи при взаимодействии с ними) и нефункциональные требования (описывающие, как должна работать система или программный продукт, и какими свойствами или характеристиками она должна обладать).
Как правило, говоря о нефункциональных требованиях, чаще всего говорят об атрибутах качества (т.е. требованиях, определяющих качественные характеристики разрабатываемого программного обеспечения или системы, такие как производительность, надежность, масштабируемость), не обращая внимания на другие виды нефункциональных требований, а именно:
Все эти требования должны быть определены и зафиксированы, прежде чем вы приступите к реализации вашей системы или продукта.
Нефункциональные требования: как их определять
Теперь, когда мы познакомились с различными видами нефункциональными требований, неплохо понять, что нужно делать дальше.
Нефункциональные требования: работа над определением
Как для определения функциональных, так и для определения нефункциональных требований используются рабочие группы, члены которых определяют, проверяют и утверждают требования. Для групп по определению нефункциональных требований особенно важно привлечь к этой работе не только аналитиков и пользователей, но и архитекторов и ключевых разработчиков продукта или системы, а также группу тестирования. Архитектор воспринимает нефункциональные требования как входные данные для выбора и проектирования архитектуры приложения, а группа тестирования планирует те сценарии нагрузочного тестирования, которые будут использоваться для проверки выполнения нефункциональных требований (в основном это касается атрибутов качества).
Роли, которые при этом играют участники рабочей группы по определению нефункциональных требований, описаны далее.
Пример сценария, используемого для определения требований к производительности модуля системы, рассылающего уведомления пользователям сайта по электронной почте:
1. Система получает оповещение о событии, инициирующем рассылку уведомлений.
2. Система осуществляет рассылку оповещений по адресам из списка рассылки X, используя шаблон Y. Для рассылки сообщений используется сервис Z.
3. В случае невозможности завершения рассылки, система предпринимает повторные попытку рассылки.
Требования к времени оповещения о событии, инициирующем рассылку уведомлений: система должна получать оповещение не позднее чем через XX секунд после возникновения события.
Требования к времени отправки уведомлений: все уведомления должны быть отправлены не позднее YY минут после получения оповещения о событии
Требования к повторной отправке рассылки после неудачной попытки: число повторных попыток должно быть равным 10, с интервалом в 10 мин после каждой неудачной попытки отправки.
Какие вопросы при этом нужно задавать заказчику? В сущности, только один: через сколько времени после возникновения события все пользователи сайта должны гарантированно получить уведомление.
Критерии качественных нефункциональных требований
Как к функциональным, так и к нефункциональным требованиям применяются критерии качества требований — т.е. описание тех качеств, которым должны удовлетворять качественные требования.
Качество нефункциональных требований непосредственно определяет качество разрабатываемого продукта или системы и достигается за счет итеративного процесса определения и анализа нефункциональных требований при слаженной работе всей группы, участвующей в их разработке.
Атрибуты качества
Этот раздел будет посвящен характеристикам качества продукта или системы.
Характеристики качества и модель качества ПО
Определение атрибутов качества тесно связано с выбранной для вашего продукта моделью качества. Разработкой модели качества занимается группа обеспечения качества (в которую входят тестировщики и которая ими, разумеется, не ограничивается).
В индустрии ПО есть несколько моделей качества, принятых в качестве стандарта. Эти модели были разработаны в 70-е-80-е годы прошлого века и продолжают совершенствоваться.
Характеристики качества с точки зрения влияния на архитектуру системы
Все атрибуты качества с точки зрения архитектуры системы можно разделить на две большие группы: первая группа (runtime) – это атрибуты, относящиеся ко времени работы приложения или системы; вторая группа (design time) определяет ключевые аспекты проектирования приложения или системы. Многие из этих атрибутов взаимозависимы.
Рассмотрим более подробно каждую из этих групп.
Группа runtime
Группа design time
О том, как, где, когда и откуда нужно взять конкретные значения для всех этих параметров, я расскажу в продолжении этой статьи.
Функциональные и нефункциональные требования: полное руководство
Точно знать, какие функции и возможности клиент хочет от приложения, довольно сложно для команды разработчиков программного обеспечения. Во избежание недоразумений заказчику и команде разработчиков программного обеспечения необходимо определить требования к проекту: как функциональные, так и нефункциональные требования для будущего приложения. В этой статье мы объясним разницу между двумя типами требований и поделимся лучшими практиками их сбора.
Что такое функциональные требования?
При разработке программного обеспечения функциональные требования определяют функции, которые должно выполнять все приложение или только один из его компонентов. Функция состоит из трех шагов: ввод данных — поведение системы — вывод данных. Он может вычислять, манипулировать данными, выполнять бизнес-процессы, устанавливать взаимодействие с пользователем или выполнять любые другие задачи.
Другими словами, функциональное требование — это то, ЧТО приложение должно или не должно делать после ввода некоторых данных.
Функциональные требования важны, поскольку они показывают разработчикам программного обеспечения, как должна вести себя система. Если система не соответствует функциональным требованиям, значит, она не работает должным образом.
Что такое нефункциональные требования?
Нефункциональные требования определяют стандарты производительности и атрибуты качества программного обеспечения, например удобство использования системы, эффективность, безопасность, масштабируемость и т.д.
В то время как функциональные требования определяют, что делает система, нефункциональные требования описывают, КАК система это делает. Например, веб-приложение должно обрабатывать более 15 миллионов пользователей без какого-либо снижения производительности, или веб-сайт не должен загружаться более 3 секунд.
Если приложение не соответствует нефункциональным требованиям, оно продолжает выполнять свои основные функции, однако не сможет обеспечить удобство для пользователя.
Нефункциональные требования важны, поскольку они помогают разработчикам программного обеспечения определять возможности и ограничения системы, которые необходимы для разработки высококачественного программного обеспечения. Следовательно, нефункциональные требования так же важны, как и функциональные требования для успешного внедрения продукта.
Почему важна разница между функциональными и нефункциональными требованиями?
Четко определенные функциональные и нефункциональные требования помогают разработчикам программного обеспечения создавать продукт, точно соответствующий потребностям клиента. Однако действительно ли необходимо знать разницу между функциональными и нефункциональными требованиями?
Основная причина знать разницу между функциональными и нефункциональными требованиями заключается в том, что они определяют объем работ по проекту. Разработчики программного обеспечения должны идти в ногу с этим объемом, чтобы разработать приложение в рамках своих временных рамок и бюджета.
Если объем работ постоянно меняется, команде разработчиков приходится продлевать сроки, и затраты на разработку возрастают. Это может привести к неблагоприятным последствиям для проекта.
Важность различения двух типов требований имеет первостепенное значение при создании MVP. Команда разработчиков и заказчик должны обсудить, какие функции и функции следует реализовать в приложении в первую очередь. Заказчик может иметь собственное видение проекта и его требований. Если заказчик решает удалить или изменить какую-либо функцию, важно понимать, что это за требование. В большинстве случаев разработчики программного обеспечения могут просто изменить нефункциональные требования, в то время как функциональные требования потребуют дополнительной работы и серьезных изменений.
Когда заказчик и поставщик разработки программного обеспечения знают разницу между функциональными и нефункциональными требованиями, это помогает им более точно определять объем работ, более точно ранжировать требования по важности, оптимизировать затраты на проект и лучше удовлетворять потребности заказчика..
Как собираются функциональные и нефункциональные требования?
В идеале, прежде чем обращаться в компанию по разработке программного обеспечения, у клиентов уже должны быть под рукой все функциональные и нефункциональные требования. Поэтому их необходимо подготовить заранее самостоятельно или попросить стороннего поставщика.
Давайте посмотрим, что включает в себя каждый тип требований.
Функциональные требования можно разделить на три группы:
Нефункциональные требования подпадают под различные категории, в том числе:
Примеры и передовой опыт
Существует множество других форматов, которые могут помочь в выполнении требований проекта. Давайте посмотрим на самые эффективные.
Истории пользователей
Обычно требования формулируются в виде пользовательских историй. Пользовательские истории — это требования, предъявляемые пользователем. Обычно они имеют форму нескольких простых предложений, имеющих один и тот же образец:
Как (пользователь) я хочу (цель), чтобы (причина).
Пример пользовательской истории: как руководитель проекта я хочу понимать прогресс команды разработки программного обеспечения, чтобы я мог сообщить о результатах генеральному директору и заинтересованным сторонам проекта.
Разработчики программного обеспечения обычно составляют требования с использованием пользовательских историй, когда они хотят донести идеи о функциях и функциях продукта до участников, не являющихся техническими специалистами.
Сценарии использования
Сценарии использования шире, чем пользовательские истории. Они включают типы пользователей и все возможные действия, которые пользователь может выполнять в приложении. В отличие от пользовательских историй, описывающих конечную цель функции, варианты использования включают последовательность шагов, ведущих к цели.
Например, если вы хотите создать приложение для управления логистикой и цепочкой поставок, разработчики программного обеспечения должны подумать о следующих ролях: продавцы, покупатели, поставщики, менеджеры, диспетчеры и многие другие.
Действия для этих ролей могут выглядеть следующим образом:
Документ со спецификацией требований к программному обеспечению
Спецификация требований к программному обеспечению ( SRS ) — это документ, на который группа разработчиков программного обеспечения полагается при создании приложения. Он включает в себя все потребности и пожелания клиентов, переведенные на понятный для команды разработчиков язык — подробное описание всех функций и возможностей продукта.
Основные разделы, которые обычно включаются в документ SRS:
Создание SRS, пользовательских примеров и пользовательских историй имеет важное значение для эффективной разработки приложений.
Однако есть и другие документы, не менее важные для успешного запуска и развития проекта.
Заключение
С помощью специализированных программных услуг компании могут создавать приложения любого типа для эффективного развития своего бизнеса. Однако для того, чтобы приложение действительно соответствовало потребностям их бизнеса, оно должно иметь подробные функциональные и нефункциональные требования.
Чтобы сформировать функциональные и нефункциональные требования, вы можете обратиться за помощью к своей компании-разработчику программного обеспечения, сторонним компаниям или сделать это самостоятельно. Хорошо продуманные требования гарантируют, что ваш партнер по разработке программного обеспечения будет полностью понимать, как разработать цифровое решение, которое полностью соответствует вашим ожиданиям и удовлетворяет потребности вашего бизнеса.
Требования к ПО на пальцах
Пост про основы разработки требований — без сложных схем, терминов и таблиц, зато с гифками.
Если коротко, то основные этапы разработки требований — это:
Если после выполнения просьбы получилось что-то не то — это либо накосячил исполнитель,
либо вы некорректно поставили задачу.
Как известно, неверная задача может обойтись довольно дорого. Например, если полгода команда из 5 программистов разрабатывала систему, которая никому не была нужна.
В наш беспокойный век Agile разработкой требований часто пренебрегают. Но гибкие методологии не всегда спасают от больших потерь. Поэтому, даже если у вас нет аналитика на проекте, даже если вы вообще не IT — не забывайте про здравый смысл и берите из лучших практик то, что нужно в данный момент.
Так что же такое требования и почему важно уметь их разрабатывать?
Итак, обратимся к истокам:
То есть о требованиях можно говорить, как о будущих свойствах. Как о том, каким будет продукт, удовлетворяющий целям разработки.
С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.
1. Зачем?
Как бы “ASAP. ” не требовалось что-то сделать — важно найти время и силы выяснить, зачем же это нужно.
Потому что часто, после выяснения цели, меняется или вовсе устраняется задача.
Заказчик попросит срочно показывать ему все заказы, которые были сделаны в системе. Допустим, мы напряглись и впихнули посреди спринта задачу на отображение всех заказов для администратора. После этого заказчик просит выводить в отдельном окне список всех компаний, чьи заказы он видит. Сделали и это. Потом заказчик просит выводить дополнительно вообще все компании-партнеры. Окей… Через какое-то время мы встречаемся с заказчиком и видим, как он выгружает оба списка в эксель, ВПРит разницу и начинает обзванивать компании, у которых нет заказов, чтобы напомнить им, что нужно делать заказы через нашу систему.
Если бы мы с самого начала спросили у заказчика, какую цель он хочет достичь, просматривая все заказы — мы бы сэкономили кучу времени и сил, сразу сделав отчет с компаниями, которые не делали пока заказы.
Можно воспользоваться методом “Пяти почему” или любым другим. Но обычно люди не сопротивляются: если проявить интерес к их работе — разгадка становится доступной.
Определившись с целью необходимо четко ее обозначить и установить критерии, по которым вы сможете точно сказать, что цель достигнута.
Процесс заказа материалов считается автоматизированным, если >90% компаний-партнеров делают заказы через систему.
Это облегчает понимание задач и в то же время развязывает руки в выборе средств достижения цели.
И да, не забывайте согласовывать эту красоту с заказчиками. Вообще не забывайте согласовывать требования со всеми заинтересованными сторонами.
2. Что?
Цель достигается разными путями. И второй важный шаг при разработке требований как раз про выбор пути — что конкретно мы будем делать, чтобы прийти к цели.
Чтобы сократить процесс согласования счетов, мы можем:
А. Перераспределить задачи между согласующими. В результате несколько человек могут быть исключены из процесса. Суммарное время процесса сократится за счет периодов передачи данных/ожидания/коммуникации при передаче.
Б. Перейти на электронный документооборот — достоверность счетов и данных в них будет подтверждена оператором ЭДО, подтверждение человеком не потребуется.
В. Автоматически распознавать сканы счетов и сравнивать данные с цифрами из системы закупок. Ручная проверка и согласование не потребуются.
Чтобы продумать все варианты, надо разобраться — а что же происходит сейчас? Как устроен процесс без вашей системы, как работают пользователи и заказчики? Даже если процесса еще нет, подробная информация про текущее состояние очень важна. Так мы поймем, какое решение устранит проблему, а не создаст еще одну.
У каждого варианта реализации свои плюсы и минусы, свои необходимые ресурсы и свой уровень результата. Смоделировав все опции, проработав или хотя бы просто проговорив с заинтересованными сторонами эту информацию — вы сможете сделать взвешенный и обоснованный выбор.
3. Как?
Итак, мы поняли нашу цель и что мы будем делать, чтобы ее достичь. Осталось разобраться с тем — как мы это реализуем: какие страницы будем показывать пользователям, в каком виде отобразим отчет для заказчика, как получим данные из другой системы, как будем хранить их у себя и так далее.
Этот этап — дело техники. И если вы успешно прошли предыдущие два — будет гораздо проще.
Хоть техника и зависит от контекста, полезно двигаться по “чек-листу” Вигерса и других умных людей. Если для вас какой-то тип требований сейчас не актуален — окей, не описываем. Но важно не забыть и проверять себя.
На каждое бизнес-требование, как правило, приходится несколько пользовательских. Пользовательское требование декомпозируется на какое-то число функциональных. К каждому функциональному требованию нужно продумать нефункциональные требования и ограничения.
Также нефункциональные требования и ограничения могут напрямую вытекать как из пользовательских требований, так и из бизнес-требований и правил.
Таким образом получаются деревья из требований, в вершине каждого из которых — бизнес-требование.
4. Когда?
В “лесу” ваших требований скорее всего найдется сколько-нибудь взаимоисключающих и сколько-нибудь повторяющихся. Поэтому полезно всю эту красоту документировать и представлять в виде таблиц и диаграмм.
Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.
Если у вас получается объяснять всем, что и как вы хотите сделать с системой, при помощи салфетки и 3х пятен от кофе — значит вы Джон Уик от аналитики и это потрясающе.
Однако, как правило, «пятенный» уровень детализации не позволяет увидеть подводные камни и продумать все возможные сценарии. Ведь вроде и так все понятно, а нарисовал схемку — и вот тебе и бесконечный вызов, и забытая ветка процесса, и кратчайший путь к золоту.
Поэтому полезно знать, какие есть инструменты для обращения хаоса в порядок.
В схематическом и структурированном виде требования нужно приоритизировать — в зависимости от полезности (это вам скажет заказчик и пользователи) и трудоемкости (это вам скажет команда разработки).
А дальше можно уже раскидывать по спринтам/этапам разработки и внедрения. Ну и повторять эти упраженения в рамках каждой итерации. И будет вам счастье — никаких переделок, довольный заказчик, счастливая команда, работающий и приносящий пользу продукт, эльфы играют на арфе на фоне радуги.
Конечно, проблемы будут всегда. Будут переделки, сгоревшие дедлайны и баги. Не всегда будет возможность пройти все этапы и сделать нормальную аналитику, договориться или даже просто поговорить с заказчиком, задокументировать и протрассировать требования. Но в любой ситуации понимание “как должно быть” помогает сделать продукт лучше. Даже если в данный момент вы делаете “как получается” — вы осознаете, что упускаете, и знаете риски. А если вы знаете риски — значит вы можете ими управлять.
Подробнее про требования рекомендую почитать в книге Вигерса и Битти: “Разработка требований к программному обеспечению”. Хоть книга не всегда простая, но очень полезная. Большинство других материалов по теме — пересказ этих истин с той или иной степенью вольности.
Спасибо за внимание и удачного проектирования.
Антифрод. Функциональные и нефункциональные требования (часть 2)
В первой части эксперимента было описано, почему проблема мошеннических платежей (fraud) стоит остро перед всеми участниками рынка online-платежей, какие сложности на пути создания собственной системы мониторинга мошеннических платежей (antifraud-системы) предстоит преодолеть, и почему для большинства мерчантов такие системы – дорогое удовольствие, за которое они не всегда готовы платить.
Еще одно, усложняющее разработку подобных систем, обстоятельство — то, что antifraud-система является business-critical системой и ее простой будет вести либо к остановке бизнес-процесса (приема оплаты), либо при некорректной работе системы к увеличению рисков финансовых и репутационных потерь для компании (интернет-магазина, банка).
Поэтому практики и подходы, перечисленные в статье применимы не только на стороне мерчанта, но на стороне других участников интернет-эквайринга – агрегаторов, платежных систем, банков. Более того, перечисленные в статье подходы зачастую являются закрытыми от сообщества best practices в соответствующих организациях.
В этой части будут описаны требования к antifraud-системе, чье влияние на программную архитектуру является существенным.
Нефункциональные требования
Атрибуты качества
Не буду растягивать описание объяснением, почему я включил те иные атрибуты качества, так как такое объяснение носит очевидный характер, если принять во внимание тип проектируемой системы – business critical.
Кроме того, я намеренно не буду указывать конкретных цифр по времени доступности antifraud-системы и другим атрибутам качества, так как статья не ставит перед собой целью обсуждение отдельно взятой системы. Вместо этого описывается набор подходов и принципов, лежащих в основе подобных систем.
Законодательные ограничения
Законодательные ограничения, являются одним из важных факторов, определяющих программную архитектуру антифрод-системы.
Так, согласно требованиям стандарта PCI DSS, нельзя хранить полный номер карты (PAN)* или код безопасности (CVV). Разрешено хранить первые шесть и последние четыре цифры карты. Также ничто не запрещает генерировать внутренний уникальный идентификатор для карт клиентов. Имя держателя и срок экспирации карты разрешено передать только по защищенным каналам.
Кроме требования стандарта PCI DSS необходимо выполнять положения закона «О персональных данных» (152-ФЗ).
Обсуждение всего многообразия технико-бюрократических процедур (с вытекающими юридическими тонкостями), необходимых просто для хранения, обработки фамилии, имени клиента, скорее всего, займет 10 листов инструкций и 1,5 месяца работы на реализацию этих инструкций (шутка, но отчасти). Поэтому лучший способ не создавать себе лишней работы соблюдать положения 152-ФЗ – не попадать под его действие.
В проектируемой антифрод-системе все программные модули будут работать с деперсонифицированными данными.
Функциональные требования
Требование к API
Для начала рассмотрим требования к системе с точки зрения внешнего мира, т.е. программных клиентов (мерчантов). Программные клиенты взаимодействует с антифрод-системой в соответствии со следующими требованиями к API:
Бизнес-требования
С точки зрения внутренней логики антифрод-системы выделим всего одно существенное бизнес-требование: предсказать по данным о платеже будет ли транзакция успешной.
В процессе реализации этого требования попытаемся доказать, что платеж не пройдет. Рассмотрим основные причины отказа в проведении транзакции: платежные данные сформированы некорректно или транзакция является мошеннической. Ниже разберем методы проверки каждой из перечисленных причин.
Проверка корректности введения платежных данных
Не стоит надеяться, что мерчант надлежащим образом проверит платежные данные. Вне зависимости от того была ли это ошибка пользовательского ввода или злонамеренные действия, выявление ошибок в платежных реквизитах на ранних этапах поможет сэкономить как такты CPU, так и предотвратить зашумление обучаемой модели (о ней речь еще пойдет позже).
Необходимо проверить содержит ли имя держателя карты хотя бы 2 буквы (тире и цифры в имени приемлемы), является ли карта действующей (у карты есть срок действия), проходит ли номер карты проверку алгоритмом Луна.
Проверка является ли транзакция мошеннической
Для выявления признака, что платеж является мошенническим, существует большое количество эвристик. Некоторые компании могут похвастаться цифрой под 200 эвристик. Хотя у меня сразу возникают подозрения, что некоторые из этих эвристик либо ничем не подкреплены, либо являются следствием какой-то другой эвристики, либо это вовсе костыль, позволяющий лучше подгонять результат под обучающую выборку и не дающий никакого эффекта на реальных данных. Большое количество эвристик дает лишь: переобученную модель, неправильное распознавание является ли транзакция мошеннической и уменьшение производительности приложения.
Часто основным подходом является наивное присвоение фиксированного значения для какого-то из фильтров и последующая обработка этих условий в конструкциях типа (это псевдокод, а не 1С):
Даже не хочу начинать перечислять недостатки такого подхода и конечную стоимость такого кода, которая сложится из потерь от ложных срабатываний на отклонение «порядочных» платежей и пропуск фрода при небольшой смене стратегии мошенниками.
Поэтому единственно верным решением будет разработать систему, в которой эвристические фильтры способны к самообучению как на накопленной истории платежей, так и на новых платежах. Тут на наш выбор будет сразу несколько алгоритмов машинного обучения: логистическая регрессия, метод опорных векторов, нейронные сети.
Глобальные фильтры
Глобальными фильтрами я называю списки, при наличии плательщика в которых, проводить все остальные проверки – валидность платежных данных, проверка на фрод – бессмысленно. К таким спискам я отношу блэклисты банковских карт, IP, стран, мерчантов.
Глобальные фильтры могут быть как статическими, так и динамическими, могут быть связанны как с бизнес-правилами (мерчант не принимает платежи из Арктики), так и с детектированием аномальной активности (IP адрес).
Заключение 2-ой части
В первых двух частях мы рассмотрели основные аспекты преимущественно нетехнического характера, которые необходимо учесть при проектировании и разработке системы распознания мошеннических платежей.
Мы собираемся создать отказоустойчивый высокомасштабируемый надежный antifraud-сервис, который «снаружи» будет открыт для программных клиентов через REST API (https), а «внутри» – содержать логику, основанную на методах машинного обучения. Для придания еще большей интриги скажу, что сервис будет работать на одной из публичных облачных платформ.
В следующей части мы, наконец, займемся делом рассмотрим программную архитектуру antifraud-сервиса, его модульную структуру и ключевые детали реализации такого сервиса.