STROKOVNI PRISPEVKI B Dokumentiranje zahtev pri razvoju mobilnih aplikacij Tina Schweighofen Marjan Heričko Univerza v Mariboru, Fakulteta za elektrotehniko, računalništvo in informatiko, Smetanova 17, 2000 Maribor tina.schweighofer@um.si; marjan.hericko@um.si Izvleček Pravilno zastavljene in dobro oblikovane zahteve so eden izmed pomembnejših gradnikov uspeha projekta. Pomembno je, da se zbiranja in kasnejšega zapisa lotimo sistematično ter v skladu s priporočili in dobrimi praksami. Izjema ni niti razvoj aplikacij za mobilne telefone. Kljub temu da gre za razmeroma sodoben programski produkt, velja enako - dobre zahteve so ključ do uspeha. V okviru zbiranja zahtev je treba dovolj časa posvetiti oblikovanju specifikacije zahtev programske opreme (SZPO). Pri izdelavi dokumenta SZPO za mobilno aplikacijo v razvoju hitro ugotovimo, da bi bilo treba prilagoditi posamezna poglavja ali pa celo dodati nova glede na obstoječe dobre prakse. V prispevku podrobneje predstavljamo proces oblikovanja dokumenta SZPO za mobilne aplikacije in njegovo priporočeno strukturo. Pregledali in analizirali bomo splošna priporočila za izdelavo dokumentov SZPO, jih dopolnili s pregledom literature in analizo praktičnih primerov dokumentov SZPO za mobilne aplikacije. Vse skupaj bomo nadgradili z izkušnjami, pridobljenimi v okviru aktualnega projekta razvoja mobilnih aplikacij. Na podlagi zbranih podatkov bomo predstavili posamezna dodatna poglavja in dopolnitve, specifične za mobilne aplikacije, ter izpostavili lastnosti mobilnih naprav in tehnologij, na katere moramo biti pozorni. Vse ugotovitve bomo povzeli ter jih v sklepu predstavili v obliki priporočil in dobrih praks za izdelavo dokumenta SZPO za mobilne aplikacije. Ključne besede: specifikacije zahtev programske opreme (SZPO), mobilne aplikacije, mobilne tehnologije, IEEE 830, ISO/IEC/IEEE 29148. Abstract Documenting the Requirements for Mobile Applications Development Project success greatly depends on well-formed requirements. Therefore it is important to collect and record software requirements systematically, according to given recommendations and best practices. Requirements engineering is also an important part of mobile applications development. It is very important to devote enough time to the creation of the Software Requirements Specification (SRS) document. When constructing the SRS document for a mobile application several challenges have to be dealt with. We soon realize that existing recommendations are not enough and that we need some changes and updates. In this paper we present the process of creating an SRS document for a mobile application in development and its proposed structure. We focus on additional sections and the supplementation of existing sections for the document. Next, we review general recommendations for writing SRS documents which we extend with a review of literature and practical examples of SRS documents for mobile applications. Finally, we present experiences gained in the process of a mobile application development project. Based on collected data we present some additional chapters and amendments to the SRS document for mobile applications. All findings are summarized in the conclusion in the form of recommendations and best practices for writing SRS documents for mobile applications. Key words: software requirements specification (SRS), mobile application, mobile environment, IEEE 830, ISO/IEC/IEEE 29148. 1 UVOD Že začetni koraki pri razvoju mobilnih aplikacij imajo pomemben vpliv tako na nadaljnji razvoj kot tudi na kasnejšo uspešnost aplikacije na trgu. Poleg vseh izzivov, s katerimi se spopadamo ob razvoju, je pomembno, da mobilno aplikacijo izoblikujemo tako, da izpolni pričakovanja naročnika. Do tega nas v veliki meri pripelje primerno in ustrezno zbiranje zahtev. Korak zbiranja zahtev je v življenjskem ciklu produkta zelo pomemben. Je namreč eden izmed najbolj zahtevnih delov razvoja pro- gramskega produkta (Hofmann & Lehner, 2001; Kamaruddin, Yusop & Ali, 2011). Neustrezne zahteve lahko pripeljejo do številnih posledic: podpora napačnim funkcionalnostim, nedo-seganje tržnih potreb, zamujanje ter številni hrošči, napake, pomanjkljivosti in nepravilnosti v produktu (Maccari, 1999). Pomanjkljive zahteve so tako lahko eden izmed pomembnih vzrokov neuspeha projekta, ki lahko sega od nenadnega zvišanja stroškov pa vse do propa- da projekta (Belfo, 2012; Giakoumakis & Xylomenos, 1996). Povedano drugače, pravilno zbiranje, oblikovanje in zapis zahtev so med najpomembnejšimi in zahtevnejšimi nalogami v okviru projekta v razvoju (Hofmann & Lehner, 2001). Končni produkt zbiranja zahtev je običajno zah-tevnik oziroma dokument specifikacija zahtev programske opreme (SZPO). Ta je eden izmed temeljev nadaljnjega razvoja programskega produkta tudi v okviru razvoja mobilnih aplikacij. Dobro oblikovan SZPO projektu prinese številne prednosti, kot npr. vzpostavitev temeljev dogovora med naročnikom in izvajalcem z vidika zahtev sistema, služi lahko kot podlaga za oceno truda in stroškov, ponuja pa tudi podlago za preverjanje ter za nadaljnje izboljšave razvojnega produkta (IEEE Recommended Practice for Software Requirements Specifications, 1998). Priporočila za izdelavo dokumenta SZPO so izdale številne organizacije, oblikovani pa so bili tudi posamezni standardi, ki podpirajo izdana priporočila posameznih organizacij (Giakoumakis & Xylomenos, 1996). Med množico organizacij zagotovo najbolj izstopa IEEE, kjer so svoja priporočila zbrali v standardu IEEE 830,1 ki je danes del širšega standarda ISO/IEC/IEEE 29148.2 Standard opisuje vsebino in lastnosti dokumenta SZPO, predstavljeni pa so tudi posamezni praktični primeri dokumentov specifikacij zahtev. Poudariti je treba, da se omenjena priporočila osredinjajo predvsem na splošni vidik izdelave dokumenta. Pri tem avtorjem dajejo napotke glede oblike in strukture, podajajo pa tudi pričakovane lastnosti dobro oblikovanega dokumenta SZPO. Če priporočila uporabimo kot primer dobre prakse pri izdelavi dokumenta SZPO za mobilne aplikacije, kar kmalu zaznamo potrebo po dodatnih podatkih in definicijah v okviru dokumenta. Mobilne aplikacije se namreč v marsičem razlikujejo od tradicionalne programske opreme in pomembno je, da to upoštevamo tudi pri njihovem razvoju. Razlike so tako vidne že pri določanju zahtev, to pa se odraža tudi pri izdelavi SZPO. Izkaže se, da SZPO za mobilne aplikacije potrebuje nekatera dodatna poglavja in zahteve, vezane na specifično delovanje in funkcionalnosti mobilnih telefonov in aplikacij. V prispevku bomo tako raziskali, katere postavke, poglavja in zahteve se razlikujejo v okviru dokumentiranja 1 IEEE Recommended Practice for Software Requirements Specifications 2 Systems and software engineering - Life cycle processes - Requirements engineering zahtev za mobilne aplikacije. S pomočjo literature in praktičnih izkušenj bomo identificirali posamezna poglavja dokumenta SZPO za mobilne aplikacije, ki se razlikujejo od dokumenta SZPO za tradicionalno programsko opremo. Ugotoviti želimo, katera poglavja je dokumentu smiselno dodati ter katera dopolniti, prav tako pa izpostaviti informacije in postavke, ki so bistvene za uspešen nadaljnji razvoj mobilne aplikacije. V drugem razdelku prispevka bomo predstavili sorodna dela, obravnavana v okviru pregleda literature z obravnavanega področja. Sledil bo povzetek trenutnih trendov s področja mobilnih tehnologij, mobilnih telefonov ter mobilnih aplikacij. V četrtem razdelku bomo povzeli dobre prakse oblikovanja strukture dokumenta ter splošne lastnosti, povezane z dokumentom. V istem razdelku bomo predstavili tudi priporočila za prilagoditve dokumenta SZPO za mobilne aplikacije. Najprej bomo predstavili lastnosti mobilnih tehnologij in telefonov, ki imajo vpliv na dokument SZPO. Sledil bo povzetek rezultatov pregleda literature in praktičnih primerov dokumentov SZPO za mobilne aplikacije. Vse skupaj bomo dopolnili s prikazom praktičnih izkušenj pri izdelavi dokumenta SZPO za mobilne aplikacije v razvoju. Prispevek bomo sklenili s povzetkom ugotovitev in predlogom pomembnih dodatnih informacij, ki jih je po naših izkušnjah smiselno vključiti v zapis specifikacij zahtev za mobilne aplikacije. 2 SORODNA DELA S področjem dokumentiranja zahtev in njihovim zapisom v dokument specifikacija zahtev za programsko opremo so se ukvarjali že številni avtorji. Na tem področju obstajajo številna uveljavljena priporočila in dobre prakse, med katerimi so nekatere prerasle tudi v standarde. Najbolj uveljavljen standard na tem področju je zagotovo IEEE 830 (IEEE Recommended Practice for Software Requirements Specifications, 1998), ki je danes del obsežnejšega standarda ISO/ IEC/IEEE 29148 (Systems and software engineering - Life cycle processes - Requirements engineering, 2011), ki so ga pripravile organizacije ISO/IEC s sodelovanjem z IEEE. Pomembno podlago na področju razvoja programske opreme in dokumentiranja procesa so postavili tudi na oddelku za obrambo Združenih držav Amerike. Trenutno aktualni standard MIL-STD-498 (Software development and documentation, DoD Military Standard MIL-STD-498, 1994) priporočila in navodila predstavlja v okviru dokumenta DI-IPSC-81433 (Software requirements specification DID, DoD Military Standard DI-IP-SC-81433, 1994). Poleg omenjenih standardov so priporočila in navodila izdale tudi nekatere druge organizacije, npr. NASA in ESA (ESA Board for Software Standardisation and Control, 1991; NASA, 2009), ki s svojimi navodili pripomoreta tako k zbiranju zahtev, kot tudi k zapisu le-teh v dokument SZPO. Vse omenjene dokumente so pri svojih raziskavah uporabili avtorji, ki so se ukvarjali z vplivi uspešnega procesa zbiranja zahtev na nadaljnje korake (Hammer, Huffman, & Rosenberg, 1998; Hofmann & Lehner, 2001) in kakovost dokumentov SZPO (Belfo, 2012; Boehm, 1984; Davis idr., 1993). Omenjeni standardi so bili tudi pregledani z namenom ovrednotenja glede na merila za namen uporabe. Avtorji dela so izbrane standarde ovrednotili glede na osem izbranih meril: neodvisnost, integracija, natančnost, splošnost, organiziranost, vsebinska popolnost, popolnost vidikov in prilagodljivost. Na podlagi podeljenih vrednosti za omenjena merila sodelujočim pri izdelavi dokumenta SZPO ponujajo hiter vpogled v lastnosti posameznega standarda. S tem pa jim na preprost način pomagajo pri odločitvi, kateri izmed standardov je najbolj primeren za izdelavo dokumenta SZPO za njihov produkt (Giakoumakis & Xylomenos, 1996). S pojavom mobilnih aplikacij so postale aktualne študije povezane z izdelavo dokumenta SZPO za mobilne aplikacije. V svojem delu avtorji Economou, Gavalas, Kenteris in Tsekouras (2008) ugotavljajo, katere so zahteve za mobilne aplikacije, ki jih je treba upoštevati pri razvoju in posledično tudi v dokumentu SZPO. Kot navajajo, moramo v dokumentu SZPO biti pozorni na mobilni kontekst, produkt načrtovati za namen prenosljivosti ter upoštevati širok spekter znanj in izkušenj uporabnikov. Izpostavljajo še omejene vire mobilnih telefonov, vhodne teh izhodne poti in zbiranje informacij s pomočjo senzorjev, ki se nahajajo na mobilnih telefonih. Podobno se z zahtevami za konkretno definirano domeno ukvarjajo v še enem delu (Doherty, McKnight & Luz, 2010), v katerem so se avtorji osredinili na zahteve za mobilne zdravstvene aplikacije. Iz obstoječih ogrodij s področja zdravstva so sestavili skupno ogrodje, katerega namen je identifikacija in analiza zahtev za mobilni produkt. Podobno so se z ogrodjem za zbiranje zahtev za aplikacije, a za drugačno domeno, ukvarjali tudi v sorodnem delu (Finkelstein & Savi- gni, 2001). Omejili so se na aplikacije, ki zaznavajo kontekst, ter na zajemanje zahtev na tem področju. Kot navajajo, je zajemanje zahtev zelo kompleksno in zahtevno delo, tudi zaradi značilnosti mobilnih telefonov. Posamezna dela se ukvarjajo tudi s pristopi identifikacije zahtev v pripadajočem procesu in izdelavo dokumenta SZPO za mobilne aplikacije. Avtorji Gil, Andersson, Milrad in Sollervall (2012) predlagajo pristop identifikacije s pomočjo evolucijskega procesa. Čeprav delujejo v domeni mobilnega učenja, navajajo, da bi lahko tehniko uporabili tudi v drugih domenah. Avtorji Kamaruddin idr. (2011) pa za namen analize zahtev za mobilno domeno predlagajo uporabo teorije aktivnosti. Na področju mobilnih aplikacij so zelo razširjene mobilne igre. Tako so se raziskave s področja dokumentiranja in zapisa zahtev pojavile tudi na tem področju. Kot npr. predstavljajo avtorji Salazar, Mitre, Olalde in Sanchez (2012), se tudi v domeni mobilnih iger pojavljajo številni izzivi. V okviru domene mobilnih iger igra ključno vlogo dokument GDD,3 ki je po značilnostih zelo podoben dokumentu SZPO. V bistvu gre za dokument SZPO, ki podpira razvoj mobilnih iger. V delu so poiskali in ovrednotili posamezne omenjene dokumente ter jih izboljšali glede na izbrana priporočila za dokumente SZPO. Posameznih del, ki bi izključno podajala priporočila in dobre prakse pri izdelavi dokumenta SZPO za mobilne aplikacije, pri pregledu digitalnih knjižnic ter na spletu nismo zasledili. Tako smo se kot logično nadaljevanje v naslednjem koraku lotili preučevanja dostopnih praktičnih primerov dokumentov SZPO za mobilne aplikacije. Na svetovnem spletu je teh na voljo veliko, podrobnejšo analizo primerov pa predstavljamo v nadaljevanju v razdelku o prilagoditvah dokumentov SZPO za mobilne aplikacije. 3 MOBILNE TEHNOLOGIJE Število mobilnih telefonov z vsakim letom strmo narašča. Po podatkih analitične hiše Gartner je bilo samo v tretji četrtini leta 2012 prodanih skoraj 428 milijonov mobilnih telefonov. Znotraj te številke pametni mobilni telefoni predstavljajo skoraj 40 odstotkov (Gartner, 2012). Podobno se dogaja tudi na področju mobilnih naročniških razmerij. Konec leta 2012 je bilo na svetu aktivnih okoli 6,8 milijarde mo- 3 Game Design Document bilnih naročniških razmerij. To pomeni, da je bilo v aktivnem naročniškem razmerju kar 96 odstotkov svetovne populacije. Trenutno je stopnja prodora mobilnih naročniških razmerij v svetovnem merilu 96 odstotkov, če se osredinimo samo na Evropo, pa znaša kar 126 odstotkov (ITU, 2013). Številke bodo še naraščale. Do leta 2016 naj bi bilo na svetu kar osem milijard mobilnih naročniških razmerij (MobiThin-king, 2012; Portio Research, 2012). S številom mobilnih telefonov narašča tudi število mobilnih aplikacij. Eden pomembnejših mejnikov na tem področju je bil dosežen decembra 2011, ko je število mobilnih aplikacij, ki so dostopne uporabnikom, preseglo milijon (The New York Times, 2011). Konec leta 2012 je mobilne aplikacije uporabljalo okoli 1,1 milijona mobilnih uporabnikov. Po napovedih bo številka hitro naraščala, za skoraj 30 odstotkov letno, in bo tako konec leta 2017 znašala 4,4 milijona uporabnikov (Whitfield, 2013). Mobilne aplikacije so leta 2012 prinesle okoli 12 milijard dolarjev prihodkov, prenesenih pa je bilo okoli 46 milijard mobilnih aplikacij (Portio Research, 2012). Tudi na tem področju lahko pričakujemo hitro rast. Leta 2013 naj bi uporabniki prenesli še dodatnih 82 milijard mobilnih aplikacij (Whitfield, 2013). 4 SPECIFIKACIJE ZAHTEV PROGRAMSKE OPREME Z vse večjo prisotnostjo mobilnih aplikacij postaja vse pomembnejši proces njihovega razvoja v okviru življenjskega cikla mobilne aplikacije. Eden od prvih korakov pri razvoju le-teh je - podobno kot pri razvoju tradicionalne programske opreme - zbiranje in dokumentiranje zahtev za produkt. Končni produkt omenjenega koraka je dokument specifikacija zahtev programske opreme (SZPO). Dokument SZPO je zaradi svojih značilnosti in namena izjemno pomemben gradnik pri razvoju programske opreme, bodisi tradicionalne ali mobilne. V okviru razvojnega cikla izstopajo specifikacije zahtev kot zelo pomembna in ključna postavka (Giakoumakis & Xylomenos, 1996). Kot pravi definicija slovarja IEEE, dokumentacija SZPO združuje bistvene zahteve, funkcionalnosti, zmogljivosti, oblikovne omejitve in atribute programskega produkta ter njegovih zunanjih vmesnikov (IEEE Standard Glossary of Software Engineering Terminology, 1990). Dokument SZPO združuje specifikacije posameznega programskega produkta, programa ali skupine programov, ki izvajajo funkcije v okviru specifičnega okolja. Pri oblikovanju do- kumenta lahko sodeluje eden ali več predstavnikov proizvajalca, eden ali več predstavnikov naročnika, ali pa dokument nastane s sodelovanjem obeh strani (IEEE Recommended Practice for Software Requirements Specifications, 1998). Izdelava dokumenta SZPO je del procesa zbiranja zahtev oziroma inženiringa zahtev programske opreme. Omenjeni proces so v izolaciji ali kot del celotnega življenjskega cikla opisovale številne organizacije (Giakoumakis & Xylomenos, 1996). Izdale so tudi različna priporočila, navodila ali celo ogrodja, s pomočjo katerih razvijalcem programske opreme in udeležencem procesa zbiranja zahtev ponujajo številne predloge in dobre prakse. Omenimo nekaj primerov od najbolj splošnega do bolj podrobnega. Navodila in priporočila za oblikovanje dokumenta SZPO lahko najdemo v okviru opisa procesa zbiranja zahtev, opisanega znotraj celotnega življenjskega cikla programske opreme. To prikazujeta npr. IBM Rational Unified Process (RUP) (Rational, 1998) in standard, ki ga je objavila organizacija ESA (ESA Board for Software Standardisation and Control, 1991). Nekoliko nižje ravni - le opisa procesa zbiranja zahtev - so se lotili pri organizaciji NASA (NASA, 2009). Najbolj podrobno so se s samim dokumentom SZPO ukvarjali pri IEEE in US DoD4 (IEEE Computer Society, 1998; Software requirements specification DID, DoD Military Standard DI-IPSC-81433, 1994). S tem, kako izdelati dokument SZPO, da bo ta primerna in trdna podlaga za nadaljnji razvoj, se je ukvarjalo že veliko avtorjev. Prav vsi so poudarili pomen inženiringa zahtev. Kot navajata avtorja Gia-koumakis in Xylomenos, viri, ki opisujejo dokument SZPO, spadajo nekam med strogo definicijo dokumenta in priporočila ter navodila za izdelavo. Priporočila in standardi so navadno oblikovani na način, ki podaja okvirno obliko dokumenta skupaj s pojasnili, kako zapisati posamezne vrste zahtev. Prilagodljivost vsebine se spreminja od standarda do standarda in od priporočila do priporočila. Avtorji navadno dodajajo, da gre le za priporočila, ki si jih vsak lahko prilagodi glede na svoje potrebe. Z uporabo dokumentacijskega standarda pri izdelavi dokumenta SZPO lahko avtorji povečajo svojo učinkovitost, tako da sledijo znanim orisom. Pomagajo si lahko tudi z uporabo seznama zahtev ter seznama elementov, ki naj bi bila del dokumenta v izdelavi (Giakoumakis & Xylomenos, 1996). 4 United States Department of Defense Tako sta korak zbiranja zahtev kot tudi njihov zapis v okviru dokumenta SZPO zahtevna naloga. Pomembno je, da se ne glede na tip produkta, ki ga razvijamo, držimo nekaterih ustaljenih standardov in smernic. Nekatere od njih, ki so po našem mnenju pomembni tudi za dokumente SZPO mobilnih aplikacij, bomo predstavili v nadaljevanju. Dokument SZPO je prvi dokument, ki podrobno opisuje programski produkt v razvoju. Zato je uporabljen v vseh nadaljnjih aktivnostih in predstavlja uporabniške potrebe, zahteve za implementacijo ter kasnejšo točko za preverjanje (Giakoumakis & Xy-lomenos, 1996). Za ustrezno oblikovan dokument specifikacije zahtev programske opreme je priporočljivo, da avtorji naslovijo nekaj ključnih vprašanj, vezanih na posamezna področja razvoja (IEEE Recommended Practice for Software Requirements Specifications, 1998): ■ funkcionalnosti (kaj naj bi izdelek delal), ■ zunanji vmesniki (kako bo produkt sodeloval z uporabniki, s sistemsko in drugo strojno opremo ter z drugo programsko opremo), ■ zmogljivost (kakšna je zahtevana hitrost, zaželena razpoložljivost ter pričakovani odzivni čas in čas obnovitve posameznih funkcij produkta), ■ atributi (kako so upoštevani vidiki prenosljivosti, pravilnosti, vzdrževanja in varnosti), ■ vpliv načrtovalnih omejitev na implementacijo (ali obstajajo kakšne omejitve, povezane s potrebnimi standardi, programskim jezikom, pravili, viri ali operacijskim okoljem, ki vplivajo na implementacijo). 4.1 Značilnosti dobrega SZPO Priporočljivo je, da ustrezen dokument specifikacij zahtev programske opreme ustreza posameznim lastnostim, ki so predstavljene na sliki 1 (Belfo, 2012; Davis idr., 1993; ESA Board for Software Standardisation and Control, 1991; Hammer idr., 1998; IEEE Recommended Practice for Software Requirements Specifications, 1998; Software requirements specification DID, DoD Military Standard DI-IPSC-81433, 1994). Slika 1: Lastnosti dokumenta SZPO Dokument specifikacij mora ustrezati lastnosti pravilnosti. Produkt v razvoju naj bi upošteval vsako zahtevo, navedeno v dokumentu SZPO. Napisan mora biti nedvoumno, tako da ima lahko ena podana zahteva samo eno možno interpretacijo. Ker je dokument SZPO pomemben skozi ves življenjski cikel programskega produkta - od analize in načrtovanja pa vse do preverjanja, testiranja in usposabljanja -, je pomembno, da je napisan nedvoumno in razumljivo za vse potencialne uporabnike, ne le za avtorje dokumenta. Če se srečamo s primerom, pri katerem je mogoča razlaga na več načinov, je treba zahtevo dodatno definirati in izraze, ki imajo dvoumen pomen, posebej razložiti v slovarju dokumenta. Pogosto se zgodi, da uporabniki SZPO nimajo enakega predznanja, zato je pomembno, da so specifikacije zapisane v naravnem jeziku. Naslednja lastnost, ki jo mora izpolnjevati dober SZPO, je popolnost dokumenta. Dokument je popoln, kadar vsebuje vse pomembne zahteve, ki se nanašajo na funkcionalnosti, zmogljivosti, oblikovne omejitve ali zunanje vmesnike, definicije odgovorov produkta na vse identi- ficirane vhodne podatke vseh situacij, označbe vseh tabel, slik ter diagramov ter definicije vseh izrazov in merskih enot. Če je kje v okviru dokumenta uporabljena oznaka »potrebno definirati«,5 potem v večini primerov SZPO ni popoln. Pojavi pa se lahko situacija, pri kateri je mogoče tudi v popolnem dokumentu SZPO uporabiti oznako »potrebno definirati«. V tem primeru mora biti oznaka opremljena z opisom stanja, ki je pripeljal do nedefiniranosti, in dopolnilom, ki pojasnjuje postopek definiranja zahteve, kdo je odgovoren ter pripadajoči časovni rok za definiranje (Belfo, 2012; IEEE Recommended Practice for Software Requirements Specifications, 1998). Priporočljivo je, da je SZPO notranje konsistenten, kar pomeni, da zahteve, zapisane v dokumentu, med seboj niso nasprotujoče. Pogosto prihaja do konfliktov pri opredelitvi karakteristik objektov iz realnega okolja. Do logičnih ali začasnih konfliktov prihaja tudi pri definiranju akcij. Tako lahko pride do primera, da dve ali več zahtev opisujejo enak objekt iz realnega okolja, a zanj uporabljajo različne izraze. Te lahko razrešimo z uporabo standardne terminologije in definicij. Dokument SZPO zadošča lastnosti razvrstitve glede na pomembnost in/ali stabilnost, če ima vsaka zahteva identifikator, ki ustrezno označuje pomembnost oziroma stabilnost zahteve. Tipično vse zahteve v dokumentu niso enako pomembne. Zahteve lahko na podlagi pomembnosti v grobem razdelimo na bistvene, pogojne in opcijske. Dokument SZPO ustreza lastnosti preverljivosti, če je preverljiva vsaka zahteva, zapisana v dokumentu. Zahteve veljajo za preverljive, če obstaja proces, s katerim lahko oseba oziroma naprava preveri, ali produkt izpolnjuje posamezno zahtevo. Če lastnost povežemo z lastnostjo nedvoumnosti, v splošnem velja, da vsaka zahteva, ki je dvoumna, ni preverljiva (Belfo, 2012; IEEE Recommended Practice for Software Requirements Specifications, 1998). SZPO zadošča lastnosti spremenljivosti, če sta struktura in stil dokumenta takšni, da lahko vsako spremembo zahtev izvedemo enostavno in konsistentno. Pri tem se ohranita struktura in stil dokumenta. Dokument je lažje spremenljiv, če ima SZPO usklajeno in enostavno strukturo s kazalom, se izogiba redundanci in ima zahteve predstavljene ločeno od drugih. Zadnja izmed lastnosti dobrega SZPO 5 TBD - »to be determined« 2014 - številka 3 - letnik XXII je sledljivost. Dokument je sledljiv, če je izvor vsake zahteve jasen in omogoča sklicevanje vsake zahteve v nadaljnjem razvoju. Priporoča se sledljivost nazaj, kar pomeni sledljivost do prejšnjih korakov v razvoju, in sledljivost naprej, kar pomeni sledljivost do vseh dokumentov, ustvarjenih na podlagi SZPO (Belfo, 2012; IEEE Recommended Practice for Software Requirements Specifications, 1998). 4.2 Struktura dokumenta SZPO Struktura dokumenta specifikacije zahtev programske opreme je bila že natančno raziskana in preučena ter opisana v številnih delih. Okvirna poglavja v svojih priporočilih in standardih predlagajo posamezne organizacije, ki se ukvarjajo s vsebino dokumenta SZPO (ESA Board for Software Standardisation and Control, 1991; IEEE Recommended Practice for Software Requirements Specifications, 1998; Software requirements specification DID, DoD Military Standard DI-IPSC-81433, 1994; NASA, 2009). Kljub vsem priporočilom in navodilom pa struktura dokumenta ni natančno predpisana in s tem strogo začrtana. Dokument si tako lahko vsak oblikuje glede na svoje želje in potrebe, pri čemer je pomembno, da je dokument zasnovan tako, da je bralcem v pomoč in ne v oviro. Kljub omenjeni svobodi je pri izdelavi dokumenta SZPO priporočljivo upoštevati posamezne standarde, priporočila in dobre prakse. Te avtorjem ponujajo številna praktična priporočila, nasvete in predloge strukture dokumenta SZPO. Dodajajo tudi sezname konkretnih poglavij, za katera je priporočljivo, da jih vsebuje dobro oblikovan dokument SZPO. V rokah avtorjev tako ostane predvsem oblika in struktura posameznih podpoglavij, prav tako pa tudi predstavitev in oblikovanje posameznih zahtev. Te lahko avtorji predstavijo s pomočjo besedila, grafične podobe ali kako drugače, primerno vsebini (NASA, 2009). Med pregledom literature smo identificirali tri vire, ki natančneje prikazujejo predlagano vsebino dokumenta SZPO v obliki poglavij in podpoglavij. Prvi je nastal v okviru organizacije NASA (NASA, 2009), drugi v okviru organizacije US DoD (Software requirements specification DID, DoD Military Standard DI-IPSC-81433, 1994), tretji pa v okviru organizacije IEEE (IEEE Recommended Practice for Software Requirements Specifications, 1998). Če primerjamo pregledana priporočila, ugotovimo, da vključu- jejo podobna poglavja z razliko pri razporeditvi glavnih poglavij. Vsi predlagajo, da naj bo v dokumentu osrednje poglavje namenjeno zahtevam ter naj vsebuje podpoglavja, oblikovana glede na vrsto zahtev. Vsi predlagajo še vključitev splošnih informacij ter splošen opis dokumenta. Glede na pregledano literaturo smo ugotovili, da večina avtorjev, med drugimi tudi standard za programsko inže-nirstvo ESA, kot referenco za izdelavo dokumenta SZPO uporablja standard IEEE (Belfo, 2012; Davis idr., 1993; ESA Board for Software Standardisation and Control, 1991). Tako smo se odločili, da predstavimo strukturo dokumenta, ki ga predstavlja organizacija IEEE. V dokumentu natančneje opisujejo priporočene prakse, navodila in predloge za izdelavo dokumenta specifikacije zahtev programske opreme. Prva verzija dokumenta je bila izdana leta 1984, danes pa IEEE 830 vključuje standard ISO/IEC/IEEE 29148 (Systems and software engineering - Life cycle processes - Requirements engineering, 2011). Omenjeni standard opisuje inženiring zahtev v okviru življenjskega cikla in tako vključuje tudi poglavje o oblikovanju in sestavi dokumenta SZPO. Standard IEEE je zelo vpliven Slika 2: Primer strukture poglavij dokumenta SZPO po priporočilih IEEE (IEEE Recommended Practice for Software Requirements Specifications, 1998) na omenjenem področju, saj gre za zapise neodvisne organizacije, ki želi pokriti čim več možnih področij in domen, prav tako pa gre za zelo berljiv, jedrnat in razumljiv dokument (Giakoumakis & Xylomenos, 1996). Slika 2 prikazuje okvirno strukturo dokumenta SZPO glede na priporočila organizacije IEEE. Sama struktura ni prilagojena mobilnim aplikacijam, temveč gre za splošno oblikovana priporočila ter navodila. Glede na pridobljene izkušnje lahko trdimo, da se dokument SZPO za mobilne aplikacije razlikuje od dokumenta SZPO za tradicionalne programske produkte. Razlike se pojavijo predvsem pri poglavju Specifične zahteve. Zaradi tega se bomo osredinili predvsem na strukturo omenjenega poglavja. Poglavje o specifičnih zahtevah prikazuje zahteve za produkt, razgrajene do stopnje, ki omogoča razvijalcem načrtovanje produkta z določenimi lastnostmi, prav tako pa ponuja temelje testerjem, da produkt lahko preizkusijo glede na zapisane lastnosti. Navadno je v okviru dokumenta definiranih več skupin zahtev, osredinjenih na zunanje vmesnike, funkcionalnosti, zmogljivosti, logične zahteve podatkovne baze, oblikovne omejitve in sistemske atribute. Pri tem so v okviru specifikacij zunanjih vmesnikov predstavljeni podrobni opisi vseh vhodov v produkt in izhodov iz produkta. Funkcionalne zahteve definirajo akcije, ki jih izvaja produkt, zahteve zmogljivosti pa specificirajo dinamične in statične numerične zahteve v povezavi s produktom ter pri sodelovanju uporabnika s produktom. Logične zahteve podatkovne baze specificirajo logične zahteve za vse informacije, ki se hranijo v podatkovni bazi. V okviru specifičnih zahtev so navedene tudi oblikovne omejitve, ki so lahko posledica splošno sprejetih standardov oziroma dobrih praks ali pa posledica notranje oblikovanih stilnih vodičev. Med omejitve spadajo tudi omejitve strojne in programske opreme ter drugih virov, povezanih z mobilnimi telefoni. Zadnji so med specifičnimi zahtevami navedeni tudi sistemski atributi, med katere spadajo zahteve, povezane z zanesljivostjo, razpoložljivostjo, varnostjo, vzdrževanjem in prenosljivostjo (IEEE Recommended Practice for Software Requirements Specifications, 1998; Systems and software engineering - Life cycle processes - Requirements engineering, 2011). Za vsak nekoliko zahtevnejši in obsežnejši produkt bo seznam zahtev zelo dolg in obsežen. V ta namen je priporočeno, da se zahteve po temeljitem UVOD Namen Obseg Definicije, akronimi in okrajšave Reference Pregled SPLOŠEN OPIS Perspektiva produkta Funkcije produkta Karakteristike uporabnikov Omejitve Predpostavke in odvisnosti SPECIFIČNE ZAHTEVE Zunanji vmesniki Funkcionalne zahteve Zmogljivostne zahteve Logične zahteve PB Oblikovne omejitve Atributi sistemske programske opreme PRILOGE KAZALA razmisleku organizirajo in razporedijo v kategorije, ki so najbolj smiselne in preproste za razumevanje. Ne obstaja namreč razdelitev, ki bi globalno ustrezala vsem sistemom, zato je pomembno, da se zahteve razporedijo specifično glede na produkt razvoja (IEEE Recommended Practice for Software Requirements Specifications, 1998; Systems and software engineering - Life cycle processes - Requirements engineering, 2011). 5 PRILAGODITEV DOKUMENTA SZPO ZA MOBILNE APLIKACIJE Splošne lastnosti dokumenta SZPO, ki veljajo tudi pri izdelavi dokumenta za mobilne aplikacije, smo že predstavili. Zdaj pa se bomo osredinili na prilagoditve dokumenta za mobilne aplikacije. Predstavili bomo dele dokumenta SZPO za mobilne aplikacije, ki se nekoliko razlikujejo od dokumentov SZPO za tradicionalno programsko opremo, predvsem glede na tehnološke razlike ter lastnosti mobilnih telefonov. Pregled prilagoditev smo pripravili na podlagi pregleda literature ter praktičnih primerov, kar smo kasneje dopolnili s svojimi izkušnjami, pridobljenimi pri pripravi dokumenta SZPO za mobilne aplikacije, razvite v okviru raziskovalno-razvojnega projekta. Najprej bomo predstavili, kako se razlikujejo mobilne tehnologije in mobilne naprave in na kaj moramo paziti pri razvoju za mobilno okolje. Sledil bo povzetek praktičnih primerov dokumentov SZPO za mobilne aplikacije. Pri tem bomo identificirali posamezne razlike in prilagoditve dokumenta SZPO, nastale na podlagi specifičnih lastnosti mobilnih aplikacij. V zadnjem razdelku sledi predstavitev praktičnega primera izdelave dokumenta SZPO z poudarkom na pridobljenih praktičnih izkušnjah. 5.1 Specifične lastnostni mobilnih telefonov Tradicionalna programska oprema nas obkroža že kar nekaj časa, medtem ko so programski produkti in aplikacije, namenjeni mobilnim telefonom, med nami zadnjih nekaj let. Zavedati se moramo, da se mobilni telefoni po nekaterih lastnostnih bistveno razlikujejo od osebnih računalnikov. To moramo upoštevati pri razvoju programskih produktov za mobilno okolje. Posebno je pomembno, da pri razvoju upoštevamo specifične lastnosti mobilnih telefonov, saj bomo le tako lahko izoblikovali uspešen in prilagojen mobilni programski produkt. Če povzamemo eno izmed definicij, ki pravi, da obstaja več tipov mobilnih tele- fonov in da mednje lahko uvrstimo običajne mobilne telefone, mobilne telefone, ki omogočajo prenos podatkov, mobilne telefone s podporo protokolu WAP6 in pametne mobilne telefone (Hribar, 2001), ki so danes najbolj razširjeni. Pametni mobilni telefon je mobilna naprava, ki ima tipkovnico QUERTY in/ali tipkovnico na dotik ter za neodvisne aplikacije odprt operacijski sistem, kot npr. Android, iOS, Windows Phone in BlackBerry (Garner, 2011). Prav pametni mobilni telefoni so torej tisti, ki omogočajo namestitev in uporabo različnih mobilnih aplikacij, zato je pomembno, da se pri razvoju aplikacij osredinimo na njihove specifične lastnosti, kot so npr. mobilna podatkovna povezava, GPS in Bluetooth, ter lastnosti, povezane z zasloni, občutljivimi na dotik, in jih upoštevamo. Literatura navaja številne lastnosti mobilnih tehnologij in mobilnih naprav, ki vplivajo na razvoj programskih produktov v mobilni domeni. Te lastnosti imajo pomemben vpliv tudi pri izdelavi dokumenta SZPO in predhodnih korakih zbiranja zahtev. Če povzamemo le nekaj najbolj pogostih, ki jih navajajo avtorji, so to izzivi, povezani z lastnostmi povezovanja mobilnih aplikacij z drugimi aplikacijami, omejitve virov, veliko število dostopnih različnih mobilnih telefonov in zanje prilagojeni uporabniški vmesnik. Ta je tesno povezan s fizičnimi dimenzijami mobilnih telefonov in ločljivostjo zaslona. Specifične lastnosti so povezane tudi z načinom vnosa podatkov prek zaslona na dotik, varnostnimi omejitvami ter tudi z novimi družinami tako strojne kot tudi programske opreme, uporabljene pri razvoju mobilnih aplikacij (Kirubakaran & Karthikeyani, 2013; Satyanarayanan, 1996; Wasserman, 2010). Podobne lastnosti navajajo tudi drugi avtorji, npr. Economou idr. (2008). Kot še dodajajo, moramo biti pri izdelavi dokumenta SZPO pozorni na mobilni kontekst, načrtovanje aplikacij za prenosljivost, načrtovanje za uporabnike s širokim spektrom znanj in izkušenj, omejitve vhodnih in izhodnih poti ter še posebno na zbiranje informacij s pomočjo senzorjev na mobilnih telefonih. Vse to so lastnosti, na katere moramo paziti tudi pri koraku zbiranja in zapisa zahtev za mobilne aplikacije. Zahteve, kot so različne resolucije zaslonov, zmoglji-vostne omejitve in zahteve, pasovna širina idr., so v dokumentih SZPO za mobilne aplikacije obvezni ele- 6 Wireless Application Protocol menti. Namreč, če zahtev ne prilagodimo omenjenim lastnostim in tega ustrezno ne zabeležimo, se lahko kar hitro zgodi, da končni produkt ne bo predstavljal zaključene celote, namenjene mobilnemu okolju. 5.2 Pregled praktičnih primerov SZPO za mobilne aplikacije Po pregledu literature v obliki člankov in drugih dostopnih del smo na svetovnem spletu poiskali prosto dostopne dokumente SZPO, oblikovane v okviru razvoja mobilnih aplikacij. Ker je dokument SZPO pri izdelavi produkta praviloma poslovna skrivnost, je bilo na spletu prisotnih le nekaj omejenih primerov dokumentov. Dokumente smo sistematično pregledali in se pri tem osredinili predvsem na: ■ dopolnitve obstoječih standardnih poglavij in v njih poiskali zahteve ter lastnosti, povezane z mobilnimi aplikacijami, ■ dodatna poglavja v okviru dokumenta, ki obravnavajo tematiko, specifično za mobilne aplikacije. Vsi pregledani dokumenti SZPO so bili oblikovani v skladu s priporočili IEEE 830, pri čemer upoštevajo predlagano strukturo in lastnosti, ki jih predlaga dokumentacija. Najprej smo se osredinili na dopolnitve v okviru obstoječih standardnih poglavij. Poglavje Uvod v dokumentih nima posebnih dopolnitev, vezanih na mobilne aplikacije oziroma mobilne tehnologije. Razlike pa so kar hitro vidne že v naslednjem poglavju, Splošni opis, in pripadajočih podpoglavjih. V podpoglavju Perspektiva produkta so v vseh dokumentih poudarili, da gre za razvoj mobilne aplikacije, ki je bila običajno povezana s storitvami drugih sistemov in rešitev. V istem podpoglavju so v nekaterih dokumentih dodali dodatno podpoglavje Operacijsko okolje, v katerem so navedli tip operacijskega sistema, za katerega bo razvita aplikacija (npr. Android, iOS ali Windows Phone), ter dodali tudi najnižjo verzijo operacijskega sistema, podprto v okviru projekta. V nekaterih dokumentih je bila navedena tudi referenčna naprava, za katero je mobilna aplikacija optimizirana. Največ razlik in dopolnitev v primerjavi z dokumenti SZPO tradicionalne programske opreme je opaziti v poglavju Specifične zahteve. Če se znova najprej osredinimo na dopolnitve v okviru obstoječih standardnih poglavij, opazimo tudi specializacijo posameznih podpoglavij za domeno mobilnih aplikacij. Razlika je opazna že v podpoglavju Zunanji vmesniki. V okviru omenjenega poglavja so med drugim navedene tudi zahteve za uporabniški vmesnik, kar je dopolnitev v primerjavi z dokumenti SZPO za tradicionalno programsko opremo. Pri tem v enem izmed pregledanih dokumentov dodajajo še opis posameznih lastnosti oblikovanja, specifičnih za posamezno platformo. Podobne podatke včasih zasledimo v okviru poglavja Splošni opis v podpoglavju Omejitve, v katerem lahko zasledimo tudi seznam odstopanj pri realizaciji rešitve na različnih platformah. Predvsem uporabniški vmesniki so običajno realizirani in prikazani nekoliko različno, v skladu z dobrimi praksami in stilnimi vodiči razvoja v okviru posameznega operacijskega sistema. V okviru specifičnih zahtev so v vseh pregledanih dokumentih SZPO dodali dodatne zahteve, specifične za mobilne telefone oziroma mobilne aplikacije. Dodali so zahteve, povezane s tehnologijami, ki jih uporabljajo mobilni telefoni, kot npr. GPS in Bluetooth. V zahteve so vpletli še hitrost mobilnega prenosa podatkov, prav tako pa so se dotaknili tudi velikosti zaslonov in s tem povezanih področij, predvsem z oblikovnega vidika in preglednosti. 5.3 Študija primera izdelave dokumenta SZPO za mobilno aplikacijo V okviru raziskovalno-razvojnega projekta razvijamo produkt, pri katerem sodelujejo strokovnjaki z različnih področij: kineziologije, psihologije, medicine in informatike. Gre za rešitev, ki uporabnike spodbuja k bolj zdravemu, manj stresnemu in čim bolj aktivnemu življenju. Projekt predstavlja celovito skupino produktov, ki je sestavljena iz portalne rešitve in mobilnih aplikacij. Prav pri razvoju le-teh aktivno sodelujemo in tako pripomoremo k ustvarjanju mobilnih aplikacij za različne mobilne platforme, Android, iOS in BlackBerry. Na začetku razvoja smo se kaj kmalu srečali z izzivom zbiranja in zapisa zahtev ter oblikovanja dokumenta SZPO za mobilne aplikacije. Zavedali smo se, da bo dokument SZPO za mobilne aplikacije nekoliko drugačen, dopolnjen in prilagojen glede na že znane dokumente SZPO, oblikovane za tradicionalno programsko opremo. Izziv nas je spodbudil, da smo se lotili pregleda literature, ki obravnava izdelavo dokumenta zahtev za mobilne aplikacije. Pri pregledu literature in praktičnih primerov smo bili pozorni na priporočila in dobre prakse, prav tako pa tudi na dopolnitve obstoječih poglavij ter dodatna poglavja v dokumentu, potrebna za popolno definiranje zahtev za uspešen razvoj mobilnih aplikacij. Ko smo se seznanili z dobrimi praksami oblikovanja dokumentov SZPO za mobilne aplikacije, smo zaceli z zbiranjem zahtev in oblikovanjem pripadajočega dokumenta. Pri oblikovanju zahtev so sodelovali tako strokovnjaki kineziologije, medicine in psihologije, ki so skrbeli za vsebinsko področje, kot tudi strokovnjaki s področja informatike, ki so skrbeli za tehnične zahteve. Oblikovanje ter izdelava dokumenta SZPO je potekala po več korakih. ■ Postavili smo okvirno strukturo dokumenta, in sicer na podlagi dobrih praks, predstavljenih v standardih IEEE 830 in ISO/IEC/IEEE 29148. ■ Vpeljali smo dodatna poglavja oziroma dopolnili obstoječa s specifičnimi podatki ali zahtevami za mobilne aplikacije. Poglavja smo glede na pregledane praktične primere in lastne praktične izkušnje ustrezno dodali oziroma razširili. ■ Začeli smo z dodajanjem vsebine v dokument SZPO, pri čemer smo zajeli vse potrebne zahteve z različnih področij. Pri razvoju so sodelovali tudi razvijalci, ki so na podlagi preteklih izkušenj z razvojem mobilnih aplikacij predlagali nekatere dopolnitve, ki poskrbijo, da ne pride do podvajanja truda in spreminjanja že razvitih funkcionalnosti. Dokument smo sproti pregledovali in po potrebi dopolnjevali. ■ Dokument SZPO je pregledal in potrdil projektni svet. Če povzamemo dopolnitve obstoječih po standardu oblikovanih poglavij s podatki, vezanimi na lastnosti mobilnih aplikaciji, smo v okviru SZPO za aplikacijo v razvoju dodali: ■ v poglavju Splošni opis smo v podpoglavju Perspektiva produkta navedli, da gre za razvoj mobilne aplikacije in ustrezno predstavili namen in način sodelovanja s storitvami v oblaku, portalno rešitvijo in podprtimi zunanjimi vmesniki; v podpoglavju Omejitve smo navedli najnižjo podprto verzijo operacijskega sistema in nekatere dodatne omejitve, vezane na lastnosti mobilnih telefonov: določili smo najmanjšo podprto ločljivost zaslona, ločljivost zaslona, optimizirano za aplikacijo v razvoju, priporočljivo pasovno širino za optimalen prenos multimedijskih vsebin in izvedbo sinhronizacije ter delovanje vmesnikov GPS in Bluetooth, ki omogočata pridobivanje podatkov; ■ v poglavju Specifične zahteve smo v okviru podpoglavja Vmesniki pri uporabniških vmesnikih predstavili zaslonske maske, prilagojene za mobilne telefone (t. i. StoryBoard), predvsem z vidika enostavnosti in preglednosti, dodali pa smo tudi zahtevo za orientacijo zaslona. Če povzamemo še dodana poglavja v dokumentu SZPO, ki dopolnjujejo predlagano strukturo, lahko rečemo, da smo v dokument SZPO dodali: ■ v poglavju Splošni opis smo dodali poglavje Operacijsko okolje, v katerem smo podrobneje navedli, za katere operacijske sisteme bo mobilna aplikacija razvita in na voljo; ■ v poglavju Specifične zahteve smo dodali poglavje Razlike med mobilnimi platformami, ki je služilo kot temelj, da smo lahko na podlagi le enega dokumenta SZPO mobilno aplikacijo razvili za več različnih platform; na podlagi izkušenj z razvojem za različne platforme smo namreč ugotovili, da zaradi dobrih praks in načina razvoja posameznih platform lahko prihaja do manjših odstopanj pri realizaciji posameznih funkcionalnosti; razlike smo v poglavju razdelili v tri skupine, in sicer na razlike v izgledu, izvajanju in sočasnosti; Slika 3: Struktura dokumenta SZPO za mobilne aplikacije ■ v poglavju Specifične zahteve smo dodali nekatere zahteve, vezane na lastnosti mobilnih aplikacij in tehnologij. V podpoglavju Zmogljivostne zahteve smo podali zahtevo, povezano z mobilnim prenosom podatkov, ki omogoča optimalno delovanje produkta. V okviru podpoglavja Vmesniki smo dodali sekcijo Orientacija zaslona, v kateri smo navedli, v katerih primerih je ležeča orientacija zaslona omogočena in v katerih ne. V okviru podpoglavja Vmesniki smo dodali še opis vmesnikov strojne opreme, v katerem smo opisali delovanje strojnih gumbov v okviru aplikacije v skladu z dobrimi praksami funkcionalnosti posameznih gumbov, ter opis komunikacijskih vmesnikov, na podlagi katerih aplikacija sodeluje z zunanjimi napravami. Dodali smo še podpoglavje Povezava z zunanjimi sistemi, v katerem smo opisali sodelovanje mobilne aplikacije z zunanjimi sistemi. Strukturo dokumenta SZPO za mobilne aplikacije, ki smo jo oblikovali, natančneje prikazuje slika 3. Struktura temelji na priporočilih standarda IEEE 830, dodana pa so poglavja, identificirana na podlagi pregledane literature, praktičnih primerov in praktičnih izkušenj v domeni razvoja mobilnih aplikacij. 6 SKLEP Glede na preučeno literaturo, praktične primere ter izkušnje, pridobljene pri izdelavi dokumenta SZPO za mobilne aplikacije, lahko z gotovostjo ugotovimo, da se dokument specifikacije zahtev za mobilne aplikacije nekoliko razlikuje od dokumenta specifikacije zahtev za tradicionalne programske produkte. Razlika se pojavi že v začetnih poglavjih splošnega opisa, v katerih je treba poudariti, da gre za razvoj mobilne rešitve, dodati pa še mobilne platforme, za katere razvijamo aplikacijo. Priporočeno je zapisati tudi omejitve, povezane s tehnologijami, kot sta GPS in Bluetooth, ki sta pomembni tehnologiji mobilnih telefonov, ter omejitve, povezane z velikostjo in ločljivostjo zaslona mobilnega telefona ter z drugimi viri. Še več razlik se pojavi pri definiranju specifičnih zahtev, npr. pri zahtevah zmogljivosti. Tam je smiselno dodati zahteve, povezane z mobilnim prenosom podatkov, in zahteve, povezane z uporabniškimi vmesniki. Pri zadnjih je treba pri oblikovanju upoštevati omejeno velikost in ločljivost zaslona, prav tako pa določiti tudi podporo različnim orientacijam zaslona pri določenih funkcionalnostih. Če aplikacijo razvijamo za več mobilnih platform, je priporočljivo predstaviti tudi dopustne in potrebne razlike med platformami, predvsem zaradi specifik posameznih mobilnih operacijskih sistemov. Če povzamemo, lahko na podlagi praktičnih izkušenj in pregledane literature ugotovimo, da se v dokumentih SZPO za mobilne aplikacije pojavljajo nekateri elementi in poglavja, ki jih ne zasledimo v dokumentih SZPO za tradicionalne programske produkte. Predlagamo, da je za doseganje dobrih praks v dokument SZPO za mobilne aplikacije primerno vključiti: ■ pojasnilo, da gre za razvoj mobilne aplikacije, ter dodatne morebitne povezave z drugimi sistemi ali rešitvami, ■ omejitve, povezane s platformo razvojnega produkta, v okviru programskih jezikov ter dobrih praks, ■ navedene omejitve delovanja funkcionalnosti za množico dostopnih mobilnih telefonov in operacijskih sistemov, ■ omejitve in zahteve, povezane z omejenimi viri pomnilnika, energije, spomina in drugih omejenih elementov, ■ morebitne zahteve in omejitve, povezane s souporabo virov, ■ zahteve, povezane z mobilnimi omrežji ter inter-netnimi povezavami, ■ zahteve in omejitve, povezane z grafičnim uporabniškim vmesnikom, ki ga določajo fizična velikost zaslona in njegova ločljivost, prav tako pa tudi dobre prakse in izoblikovani stilni vodiči, ■ zahteve, povezane z vnosom podatkov prek zaslona na dotik, in ■ zahteve, povezave s senzorji mobilnih telefonov, ki zajemajo podatke. Dobro napisan dokument SZPO je trdna podlaga za nadaljnji razvoj ter aktivnosti v življenjskem ciklu razvojnega produkta. Zaradi tega je pomembno, da si za zbiranje zahtev vzamemo dovolj časa in dokument oblikujemo po tehtnem premisleku, v skladu s priporočili in dobrimi praksami. Le tako bomo kot rezultat zbiranja zahtev dobili produkt, ki bo skozi ves razvojni cikel v pomoč, hkrati pa bo pomagal najti odgovore na vprašanja, ki se bodo morda pojavila pri nadaljnjem razvoju. ZAHVALA Študija je nastala v okviru programa usposabljanja mladih raziskovalcev, ki ga izvaja Javna agen- cija za raziskovalno dejavnost RS. V članku so med drugim uporabljeni tudi nekateri rezultati projekta, izvedenega v okviru Razvojnega centra IKT Savinja Žalec. Operacija se izvaja v okviru Operativnega programa krepitve regionalnih razvojnih potencialov za obdobje 2007-2013 v okviru izvajanja prve razvojne prioritete Konkurenčnost podjetij in raziskovalna odličnost, prednostne usmeritve Izboljšanje konkurenčnih sposobnosti podjetij in raziskovalna odličnost. VIRI IN LITERATURA [1] Belfo, F. (2012). People, Organizational and Technological Dimensions of Software Requirements Specification. Procedia Technology, 5(0), 310-318. doi:http://dx.doi.org/10.1016/j. protcy. 2012.09.034. [2] Boehm, B. W. (1984). Verifying and Validating Software Requirements and Design Specifications. Software, IEEE. doi:10.1109/MS.1984.233702. [3] Davis, A., Overmyer, S., Jordan, K., Caruso, J., Dandashi, F., Dinh, A.....Theofanos, M. (1993). Identifying and measuring quality in a software requirements specification. Software Metrics Symposium, 1993. Proceedings., First International. doi:10.1109/METRIC.1993.263792. [4] Doherty, G., McKnight, J. & Luz, S. (2010). Fieldwork for requirements: Frameworks for mobile healthcare applications. International Journal of Human-Computer Studies, 68(10), 760-776. doi:http://dx.doi.org/10.1016/j.ijhcs.2010.06.005. [5] Economou, D., Gavalas, D., Kenteris, M. & Tsekouras, G. E. (2008). Cultural applications for mobile devices: Issues and requirements for authoring tools and development platforms. SIGMOBILE Mob. Comput. Commun. Rev., 12(3), 18-33. doi:10.1145/1462141.1462145. [6] ESA Board for Software Standardisation and Control. (1991). ESA Software Engineering Standards. Prentice-Hall International. Dostopno na ftp://ftp.estec.esa.nl/pub/wm/anonymo-us/wme/bssc/PSS050.pdf (1. 8. 2013). [7] Finkelstein, A. & Savigni, A. (2001). A Framework for Requirements Engineering for Context-Aware Services. In 1 st International Workshop From Software Requirements to Architectures. [8] Garner, R. (2011). Mobile Payments: The importance of trust and familiarity and the need for co-operation (str. 1-12). [9] Gartner. (2012). Gartner Says Worldwide Sales of Mobile Phones Declined 3 Percent in Third Quarter of 2012; Smartphone Sales Increased 47 Percent. Dostopno na http://www.gartner. com/newsroom/id/2237315 (19. 2. 2013). [10] Giakoumakis, E. A. & Xylomenos, G. (1996). Evaluation and selection criteria for software requirements specification standards. Software Engineering Journal. [11] Gil, D., Andersson, J., Milrad, M. & Sollervall, H. (2012). Towards a Decentralized and Self-Adaptive System for M-Lear-ning Applications. Wireless, Mobile and Ubiquitous Technology in Education (WMUTE), 2012 IEEE Seventh International Conference on. doi:10.1109/WMUTE.2012.37. [12] Hammer, T. F., Huffman, L. L. & Rosenberg, L. H. (1998). Doing Requirements Right the First Time. Dostopno na http://www.crosstalkonline.org/storage/issue--archives/1998/199812/199812-Hammer.pdf. [13] Hofmann, H. F. & Lehner, F. (2001). Requirements engineering as a success factor in software projects. Software, IEEE. doi:10.1109/MS.2001.936219. [14] Hribar, U. (2001). Tehnologije za mobilno poslovanje. V Dnevi slovenske informatike. [15] IEEE Computer Society. (1998). IEEE Recommended Practice for Software Requirements Specifications (str. 39). [16] IEEE Recommended Practice for Software Requirements Specifications. (1998). IEEEStd830-1998. doi:10.1109/IEEE-STD.1998.88286. [17] IEEE Standard Glossary of Software Engineering Terminology. (1990). IEEE Std 610.12-1990. doi:10.1109/IEEE-STD.1990.101064. [18] ITU. (2013). The World in 2013 - ICT Facts and Figures. Dostopno na http://www.itu.int/en/ITU-D/Statistics/Documents/ facts/ICTFactsFigures2013.pdf (22. 7. 2013). [19] Kamaruddin, K. A., Yusop, N. S. M. & Ali, M. A. M. (2011). Using activity theory in analyzing requirements for mobile phone application. Software Engineering (MySEC), 2011 5th Malaysian Conference in. doi:10.1109/MySEC.2011.6140636. [20] Kirubakaran, B. & Karthikeyani, V. (2013). Mobile application testing - Challenges and solution approach through automation. 2013 International Conference on Pattern Recognition, Informatics and Mobile Engineering, 79-84. doi:10.1109/ ICPRIME.2013.6496451. [21] Maccari, A. (1999). The challenges of requirements engineering in mobile telephones industry. Database and Expert Systems Applications, 1999. Proceedings. Tenth International Workshop on. doi:10.1109/DEXA.1999.795189. [22] MobiThinking. (2012). Global mobile statistics 2012 Part A: Mobile subscribers; handset market share; mobile operators. Dostopno na http://mobithinking.com/mobile-marketing--tools/latest-mobile-stats/a#subscribers (19. 2. 2013). [23] NASA. (2009). NASA Software Engineering Requirements. Dostopno na August 01, 2013, from http://nodis3.gsfc.nasa. gov/npg_img/N_PR_7150_002A_/N_PR_7150_002A_.pdf. [24] Portio Research. (2012). Your Portio Research Mobile Fact-book 2012. Dostopno na http://www.portioresearch.com/en/ free-mobile-factbook.aspx (19. 2. 2013). [25] Rational. (1998). Rational Unified Process, Best Practices for Software Development Teams. Dostopno na http://www.ibm.com/developerworks/rational/library/ content/03July/1000/1251/1251_bestpractices_TP026B.pdf (1. 8. 2013). [26] Salazar, M. G., Mitre, H. A., Olalde, C. L. & Sanchez, J. L. G. (2012). Proposal of Game Design Document from software engineering requirements perspective. Computer Games (CGAMES), 2012 17th International Conference on. doi:10.1109/CGames.2012.6314556. [27] Satyanarayanan, M. (1996). Fundamental challenges in mobile computing. Proceedings of the fifteenth annual ACM symposium on Principles of distributed computing - PODC '96, 1-7. doi:10.1145/248052.24805. [28] Software development and documentation, DoD Military Standard MIL-STD-498. (1994). Washington, DC, USA: US Department of Defence. [29] Software requirements specification DID, DoD Military Standard DI-IPSC-81433. (1994). Washington, DC, USA: US Department of Defence. [30] Systems and software engineering - Life cycle processes - Requirements engineering. (2011). ISO/IEC/IEEE 29148:2011(E). doi:10.1109/IEEESTD.2011.6146379. [31] The New York Times. (2011). One Million Mobile Apps, and Counting at a Fast Pace. Dostopno na http://www.nytimes. com/2011/12/12/technology/one-million-apps-and-coun-ting.html (19. 2. 2013). [32] Wasserman, A. I. (2010). Software engineering issues for mobile application development. Proceedings of the FSE/SDP workshop on Future of software engineering research - Fo-SER '10, 397. doi:10.1145/1882362.1882443. [33] Whitfield, K. (2013). Fast growth of apps user base in booming Asia Pacific market. Portio Research. Dostopno na http://www.portioresearch.com/en/blog/2013/fast-growth--of-apps-user-base-in-booming-asia-pacific-market.aspx (22. 7. 2013). ■ Tina Schweighofen je mlada raziskovalka na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru, kjer je leta 2012 magistrirala in si pridobila strokovni naziv magistrica inženirka informatike in tehnologij komuniciranja. Trenutno je doktorska študentka bolonjskega doktorskega študija Računalništvo in informatika. Njeno raziskovalno delo obsega mobilne tehnologije, razvoj mobilnih aplikacij ter pripadajoče postopke testiranja, dokumentiranje razvoja mobilnih aplikacij, prav tako pa tudi razvojni cikel mobilnih aplikacij s pristopom programskih produktnih linij. ■ Marjan Heričko je redni profesor za informatiko na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru, kjer je nosilec več predmetov, ki so v pristojnosti Inštituta za informatiko. Je namestnik predstojnika inštituta ter vodja laboratorija za informacijske sisteme. Doktoriral je leta 1998 na Univerzi v Mariboru na področju zagotavljanja kakovosti objektno orientiranega razvoja programske opreme. Njegovo raziskovalno delo zajema vsa področja razvoja sodobnih informacijskih rešitev in storitev s poudarkom na naprednih pristopih k modeliranju in načrtovanju informacijskih sistemov, načrtovalskih vzorcih in metrikah.