Jednotka 2 / 12

Analýza požadavků a návrh softwaru

zisky:

  • Schopnost transformovat nejasné obchodní požadavky na jasné, testovatelné softwarové požadavky a uživatelské příběhy s podporou AI
  • Schopnost porovnávat klady a zápory návrhu systému, datového modelu a architektonických rozhodnutí strukturovaným způsobem s AI
  • Schopnost kriticky ověřit navržený návrh AI s ohledem na požadavky, škálovatelnost a omezení

Většina softwarových projektů selže ne kvůli špatnému kódu, ale kvůli špatně pochopeným požadavkům. Požadavek v jedné větě jako „Umožněte uživatelům stahovat přehledy“ za sebou zanechává desítky nezodpovězených otázek: V jakém formátu? Kdo má na starosti? Kolik záznamů? Co když je to pomalé? Analýza požadavků (převedení obchodního požadavku na jasné, testovatelné technické potřeby) a návrh softwaru (konstruování struktury na papíře tak, aby vyhovovala těmto potřebám) je fází, ve které je před napsáním kódu zabráněno nejdražším chybám. V této jednotce se v této fázi naučíme používat umělou inteligenci jako „myšlenkového partnera“: partnera, který demystifikuje nejistotu, třídí možnosti, ale konečné rozhodnutí nechává na vás.

AI zde vytváří dvě velké hodnoty. Nejprve klade otázky, které přeskakujete; Vynáší na povrch skryté předpoklady a okrajové případy v požadavku. Za druhé, rychle sestaví klady a zápory rozhodnutí o návrhu. Ale to je nebezpečí: AI bude dávat obecná doporučení jako „nejlepší praxi“, aniž by plně znala váš kontext (rozpočet, tým, stávající systém, právní omezení). Vaším úkolem je filtrovat tyto rady proti vaší vlastní pravdě.

Pojmy: Uživatelský příběh: Krátká věta vyjadřující potřebu ve formě „... jako, chci umět... protože...“. Kritéria přijetí: Testovatelné podmínky, které musí být splněny, aby byla práce považována za „hotovou“. Nefunkční požadavek: Požadavky týkající se „jak se to bude chovat“ spíše než „co to bude dělat“, jako je rychlost, bezpečnost, škálovatelnost.

Od vágního požadavku k testovatelnému požadavku

Dobrý požadavek je měřitelný a ověřitelný. Ne „ať je systém rychlý“, ale „ať se výsledky vyhledávání vrátí do 500 ms“. Zde je krok za krokem, jak pomocí umělé inteligence zúžit nejistotu:

  1. Zadejte požadavek tak, jak je, a nechte vygenerovat otázku. Neptejte se AI ​​ne na řešení, ale nejprve „uveďte cokoli nejasného v tomto požadavku jako otázku“.
  2. Vy dáváte odpovědi. Pouze vy znáte kontext; Odpovězte na otázky AI se svými skutečnými obchodními omezeními.
  3. Nechte to převést do uživatelských příběhů a kritérií přijetí. Přeložte vyjasněnou potřebu do testovatelných položek.
  4. Přidejte okrajové případy a negativní scénáře. "Prázdný výsledek", "neoprávněný uživatel", "příliš velký soubor" atd.

Výzva k extrakci nejasností: "Následující obchodní požadavek převedeme na softwarový požadavek. Zatím nenavrhujte řešení. Nejprve extrahujte VŠECHNY nejednoznačnosti a skryté předpoklady, které nejsou zodpovězeny v tomto požadavku, jako seznam otázek. Seskupte otázky do následujících nadpisů: rozsah, uživatel/autorita, objem dat, výkon, chybové podmínky, zabezpečení. Požadavek: "Umožněte uživatelům stáhnout historii objednávek jako zprávu."

Příběh uživatele + výzva ke kritériím přijetí: "Rozdělte následující vyjasněnou potřebu na příběhy uživatelů, které jsou v souladu s principy INVEST. Napište 3–5 testovatelných kritérií přijetí pro každý příběh (ve formátu Dan-When-Then). Přidejte alespoň 2 negativní scénáře (neoprávněný přístup, prázdná data). Potřeba: [napište objasněnou potřebu zde]“

Porovnání návrhových rozhodnutí s AI

Design je neustálý kompromis: rychlost versus flexibilita, jednoduchost versus škálovatelnost? AI vkládá tyto kompromisy do rychlé tabulky. Například u funkce „odeslat upozornění“ můžete diskutovat o tom, zda použít synchronní (odeslat na vyžádání) nebo asynchronní (ve frontě, odeslat na pozadí).

Výzva k porovnání návrhu: "Navrhuji funkci 'odeslat e-mailové upozornění uživateli'. Porovnejte dva přístupy: (A) synchronní doručování během požadavku HTTP, (B) asynchronní doručování na pozadí jeho umístěním do fronty zpráv. Vytvořte tabulku na následujících osách: doba čekání uživatele, odolnost proti chybám, složitost, náklady na infrastrukturu, obtížnost při ladění. Shrňte, kterým případem bych větu neskončil. rozhodnutí za mě."

osa

synchronní přenos

Asynchronní (fronta)

Čekací doba uživatele

Dlouhé (čekání na zásilku)

Krátké (okamžitě se vrací)

Tolerance chyb

Nízká (požadavek exploduje, pokud exploduje odeslání)

Vysoká (možnost opakování)

složitost

nízká

Středně vysoká (infrastruktura fronty)

