Классификация требований/Что представляет собой каждый вид требования.

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

Пользовательские требования

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

Вверх

Список требований

Бизнес правила

Факты:

Все продукты имеют уникальный идентификатор.
Каждый сотрудник относится к одному департаменту.
В компании 4 отдела: HR, IT, Sales, Finance.
Компания работает в 3 регионах: Америка, Европа, Азия.

Ограничения:

Зарплата не может быть ниже минимума по региону.
Максимальное количество часов работы в неделю - 40.
Все счета должны быть оплачены в течение 30 дней.
Количество отпускных дней в год не может превышать 30.

Выводы:

Если клиент совершил более 5 покупок, он получает статус VIP.
Сотрудник считается ветераном после 10 лет работы.
При заказе свыше 1000 единиц товара предоставляется скидка.
При опоздании оплаты более чем на 10 дней начисляются штрафы.

Вычисления:

Зарплата рассчитывается исходя из отработанных часов и ставки.
Бонусы сотрудников основаны на их производительности.
Налог на продукт рассчитывается как 18% от его стоимости.
Общая стоимость заказа включает стоимость товаров и доставки.

Активаторы операций:

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

Где фиксировать бизнес правила:

Атрибуты качества

Здесь чеклист для NFR: https://docs.google.com/document/d/1LNBTteuTfvSIBj9Fho4pJmVXZExUaCQfzYQTYm0ER0E/edit#heading=h.mxyeh5dgilte

Вверх

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

Часть первая. Обзор темы

Разрабатываете ли вы настольное приложение (desktop application), web-cайт или систему для автоматизации процессов предприятия, вы неизбежно сталкиваетесь с тем, что вы определяете нефункциональные требования. В этой статье я расскажу, какими они могут быть, и что нужно для того, чтобы определить их значения.

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

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

ограничения, которые, как правило, связаны с отдельными требованиями или их группами и оказывают существенное влияние на выбор решений, реализующих данные требования
бизнес-правила, которые учитывают действующие корпоративные стандарты, законодательные и нормативные акты и т.п.
внешние интерфейсы, которые используются для взаимодействия с другими системами или приложениями
системные требования, или набор характеристик, которым должна соответствовать среда, чтобы в ней могло быть развернуто и использоваться разрабатываемое программное обеспечение. Эти характеристики могут описывать требования как к аппаратному обеспечению (тип и частота процессора, объём оперативной памяти, объём жёсткого диска), так и к программному окружению (операционная система, наличие установленных системных компонентов и сервисов и т. п.).
предложения по реализации (например, использование готовых архитектурных решений, определенных платформ)
предложения по тестированию разрабатываемого ПО (дополнения к требованиям, указывающие, каким образом то или иное требование должно быть протестировано).

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

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

Чтобы составить полный перечень нефункциональных требований, можно открыть книгу Вигерса и ГОСТ 34; в большинстве случаев этого должно хватить.

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

Все атрибуты качества с точки зрения архитектуры системы делятся на две большие группы: первая группа (runtime) – это атрибуты, относящиеся ко времени работы приложения или системы; вторая группа (design time) определяет ключевые аспекты проектирования приложения или системы. Многие из этих атрибутов взаимозависимы.

Рассмотрим более подробно каждую из этих групп.

Группа runtime

Доступность – атрибут качества, определяющий время непрерывной работы приложения или системы. Чтобы определить этот параметр, обычно указывают максимально допустимое время простоя системы.
Надежность – требование, описывающее поведение приложения или системы в нештатных ситуациях (примеры: автоматический перезапуск, восстановление работы, сохранение данных, дублирование важных данных, резервирование логики)
Требования к времени хранения данных (например, использование БД в качестве постоянного хранилища данных, продолжительность хранения данных)
Масштабируемость – требования к горизонтальному и/или вертикальному масштабированию приложения или системы. Говоря о вертикальной масштабируемости, мы определяем требования к вертикальной архитектуре системы или приложения. К требованиям вертикальной масштабируемости могут относиться, например, возможность переноса приложений на более мощные SMP-системы, поддержка большого объема памяти и файлов. Говоря о горизонтальной масштабируемости, мы определяем требования к горизонтальной архитектуре системы или приложения. К требованиям горизонтальной масштабируемости могут относиться, например, возможность использования технологий кластеризации. Следует особо заметить, что вертикальное масштабирование обычно направлено на повышение производительности системы. Горизонтальное масштабирование, помимо производительности, позволяет повысить отказоустойчивость системы. Более подробно о вертикальном и горизонтальном масштабировании можно прочитать, например, здесь.
Требования к удобству использования системы/приложения (с точки зрения пользователя) и требования к удобству и простоте поддержки (Usability)
Требования к безопасности, как правило, включают в себя три большие категории: требования, связанные с разграничением доступа, требования, связанные с работой с приватными данным, и требования, направленные на снижение рисков от внешних атак
Требования к конфигурируемости приложения, взаимодействия и расположения компонентов можно условно разделить на четыре уровня: 1. конфигурируемость на основе предопределенного набора параметров (predefined configurability), когда необходимый уровень модификации достигается путем изменения значений параметров из предопределенного набора; 2. конфигурируемость на основе предопределенного набора базовых объектов (framework constrained configurability), когда необходимый уровень модификации достигается путем перекомпоновки предопределенного набора процессов, сущностей и служебных процедур; 3. конфигурируемость путем реализации новых базовых объектов (basis reimplementation), когда обеспечивается расширение набора процессов и сущностей; 4. конфигурируемость путем новой реализации системы (system reimplementation), когда система должна устанавливаться и настраиваться с нуля.
Требования к производительности решения, определяемые в терминах количества одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, а также скорости и пропускной способности каналов связи
Ограничения, накладываемые на объем доступной памяти, процессорного времени, дискового пространства, пропускную способность сети, при которых приложение должно эффективно выполнять возложенные на него задачи

