Автор: 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-летний опыт связан с крупными проектами трансформации бизнеса и совершенствованием процессов. Он накопил богатый передовой опыт в крупных проектах в области трансформации предприятий, интеграции, миграции и модернизации систем.

У него есть ряд академических достижений. Он имеет степень бакалавра по разработке программного обеспечения в Университете Квебека Монреаля (UQAM) и степень магистра по вычислительной технике в Технологическом университете Сиднея (UTS).

Электронная почта: adamalami2016@gmail.com

Опубликовано на ресурсе Modernanalyst.com

Комментарии (6)


  1. YourChief
    01.07.2018 09:01

    А почему перевод не отмечен как перевод?


    1. Hokum
      01.07.2018 10:20

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


      1. EdwardG Автор
        01.07.2018 21:57

        Да, я сразу хотел пометить статья как перевод. И в комментариях там писал модератору, если он не затерся. А можно ли прямо сейчас пометить как перевод?


        1. Hokum
          02.07.2018 10:52

          Я не знаю, я никогда не делал перевод.


  1. VolCh
    01.07.2018 11:34

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

    Вопрос ко всем: по чьей инициативе, по-вашему, должны выявляться такие противоречия на ранних этапах и должны ли? Ну и насколько правильно со стороны ИТ делать «маст хэв» вещи «инкапсулируя» их от бизнеса?


    1. EdwardG Автор
      01.07.2018 22:43

      Вопрос ко всем: по чьей инициативе, по-вашему, должны выявляться такие противоречия на ранних этапах и должны ли?

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

      Ну и насколько правильно со стороны ИТ делать «маст хэв» вещи «инкапсулируя» их от бизнеса?

      Как минимум, когда решение достаточно типовое, ну и не прибавляет стоимости и не будет увеличивать сроки поставки.