Náklady na infrastrukturu

nízká

Jsou vyžadovány další komponenty

Kam se to hodí

Nízká hlasitost, jednoduchá aplikace

Velký objem, kritické doručení

Tip: Řekněte AI „nerozhodujte za mě, jen mi ukažte možnosti a podmínky“ vás donutí přemýšlet a sníží riziko slepého přijetí návrhu. Nejlepší rozhodnutí o designu je to, které udělá osoba, která zná váš kontext (vy).

Slabá výzva / Silná výzva

WEAK: "Navrhněte databázi pro objednávkový systém." (Výsledek: jaké měřítko, jaké vztahy, která omezení nejsou jasné; obecné, nerealistické schéma.) SILNÝ: "Navrhněte návrh datového modelu pro malý e-commerce. Entity: Zákazník, Objednávka, Produkt, Položka objednávky. Omezení: V objednávce může být mnoho produktů; cena produktu se může v průběhu času měnit, ale aktuální cena by měla být zachována ~500 dní a očekávané objednávky z minulých objednávek. „Vysvětlete, že jste se rozhodl. Uveďte, jak jste vyřešili problém s historií cen. Uveďte jej jako seznam entit a polí, nikoli kód."

Rozdíl silné výzvy; měřítko (500 objednávek za den), obchodní pravidlo (musí být zachována minulá cena) a požadovaný výstupní formát. Jediná věta jako "Původní cena musí být zachována" zcela změní design; Pokud to nezadáte, AI vytvoří nepřesný, ale věrohodně vypadající diagram.

Mini pouzdra

Případ 1 – Skrytý předpoklad. Tým přímo kóduje požadavek „uživatel může nahrát profilovou fotku“. Jiný tým se zeptal AI ​​na nejistotu: "maximální velikost? povolené formáty? nevhodné ovládání obsahu? smazat starou fotku?" Vytváří 8 otázek jako. První tým se dozví o problému v produkci, když 20 MB soubory zaplní server; Druhý tým to řeší designově.

Případ 2 – Nesprávný předpoklad měřítka. AI navrhuje komplexní mezipaměťovou vrstvu pro funkci vytváření sestav. Když technik podotkne, že skutečná data jsou pouze 30 zpráv za den, AI návrh zjednoduší. Neuvedení měřítka vede ke zbytečné složitosti; upřesnění ušetří 2 týdny zbytečné práce.

Případ 3 – Mezera kritérií přijetí. "Co se stane, když platba selže?" Vzhledem k tomu, že dotaz nebyl nikdy položen, objednávkový systém bude v případě neúspěšné platby stále označovat objednávku jako "potvrzenou". Seznam negativních scénářů generovaných AI tuto mezeru zachycuje; Kritéria přijetí 1 řádku zabrání skutečným ztrátám peněz.

Časté chyby

  • Předání požadavku přímo do kódu. Kód napsaný před vyřešením nejednoznačnosti rychle řeší špatný problém.
  • Slepě přebíráme obecný „nejlepší postup“ umělé inteligence. Pokud neurčíte svůj kontext (rozsah, rozpočet, tým), doporučení pro vás nebude fungovat.
  • Přeskakování nefunkčních požadavků. Pokud rychlost, zabezpečení a rozsah nejsou specifikovány, návrh bude neúplný.
  • Jen přemýšlím o šťastném scénáři. Do návrhu by měly být zahrnuty negativní scénáře, jako jsou prázdná data, neoprávněný uživatel, chybový stav.
  • Delegování rozhodnutí na AI. AI generuje možnosti; Vy rozhodnete, který kompromis vyhovuje vašemu podnikání.

V souhrnu

Analýza a návrh požadavků je fází, kde jsou zachyceny nejlevnější chyby. Umělá inteligence zde generuje otázky, které odhalují nejistotu, navrhuje příběhy uživatelů a kritéria přijetí a mapuje kompromisy v designu. Ale jen vy znáte kontext; Vaším úkolem je filtrovat doporučení AI na základě vašeho rozsahu, rozpočtu, týmu a právních omezení a učinit konečné rozhodnutí. Disciplína „nerozhoduj za mě, ukaž mi možnosti“ vede k lepšímu designu a hlubšímu učení.

Aplikační úkol

Vyberte si jednovětový požadavek na úlohu z vašeho kontextu. Nejprve použijte výzvu k nejednoznačnosti na AI a odpovězte na otázky se svými skutečnými omezeními. Poté převeďte vyjasněnou potřebu do alespoň 2 uživatelských příběhů a 3 kritérií přijetí pro každý z nich; Uveďte alespoň 1 negativní scénář. Nakonec vytvořte srovnávací tabulku pro návrhové rozhodnutí (synchronní/asynchronní, struktura tabulky atd.) a napište své vlastní rozhodnutí ve 2 větách.

kontrolní seznam

  • [ ] Nejasnosti jsem odstranil jako otázky před předáním požadavku do kódu.
  • [ ] Dal jsem kontext (rozsah, pravomoc, výkon, právní omezení) AI.
  • [ ] Rozdělil jsem příběhy uživatelů do testovatelných kritérií přijetí.
  • [ ] Přidal jsem alespoň jeden negativní/okrajový scénář.
  • [ ] Návrhové rozhodnutí jsem vyhodnotil pomocí kompenzační tabulky.
  • [ ] Konečné rozhodnutí jsem učinil na základě svého kontextu, nenechal jsem to na AI.