В сегодняшней статье мы разберем, что такое классификация требований ПО и для чего их нужно классифицировать
Что такое классификация?
Классическое определение звучит следующим образом: "Классификация - это разделение объёма классифицируемого понятия по определённому основанию (признаку, критерию)."
Другими словами, классификация это не что иное, как разделение того, что нужно классифицировать, на отдельные группы по определенному признаку.
Пример: классификация по цвету, весу, первой букве в названии и другие варианты.
При проведении классификации необходимо соблюдать ряд правил:
- Единство основания классификации:
Классификация всегда должна выполнять по одному признаку, иначе произойдет эффект "пересечения" когда один и тот предмет окажется одновременно в разных группах.Пример: классификация требований на "функциональные", "приоритетные", "пользовательские" и "системные". В таком случае одно и тоже требование может оказаться сразу в двух группах или ни в одной.
- Соразмерность деления:
Это значит, что должны перечисляться все возможные значения признака для классификации, иначе часть классифицируемого не попадет ни в какую группу, так как нет подходящего значения признака.Пример: если хотим классифицировать требования ПО по признаку "приоритет" и указываем значения: "высокоприоритетные" и "низкоприоритетные." В таком случае теряются требования со средним приоритетом.
- Взаимное исключение групп:
Означает, что все значения признака, по которому классифицируем, должны исключать друг друга.Пример: классификация по типам "функциональные", "пользовательские", "бизнес", "нефункциональные" и "требования производительности". Здесь есть пересечение между "нефункциональные" и "требования производительности"
- Непрерывность деления:
Классификация должна быть последовательной и постепенной и идти от общего к частному без пропуска уровней и каждый следующий уровень должен быть логическим продолжением предыдущего.Пример: классификация по значениям "бизнес", "пользовательские", "системные", "нефункциональные". Здесь пропущен уровень разделения на "функциональные" и "нефункциональные"
Цель классификации требований
Классификация требований к ПО нужна для того, чтобы:
- упорядочивать требования, что упрощает процесс управления ими (сбор, анализ, верификация и документирование);
- упростить поиск и ознакомление с требованиями;
- выявлять закономерности между требованиями (трассировка требований);
- выявлять пробелы в требованиях;
Это помогает:
- Разделить требования на группы, которыми легче управлять и отслеживать на протяжении всего процесса разработки;
- Улучшить коммуникацию, так чёткая классификация упрощает доведение требований до заинтересованных сторон, разработчиков и других членов команды;
- Выявить потенциальные конфликты или пробелы на ранних этапах процесса разработки, что снижает риск ошибок, упущений или недопонимания;
- Установить прослеживаемость - классификация требований помогает продемонстрировать соответствие бизнес запросам, нормативным требованиям и стандартам качества (трассировка требований);
- Упростить процесс принятия решения;
Больше другой полезной информации в ТГ канале: https://t.me/all_for_analyse
Преимущества классификации требований
- Лучшая организация: классификация требований помогает разделить их на группы, которыми легче управлять, расставлять приоритеты и отслеживать их выполнение на протяжении всего процесса разработки;
- Упрощение документирования: структурированные требования проще документировать, обновлять, управлять историчностью изменений;
- Улучшение коммуникации: четкая классификация требований упрощает их передачу заинтересованным сторонам, разработчикам и другим членам команды. Это также гарантирует, что все будут одинаково понимать, что от них требуется;
- Повышение качества: за счет выявления потенциальных конфликтов или пробелов на ранних этапах разработки. Это снижает риск ошибок, упущенных требований, что позволяет создавать более качественный продукт;
- Улучшение наблюдаемости: классификация требований помогает обеспечить отслеживаемость, которая необходима для подтверждения соответствия бизнес запросам, нормативным требованиям и стандартам качества (трассировка требований);
- Снижение затрат на реализацию: за счет уменьшения числа переделок по причине выявленных на ранних этапах ошибок в требованиях;
Недостатки классификации требований
- Сложность реализации: классификация требований является ресурсоемкой задачей как с точки зрения затрачиваемого времени, так и необходимости работы с большим числом требований и выявлением критериев для классификации;
- Снижение гибкости: жёсткая структура классификации может препятствовать внедрению нестандартных подходов и решений, а также замедляет реагирование на возникающие изменения;
- Риск чрезмерного формализма: излишнее документирование в ущерб реальному процессу разработки ПО;
- Необходимость актуализации: требуется постоянное участие в поддержании классификации в актуальном состоянии;
Где рекомендуется применять классификацию
- Крупные проекты с множеством заинтересованных сторон: вообще в крупных проектах без определенной степени формализма нельзя обойтись
- Сложные системы с большим количеством функциональных возможностей: аналогично, где много функций и процесс распределен по времени, без классификации и некоторого формализма проект постепенно перейдет в стадию бардака;
- Проекты с высокими ставками, где ошибки могут привести к серьезным последствиям: классификация помогает контролировать и предотвращать возникновение ошибок, в том числе и на ранних стадиях;
- Долгосрочные проекты с планируемой эволюцией системы: ситуация аналогична "сложным системам";
Подведем итог: несмотря на существующие недостатки, классификация требований является важной задачей процесса разработки ПО, которая помогает избежать множества проблем и обеспечивает успешное завершение проекта. Главное - найти баланс между формализацией и гибкостью, учитывая специфику конкретного проекта и команды разработчиков.
Больше другой полезной информации в ТГ канале: https://t.me/all_for_analyse
Дополнительные материалы по теме статьи: