В этом посте мы рассмотрим ключевые критерии, которые помогут оценить и улучшить требования, чтобы они были чёткими, проверяемыми и реализуемыми. !!!На каждом из собеседований, которые мне приходилось проходить, вопрос про критерии задавался в обязательном порядке!!!

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

1. Полнота

• Определение: Требования должны полностью описывать систему или функцию, без упущенных элементов. Все аспекты, которые должны быть включены в проект, должны быть учтены.
• Пример: Если система должна отправлять уведомления пользователям, требования должны описывать, когда и как эти уведомления должны отправляться.

2. Однозначность

• Определение: Требования должны быть сформулированы так, чтобы их можно было трактовать только одним способом. Избегайте двусмысленных фраз и терминов.
• Пример: Фраза "быстрое время отклика" является неоднозначной. Лучше указать точное время — "время отклика не должно превышать 2 секунд".

3. Проверяемость

• Определение: Требования должны быть сформулированы так, чтобы можно было проверить их выполнение с помощью тестирования, инспекций или демонстраций.
• Пример: Требование "система должна быть удобной" не проверяемо. "Пользователь должен выполнять задачу за 3 клика" — проверяемо.

4. Выполнимость

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

5. Необходимость

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

6. Последовательность

• Определение: Требования не должны противоречить друг другу. Все требования должны быть согласованы между собой, а также с другими документами и системными ограничениями.
• Пример: Если одно требование гласит, что система должна быть доступна 24/7, а другое допускает еженедельное обслуживание на несколько часов, они противоречат друг другу.

7. Актуальность

• Определение: Каждое требование должно иметь связь с бизнес-целями или источником, чтобы можно было отследить его необходимость и обоснованность.
• Пример: Если требование не может быть связано с какой-либо бизнес-задачей или пользовательской потребностью, его нужно пересмотреть.

8. Изменяемость

• Определение: Требования должны быть легко изменяемы в будущем, чтобы их можно было корректировать по мере появления новых данных или условий, не нарушая общей структуры проекта.
• Пример: Документ требований должен быть структурирован и поддерживаться в актуальном состоянии, чтобы изменения можно было легко вносить и отслеживать.

9. Непротиворечивость

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

10. Понятность

• Определение: Требования должны быть изложены понятным языком, без сложных и технически запутанных выражений, чтобы их могли понять все стейкхолдеры.
• Пример: Использование технических терминов или аббревиатур без объяснения может затруднить понимание требования.

11. Приоритизация

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

Продолжение в комментариях!