Запас - это не проценты, это РАЗЫ. Либо заказчик четко знает, чего хочет, все чего он хочет, отражено в ТЗ и изменения ТЗ идут как до, а может и переработка изделия. Либо надо закладывать запас на дурость заказчика - причем двухкратный как минимум. Потому как заложить запас и потом его не использовать выходит дешевле, чем не заложить запас и попасть вот в такую ситуацию. Ну хорошо, в этот раз человек справился, нашел этот байт. Сроки по изделию - заметьте - сьехали на две недели вместо получаса в случае когда запас есть. Но что будет в СЛЕДУЮЩИЙ раз, когда тому же заказчику в голову придет доработать еще что-то, а? Запас-то уже того, тю-тю, выбран до упора.
А лучше всего - применить некое типовое серийное решение, которое избыточно уже раз в 5, но УЖЕ отработано и обладает нужным функционалом.
Кстати, я бы в данной ситуации действовал по другому. Я бы вынес часть функционала за пределы контроллера - поставил второй. Скажем, модуль индикации/клавиатуры может быть абстрагирован настолько, что для его подключения достаточно будет одного провода. Тогда и уже заказанное устройство не уходит в корзину, и одновременно оно разгружается настолько, что добавление функционала не представляет проблемы. Конечно, получается дороже, да. Но это уже проблемы заказчика - если бы он включил требование в ТЗ изначально, было бы дешевле - т.е. все равно дороже, чем спроектированное изделие, поскольку контроллер был бы другой, но дешевле чем дополнительная плата с дополнительным контроллером.