Ograniczenie projektowe (ang. constraint) to narzucony z góry warunek, który zawęża przestrzeń możliwych rozwiązań - budżet, termin, technologia, regulacje, dostępność ludzi - i którego zespół nie może zmienić, a jedynie musi uwzględnić. BABOK wyraźnie odróżnia ograniczenia od wymagań: wymaganie opisuje potrzebę, ograniczenie - ramy, w których wolno ją zaspokajać.
Analityk dokumentuje ograniczenia na początku analizy, bo każde z nich wycina całe gałęzie rozwiązań. Nieznane ograniczenie odkryte w połowie projektu to klasyczne źródło przeróbek: zespół zdążył zaprojektować coś, czego nie wolno albo nie da się wdrożyć.
Przykład (MediFlow). Rejestracja online dla 12 przychodni ma cztery twarde ramy: (1) integracja wyłącznie z już używanym systemem gabinetowym - wymiana nie wchodzi w grę, kontrakt trwa do 2028; (2) dane o zdrowiu to szczególna kategoria w RODO, więc hosting tylko w EOG i obowiązkowa ocena skutków (DPIA); (3) start przed 1 stycznia, bo wtedy rusza nowy kontrakt z NFZ; (4) budżet 400 tys. zł. Te cztery zdania eliminują połowę ofert dostawców, zanim ktokolwiek otworzy prezentację sprzedażową.
Częsta pomyłka. Mieszanie ograniczeń z wymaganiami. "System ma być w Javie" zapisane jako wymaganie biznesowe to błąd dwa razy: po pierwsze biznesu nie obchodzi język, po drugie - jeśli to realne ograniczenie (bo zespół utrzymaniowy zna tylko Javę), powinno być nazwane ograniczeniem i mieć uzasadnienie. Drugi błąd: przyjmowanie fałszywych ograniczeń bez weryfikacji. "Zawsze tak robiliśmy" i "prezes sobie nie życzy" potrafią rozpłynąć się po jednym pytaniu o źródło - a potrafią też kosztować projekt pół roku okrężnej architektury.