Predpogoj za dolgoročni uspeh katerega koli projekta je čim boljše zajetje uporabniških potreb in zapis le teh v funkcionalno specifikacijo. Brez te bomo težko merili uspešnost izvedbe, se pogajali z naročnikom in vzdrževali rešitev. Žal še vedno obstaja veliko ekip, ki ta korak preprosto izpusti in direktno skočijo na kodiranje. Izkušnje kažejo, da ni učinkovitejšega načrtovanja in modeliranja kot z uporabo naravnega opisa domene. Naravni jezik nam omogoča tudi hitrejše odpravljanje nelogičnosti že predenj pridemo do razvoja, kar je veliko cenejše. Med nami so tudi ekipe, ki specifikacijo zapišejo in je sama sebi namen, kajti je zapisana v obliki, da jo je nemogoče obvladovati in iz nje razbrati kaj sploh rešujemo naročniku, kaj šele “navodila” za izvedbo in verifikacijo. Take specifikacije so žal celo potrjene pri naročniku a obstanejo nekje na polici. Res je, da vsak projekt zahteva drugačen pristop in zato so tudi funkcionalne specifikacije v drugačnih oblikah, ampak naj bodo žive in naj odražajo dejansko potrebo in implementacijo. Cilj predavanja je predstaviti zakaj so funkcionalne specifikacije pomembne, kakšni so slabi in dobri primeri in navodila za pisanje specifikaciji. Predstavil bom več načinov pisanja specifikaciji, njihove prednosti in slabosti.

1. Nujnost odličnih
specifikacij in kako jih
zapisati
Miloš Cigoj
vodja kakovosti
Parsek d.o.o.

2. Kdo sem
QA Manager
17+ let v IT
Desk // Web // Mobile
@CigojMilos
Parsek d.o.o.
16+ let v IT
Enterprise solutions for HC,
Insurance, Telco etc.
@parseksolutions

4. Agenda
• značilnosti dobre zahteve
• najpogostejše napake
• tehnike pisanja
• orodja za upravljanje z zahtevami

6. Značilnosti dobre
zahteve

8. Najpogostejše napake

10. Opustitve
• pomembna dejstva povezana s problemsko
domeno niso del funkcijske specifikacije
• avtorji pogosto predpostavljajo, da so določene
informacije ali znanja samoumevna, zato jih ne
zapišejo

11. Dvoumnosti
• zapisana dejstva imajo več možnih interpretaciji
• negativni pogoji, robni primeri, sinonimi, zaimki,
okrajšave, prislovi

12. Neusklajenost
• zaheteva je neusklajena z drugimi zahtevami v
specifikacijah ali z drugimi dokumenti, ki opisujejo
problemsko domeno

13. Odvečnosti
• vsebina funkcijske specifikacije, ki se ne nanaša na
problemsko domeno ali pa ne prispeva k reševanju
problemske domene

14. Nepravilnosti
• nekatere zahteve so nepravilne glede na
problemsko domeno

15. Ne izvedljivost
• nekatere zahteve so ne izvedljive zaradi omejitev
sistema, okolja, človeških in ostalih virov, omejitev
tehnologije, …

16. Neprimerne omejitve
• zahteve osredotočene na kako ne pa na kaj naj
sistem počne so pogosto nepotrebne omejitve
• zahteve morajo praviloma definirati vidike, ki so
preverljivi od „zunaj“

17. Ne preverljivost
• posamezne zahteve morajo podpirati rešitev
konkretne potrebe uporabnika in zato morajo biti
preverljive
• zahteve brez pogojev sprejemljivosti oziroma z zelo
subjektivnimi pogoji vodijo v nepravilno izvedbo

18. Tehnike pisanja

19. ?
„esejski tip“
IEEE-***
Use Case
User Story

20. Zgodbe | Use Cases | Zahteve

21. Esejski tip
• prednosti
• prilagodljiv
• svoboden
• slabosti
• podvržen prav vsem težavam
• pozno odkrivanje napak v specifikaciji

22. 830-1998-IEEE Recommended Practice for SRS
• prednosti
• natančno definirana struktura
• slabosti
• dolgočasen
• zamegljeni cilji
• ne osredotočenost
• pozno odkrivanje napak

23. Use Cases
• prednosti
• zajem vseh scenarijev
• osredotočen na uporabnika
• dekompozicija
• ojačujejo identifikacijo
potreb
• slabosti
• formaliziran -> omejitve
• pozno odkrivanje napak
• nerazumljiv deležnikom

24. User Story
• prednosti
• hitrejše odkrivanje težav v zahtevi
• interdisciplinarno pisanje
• Prioritizacija & fleksibilnost & planiranje
• osredotočena na uporabniški vidik
• slabosti
• obvezno sodelovanje naročnika ->dvoumnosti
• ne definiran standard uporabnosti

25. Zakaj Gherkin?
Ker
• smo pripravljeni za avtomatizacijo testiranja
• nas sili v konsistentnost pri pisanju
• testni primeri razumljivi in dosegljivi uporabniku
• "single source of truth"

26. Primer
Feature: Adminsitrator want sot do something
Some terse yet descriptive text of what is desired
In order to realize a named business value
As an explicit system actor
I want to gain some beneficial outcome so that I can reach the goal
Background:
Given a global administrator named "Greg"
And a blog named "Greg's anti-tax rants"
And a customer named "Wilson"
And a blog named "Expensive Therapy" owned by "Wilson"
Scenario: Wilson posts to his own blog
Given I am logged in as Wilson
When I try to post to "Expensive Therapy"
Then I should see "Your article was published."
Scenario: Greg posts to a client's blog
Given I am logged in as Greg
When I try to post to "Expensive Therapy"
Then I should see "Your article was published."

27. Orodja

28. Orodja
Visual Studio Online
JIRA & Confluence
SpecLog
IBM Rational DOORS ipd
WORD/Excel

29. Pregled značilnosti orodji
Epic/Story/Task
metapodatki
Epic/Story/Task
Metapodatki
Epic/Story
metapodatki
Use Case
metapodatki

30. POVZETEK
značilnosti dobre zahteve
tehnike
orodja

31. Izpolnite anketo!
Vam je bilo predavanje všeč?
Ste se naučili kaj novega?
Vaše mnenje nam veliko pomeni!
Da bo NT konferenca prihodnje leto še boljša, vas
prosimo, da izpolnite anketo o zadovoljstvu, ki jo
najdete v svojem NTK spletnem profilu.
Please also see this short survey about new MSDN:
https://aka.ms/ntkdocssurvey