Nyereség:
- Képes a homályos üzleti kéréseket egyértelmű, tesztelhető szoftverkövetelményekké és felhasználói történetekké alakítani AI-támogatással
- Képes a rendszertervezés, az adatmodell és az építészeti döntések előnyei és hátrányai strukturált módon összehasonlítani az AI-val
- Képes kritikusan ellenőrizni az AI javasolt tervezését a követelmények, a méretezhetőség és a korlátok alapján
A szoftverprojektek többsége nem a rossz kód miatt bukik meg, hanem a félreértett követelmények miatt. Az egymondatos kérés, mint például a „Jelentések letöltése a felhasználók számára”, tucatnyi megválaszolatlan kérdést hagy maga után: Milyen formátumban? Ki a felelős? Hány rekord? Mi van, ha lassú? A követelményelemzés (egy üzleti kérés egyértelmű, tesztelhető műszaki szükségletekké alakítása) és a szoftvertervezés (a struktúra papíron történő felépítése, hogy megfeleljen ezeknek az igényeknek) az a szakasz, ahol a legdrágább hibákat megelőzik a kódírás előtt. Ebben az egységben megtanuljuk az AI-t „gondolatpartnerként” használni ebben a szakaszban: olyan partnert, aki felszámolja a bizonytalanságot, kiválogatja a lehetőségeket, de a végső döntést rád bízza.
Az AI itt két nagy értéket produkál. Először is olyan kérdéseket tesz fel, amelyeket kihagysz; Rejtett feltételezéseket és éles eseteket hoz felszínre egy kérésben. Másodszor, gyorsan táblázatba foglalja a tervezési döntés előnyeit és hátrányait. De ez a veszély: a mesterséges intelligencia általános ajánlásokat ad „legjobb gyakorlatként”, anélkül, hogy teljesen ismerné a kontextust (költségvetés, csapat, meglévő rendszer, jogi korlátozás). A te dolgod, hogy ezt a tanácsot a saját igazságoddal szemben szűrd.
Fogalmak: Felhasználói történet: Egy rövid mondat, amely igényt fejez ki "... mint, azt akarom, hogy képes legyen... mert..." formában. Elfogadási feltételek: Tesztelhető feltételek, amelyeknek teljesülniük kell ahhoz, hogy egy munkát „elvégzettnek” lehessen tekinteni. Nem funkcionális követelmény: A „hogyan fog viselkedni” és nem a „mit fog csinálni” követelményei, például sebesség, biztonság, méretezhetőség.
A homályos kéréstől a tesztelhető követelményig
A jó követelmény mérhető és ellenőrizhető. Nem "legyen gyors a rendszer", hanem "a keresési eredmények 500 ms-on belül térjenek vissza". Íme egy lépésről lépésre az AI használatának módja a bizonytalanság csökkentésére:
- Adja meg a kérést úgy, ahogy van, és generálja a kérdést. Ne az MI-től kérdezze meg a megoldást, hanem először „soroljon fel kérdésként minden nem egyértelműt ebben a kérésben”.
- Te megadod a válaszokat. Csak te ismered a szövegkörnyezetet; Válaszoljon az AI kérdéseire valós üzleti korlátaival.
- Lefordíttatja felhasználói történetekre és elfogadási feltételekre. Fordítsa le a tisztázott igényt tesztelhető tételekre.
- Adjon hozzá szélső eseteket és negatív forgatókönyveket. "Üres eredmény", "jogosulatlan felhasználó", "túl nagy fájl" stb.
Kétértelműség kivonatolási prompt: "A következő üzleti kérést szoftverkövetelményré fordítjuk. Még ne javasoljon megoldást. Először is bontsa ki az ÖSSZES kétértelműséget és rejtett feltevést, amelyre ebben a kérésben nem válaszolt kérdéslistaként. Csoportosítsa a kérdéseket a következő címsorok alá: hatókör, felhasználó/hatóság, adatmennyiség, teljesítmény, hibafeltételek, biztonság. Felhasználók letöltési előzményei kérése:"
Felhasználói történet + elfogadási feltételek prompt: "Ossza fel az alábbi tisztázott igényt felhasználói történetekre, amelyek megfelelnek az INVEST elveknek. Írjon 3-5 tesztelhető elfogadási feltételt minden történethez (Adott-Mikor-Akkor formátumban). Adjon hozzá legalább 2 negatív forgatókönyvet (jogosulatlan hozzáférés, üres adatok). Szükséges: [a tisztázott igényt írja ide]"
A tervezési döntések összehasonlítása az AI-val
A tervezés állandó kompromisszum: sebesség kontra rugalmasság, egyszerűség kontra skálázhatóság? Az AI ezeket a kompromisszumokat egy gyors táblázatba foglalja. Például egy "értesítés küldése" funkciónál megvitathatja, hogy szinkron (kérésre küldés) vagy aszinkron (sor, küldés a háttérben) megközelítést használja-e.
Tervezési összehasonlító prompt: "E-mail értesítés küldése a felhasználónak funkciót tervezek. Hasonlítsa össze a két megközelítést: (A) szinkron kézbesítés a HTTP-kérés során, (B) aszinkron kézbesítés a háttérben az üzenetsorba helyezve. Készítsen táblázatot a következő tengelyekről: felhasználói várakozási idő, hibatűrés, összetettség, mondatösszegzés, infrastruktúra-költség, ami nehézkes lenne. a végén ne dönts helyettem."
tengely
szinkron átvitel
Aszinkron (sor)
Felhasználói várakozási idő
Hosszú (várom a szállítást)
Rövid (azonnal visszatér)
Hibatűrés
Alacsony (a kérés felrobban, ha a küldés felrobban)
Magas (újrapróbálkozás lehetséges)
összetettsége
alacsony
Közepesen magas (sorinfrastruktúra)
Infrastruktúra költség
alacsony
További alkatrészek szükségesek
Ahova illik
Alacsony hangerő, egyszerű alkalmazás
Nagy mennyiség, kritikus szállítás
Tipp: Ha azt mondjuk az MI-nek, hogy „ne dönts helyettem, csak mutasd meg a lehetőségeket és a feltételeket” gondolkodásra kényszerít, és csökkenti annak kockázatát, hogy vakon fogadj el egy javaslatot. A legjobb tervezési döntést az a személy hozza meg, aki ismeri a kontextust (Ön).
Gyenge felszólítás / Erős felszólítás
GYENGE: "Tervezzen adatbázist a rendelési rendszerhez." (Eredmény: melyik skála, mely összefüggések, milyen megszorítások nem egyértelműek; általános, irreális séma.) ERŐS: "Javasljon adatmodellvázlatot egy kis e-kereskedelemhez. Entitások: Vevő, Megrendelés, Termék, Rendelési tétel. Megkötések: sok termék lehet egy rendelésben; a termék ára idővel változhat, de az aktuális rendelési árat meg kell őrizni a ~5 napon belül. és miért „Indokolja meg, hogy Ön hozta meg a döntést. Adja meg, hogyan oldotta meg az árelőzmények problémáját. Adja meg entitások és mezők listájaként, ne kódként."
Az erőteljes felszólítás különbsége; léptéket (500 rendelés naponta), üzleti szabályt (a múltbeli árat fenn kell tartani) és a kívánt kimeneti formátumot. Egyetlen mondat, mint például „A múltbeli árat fenn kell tartani”, teljesen megváltoztatja a dizájnt; Ha ezt nem adja meg, az AI pontatlan, de hihetőnek tűnő diagramot fog készíteni.
Mini tokok
1. eset – Rejtett feltételezés. Egy csapat közvetlenül kódolja a „felhasználó feltölthet profilfotót” kérést. Egy másik csapat a bizonytalanságról kérdezte az AI-t: "maximális méret? megengedett formátumok? nem megfelelő tartalomvezérlés? régi fotó törlése?" 8 hasonló kérdést produkál. Az első csapat akkor értesül a problémáról a termelésben, amikor 20 MB fájl tölti meg a szervert; A második csapat tervezésben oldja meg.
2. eset – Helytelen skálafeltevés. A mesterséges intelligencia komplex gyorsítótárazási réteget javasol a jelentéskészítési funkcióhoz. Amikor a mérnök rámutat, hogy a valós adatok csak napi 30 jelentés, az AI leegyszerűsíti a javaslatot. A lépték megadásának elmulasztása szükségtelen bonyolultság költségeit vonja maga után; megadása 2 hét felesleges munkát takarít meg.
3. eset – Elfogadási feltételek hiánya. "Mi történik, ha a fizetés sikertelen?" Mivel a kérdés soha nem hangzott el, a rendelési rendszer továbbra is „megerősítettként” jelöli a megrendelést sikertelen fizetés esetén. A mesterséges intelligencia által generált negatív forgatókönyvek listája ezt a hiányosságot tükrözi; Az 1 sor elfogadási kritériuma megakadályozza a valódi pénz elvesztését.
Gyakori hibák
- A kérés közvetlenül a kódnak való továbbítása. A kétértelműség megoldása előtt írt kód gyorsan megoldja a rossz problémát.
- Vakon követve az AI általános „legjobb gyakorlatát”. Ha nem adja meg a kontextust (méretarány, költségvetés, csapat), a javaslat nem fog működni.
- A nem funkcionális követelmények kihagyása. Ha a sebesség, a biztonság és a lépték nincs megadva, a tervezés hiányos lesz.
- Csak a boldog forgatókönyvre gondolok. A negatív forgatókönyveket, például üres adatokat, jogosulatlan felhasználót, hibaállapotot bele kell foglalni a tervezésbe.
- A döntés átruházása az AI-ra. Az AI opciókat generál; Ön dönti el, hogy melyik kompromisszum felel meg a vállalkozásának.
Összefoglalva
A követelmények elemzése és tervezése az a szakasz, ahol a legolcsóbb hibákat észlelik. Itt a mesterséges intelligencia kérdéseket generál, amelyek bizonytalanságot fednek fel, felhasználói történeteket és elfogadási kritériumokat fogalmaz meg, valamint diagramokat készít a tervezési kompromisszumokról. De csak te ismered a szövegkörnyezetet; Az Ön feladata, hogy az Ön léptéke, költségvetése, csapata és jogi korlátai alapján kiszűrje a mesterséges intelligencia ajánlásait, és meghozza a végső döntést. A „ne dönts helyettem, mutasd meg a lehetőségeket” fegyelem jobb tervezéshez és mélyebb tanuláshoz vezet.
Pályázati feladat
Válasszon ki egy egymondatos álláskérelmet a környezetéből. Először alkalmazza a kétértelműségi promptot az AI-ra, és válaszoljon a kérdésekre a valódi korlátaival. Ezután fordítsa le a tisztázott igényt legalább 2 felhasználói történetre és mindegyikhez 3 elfogadási feltételt; Tartalmazzon legalább 1 negatív forgatókönyvet. Végül készítsen összehasonlító táblázatot egy tervezési döntéshez (szinkron/aszinkron, táblázatszerkezet stb.), és írja le saját döntését 2 mondatban.
ellenőrző lista
- [ ] A kérés kódba való átadása előtt eltávolítottam a kétértelműségeket, mint kérdéseket.
- [ ] Megadtam a kontextust (méretarány, jogosultság, teljesítmény, jogi korlát) az MI-nek.
- [ ] A felhasználói történeteket tesztelhető elfogadási kritériumokra bontottam.
- [ ] Hozzáadtam legalább egy hátrány/szél forgatókönyvet.
- [ ] A tervezési döntést a kompromisszumos táblázattal értékeltem.
- [ ] A végső döntést a kontextusom alapján hoztam meg, nem bíztam az AI-ra.