Sztuka opisu problemu: od tradycyjnych wymagań do inżynierii promptów dla AI

Wstęp: ewolucja kluczowej umiejętności

Historycznie Opis problemu (OP) był podstawowym artefaktem w analizie systemów. Służył jako jedyne źródło prawdy do wyprowadzania przypadków użycia,modeli procesów biznesowych (BPMN)diagramów klas i schematów baz danych. Niejasny OP oznaczał rozrost zakresu; precyzyjny OP oznaczał udaną realizację.

Dziś, wraz z pojawieniem się sztucznej inteligencji generatywnej, Opis problemu nie stał się przestarzały; stał się promptem.

Modele AI są w istocie „silnikami wymagań”. Nie potrafią czytać w naszych myślach, ale mogą wykonywać instrukcje z nadludzką prędkością, jeśli instrukcje te są sformułowane w sposób przypominający rygorystyczny opis problemu. Pisanie OP dla AI wymaga tej samej dyscypliny analitycznej co pisanie go dla zespołu deweloperskiego, ale z dodatkowymi warstwami kontekstu dotyczącymi formatu wyjściowego, ograniczeńoraz iteracyjnego udoskonalania.

Ten przewodnik łączy tradycyjną analizę systemów ze współczesnym tworzeniem promptów dla AI, dostarczając kompleksowego ramowego podejścia do pisania Opisów problemu, które generują wysokiej jakości diagramy, kod i strategiczne wnioski.

1. Kluczowe koncepcje skutecznego opisu problemu

Niezależnie od tego, czy adresujemy ludzkich analityków, czy modele językowe (LLM), cztery filary wspierają solidny OP:

1. Kontekstowe zakotwiczenie

• Tradycyjne: Tło biznesowe, interesariusze, środowisko regulacyjne.

• Zastosowanie w AI: Definicja persony, poziom wiedzy eksperckiej w danej dziedzinie, grupa docelowa dla wyniku.

• Dlaczego to ma znaczenie: Bez kontekstu AI domyślnie generuje uśrednione, ogólne rozwiązania. „Zaprojektuj system logowania” daje projekt studencki; „Zaprojektuj logowanie do portalu pacjenta zgodne z HIPAA dla osób starszych o niskiej kompetencji cyfrowej” daje wyspecjalizowany wzorzec architektoniczny.

2. Dekompozycja strukturalna

• Tradycyjne: Dzielenie problemów na wymagania funkcjonalne/niefunkcjonalne, aktorów i encje.

• Zastosowanie AI:Strukturyzacja łańcucha myślenia (CoT), żądania rozumowania krok po kroku, modularne wyzwalacze.

• Dlaczego to ma znaczenie:AI ma trudności z monolityczną złożonością. Rozkładanie opisu problemu (PD) pomaga modelowi zachować spójność w długich outputach.

3. Określenie ograniczeń

• Tradycyjne:Budżet, harmonogram, stos technologiczny, standardy zgodności.

• Zastosowanie AI:Format wyjściowy (Mermaid, PlantUML, JSON), wytyczne stylistyczne, zakazane wzorce, limity tokenów.

• Dlaczego to ma znaczenie:Ograniczenia wymuszają kreatywność i precyzję. Nieograniczona AI generuje obszerny, często nieprzydatny materiał.

4. Kryteria akceptacji

• Tradycyjne:Definicja ukończenia, przypadki testowe, wskaźniki KPI.

• Zastosowanie AI:Sprawdzenia walidacyjne, wyzwalacze samokorekty, weryfikacja oczekiwanej struktury.

• Dlaczego to ma znaczenie:Musisz określić, jak wygląda „dobry” wynik przed rozpoczęciem generowania, aby umożliwić skuteczną iterację.

2. Ramy: Model C.R.E.F.O. dla opisów problemów w AI

Zadaptowany z tradycyjnego gromadzenia wymagań, użyj tego szablonu do zadań AI:

3. Przypadki użycia i przykłady

Przypadek A: Generowanie Diagramów klas UML

