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

Главные идеи#

Модель Вигерса в общих чертах#

В модели Карла Вигерса бизнес-правила влияют на бизнес-требования (их фиксируют в документе концепции и границ), из бизнес-требований вытекают пользовательские требования, а из них — функциональные требования. Параллельно идут атрибуты качества, требования к внешним интерфейсам и ограничения. Функциональные и нефункциональные требования сходятся в спецификации требований к ПО (SRS). Руководство BABOK® делит требования иначе (бизнес-требования, требования заинтересованных сторон, требования к решению, переходные требования), но две схемы достаточно хорошо соотносятся друг с другом. Уровни подробно разобраны на странице Уровни и типы требований.

Четыре практические категории нефункциональных требований#

Автор скетчноута «Requirements» Г. Косцевич ставит модель Вигерса рядом со схемой BABOK и группирует нефункциональные требования (non-functional requirements, NFR) в четыре корзины. Используйте их как подсказки при выявлении:

Семь характеристик отдельного требования#

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

• Полнота — требование содержит всю информацию, нужную для реализации. Известные пробелы явно помечайте как TBD (подлежит определению).
• Корректность — требование точно описывает нужную возможность и не противоречит родительскому требованию. Оценивают это представители пользователей, а не аналитик.
• Осуществимость — требование можно реализовать в известных технических, бюджетных и временных рамках. Оценивают это разработчики.
• Необходимость — требование прослеживается до источника, обладающего полномочиями, и до бизнес-цели. Вы можете ответить на вопрос «зачем это здесь?».
• Приоритизированность — у требования есть приоритет реализации.
• Однозначность — все читатели понимают требование одинаково. Авторы описывают два вида неоднозначности: автор сам видит больше одного прочтения или, что опаснее, каждый читатель видит своё прочтение, которое кажется ему очевидным.
• Проверяемость — тестировщик может составить тест, который покажет, что требование выполнено. Без этого вопрос «готово ли?» становится делом мнения.

Четыре характеристики набора требований#

• Полнота — ничего не упущено. Абсолютная полнота на практике недостижима, а любая спецификация с TBD формально неполна.
• Согласованность — нет конфликтов с требованиями того же или более высокого уровня. Записывайте автора каждого требования, чтобы при конфликте знать, к кому обратиться.
• Модифицируемость — у каждого требования уникальный ID, и оно записано один раз. Текст, продублированный в нескольких местах, рано или поздно разойдётся.
• Трассируемость — каждое требование можно связать назад с его источником и вперёд с дизайном, кодом и тестами. Записывать каждую связь не обязательно, но формат должен это позволять: короткие формулировки с уникальными номерами, а не длинные повествовательные абзацы.

Другие версии списка#

В скетчноуте «Requirements» дан более короткий список из шести характеристик: ясность, полнота, применимость, приоритизированность, реализуемость (подтверждают разработчики) и тестируемость (подтверждают тестировщики); проверяют их с помощью взаимных проверок (peer review) и сквозных просмотров (walkthrough). Курс лекций Маглинца, опирающийся на работы IEEE и Вигерса, перечисляет двенадцать свойств. Он добавляет числовую метрику для каждого нефункционального требования, упорядочивание и по важности, и по стабильности, разделение на необходимые и просто полезные требования, а также согласованность как между уровнями, так и внутри уровня. Маглинец использует и треугольник компромиссов «ресурсы — время — границы»: если меняется одна сторона, должны подстроиться и другие; это ещё одна причина формулировать каждое требование только один раз.

Откуда берутся требования#

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