Zbudowane zgodnie z opisem:
pięć ryzyk w wymaganiach na oprogramowanie, które decydują o projekcie

Projekt może zostać dostarczony w terminie, w budżecie i ze stosunkowo niewielką liczbą błędów technicznych, a mimo to ponieść porażkę biznesową. Po prostu zbudowano nie to, co trzeba. Problem pojawia się tam, gdzie powstają wymagania na oprogramowanie – na długo przed pierwszą linijką kodu. Tam też najtaniej temu zapobiec.

Badania wskazują wiele problemów tkwiących w wymaganiach. W typowym średnim lub dużym projekcie wskazałbym pięć najważniejszych. Ich względna waga zależy od dziedziny projektu i modelu realizacji.

Niekompletne wymagania na oprogramowanie: kosztowne poprawki

Tego, czego brakuje w wymaganiu, rzadko widać w dniu, w którym je zapisano. Wychodzi to później, gdy ktoś musi je zbudować albo przetestować. Badanie zaprezentowane na konferencji ASE 2026 objęło 8082 wymagania, które producent układów scalonych otrzymał od producentów samochodów, organizacji normalizacyjnych i własnych zespołów inżynierskich. Tylko 0,2% z nich było w pełni określonych. Kontekstu działania brakowało w 81,5% wymagań, logiki warunkowej w 51,5%, a oczekiwanego zachowania w 45%. Im mniej kontekstu miało wymaganie, tym więcej szczegółowych wymagań musieli z niego wyprowadzić inżynierowie^[1].

Wywiady u producenta samochodów i jego dostawcy wyjaśniają, skąd się to bierze. Na początku projektu autorom wymagań często brakuje wiedzy o przyszłym produkcie. Wymagania wychodzą więc ogólnikowe albo szybko się dezaktualizują. Klienci, którzy nie do końca rozumieją swój problem, opisują rozwiązanie, którego chcą. Krótkie terminy kontraktowe zmuszają zespoły do zbierania wymagań w pośpiechu^[2].

Niektóre luki są ukryte na widoku. Gdy wymienia się stary system, wymaganiem jest także wszystko, co on już robi. Badanie modernizacji starego systemu z 2026 roku pokazało, że wywiady dobrze uchwyciły nowe potrzeby. Pominęły jednak to, co istniejący system już robił. Ta wiedza była tylko w głowach ludzi^[3].

Niejednoznaczne wymagania na oprogramowanie: błędnie działające funkcje

Niejednoznaczne wymaganie jest gorsze niż brakujące, bo wygląda na kompletne. Dwie osoby znajdują w nim dwa znaczenia i każda buduje to, co zrozumiała.

Praktycy uznają niejednoznaczność za najgorszą wadę wymagań. Badanie z 2025 roku w dużej europejskiej firmie zbrojeniowej objęło wywiady z dziesięcioma doświadczonymi inżynierami i ankietę wśród 58 kolejnych. Ośmiu z dziesięciu rozmówców zaliczyło niejednoznaczność do trzech najpoważniejszych wad, a siedmiu do trzech najczęstszych. Ankieta również potwierdziła oba rankingi. Inżynierowie opisali skutki wprost. Niejednoznaczne wymaganie krąży między analitykami a programistami i ściąga wnioski o zmianę. Co gorsza, może pozostać niezauważone aż do testów integracyjnych lub utrzymania, gdy poprawka kosztuje najwięcej^[4]. Podobnie badania naukowe odzwierciedlają ten sam priorytet. Przegląd 105 badań empirycznych nad jakością wymagań wykazał, że niejednoznaczność jest najczęściej badanym atrybutem jakości i ma najwięcej odmian^[5].

AI zaostrza to ryzyko, a nie je zmniejsza. W badaniu zaprezentowanym na konferencji ASE 2026 przepisano 1304 zadania programistyczne w wersjach niejednoznacznych i przekazano je dużym modelom językowym. Niejednoznaczność obniżyła odsetek poprawnych rozwiązań średnio o 7,22 punktu procentowego, a maksymalnie o 32 punkty. Odpowiedzi stały się też mniej spójne: w przypadku GPT-4 odsetek sprzecznych odpowiedzi na to samo zadanie wzrósł z 14% do 28%. Modele wykryły tylko od 25% do 44% niejednoznacznych sformułowań, zależnie od ich rodzaju^[6]. Model AI nie pyta, co miałeś na myśli. Wybiera jedno znaczenie i pisze kod.

