1 заметка с тегом

вигерс

Как работать с требования к сайту, сервису или программе?

На моей первой работе заказчик (начальник) сидел у меня за спиной. Я не тратил время на документы, а сразу же «пилил» код. Работа была организована по принципу — утром «хотелки», вечером релиз. Биллинговая система, которую мы разрабатывали, постепенно разрасталась, её всё сложнее было поддерживать. Там были кнопки, про которые никто не мог точно сказать для чего они и как работают. Некоторые кнопки не использовались, а некоторые настройки могли порушить работу системы и их было опасно трогать.

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

Прошло 20 лет с тех пор, как я выпустил и внедрил на предприятии свою первую программу. Появились сотни классных книг и курсов по разработке ПО. Уже никому не нужно рассказывать о важности технического задания (ТЗ).

В небольших проектах заказчик присылает разработчику ТЗ, а разработчик пишет список вопросов после изучения ТЗ. Спустя несколько встреч и цепочки писем получается что-то похожее на список требований в свободной форме. Только проблема в том, что в таком виде с требованиями сложно работать и нельзя однозначно сказать, всё ли мы учли. Риск и цена ошибки на этом этапе очень большие.

Решение — разложить требования по типам и уровням. На это может уйти пару часов. Но в результате получаем ясность в голове и уверенность в правильности действий. Про это есть отличная книга Карла Вигерса «Разработка требований к программному обеспечению». На мой взгяд, это библия для аналитика.

Вигерс выделяет три уровня требований:
— Бизнес-требования (высокоуровневые цели (ПОЧЕМУ?))
— Пользовательские требования (цели/задачи пользователей, которые будут выполняться с помощью ПО (КТО?)
— Функциональные требования (функциональность ПО, которая должна быть создана (ЧТО?))

Типы требований по Вигерсу:
— Нефункциональные требования (атрибуты качества, ограничения, бизнес-правила)
— Системные требования (для комплексных систем — интеграционные требования)

.