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

Антифрод. Функциональные и нефункциональные требования (часть 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-сервиса, его модульную структуру и ключевые детали реализации такого сервиса.

Источник

В чем разница между функциональными и нефункциональными требованиями? [закрытый]

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

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

6 ответов

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

пример функциональное требование будет:

, связанные с нефункциональные требования для системы может быть:

функциональное требование описание поведения системы как это относится к функциональности системы. Нефункциональное требование разрабатывает характеристику производительности из система.

обычно нефункциональные требования попадают в такие области, как:

более полный список доступен на Запись Википедии для нефункциональных требований.

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

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

нефункциональное приобретение не является прямым требованием системы, а связано с удобством использования (в некотором роде ), например, для банковское приложение основным нефункциональным требованием будет доступность приложение должно быть доступно 24/7 без простоя, если это возможно.

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

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

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

функциональные требования-это то, что система должен был выполнить. Может быть!—5—>

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

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

LBushkin уже объяснили больше о Нефункциональные требования. Я добавлю еще.

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

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

выражено ли требование в виде функционального или нефункционального требования, может зависеть:

Ex. Система может потребоваться, чтобы представить пользователю с отображением номера записи в базе данных. Это функциональное требование. Насколько актуально [обновление] это число должно быть, является нефункциональным требованием. Если число должно быть обновлено в режиме реального времени, системные архитекторы должны убедиться, что система способна обновлять [отображаемое] количество записей в течение приемлемо короткого интервала изменения количества записей.

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

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

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

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

ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ действия, которые должна выполнять система

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

Источник

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

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

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

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

Другими словами, функциональное требование — это то, ЧТО приложение должно или не должно делать после ввода некоторых данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Давайте посмотрим, что включает в себя каждый тип требований.

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

Нефункциональные требования подпадают под различные категории, в том числе:

Примеры и передовой опыт

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

Истории пользователей

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

Как (пользователь) я хочу (цель), чтобы (причина).

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

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

Сценарии использования

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

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

Действия для этих ролей могут выглядеть следующим образом:

Документ со спецификацией требований к программному обеспечению

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

Основные разделы, которые обычно включаются в документ SRS:

Создание SRS, пользовательских примеров и пользовательских историй имеет важное значение для эффективной разработки приложений.

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

Заключение

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

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

Источник

Нефункциональные требования: Масштабируемость

Автор: 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).

Источник