Niekontrolowane zmiany wymagań: przekroczenie kosztów i terminów

Wymagania będą się zmieniać, bo zmienia się biznes. Ryzykiem jest zmiana bez kontroli: taka, której nikt nie ocenia, nie wycenia i nie śledzi w projekcie systemu.

Studium przypadku w firmie tworzącej oprogramowanie, oparte na 15 wywiadach, wskazało dwa główne źródła zmienności wymagań. Były to niepewne wymagania i zmieniające się otoczenie biznesowe. Architekci wskazali jako skutek problemy z harmonogramem i dług techniczny w architekturze^[7]. Badanie z branży zbrojeniowej dodaje powiązanie z ryzykiem nr 2: niejednoznaczne wymagania są częstym źródłem wniosków o zmianę^[4]. Wiele zmian to wcale nie nowe potrzeby, lecz stare wymagania wreszcie zrozumiane.

Co więcej, złożoność to utrudnia. W raporcie PMI Pulse of the Profession 2026 81% specjalistów od projektów stwierdziło, że projekty stały się bardziej złożone. Cztery na pięć złożonych projektów poniosły negatywne skutki, takie jak dryf strategiczny lub zakłócenia realizacji^[8]. Bez zarządzanej wersji bazowej i oceny wpływu każdej zmiany każda zmiana priorytetów uderza wprost w budżet i harmonogram.

Brak wymagań niefunkcjonalnych: awarie w trakcie eksploatacji

Wymagania funkcjonalne opisują, co system robi. Wymagania niefunkcjonalne opisują, jak dobrze to robi: wydajność, niezawodność, bezpieczeństwo, łatwość utrzymania. To one kształtują architekturę i to one najczęściej pozostają niezapisane.

Analiza międzynarodowej ankiety NaPiRE o inżynierii wymagań z 2025 roku wykazała, że większość respondentów uważa łatwość utrzymania, niezawodność, użyteczność i wydajność za ważne. Część z nich zgłosiła jednak, że wymagań dla tych ważnych atrybutów nie udokumentowano. Autorzy traktują te luki jako dług techniczny^[10]. Inżynier z badania w branży zbrojeniowej podał przykład tego, co dzieje się dalej. Zadania opisanego tylko jako „wysoki priorytet” i „szybkie” nie da się porządnie przetestować. System przechodzi testy, a potem działa źle na produkcji, gdzie rzeczywiste ograniczenia są inne^[4].

Również przeglądy w sektorze publicznym wskazują to samo. Holenderska rada oceniająca rządowe projekty IT, Adviescollege ICT-toetsing (AcICT), oceniła w 2025 roku 20 projektów o wartości ponad 1,1 mld euro. Oczekuje wymagań bezpieczeństwa, które są „konkretne, możliwe do zastosowania i testowalne”. Chce też, by utrzymanie zaplanowano i sfinansowano już na etapie projektu^[9].

Niewystarczający udział interesariuszy: niespełnienie potrzeb biznesu

Wymagania na oprogramowanie są tylko tak dobre, jak ludzie, którzy je kształtują. Gdy właściwych osób brakuje, system spełnia specyfikację, ale mija się z potrzebami biznesu.

AcICT stwierdziła, że rola zamawiającego w rządowych projektach IT wciąż zbyt często jest wypełniana niewystarczająco. Projekty grzęzną, gdy zamawiający za bardzo polegają na dostawcy i sami formułują za mało konkretnych, mierzalnych wymagań^[9]. Podobnie wywiady z branży motoryzacyjnej opisują ten sam problem od środka. Trudno zbudować kanały komunikacji i informacji zwrotnej między poziomami i organizacjami, a podział odpowiedzialności między zespołami często jest niejasny^[2]. W badaniu modernizacji starego systemu użytkownicy z jednego kraju nie wzięli udziału w ustalaniu priorytetów. Programiści zrezygnowali z udziału, bo nie uważali tego za swoją rolę^[3].

Osoby, które piszą wymagania, mają takie samo znaczenie jak te, których się pyta. Niewielkie badanie z 2026 roku wśród 18 praktyków w Brazylii wymieniło 17 niepożądanych cech inżynierów wymagań. Problemy z komunikacją i brak wiedzy dziedzinowej należały do głównych grup^[11]. Wreszcie PMI ustaliło, że najlepsze zespoły częściej uzgadniały ze sponsorami kryteria sukcesu przed realizacją: 39% wobec 30%. Ogółem 31% złożonych projektów nie przyniosło wszystkich zamierzonych korzyści^[8].