Wyzwanie:Sztuczna inteligencja często tworzy zbyt złożone lub składniowo błędne diagramy, gdy otrzymuje niejasne opisy domenowe.

❌ Słaby opis problemu

„Stwórz diagram klas dla systemu e-commerce.

✅ Kompleksowy opis problemu

KONTEKST: Jesteś ekspertem w dziedzinie projektowania opartego na domenie (Domain-Driven Design). Budujemy platformę e-commerce B2B dla hurtowni, gdzie ceny są ustalane na podstawie umów, a nie katalogów.

WYMAGANIA: Zamodeluj podstawowy kontekst ograniczony zamówień. Skup się na relacjach między Umowami, Listami cenowymi, Produktami i Zamówieniami. NIE modeluj interfejsu użytkownika ani przetwarzania płatności.

ENTYTETY I ZASADY:
- Umowa: Posiada daty ważności, należy do jednego Konta klienta
- Lista cenowa: Powiązana z Umową, zawiera zasady cenowania warstwowego
- Linia zamówienia: Musi zweryfikować cenę wobec aktywnej Umowy w momencie tworzenia
- Konto klienta: Może mieć wiele Umów (bieżących/historycznych)

FORMAT: Składnia Mermaid classDiagram. Uwzględnij modyfikatory widoczności (+/-/#). Pokaż mnożność na WSZYSTKICH asocjacjach. Używaj notatek dla złożonych zasad biznesowych.

OGRANICZENIA: Maksymalnie 12 klas. Zastosuj zasady SOLID. Brak dziedziczenia głębszego niż 2 poziomy. Preferuj kompozycję nad dziedziczeniem.

WALIDACJA: Po wygenerowaniu, wypisz 3 potencjalne słabości projektowe w tym modelu.

Przypadek B: Modelowanie procesów biznesowych (BPMN)

Wyzwanie:Sztuczna inteligencja myli notację BPMN i pomija ścieżki wyjątków.

✅ Kompletny opis problemu

KONTEKST: Obsługa wniosków o świadczenia w ubezpieczeniach zdrowotnych. Grupa docelowa: audytorzy ds. zgodności i junior developerzy. Styl: Formalny i precyzyjny.

ZADANIE: Stwórz diagram procesu zgodny z BPMN 2.0 dla "Wniosku o wstępną autoryzację".

ZAKRES PROCESU:
START: Lekarz składa wniosek o autoryzację poprzez integrację z EHR (elektroniczną dokumentacją medyczną)
KONIEC: Decyzja przekazywana z powrotem do EHR + wysłanie powiadomienia do ubezpieczonego

KLUCZOWE PUNKTY PODJĘCIA DECYZJI:
1. Czy procedura jest objęta planem ubezpieczeniowym członka? (Jeśli nie → automatyczna odmowa + ścieżka odwoławcza)
2. Czy dokumentacja kliniczna jest kompletna? (Jeśli nie → zawieszenie do przeglądu przez pielęgniarkę)
3. Czy wymaga przeglądu przez dyrektora medycznego? (Próg: >50 000 USD lub procedura eksperymentalna)

OBSŁUGA WYJĄTKÓW: Zamodeluj zdarzenia przekroczenia czasu oczekiwania dla każdego etapu przeglądu (SLA 48 godzin). 
Zamodeluj ścieżkę eskalacji w przypadku naruszenia SLA.

FORMAT: Wykres przepływu Mermaid ze stylem przypominającym BPMN. Użyj podgrafów dla ścieżek "Przegląd Kliniczny" i "Weryfikacja Administracyjna".

WYMAGANIA DOTYCZĄCE WYNIKU: Podaj kod diagramu ORAZ tabelę w formacie Markdown mapującą każdy węzeł decyzyjny do konkretnego sekcji dokumentu polityki, która go reguluje.

Przypadek C: Wyprowadzanie historii użytkowników i kryteriów akceptacji

Wyzwanie:Sztuczna inteligencja generuje ogólne historie pozbawione możliwości testowania.

✅ Kompletny opis problemu

KONTEKST: Zespół Agile migruje dziedziczny system płacowy COBOL do architektury natywnej dla chmury. 
Zespół wykorzystuje BDD w Gherkin/Cucumber.

WEJŚCIE: [Wklej fragment specyfikacji systemu dziedzicznego lub transkrypcję wywiadu]

ZADANIE: Wyprowadź historie użytkowników dla modułu "Obliczanie potrąceń podatkowych".

WYMAGANIA DLA KAŻDEJ HISTORII:
- Zgodność z kryteriami INVEST
- Format tytułu: Jako [rola], chcę [możliwość], aby [wartość biznesowa]
- Kryteria akceptacji: Minimum 5 scenariuszy Gherkin na każdą historię
- Uwzględnij przypadki brzegowe: Pracownicy zatrudnieni w wielu stanach, retroaktywne korekty wynagrodzenia, 
  limity potrąceń na rzecz wierzycieli, zwolnienia z umów podatkowych

OGRANICZENIA: Każda historia musi być możliwa do zrealizowania w ≤3 dniach. Oznacz każdą historię, 
która wydaje się zbyt duża, tagiem "[WYMAGA PODZIAŁU]".

FORMAT: Strukturyzowany Markdown z nagłówkiem YAML zawierającym:
  - story_id
  - priorytet (MoSCoW)
  - szacowane punkty
  - zależności

Przypadek D: Rejestr Decyzji Architektury Systemu (ADR)

Wyzwanie:Zmuszenie sztucznej inteligencji do rozumowania o kompromisach, a nie tylko wymieniania opcji.

✅ Kompletny opis problemu

KONTEKST: Wybieramy platformę strumieniowania zdarzeń do telemetrii IoT 
(10 mln urządzeń, 50 tys. wiadomości na sekundę w szczycie). Zespół ma duże doświadczenie z Kafka, 
ale kierownictwo chce niższych nakładów operacyjnych.

ZADANIE: Napisz ADR porównujący Apache Kafka vs. AWS Kinesis vs. Pulsar.

STRUKTURA (Zgodnie z szablonem Michaela Nygarda dla ADR):
1. Tytuł i status
2. Kontekst (uwzględnij poniższe nasze specyficzne ograniczenia)
3. Czynniki decyzyjne (z wagami)
4. Rozważane opcje (macierz zalet i wad)
5. Decyzja + Uzasadnienie
6. Konsekwencje (pozytywne I negatywne)

CZYNNIKI DECYZYJNE (z wagami):
- Złożoność operacyjna (35%) - zespół jest mały (3 inżynierów)
- Koszt przy skali (25%)
- Gwarancje kolejności wiadomości (20%)
- Ryzyko uzależnienia od dostawcy (15%)
- Społeczność/ekosystem (5%)

OGRANICZENIE: Bądź brutalnie szczery co do wad. Nie rekomenduj wyłącznie na podstawie popularności. 
Jeśli żadna opcja nie jest odpowiednia, tak powiedz i zaproponuj alternatywy.

STYL: Techniczny, oparty na dowodach, bez języka marketingowego.

4. Wskazówki i triki

🎯 Techniki precyzyjne

1. Najpierw zdefiniuj swoją ontologię: Przed poproszeniem o dowolny diagram, poproś AI o stworzenie glosarza lub modelu domenowego. Ustal wspólną terminologię przed generowaniem artefaktów.„Najpierw zdefiniuj kluczowe encje i ich relacje w punktach. Czekaj na moją akceptację przed wygenerowaniem diagramu.”

2. Negatywne ograniczenia są potężne: Mówienie AI, czego NIE robić, jest często skuteczniejsze niż mówienie, co robić.„Nie uwzględniaj operacji CRUD w tym diagramie sekwencji. Nie używaj dziedziczenia. Nie zakładaj komunikacji synchronicznej.”

3. Podawaj przykłady negatywne: Pokaż, jak wygląda zły wynik.„Oto przykład zbyt złożonego diagramu, który odrzuciliśmy w zeszłym tygodniu [wklej]. Unikaj tego wzoru, ponieważ…

4. Używaj sformatowanych danych wejściowych: Przekazuj wymagania w formacie YAML, JSON lub jako listy numerowane, a nie jako tekst ciągły. AI przetwarza dane strukturalne znacznie niezawodniej.

5. Protokół iteracyjnego udoskonalania: Nigdy nie akceptuj wyniku pierwszej generacji dla złożonych diagramów. Wbuduj proces udoskonalania w swoje PD: „Po wygenerowaniu oceń własny wynik na podstawie tych 5 kryteriów jakości. Następnie wygeneruj go ponownie, uwzględniając wszystkie zidentyfikowane problemy.”

⚠️ Typowe błędy, których należy unikać

5. Lista kontrolna wytycznych

Przed przesłaniem jakiegokolwiek Opisu Problemu do AI, zweryfikuj:

• Zdefiniowana rola/persona z odpowiednim poziomem ekspertyzy

• Kontekst biznesowy zapewniony (nie tylko specyfikacje techniczne)

• Granice zakresu jawnie określone (w zakresie/z zakresu)

• Kluczowe podmioty/terminy zdefiniowane lub powołane

• Format wyjściowy określony z szczegółami składni/wersji

• Ograniczenia wymienione (techniczne, biznesowe, stylistyczne)

• Kryteria jakości zdefiniowane do samooceny

• Przypadki brzegowe/wyjątki uwzględnione

• Strategia dekompozycji zaplanowana dla złożonych wyników

• Protokół iteracji ustanowiony

6. Metakompetencja: Opis problemu jako narzędzie myślowe

Najważniejsza refleksja: Pisanie opisu problemu dla AI to przede wszystkim ćwiczenie w klarowności własnego myślenia.

Jeśli masz trudności z napisaniem jasnego opisu problemu (PD), nie masz problemu z formułowaniem poleceń – masz problem z wymaganiami. AI jedynie ujawnia niejednoznaczność, która i tak spowodowałaby problemy na późniejszym etapie.

Użyj tego przepływu pracy:

1. Stwórz szkic swojego PD

2. Zapytaj AI: „Jakie pytania musiałbyś uzyskać odpowiedzi, aby wykonać to zadanie idealnie?”

3. Odpowiedz na te pytania, dopracowując swój PD

4. Dopiero wtedy zażądaj rzeczywistego wyniku

To zamienia AI w partnera w pozyskiwaniu wymagań, a nie tylko silnik generowania. Jakość Twojego opisu problemu pozostaje, jak zawsze, jedynym najważniejszym predyktorem sukcesu – niezależnie od tego, czy Twoim współpracownikiem jest człowiek, czy sztuczna inteligencja.

WYMAGANIE DOTYCZĄCE FORMATU: Wygeneruj diagram klas w składni PlantUML 
kompatybilnej z importem do Visual Paradigm. Dołącz wszystkie adnotacje stereotypów 
(<<entity>>, <<service>>, <<repository>>). Używaj wyłącznie notacji relacji 
obsługiwanych przez VP. NIE używaj własnych rozszerzeń ani niestandardowych dekoratorów.

class OrderService {
  +processOrder(order: Order): void
}
class Order {
  +orderDate: Date
}
OrderService --> Order : uses

<<service>> class OrderService {
  +processOrder(order: Order): void
}
<<entity>> class Order {
  +orderDate: Date
}
<<repository>> class OrderRepository {
  +findById(id: UUID): Optional<Order>
}
OrderService --> OrderRepository : zależy od
OrderService ..> Order : używa [1..* tworzy]

Ten przewodnik syntetyzuje najlepsze praktyki z tradycyjnej analizy systemowej (normy IEEE 830, BABOK, specyfikacje UML) oraz z badań nad inżynierią promptów w nowoczesnej sztucznej inteligencji. Dostosuj ramy do kontekstu swojej organizacji i stale je udoskonalaj na podstawie pętli informacji zwrotnych dotyczących jakości wyników.