День 1935. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 9. Качество требований каждый определяет по-своему. Начало
У требований к ПО есть своя аудитория: как разработчики, которые будут использовать их для выполнения своей работы, так и представители клиентов, которые получат или будут использовать продукт. Именно получатели, а не разработчики требований, должны оценивать их качество.
Если кто-то обнаружит проблемы с моими требованиями, то это повод пересмотреть их. И неважно, насколько хорошими считал их я. Создатели (бизнес-аналитики) и получатели (архитекторы, дизайнеры, разработчики, тестировщики и др.) этих сводов знаний должны согласовать их содержание, формат, организацию, стиль и уровень детализации.

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

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

Чтобы требования можно было считать качественными, люди должны ответить «да» на каждый вопрос из представленных ниже.

Аудитория: Спонсор, отдел маркетинга, клиенты
Вопросы:
- Позволит ли решение, основанное на требованиях, достичь целей, поставленных клиентами?
- Понятны ли риски и последствия для бизнеса, связанные с каждым требованием?

Пользователи:
- Понятно ли каждое требование?
- Достаточно ли точно каждое требование выражает потребность клиента?
- Будет ли решение, основанное на этом наборе требований, удовлетворять мои потребности?
- Все ли требования необходимы?

Руководитель проекта:
- Сможет ли команда разработать решение с учетом имеющихся ресурсов и в рамках существующих ограничений?
- Позволяет ли описание каждого требования оценить его сложность и влияние на проект?

Бизнес-аналитик, владелец продукта, продакт-менеджер:
- Каждое ли требование представляет ценность для клиента?
- Являются ли требования чёткими и однозначными?
- Отсутствуют ли конфликты между требованиями?

Дизайнеры, разработчики:
- Понятно ли каждое требование?
- Содержат ли требования всю информацию, необходимую для разработки решения, и если нет, указывают ли, где её получить?
- Возможно ли реализовать решение, основанное на требованиях, с технической точки зрения и с учетом имеющихся ресурсов и ограничений во времени?

Тестировщик:
- Можно ли протестировать выполнение каждого требования?

Другие заинтересованные стороны:
- Соответствуют ли требования всем ожиданиям и ограничениям, накладываемым моей точкой зрения?

Окончание следует…

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.