Fitimet:
- Aftësia për të dalluar kërkesat funksionale dhe jofunksionale dhe për të shkruar shprehje të qarta, të matshme të kërkesave me mbështetjen e inteligjencës artificiale
- Aftësia për të përdorur inteligjencën artificiale me kërkesa të strukturuara për të nxjerrë historinë e përdoruesit, kriteret e pranimit dhe kufirin e fushëveprimit nga shënimet e intervistës
- Marrja e zakonit për të kontrolluar kërkesat e krijuara nga AI për paqartësi, kontradikta dhe rregulla të munguara dhe konfirmimi i tyre me palët e interesuara
Analiza e kërkesave është detyra e përcaktimit në mënyrë të plotë, të qartë dhe të verifikueshme se çfarë duhet të bëjë një sistem. Është një nga fazat ku specialisti i MIS prodhon vlerën më të madhe; sepse një gabim këtu rritet në mënyrë eksponenciale në fund të projektit. Ekzistojnë dy lloje themelore të analizës së kërkesave. Kërkesa funksionale përshkruan punën që duhet të bëjë sistemi: "Sistemi duhet t'i dërgojë email klientit kur të konfirmojë porosinë." Kërkesa jofunksionale përshkruan se si duhet të jetë sistemi: cilësi të tilla si performanca, siguria, përdorshmëria dhe aksesueshmëria. "Ekrani i raportit duhet të hapet në më pak se 2 sekonda me ngarkesë mesatare" është një kërkesë jofunksionale.
Një kërkesë e mirë ka tre karakteristika: është e qartë (ka një interpretim të vetëm), është e matshme (ka një prag të testueshëm) dhe është e gjurmueshme (është e qartë se nga çfarë nevoje biznesi vjen). "Sistemi duhet të jetë i shpejtë" nuk plotëson asnjë nga këto; "i shpejtë" është subjektiv, nuk mund të matet, nuk mund të testohet. Në këtë fazë, AI është një ndihmë e fuqishme në hartimin e kërkesave dhe kapjen e formulimeve të paqarta; por vetëm palët e interesuara vendosin se cili rregull biznesi është real.
Historia e përdoruesit dhe kriteret e pranimit
Një format i zakonshëm në shkrimin e kërkesave moderne është historia e përdoruesit: "Si një [rol], për [qëllim], dua [veçori]." Shembull: "Si përfaqësues shitjesh, dua llogaritjen e zbritjes nga ekrani i celularit në mënyrë që të bëj kuota të shpejta në terren." Historia është e shkurtër dhe e orientuar drejt biznesit; Nuk imponon zgjidhje teknike.
Çdo histori duhet të ketë kritere pranimi: kushte të testueshme që duhet të plotësohen që historia të konsiderohet "ok". Një model i përdorur shpesh është modeli "Dhenet/Kur/Pastaj": "Duhet: klienti është në segmentin VIP. Kur: porositë mbi 10,000 TL. Më pas: sistemi aplikon një zbritje prej 5%. Ky model eliminon paqartësinë sepse lidh qartë gjendjen dhe rezultatin e pritur.
Këshillë: Kur shkruani një histori përdoruesi në inteligjencën artificiale, sigurohuni që të thoni "gjeneroni të paktën 2 kritere pranimi në formatin Given/When/Then për secilën histori". Kur modeli detyrohet të prodhojë standarde, boshllëqet e fshehura në kërkesë bëhen të dukshme.
Hap pas hapi: Nxjerrja e kërkesave të asistuara nga AI
Hapi 1 - Mblidhni të dhëna të papërpunuara. Regjistrat e thirrjeve, emailet, pamjet ekzistuese të ekranit, listat e ankesave. Sa më shumë të dhëna reale, aq më pak fabrikim.
Hapi 2 - Ekstraktoni grupin e parë të tregimeve. Jepni të dhëna të papërpunuara inteligjencës artificiale dhe lëreni të prodhojë drafte të historive të përdoruesve. Ky hap nuk është një listë e plotë, por një hap i parë.
Hapi 3 - Shtoni kriteret e pranimit. Krijoni kritere të dhëna/Kur/Atëherë për secilën histori. Një histori për të cilën kriteret nuk mund të prodhohen në fakt do të thotë se nuk është e përcaktuar mjaftueshëm.
Hapi 4 - Skanimi për kontradikta dhe boshllëqe. Pyesni AI "a ka ndonjë kontradiktë, dyfishim, apo situata të papërcaktuara midis këtyre kërkesave?" Pyete dhe kontrolloje. Filtro rezultatin si njeri.
Hapi 5 - Prioritet dhe konfirmo. Jepini prioritet historive me palët e interesuara bazuar në vlerën e biznesit dhe urgjencën. Vendimi prioritar i takon njësisë së biznesit, jo UA.
Mos harroni kërkesat jofunksionale
Shumica e projekteve kanë vështirësi në terren sepse harrojnë ato jofunksionale duke shkruar kërkesat funksionale. Një raport mund të funksionojë "korrekt", por nëse duhen 45 sekonda për t'u hapur, askush nuk do ta përdorë atë. Tabela e mëposhtme tregon llojet e kërkesave jofunksionale të anashkaluara zakonisht dhe shembujt e matshëm të shkrimit.
Zhanri
shprehje e keqe
shprehje e matshme
Performanca
"Duhet të jetë i shpejtë"
"Përgjigja e pyetjes < 2 sek me ngarkesë mesatare"
aksesueshmërisë
"Të gjithë duhet të jenë në gjendje ta përdorin atë"
"Në përputhje me WCAG 2.1 AA; navigim i plotë me tastierë"
Siguria
"Duhet të jetë e sigurt"
"Të dhënat personale janë të koduara në pushim; qasja është e bazuar në role"
disponueshmëria
"Duhet të jetë e lehtë"
"Përdoruesi i ri plotëson porosinë në 3 hapa pa trajnim"
Disponueshmëria/vazhdimësia
"Nuk duhet të rrëzohet"
"Koha mujore ≥ 99,5%"
Tre Mini Rastet: Nga Numrat
Rasti 1 - Çmimi i një nevoje të pamatshme. Ekrani, i cili u zhvillua në një bankë me kërkesën që "ekrani i raportit të hapet shpejt", u hap në 22 sekonda nën ngarkesën në terren. Zhvilluesi mendoi se po jepte fjalën "shpejt" në mjedisin e tij (2 sekonda). Nëse kërkesa do të ishte shkruar si "< 3 sek në orën e pikut, xhiroja aktuale", problemi do të ishte kapur në testim. Rizhvillimi kushtoi 3 javë dhe kosto shtesë të matshme.
Rasti 2 - Hendeku i kapur nga kriteret e pranimit. Ndërsa shkruante kriteret e pranimit për tregimin "sistemi aplikon zbritje" në një projekt të tregtisë elektronike, palët e interesuara vuri re se çfarë do të ndodhte nëse zbritja binte ndesh me kuponin dhe zbritjen VIP nuk diskutohej fare. Një pyetje e vetme e dhënë/Kur/Atëherë parandaloi gabimin e zbritjes së dyfishtë përpara transmetimit të drejtpërdrejtë; Ky gabim shkaktoi humbje serioze të të ardhurave në projekte të ngjashme.
Rasti 3 - Rregulli i krijuar nga AI. Në një projekt HR, AI shtoi fjalinë "kërkesa për pushim miratohet automatikisht brenda 24 orëve" në draftin e kërkesave. Asnjë miratim i tillë automatik nuk u diskutua në takim; Modelja kishte krijuar një rregull që dukej "i arsyeshëm". Pranë çdo kërkese, eksperti shkruan "burimi: cila intervistë/dokument?" Duke shtuar kolonën, ai hoqi 4 fjali pa burim.
Prompt i dobët / Prompt i fortë
Njoftim i dobët:
Shkruani histori të përdoruesve për këtë projekt.
Njoftim i fuqishëm:
Roli juaj: Ju jeni një analist biznesi MIS. Nxjerrni historitë e përdoruesve nga shënimi i intervistës më poshtë. Rregullat:- Formati: "Si një [rol], për [qëllim], dua [veçori]."- Shkruani TË PAKTËN 2 kritere pranimi për secilën histori në formatin Given/When/Then.- Shtoni një "Burim" fjalia "Në cilën rregull" erdhi në çdo histori? kjo nuk është e qartë në shënim; përshtatje.- Shkruani kërkesat e matshme jofunksionale (performanca, siguria, aksesueshmëria) në një seksion të veçantë. Shënimi i intervistës:[tekst]
Prompt i fuqishëm zbaton formatin e tregimit, kriteret e pranimit, gjurmueshmërinë e burimit dhe kërkesat jofunksionale të gjitha menjëherë; Kjo e bën më të lehtë kontrollin e prodhimit.
Katër modele të kopjueshme
1) Sqarimi i kërkesave:
Rishikoni kërkesën më poshtë. Shënoni çdo deklaratë që është e paqartë, e pakrahasueshme ose e hapur për më shumë se një interpretim dhe shkruani një pyetje sqaruese për secilën. Mos e gjeni përgjigjen. Kërkesa: [tekst]
2) Skanimi i kontradiktave:
Në listën e kërkesave më poshtë, gjeni artikuj që kundërshtojnë njëra-tjetrën, janë të përsëritura ose lënë boshllëqe logjike. Raportoni çdo gjetje me numrat e artikujve dhe një justifikim me një fjali. Lista: [tekst]
3) Krijimi i kritereve të pranimit:
Shkruani të paktën 4 kritere pranimi për historinë e mëposhtme të përdoruesit në formatin Given/When/Then, duke përfshirë rastet kufi dhe përjashtime. Gjithashtu listoni çdo pikë që mbetet e paqartë. Historia: [tekst]
4) Skica e fushëveprimit:
Hartoni artikujt "Në fushëveprimi" dhe "Jashtë fushëveprimit" si një tabelë me dy kolona sipas kërkesave të mëposhtme. Etiketoni [KËRKOHET KONFIRMIM] për çdo artikull për të cilin nuk jeni të sigurt. Kërkesat: [tekst]
Gabimet e zakonshme
- Të mendosh se zgjidhja është një nevojë. "Shto një menu dropdown" është një zgjidhje, jo një kërkesë. Kërkesa thotë "përdoruesi duhet të jetë në gjendje të zgjedhë vendin nga lista e përcaktuar"; Ekipi i IT harton zgjidhjen.
- Duke anashkaluar ato jofunksionale. Thjesht të shkruajmë "çfarë të bëjmë" dhe të harrosh "si të jesh" (shpejtësia, siguria, aksesi) është zbrazëtia më e zakonshme dhe më e shtrenjtë.
- Përdorimi i mbiemrave të pamatshëm. Fjalët si "i shpejtë, i lehtë, i sigurt, i përshtatshëm për përdoruesit" janë të pavlefshme pa një prag.
- Duke mos vënë re rregullin që ka krijuar AI. Modeli mund të shtojë rregulla "të arsyeshme", por jo të shprehura në të vërtetë; Kërkoni burime për çdo nevojë.
- Duke i lënë prioritet AI. Çfarë duhet bërë së pari është një vendim për vlerën e biznesit; Njësia e biznesit e jep këtë.
Kujdes: Fjalia më e rrezikshme në analizën e kërkesave është "të gjithë tashmë e dinë këtë". Supozimet e pashprehura nuk futen në dokumentacion, kurrë nuk futen në kod dhe shfaqen në terren. Pyete AI "çfarë supozohet por nuk është shkruar në këtë kërkesë?" i bën të dukshme këto supozime të fshehura.
Në përmbledhje
Analiza e kërkesave përcakton se çfarë duhet të bëjë sistemi në mënyrë të qartë, të matshme dhe të gjurmueshme. Kërkesat funksionale përshkruajnë punën, kërkesat jofunksionale përshkruajnë cilësitë dhe kjo e fundit shpesh harrohet. Historia e përdoruesit dhe kriteret e pranimit të dhënë/Kur/pastaj janë mjete të fuqishme që eliminojnë pasigurinë. Inteligjenca artificiale përshpejton ndjeshëm prodhimin e tabelave, kriteret e pranimit, zbulimin e konflikteve dhe pyetjet sqaruese; Megjithatë, korrektësia e rregullit të biznesit, qëllimi dhe vendimi prioritar, dhe burimi i secilës fjali janë përgjegjësi e njeriut. Mos finalizoni asnjë kërkesë që është pa burim dhe të pamatshme.
Detyra e aplikimit
Shkruani një kërkesë biznesi me një paragraf për një "sistem takimesh në internet" imagjinar (p.sh., "Klientët duhet të jenë në gjendje të bëjnë takime në internet, stafi duhet të jetë në gjendje të shohë kalendarët"). (1) Krijo të paktën 5 histori përdoruesish dhe 2 kritere pranimi për secilin me një nxitje të fortë nga kjo kërkesë. (2) Gjeni të paktën 2 boshllëqe të fshehura në kriteret e prodhuara nga modeli (p.sh. takim i dyfishtë në të njëjtën kohë, rregulli i anulimit). (3) Përfshini të paktën 3 kërkesa jofunksionale në një formë të matshme. (4) Identifikoni të paktën 3 artikuj si "jashtë fushëveprimit". (5) Shënoni një rregull që modeli mund të ketë krijuar dhe shkruani se si do ta konfirmonit atë.
listë kontrolli
- [ ] Kam shkruar veçmas kërkesat funksionale dhe jofunksionale.
- [ ] Çdo kërkesë është e qartë, e matshme dhe e testueshme.
- [ ] Çdo histori ka kriteret e pranimit të dhëna/Kur/pastaj.
- [ ] Mund të gjurmoj burimin (bisedën/dokumentin) e çdo kërkese.
- [ ] Shënova rregullat e mundshme që kishte krijuar UA dhe i lashë për konfirmim.
- [ ] Përcaktimin e prioriteteve e bëra bashkë me njësinë e biznesit.