Группа design time

Требования к повторному использованию реализации или компонентов приложения или системы (Reusability). О том, как это выражается в конкретной реализации, будет рассказываться далее. Пока ограничимся лишь тем, что чаще всего эти требования будут возникать там, где общие компоненты используются несколькими модулями разрабатываемой вами системы.
Требования к расширяемости (Extensibility) приложения или системы в связи с появлением новых функциональных требований, тесно связанное с таким архитектурным атрибутом качества, как переносимость кода. Как правило, на начальном этапе сбора требований можно ограничиться указанием тех функциональных областей, которые в дальнейшем должны удовлетворять требованию расширяемости.
Требования к переносимости (Portability) приложения или системы на другие платформы
Требования к взаимодействию между компонентами решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия (Interoperability). Например, к таким требованиям можно отнести возможность использования нескольких стандартных протоколов для обмена данными между одной из подсистем разрабатываемой системы и внешней системой-поставщиком данных (на примере ArcGIS)
Требования к поддержке системы или приложения (Supportability). Среди этих параметров могут быть названы такие как, напрмиер, дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе
Требования к модульности приложения или системы (Modularity). Обычно такие требования указывают, каким образом система должна быть разделена на модули, или перечисляют список обязательных модулей, которые должны входить в состав системы.
Требования к возможности тестирования (Testability) приложения или системы определяют объем требований к автоматическому и ручному тестированию, наличие необходимого инструментария
Требования к возможности и простоте локализации (Localizability) приложения или системы определяют возможности и специфические архитектурные требования, накладываемые процессом локализации. Эти требования содержат также перечень языков, на которые предполагается выполнять локализацию приложения или системы
Требования к совместимости между версиями приложений, между различными приложениями и внешними подсистемами (Compatibility) определяют предыдущие версии продукта или системы, а также список версий внешнего ПО, с которыми должны быть совместимы разрабатываемый продукт или система.

Источник

Вверх к оглавлению

Определение требования

Прежде чем погрузиться в теорию разработки требований к ПО, попробуйте, основываясь на своих знаниях и опыте, ответить на вопрос: как вы определяете термин «требование»?

Вопрос, что считать требованием к ПО, является сугубо дискуссионным. Но так или иначе нам с вами необходима отправная точка для изучения темы, поэтому обратимся к уже устоявшимся определениям:

Требования к ПО — это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы (Ian Sommerville и Pete Sawyer, 1997).

Требования к ПО — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению (ПО), в результате анализа требований (Википедия).

Из определений можно выделить следующие пункты, которые относятся к требованиям:

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

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

Термин «требование» охватывает довольно широкую предметную область. Поэтому возникает вопрос типизации и классификации требований.

Уровни и типы требований

Требования к ПО состоят из трех уровней:

Бизнес-требования.
Пользовательские требования.
Функциональные требования.

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

Бизнес-требования BRQ

Бизнес-требование (business requirements) — высокоуровневая бизнес-цель организации или заказчиков системы.

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

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

Если кратко, документ содержит определение следующих понятий:

Бизнес-возможности, бизнес-проблемы — факты и события, формирующие бизнес-цели, то есть грубо — причины инициации проекта.
Бизнес-цели — цели, которые должны быть решены разработкой и вводом в эксплуатацию системы. Являются критериями успеха проекта.
Концепция продукта (Vision) — сжато описывает конечный продукт, который достигнет заданных бизнес-целей.
Границы проекта (scope) — показывают, на какую часть конечной концепции продукта будет направлен текущий проект или итерация.

Источники бизнес-требований (где искать?):

Внутренняя документация компании (положения, инструкции, приказы).
Документация по предметной области (профильные литература и статьи, исследования).
Нормативная документация (законы и иные правовые акты, государственные стандарты).
Продукты конкурентов.

Стейкхолдеры (у кого спрашивать?):

Инициатор проекта.
Руководитель проекта (менеджер проекта).
Руководитель структурного подразделения заказчика (коммерческий директор, директор по маркетингу).
Бизнес-аналитик.

Пользовательские требования URQ

Пользовательские требования (user requirements) описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта, который в свою очередь должен приносить пользу кому-то. Область пользовательских требований также включает описания атрибутов или характеристик продукта, которые важны для удовлетворения пользователе (Карл Вигерс, «Разработка требований к программному обеспечению»).

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

Источники пользовательских требований требований (где искать?):

Анализ и декомпозиция бизнес-требований.
Описание бизнес-процессов.
Артефакты бизнес-процессов:
документы входные/выходные,
стандарты,
регламенты,
обрабатываемые данные,
иная информация, используемая и/или производимая в бизнес-процессе.
Отраслевые стандарты.
Реализованные проекты, проекты конкурентов.

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

Функциональные требования (functional requirements) — описание требуемого поведения системы в определенных условиях.

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

Функциональные требования самые низкоуровневые.

Источники требований (где искать?):

- Анализ пользовательских требований.
- Таски.
- Прототипы интерфейса (мокапы).
- Отраслевые стандарты.
- Внешние системы и документация к ним (интеграции).

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

Нефункциональное требование (non-functional requirements) — описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система.

https://dzen.ru/a/Ys_erPQlgUMeaHvt

Оглавление

Примеры требований

Business requirement: Implement an advanced ticketing system and knowledge base within 6 months to reduce support ticket resolution time by 25% and increase first contact resolution by 15%, enhancing customer service efficiency and satisfaction.

User requirements:

Оглавление