Раннее уже разбирались в том, зачем классифицировать требования.
Теперь пришла очередь поговорить о способах классификации требований и начнем с того, что вспомним само понятие классификации требований:
Классификация - это разделение объёма классифицируемого понятия по определённому основанию (признаку, критерию).
Другими словами, классификация это не что иное, как разделение того, что нужно классифицировать, на отдельные группы по определенному признаку.
Основания для классификации ПО
Основные из них:
- по уровням
- по характеру
Еще встречаются упоминания оснований в виде "источника", "качества" и другие, но это не самые распространенные, так как 1-ый говорит об источнике требования и не всегда важен с точки зрения процесса анализа требований, 2-ой - критерий с изменяемым в процессе проработки значением + достаточно сложно обеспечить выполнение правила классификации под названием "Взаимное исключение групп".
Вообще классифицировать требования как и все на свете, можно самым разным способом, главное чтобы от этой классификации была практическая польза.
Больше другой полезной информации в ТГ канале: https://t.me/all_for_analyse
Классификация по уровням
"Уровень" - степень детализации и абстракции требований к программному обеспечению
Различают следующие уровни:
- бизнес уровень
- пользовательский уровень
- системный уровень
1. Бизнес уровень - высокоуровневые требования, которые определяют цели и задачи бизнеса. Описывают причины запуска проекта и какие бизнес-выгоды ожидаются от его реализации.
Отвечают на вопросы:
- Какие бизнес-проблемы решает система?
- Какие возможности предоставляет?
- Какую ценность создает для организации?
2. Пользовательский уровень - требования описывают, что пользователи ожидают от системы, фокусируются на потребностях конечных пользователей и том, как система должна помочь им в решении их задач.
Отвечают на вопросы:
- Какие задачи пользователь сможет решать?
- Какие операции будет выполнять?
- Какие функции будут доступны?
- Какие процессы автоматизируются?
3. Системный уровень - требования отвечают за техническую реализацию программного продукта и определяют, как именно система будет работать на техническом уровне. Включают функциональные и нефункциональные требования.
Отвечают на вопросы:
- какие функции должна система предоставлять пользователю?
- как система должна работать?
- какие ограничение на работу системы накладываются?
В свою очередь делятся на:
- Функциональные требования - определяют, ЧТО система должна уметь делать с точки зрения функциональности.
- Нефункциональные требования - описывают, КАК система должна работать, включая в себя производительность, безопасность, масштабируемость и другие аспекты, которые не связаны напрямую с функциональностью.
Примеры нефункциональных требований, разделенные по категориям:
- Требования к производительности
- Требования к удобству использования
- Требования к надежности
- Требования безопасности
- Требования к ремонтопригодности
- Требования к масштабируемости
- Требования к переносимости
и тд., думаю понятно, что данный список может быть достаточно длинным.
Классификация по характеру
"Характер" - направленность требований к программному обеспечению. Он показывает, на что именно направлены требования: на поведение системы или на характеристики её работы.
Различают следующие уровни:
- функциональные требования
- нефункциональные требования
- Функциональные требования - определяют, ЧТО система должна уметь делать с точки зрения функциональности.
- Нефункциональные требования - описывают, КАК система должна работать, включая в себя производительность, безопасность, масштабируемость и другие аспекты, которые не связаны напрямую с функциональностью.
Классификация требований в различных источниках
Наибольшее распространение "в жизни" получили классификации требований ПО, описанные в следующих источниках:
- Карл Вигерс «Разработка требований к программному обеспечению»
- BABOK (Business Analysis Body of Knowledge) - свод знаний по бизнес-анализу, разработанный Международным институтом бизнес-анализа (IIBA)
- ISO/IEC/IEEE 29148 "Systems and software engineering - Life cycle processes - Requirements engineering" (системная и программная инженерия - процессы жизненного цикла - разработка требований)
- ГОСТ 34.602- 2020 "КОМПЛЕКС СТАНДАРТОВ НА АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ Техническое задание на создание автоматизированной системы"
- RUP (Rational Unified Process) - методология разработки ПО
Больше другой полезной информации в ТГ канале: https://t.me/all_for_analyse
Классификация по Вигерсу
Классификацию по Вигерсу, описанная в книге "Разработка требований к программному обеспечению" можно отнести к самой классической классификации, в которой все требования разделены на следующие группы:
Согласно ей, требования бывают следующих видов:
- Бизнес-требование - высокоуровневая бизнес-цель организации или заказчиков системы
- Бизнес-правило - политика, предписание, стандарт или правило, определяющее или ограничивающее некоторые стороны бизнес-процессов. По своей сути это не требование к ПО, но оно служит источником нескольких типов требований к ПО
- Ограничение - ограничение на выбор вариантов, доступных разработчику при проектировании и разработке продукта
- Внешнее требование к интерфейсу - описание взаимодействия между ПО и пользователем, другой программной системой или устройством
- Характеристика - одна или несколько логически связанных возможностей системы, которые представляют ценность для пользователя и описаны рядом функциональных требований
- Функциональное требование - описание требуемого поведения системы в определенных условиях
- Нефункциональное требование - Описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система
- Атрибут качества - вид нефункционального требования, описывающего характеристику сервиса или производительности продукта
- Системное требование - требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой
ПО или совокупность ПО и оборудования - Пользовательское требование - задача, которую определенные классы пользователей должны иметь возможность выполнять в системе, или требуемый атрибут продукта
Классификация по BABOK
BABOK различает следующие виды требований:
- Бизнес-требования: формулировка целей, задач и результатов, которые описывают, почему изменение было инициировано. Они могут относиться к предприятию в целом, области бизнеса или
конкретной инициативе. - Требования заинтересованной стороны: описывают потребности заинтересованных сторон, которые необходимо удовлетворить, чтобы выполнить бизнес-требования. Они могут служить мостом между бизнес-требованиями и требованиями к решению.
- Требования к решению: описывают возможности и качества решения, отвечающего требованиям заинтересованных сторон. Они обеспечивают необходимый уровень детализации, позволяющий разработать и внедрить решение. Требования к решению можно разделить на две категории:
a) Функциональные требования: описывают возможность, которой должно обладать решение с точки зрения поведения и информации, с которой решение будет работать,
b) Нефункциональные требования или требования к качеству сервиса: не относятся напрямую к поведению функциональности решения, а скорее описывают условия, при которых решение должно оставаться действенным, либо качества, которыми оно должно обладать. - Переходные требования (требования переходного периода): описывают возможности, которыми должно обладать решение, или условия, которым оно должно соответствовать, чтобы обеспечить переход из текущего состояния в будущее. Необходимость в таких требованиях отпадает после завершения изменения. Они отличаются от других видов требований тем, что имеют временный характер. Переходные требования решают такие вопросы, как конвертация данных, обучение, обеспечение непрерывности бизнеса.
Классификация по ISO/IEC/IEEE 29148
Согласно документу требования бывают следующих видов:
1. Функциональные требования - определяют, что система должна делать, включая реакции на входные данные, поведение в конкретных условиях и взаимодействие с другими системами
2. Нефункциональные требования - ограничения и атрибуты, не связанные с функциональностью.
Подкатегории:
- Производительность - требования к времени отклика, пропускной способности и использованию ресурсов.
- Надежность - способность системы выполнять функции в заданных условиях в течение определенного времени.
- Безопасность - защита информации от несанкционированного доступа, модификации или уничтожения.
- Сопровождаемость - возможность модификации системы без нарушения её работоспособности.
3. Требования к внешним интерфейсам - взаимодействие с пользователями, аппаратурой и другими системами, включают форматы данных, протоколы связи, аппаратные интерфейсы и элементы пользовательского интерфейса
4. Проектные ограничения определяют технологии, стандарты, языки программирования и архитектурные решения, которые должны быть соблюдены.
5. Требования к документации - документация должна включать руководство пользователя, описание API и инструкции по развертыванию.
6. Требования к приемке определяют тесты, метрики и сценарии, подтверждающие выполнение всех заявленных функций и характеристик.
Больше другой полезной информации в ТГ канале: https://t.me/all_for_analyse
Классификация по RUP
В RUP для классификации требований используется модель FURPS+ , состоящая из следующих категорий:
1. Функциональные требования - определяют, что система должна делать.
2. Нефункциональные требования - определяют, как система должна выполнять функции.
Категории:
- Производительность - определяет скорость, время отклика и пропускную способность системы.
- Безопасность - защита данных, аутентификация, шифрование и контроль доступа.
- Надежность - отвечает за стабильность работы, восстановление после сбоев и доступность.
- Удобство использования - простота интерфейса, доступность для пользователей с ограничениями.
- Масштабируемость - возможность расширения функционала или увеличения нагрузки.
- Совместимость - работа с различными ОС, браузерами, устройствами.
- Поддерживаемость - удобство внесения изменений, обновлений и исправления ошибок.
- Эффективность - оптимизация использования ресурсов.
- Физические ограничения - требования к оборудованию, сети, инфраструктуре.
3. Ограничения - внешние условия, влияющие на дизайн и реализацию.
4. Бизнес-требования - определяют высокоуровневые цели проекта, целевую аудиторию и ключевые преимущества системы»
5. Требования к интерфейсам - описывают взаимодействие с пользователями, системами и аппаратурой. Типы:
- Пользовательские интерфейсы
- Внешние API
6. Требования к документации - требования к составу руководства для пользователей и разработчиков.
Классификация по ГОСТ 34.602- 2020
Согласно ГОСТ (34.602, 51904 и другим, связанным с ними) требования классифицируются следующим образом:
1. Функциональные требования:
- Требования к функциям и задачам системы
- Требования к обработке данных
- Требования к взаимодействию компонентов
- Требования к пользовательскому интерфейсу
2. Нефункциональные требования (включают подкатегории):
- Требования к производительности: время отклика системы, пропускная способность, нагрузка на систему
- Требования к надежности: вероятность безотказной работы, время восстановления, отказоустойчивость
- Требования к безопасности: защита данных, управление доступом, шифрование информации
4. Требования к документации: состав документации, форматы представления, стандарты оформления
5. Требования к качеству: надёжность, удобство использования, масштабируемость, переносимость, эффективность
6. Требования к интерфейсам: взаимодействие с пользователями, взаимодействие с другими системами, взаимодействие с аппаратным обеспечением
6. Требования к сопровождению: возможность модификации, документирование изменений, поддержка версий
7. Специфические требования: временные требования, требования к ресурсам, требования к взаимодействию, требования к обработке ошибок
Вывод: не бывает "неправильной" классификации, бывает отсутствие согласованных договоренностей по признакам классификации. Важно соблюдать правила классификации и следовать договоренностям на всем протяжении проекта, а также помнить - классификация делается не ради классификации, а ради достижения практических целей.
Подробнее про преимущества классификации можно почитать здесь.
Больше другой полезной информации в ТГ канале: https://t.me/all_for_analyse
Дополнительные материалы по теме статьи: