Книжный клуб. К. Вигерс - Разработка требований к ПО

Скопировал требование из прошлого проекта «по привычке», а оно не работает в новой реальности. Переиспользование спасает месяцы, только если это проверка и адаптация, а не копипаст. Это восемнадцатая глава книги Карла Вигерса «Разработка требований к ПО», которую я разбираю в рубрике «Книжный клуб». После проверки требований кажется, что самое сложное позади. Но есть тема, которая экономит месяцы: повторное использование требований. У большинства проектов много общего: логин, оплата, уведомления, права доступа...

Заказчик поставил подпись «утверждено», не прочитав ни строки, и через три месяца команда переделывает всё с нуля. Утверждение ради галочки становится самой дорогой формой экономии времени в проекте. Это семнадцатая глава книги Карла Вигерса «Разработка требований к ПО», которую я разбираю в рубрике «Книжный клуб». После приоритизации у меня есть список требований, который команда готова делать. Но прежде чем отдать его в разработку, стоит остановиться и проверить, а правильно ли всё записано. Вигерс посвящает этому главу про утверждение и проверку требований...

«Всё срочно, всё важно» - слышишь это каждую неделю? Команда тянет всё параллельно, к релизу - 20 функций «наполовину» и удивлённый заказчик, который получил не то. Приоритеты решают это до того, как потрачены деньги и нервы. Это шестнадцатая глава книги Карла Вигерса «Разработка требований к ПО», которую я разбираю в рубрике «Книжный клуб». После прототипов у тебя может собраться список требований, который невозможно сделать за раз. И тут приходит заказчик и говорит: «Всё срочно, всё важно». Знакомо?...

Ошибка в требованиях, найденная на макете, стоит рублей. Та же ошибка, обнаруженная после релиза, стоит недель переделок и испорченных отношений. Чтобы поймать её дёшево, достаточно показать заказчику что-то руками, ещё до первой строки кода. Это пятнадцатая глава книги Карла Вигерса «Разработка требований к ПО», которую я разбираю в рубрике «Книжный клуб». После того, как сделать НФТ измеримыми, остался практичный инструмент, который снижает риск на самых ранних этапах: прототипы. Ведь заказчик почти всегда не может объяснить, что ему нужно, пока не увидит хоть что-то своими глазами...

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

«Система должна быстро обрабатывать заказы» звучит как требование. Пока в час пик всё не ложится, а из системы не начинают течь данные. Обычно об этих требованиях вспоминают на проде и дорого за это платят. Это четырнадцатая глава книги Карла Вигерса «Разработка требований к ПО», которую я разбираю в рубрике «Книжный клуб» (точнее, её первая часть). После требований к данным осталась большая и недооценённая тема: нефункциональные требования (НФТ). Функциональные отвечают на вопрос «что система делает», а НФТ на вопрос «как она это делает»...