что такое нефункциональные требования к системе
Нефункциональные требования: Масштабируемость
Автор: Adam Alami, PhD Fellow, IT University of Copenhagen (перевод с англ.)
ВВЕДЕНИЕ
Нефункциональные требования широко представлены в литературе. Нет недостатка в определениях и примерах нефункциональных требований. Международный институт бизнес-анализа (IIBA) определяет нефункциональные требования следующим образом:
Нефункциональные требования фиксируют условия, которые непосредственно не связаны с поведением или функциональностью решения, а скорее описывают условия окружающей среды, при которых решение должно оставаться эффективным, или качества, которыми система должны обладать. Они также известны как атрибуты (показатели) качества или дополнительные требования. Они могут включать требования, связанные с пропускной способностью, скоростью, безопасностью, доступностью, информационной архитектурой и представлением пользовательского интерфейса.
Ключевыми словами в этом определении являются «не имеют прямого отношения к поведению или функциональности решения». Это либо «условия», либо «качества».
Условия: они являются внешними или внутренними ограничениями. Внутренние ограничения — это политика и саморегулирование организации, в то время как внешние ограничения — это государственные правила, отраслевые стандараты и другие параметры, определяющие бизнес-среду.
Качества: это бизнес-требования, которые определяют не системное поведение и не связаны с процессом, а являются требованиями к качеству решения.
Примеры:
i) Условия
а. Брендинг,
б. Конфиденциальность данных,
с. Совместимость с PCI;
ii) Качества
а. Доступность,
б. Производительность.
Даже самый опытный бизнес-аналитик прикладывает немало усилий, чтобы выявить нефункциональные требования. Основная причина таких трудностей заключается в том, что нефункциональные требования являются не простыми для их выявления, и не существует заранее определенного процесса их идентификации. Чтобы определить эти требования, нужно быть творческим и думать широко, выходя за определенные рамки!
ЗАЧЕМ НУЖНЫ «НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ»
В соответствии со всеми типами требований, пропуск того или иного требования может потенциально поставить под угрозу целостность и полноту решения. Функциональные и нефункциональные требования тесно связанны между собой множественными взаимосвязями.
Обычно основное внимание уделяется функциональному аспекту требований, а значение нефункциональных требований часто недооценивается.
Почему же нефункциональные требования недооцениваются?
1. Основное внимание уделяется функциональным требованиям, поскольку они дают ощутимую отдачу. Нефункциональные требования же вносят вклад в инфраструктуру, а не в поведение системы. Инфраструктура бизнеса, являющаяся неосязаемой, представляется незначительной.
2. Команда доставки решения вознаграждается и измеряется с точки зрения системных функций, процессов и поведения. Бизнес-пользователи рассматривают нефункциональные требования как «ИТ-требования», а ИТ рассматривает любые «потребности» как бизнес-потребности, а не технологии. Технология обеспечивает обслуживание, а бизнес управляет потребностями. В ходе этого процессе ИТ иногда забывает, что у них только «консультативная» роль.
Каждое решение достигает эффективности из исчерпывающего списка требований, собранных как в начале, так и во время процесса внедрения. Требования могут быть разделены на две широкие категории: существенные и фундаментальные. Существенные требования вытекают из их аналогии с «функциональными требованиями» и, как представляется, имеют непосредственное отношение к решению. Однако так называемые фундаментальные требования могут не иметь прямой связи с решением, но они имеют основополагающее значение для создания устойчивой среды, в которой сохраняются существенные функциональные требования. Поэтому эти «нефункциональные требования» составляют структуру и инфраструктуру, которые поддерживают системные решения.
ЧТО ТАКОЕ МАСШТАБИРУЕМОСТЬ?
Масштабируемость — это способность системы или процесса обрабатывать увеличенный объем операций без ограничений или структурных узких мест. Каждая бизнес-модель имеет первостепенное значение для генерации бизнеса, что приводит к увеличению объема транзакций и последующему увеличению операционной деятельности. Масштабирование операций для обработки расширяющейся деловой активности присуще и встроено в дизайн системы. Масштабируемость можно разделить на две категории: физическую и нематериальную.
1. Физическая масштабируемость
Она относится к тем параметрам, которые имеют решающее значение для обеспечения того, чтобы организация была оснащена средствами (возможно, дополнительными) для обработки увеличивающегося числа операций. Это подразумевает физическую устойчивость. Это указывает на наличие факторов, необходимых с точки зрения физических компонентов процесса для обеспечения устойчивости (т.е. хранения данных, пропускной способности сети, аппаратного обеспечения и т.д.).
Что значит быть устойчивым? Это отвечает текущим требованиям, не ставя под угрозу способность поддерживать будущие потребности. Например, если характеристики сетевого решения поддерживают текущие потребности, то они также должны быть способны поддерживать будущие потребности в течение ближайших трех-пяти лет. В целом, устойчивость определяется и оценивается с помощью прогнозов на три-пять лет.
Почему нужно определять потребность в устойчивости при разработке бизнес-модели / решения? Устойчивая бизнес-модель основывается на своем дизайне и структуре, которые лучше всего подходят для достижения решения посредством стабильных и надежных систем, процессов и инфраструктуры. Физическая устойчивость направлена на достижение двух основных характеристик: стабильности и надежности бизнес- и технологических решений.
Стабильность: то, что позволяет бизнесу оставаться стабильным, устойчивым к внешним воздействиям. ИТ-инфраструктура устойчива и гарантирует поддержку бизнес-операций в течение предполагаемого периода в будущем.
Надежность: если бизнес постоянно растет в течение пяти лет, а инфраструктура при этом остается устойчивой. Надежность позволяет бизнесу сосредоточиться на своих основных компетенциях в устойчивой инфраструктуре.
2. Нематериальная масштабируемость
Это относится к присущей способности поддерживать нефизический рост. Рост бизнеса имеет решающее значение для поддержания рыночной доли и конкурентоспособности. Рост может быть как внутренним, так и внешним, основанным на принятых драйверах и стратегиях. Ниже приведены несколько примеров:
* Новые продукты, которые будут размещаться на одной платформе / решении
* Дополнительные бренды (для мультибрендовых организаций)
* Дополнительные бизнес-процессы
В чем разница между физическим и нематериальным? Хотя оба они могут казаться похожими, они не идентичны. Решение может быть устойчивым физически, но может не поддерживать неосязаемый рост. Например, если объем операций увеличивается, то решение должно быть устойчивым физически. Если бизнес вводит новые продукты, то это классифицируется как неосязаемый рост, и решение должно иметь масштабируемые функции и процессы (не физические) для поддержки этого роста.
Зачем нам нужно определять требования к нематериальной масштабируемости? Необходимость определения требований к нематериальной масштабируемости становится необходимой, поскольку она является предпосылкой, которая поддерживает рост. Требования к масштабируемости, по сути, являются отражением стремления организации к росту и необходимостью решения для поддержки роста с минимальными изменениями и нарушением повседневной деятельности.
КАК ОПРЕДЕЛЯТЬ ТРЕБОВАНИЯ К МАСШТАБИРУЕМОСТИ?
Нет простого объяснения или простой методологии для определения требований к масштабируемости. Крайне субъективно и относительно сложно определить условия и особенности, необходимые для принятия устойчивого решения. Это одна из причин, почему это называется «анализом». Ниже приведен подход, который всегда работал для автора. Однако это не подходит для всех подобных ситуаций.
1. Определите физические компоненты решения, которые необходимо масштабировать.
2. Определите функции, которые могут сделать определенный компонент масштабируемым.
3. Определите параметры для измерения функций.
4. Определите значения каждого параметра, определенного выше. Это нефункциональные требования (определение параметра).
Ответы на эти вопросы нужно формулировать с точки зрения бизнеса, а не с точки зрения ИТ.
Ситуация: ваша организация является финансовым учреждением, которое выпускает кредитные карты клиентам. Она прикладывает усилия для преобразования своих технологий и систем.
Какие вопросы следует задать, чтобы начать анализ идентификации физической масштабируемости? В целях упрощения мы сузим сферу действия. Ниже приведены некоторые примеры:
1. Каков текущий объем клиентов, транзакций, счетов и т.д.?
2. Какие объемы ожидаются от работы систем в первый день?
3. Каков ежегодный рост объема (клиентов, транзакций и т.д.), ожидаемый в ближайшие три-пять лет?
Вопрос 1 следует задать для определения текущего состояния.
Вопрос 2 определяет непосредственное требование с первого дня жизни (эксплуатации).
Вопрос 3 является вкладом в определение требования масштабируемости решения. Например, если организация прогнозирует рост новых клиентов на 10% в год и ежегодный рост числа транзакций на 15%, то требования к масштабируемости могут быть следующими:
1. Решение должно поддерживать ежегодный рост на 10% новых клиентов.
2. Решение должно поддерживать ежегодный рост на 15% от предыдущего количества транзакций.
Однако, в этом примере, я бы предложил дополнительно определить ожидания того, что требование предполагает «поддержку» (т.е. технология не требует каких-либо изменений для обработки роста)?
Это рост бизнеса, а не развитие технологий, инфраструктуры или логистики. Это будет варьироваться от одного бизнеса к другому и зависит от специфики предметной области. Поэтому знание бизнеса и промышленности, разработанное с помощью экспертного исследования, является ключом к определению параметров масштабируемости на уровне детализации. Тем не менее, бизнес-стратегия высокого уровня формулируется на основе детализации из определения видения организации.
Ситуация: ваша организация является финансовым учреждением, которое выпускает кредитные карты своим клиентам. Она прикладывает усилия для преобразования своих технологий и систем.
Какие вопросы следует задать, чтобы начать анализ идентификации нематериальной масштабируемости? В целях упрощения мы сузим сферу действия. Ниже приведены некоторые примеры:
1. Планирует ли организация выпускать новые продукты (например, мобильные платежи, продукты, подобные Apple Pay или Bitcoin)?
2. Есть ли какие-либо будущие приобретения или слияния с аналогичными предприятиями?
3. Какова стратегия организации (т.е. новые каналы сбыта, выход на новые рынки и т.д.)?
Эти вопросы помогают определить нематериальный рост. Например, если организация планирует запустить новый бренд продуктов для кредитных карт, тогда требования к масштабируемости будут следующими:
1. Решение должно быть в состоянии разместить два разных бренда: Brand A и Brand B.
2. Оба бренда должны иметь возможность использовать одни и те же системы и процессы.
Эти требования достаточно высокоуровневы и приведены только в качестве примера. В реальном сценарии они должны быть изучены более подробно.
Нет простого метода определения нефункциональных требований. Относительно сложно определить условия и функции, необходимые для создания масштабируемого решения.
__________________________________________________________
Автор: Адам Алами, доктор философии, ИТ-университет Копенгагена
Адам Алами — кандидат наук в ИТ-университете Копенгагена. Адам обладает богатым опытом в области информационных технологий. Он начал свою карьеру в качестве разработчика программного обеспечения, затем перешел в бизнес-анализ и управление проектами. Его 20-летний опыт связан с крупными проектами трансформации бизнеса и совершенствованием процессов. Он накопил богатый передовой опыт в крупных проектах в области трансформации предприятий, интеграции, миграции и модернизации систем.
У него есть ряд академических достижений. Он имеет степень бакалавра по разработке программного обеспечения в Университете Квебека Монреаля (UQÀM) и степень магистра по вычислительной технике в Технологическом университете Сиднея (UTS).
Антифрод. Функциональные и нефункциональные требования (часть 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-сервиса, его модульную структуру и ключевые детали реализации такого сервиса.
Требования к ПО на пальцах
Пост про основы разработки требований — без сложных схем, терминов и таблиц, зато с гифками.
Если коротко, то основные этапы разработки требований — это:
Если после выполнения просьбы получилось что-то не то — это либо накосячил исполнитель,
либо вы некорректно поставили задачу.
Как известно, неверная задача может обойтись довольно дорого. Например, если полгода команда из 5 программистов разрабатывала систему, которая никому не была нужна.
В наш беспокойный век Agile разработкой требований часто пренебрегают. Но гибкие методологии не всегда спасают от больших потерь. Поэтому, даже если у вас нет аналитика на проекте, даже если вы вообще не IT — не забывайте про здравый смысл и берите из лучших практик то, что нужно в данный момент.
Так что же такое требования и почему важно уметь их разрабатывать?
Итак, обратимся к истокам:
То есть о требованиях можно говорить, как о будущих свойствах. Как о том, каким будет продукт, удовлетворяющий целям разработки.
С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.
1. Зачем?
Как бы “ASAP. ” не требовалось что-то сделать — важно найти время и силы выяснить, зачем же это нужно.
Потому что часто, после выяснения цели, меняется или вовсе устраняется задача.
Заказчик попросит срочно показывать ему все заказы, которые были сделаны в системе. Допустим, мы напряглись и впихнули посреди спринта задачу на отображение всех заказов для администратора. После этого заказчик просит выводить в отдельном окне список всех компаний, чьи заказы он видит. Сделали и это. Потом заказчик просит выводить дополнительно вообще все компании-партнеры. Окей… Через какое-то время мы встречаемся с заказчиком и видим, как он выгружает оба списка в эксель, ВПРит разницу и начинает обзванивать компании, у которых нет заказов, чтобы напомнить им, что нужно делать заказы через нашу систему.
Если бы мы с самого начала спросили у заказчика, какую цель он хочет достичь, просматривая все заказы — мы бы сэкономили кучу времени и сил, сразу сделав отчет с компаниями, которые не делали пока заказы.
Можно воспользоваться методом “Пяти почему” или любым другим. Но обычно люди не сопротивляются: если проявить интерес к их работе — разгадка становится доступной.
Определившись с целью необходимо четко ее обозначить и установить критерии, по которым вы сможете точно сказать, что цель достигнута.
Процесс заказа материалов считается автоматизированным, если >90% компаний-партнеров делают заказы через систему.
Это облегчает понимание задач и в то же время развязывает руки в выборе средств достижения цели.
И да, не забывайте согласовывать эту красоту с заказчиками. Вообще не забывайте согласовывать требования со всеми заинтересованными сторонами.
2. Что?
Цель достигается разными путями. И второй важный шаг при разработке требований как раз про выбор пути — что конкретно мы будем делать, чтобы прийти к цели.
Чтобы сократить процесс согласования счетов, мы можем:
А. Перераспределить задачи между согласующими. В результате несколько человек могут быть исключены из процесса. Суммарное время процесса сократится за счет периодов передачи данных/ожидания/коммуникации при передаче.
Б. Перейти на электронный документооборот — достоверность счетов и данных в них будет подтверждена оператором ЭДО, подтверждение человеком не потребуется.
В. Автоматически распознавать сканы счетов и сравнивать данные с цифрами из системы закупок. Ручная проверка и согласование не потребуются.
Чтобы продумать все варианты, надо разобраться — а что же происходит сейчас? Как устроен процесс без вашей системы, как работают пользователи и заказчики? Даже если процесса еще нет, подробная информация про текущее состояние очень важна. Так мы поймем, какое решение устранит проблему, а не создаст еще одну.
У каждого варианта реализации свои плюсы и минусы, свои необходимые ресурсы и свой уровень результата. Смоделировав все опции, проработав или хотя бы просто проговорив с заинтересованными сторонами эту информацию — вы сможете сделать взвешенный и обоснованный выбор.
3. Как?
Итак, мы поняли нашу цель и что мы будем делать, чтобы ее достичь. Осталось разобраться с тем — как мы это реализуем: какие страницы будем показывать пользователям, в каком виде отобразим отчет для заказчика, как получим данные из другой системы, как будем хранить их у себя и так далее.
Этот этап — дело техники. И если вы успешно прошли предыдущие два — будет гораздо проще.
Хоть техника и зависит от контекста, полезно двигаться по “чек-листу” Вигерса и других умных людей. Если для вас какой-то тип требований сейчас не актуален — окей, не описываем. Но важно не забыть и проверять себя.
На каждое бизнес-требование, как правило, приходится несколько пользовательских. Пользовательское требование декомпозируется на какое-то число функциональных. К каждому функциональному требованию нужно продумать нефункциональные требования и ограничения.
Также нефункциональные требования и ограничения могут напрямую вытекать как из пользовательских требований, так и из бизнес-требований и правил.
Таким образом получаются деревья из требований, в вершине каждого из которых — бизнес-требование.
4. Когда?
В “лесу” ваших требований скорее всего найдется сколько-нибудь взаимоисключающих и сколько-нибудь повторяющихся. Поэтому полезно всю эту красоту документировать и представлять в виде таблиц и диаграмм.
Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.
Если у вас получается объяснять всем, что и как вы хотите сделать с системой, при помощи салфетки и 3х пятен от кофе — значит вы Джон Уик от аналитики и это потрясающе.
Однако, как правило, «пятенный» уровень детализации не позволяет увидеть подводные камни и продумать все возможные сценарии. Ведь вроде и так все понятно, а нарисовал схемку — и вот тебе и бесконечный вызов, и забытая ветка процесса, и кратчайший путь к золоту.
Поэтому полезно знать, какие есть инструменты для обращения хаоса в порядок.
В схематическом и структурированном виде требования нужно приоритизировать — в зависимости от полезности (это вам скажет заказчик и пользователи) и трудоемкости (это вам скажет команда разработки).
А дальше можно уже раскидывать по спринтам/этапам разработки и внедрения. Ну и повторять эти упраженения в рамках каждой итерации. И будет вам счастье — никаких переделок, довольный заказчик, счастливая команда, работающий и приносящий пользу продукт, эльфы играют на арфе на фоне радуги.
Конечно, проблемы будут всегда. Будут переделки, сгоревшие дедлайны и баги. Не всегда будет возможность пройти все этапы и сделать нормальную аналитику, договориться или даже просто поговорить с заказчиком, задокументировать и протрассировать требования. Но в любой ситуации понимание “как должно быть” помогает сделать продукт лучше. Даже если в данный момент вы делаете “как получается” — вы осознаете, что упускаете, и знаете риски. А если вы знаете риски — значит вы можете ими управлять.
Подробнее про требования рекомендую почитать в книге Вигерса и Битти: “Разработка требований к программному обеспечению”. Хоть книга не всегда простая, но очень полезная. Большинство других материалов по теме — пересказ этих истин с той или иной степенью вольности.
Спасибо за внимание и удачного проектирования.