Wymagania na oprogramowanie jako wskaźnik ryzyka projektu

Podstawowym wyzwaniem, jakie stawiają wymagania na oprogramowanie, nie jest samo opisanie, co system ma robić. Jest nim zapewnienie wspólnego, zweryfikowanego, testowalnego i stale zarządzanego zrozumienia potrzeb biznesu.

Projekt może zostać dostarczony w terminie, w budżecie i ze stosunkowo niewielką liczbą błędów technicznych, a mimo to ponieść porażkę biznesową, bo realizuje niewłaściwe wymagania. Dlatego w nadzorze nad projektami informatycznymi jakość wymagań należy traktować jako kluczowy wskaźnik ryzyka projektu, obok budżetu, harmonogramu i jakości technicznej.

Pięć pytań pomaga ją zmierzyć przed kolejnym posiedzeniem komitetu sterującego.

1. Czy każde wymaganie jest na tyle kompletne, by je zbudować i przetestować bez zgadywania? Sprawdź kontekst, warunki i oczekiwane zachowanie, także to, co już robi stary system.
2. Czy dwie osoby mogą je zrozumieć inaczej? Jeśli tak, dodaj przykład lub kryterium akceptacji, zanim ktokolwiek napisze kod, człowiek czy AI.
3. Czy każdą zmianę ocenia się przed jej przyjęciem? Ustal, kto ją zatwierdza, ile kosztuje i których części projektu systemu dotyczy.
4. Czy wydajność, niezawodność, bezpieczeństwo i łatwość utrzymania są zapisane i testowalne? Jeśli nie, o architekturze decyduje przypadek.
5. Czy przyszli użytkownicy systemu kształtowali wymagania? I czy sponsor zgodził się, co dla niego oznacza sukces?

Ktokolwiek pisze kod, własny zespół, dostawca czy model AI, buduje to, co mówią wymagania na oprogramowanie.

Źródła

1. Z. Wang, S. Yu, Z. Xing, T. Wenzel, C. Chen, „Bridging Stakeholder and Product Requirements: An Empirical Study of Requirement Engineering in the Automotive Industry”, ASE 2026, arXiv:2607.05632, 6 lipca 2026. arxiv.org
2. G. Liebel, M. Tichy, E. Knauss, O. Ljungkrantz, G. Stieglbauer, „Organisation and communication problems in automotive requirements engineering”, Requirements Engineering 23 (2018) 145–167, opublikowano online 28 października 2016. doi.org
3. R. S. Karper, D. A. Tamburri, A. Ferrari, W.-J. van den Heuvel, „When Stakeholder-centric Requirements Engineering is Not Enough: An Action Research Study on Legacy System Modernisation”, arXiv:2609.07340, 7 września 2026. arxiv.org
4. E. Gentili, D. Falessi, „Practitioners’ perceptions on requirements smells”, Information and Software Technology 187 (2025) 107823, dostępne online od 5 lipca 2025. doi.org
5. L. Montgomery, D. Fucci, A. Bouraffa, L. Scholz, W. Maalej, „Empirical research on requirements quality: a systematic mapping study”, Requirements Engineering 27 (2022) 183–209. doi.org
6. D. Yang i in., „Clarity Is Not Assumed: Understanding LLM-Based Code Generation under Ambiguous Requirements”, ASE 2026 (East China Normal University), arXiv:2604.21505. arxiv.org
7. S. Aaramaa, S. Dasanayake, M. Oivo, J. Markkula, S. Saukkonen, „Requirements Volatility in Software Architecture Design: An Exploratory Case Study”, arXiv:2603.17648 (opublikowano 18 marca 2026). arxiv.org
8. Project Management Institute, Pulse of the Profession 2026, „Driving Success in Complex Projects”, komunikat prasowy, 12 maja 2026. businesswire.com
9. Adviescollege ICT-toetsing, „Jaarrapportage 2025” (Raport roczny 2025), marzec 2026, opublikowano 9 kwietnia 2026, CC BY 4.0. adviescollegeicttoetsing.nl
10. E. Scott, G. Robiolo, S. Matalonga, M. Felderer, D. Pfahl, „A study on reported under-documented non-functional requirements as an indicator of technical debt”, Software Quality Journal 33 (2025), artykuł 28, opublikowano online 30 czerwca 2025. doi.org
11. L. Barbosa i in., „Understanding Undesirable Attributes of Requirements Engineers: Insights from Practitioners”, arXiv:2606.01370, 31 maja 2026. arxiv.org