Veebi- ja mobiilirakendused 5 min

Rakenduse lähteülesanne: mis on oluline

Hea rakenduse lähteülesanne kirjeldab, kes seda kasutab ja milleks, mida rakendus teeb esimesel päeval ja mis ootab, kes milliseid andmeid näeb, milliseid programme tuleb ühendada, kasutuspiiranguid, koodi ja kontode omandit ning käitamist pärast käivitamist. See võimaldab võrrelda hinnapakkumisi ja teada, millal see on valmis.

Sisukord6
  1. 01Milleks lähteülesanne on
  2. 02Seitse olulist elementi
  3. 03Kohustused, mis tuleb kirja panna algusest peale
  4. 04Mis ei kuulu lähteülesandesse
  5. 05Kust alustada
  6. 06Korduma kippuvad küsimused

Lähteülesandel on halb maine ja sageli põhjusega: pikk dokument, mis kirjutatakse üks kord, mida keegi uuesti ei loe ja mis kirjeldab funktsioone, mitte vajadusi. Ometi on just see dokument see, mis otsustab, kas kolm hinnapakkumist on võrreldavad, kas projekt püsib eelarves ja kas üleandmisel saab öelda, et see on valmis. Oluline ei ole selle pikkus, vaid see, mida see võimaldab otsustada.

Lühidalt

  • Kasulik lähteülesanne teenib kolme asja: hinnapakkumiste võrdlemine, esimese päeva määramine, teadmine, millal see on valmis.
  • See kirjeldab kasutusviise ja tulemusi, mitte funktsioonide loendit ega põhjuseta pealesurutud tehnilisi valikuid.
  • Olulised on seitse elementi: kasutajad, esimene päev, andmed ja õigused, integratsioonid, piirangud, omand, käitamine.
  • Kohustused (isikuandmed, konto kustutamine, ligipääsetavus) kirjutatakse sisse algusest peale, kui need maksavad kõige vähem.
  • Klikitav prototüüp täiendab seda: see näitab seda, mida sõnad halvasti kirjeldavad.

Milleks lähteülesanne on

Lähteülesanne ei ole formaalsus enne päris tööd. See osutab kolme teenust, mida mõõdetakse kogu projekti vältel.

  • Hinnapakkumiste võrdlemine. Kolm teenusepakkujat, kes loevad sama dokumenti, hindavad sama asja. Ilma selleta hindab igaüks oma ettekujutust projektist ja hinnaerinevus ei ütle midagi.
  • Esimese päeva määramine. Ületamised tulenevad sageli teel lisatud funktsioonidest. Kirjalik ulatus võimaldab öelda „jah, järgmises versioonis“ ilma konfliktita.
  • Teadmine, millal see on valmis. Kirjalikud vastuvõtukriteeriumid („tehnik registreerib kolme fotoga töö vähem kui minutiga“) muudavad üleandmise kontrolliks, mitte vaidluseks.

Vajadusest hinnapakkumiseni

  1. Vajadus

    Lihtsustatav toiming ja kelle jaoks.

  2. Prototüüp

    Mõned ekraanid, mida on testitud päris kasutajatega.

  3. Lähteülesanne

    See, mis on kinnitatud, kirja pandud ja piiritletud.

  4. Hinnapakkumine

    Iga otsus eraldi hinnatud, käitamine kaasa arvatud.

Seitse olulist elementi

1. Kes seda kasutab ja milleks

Kasutajad, nimetatuna rolli järgi (tehnik, klient, raamatupidaja), ja igaühe kohta kaks või kolm toimingut, mida ta peab saama teha. Ühe lausega kirjeldatud teekond („klient laadib puuduva dokumendi telefonist üles ja saab kinnituse“) on väärtuslikum kui neljakümne funktsiooni loend.

2. Esimene päev ja mis ootab

Lühike loend sellest, mida rakendus käivitamisel teeb, ja pikem loend sellest, mis tuleb hiljem. See on otsus, mis mõjutab kõige rohkem rakenduse hinda.

Praktikast

Challenge Us: ühelauseline vajadus, järgmisel päeval veebis

Meie arendatud grupiväljakutsete rakenduse Challenge Us vajadus mahtus ühte lausesse: seada grupis eesmärk, sisestada oma päev, näha teiste oma reaalajas, ilma keerulise registreerimiseta. Piiritletuna 1. septembril 2026 töötas selle esimene versioon brauseris 2. septembril. Üksikasjad on Challenge Usi juhtumiuuringus.

3. Andmed ja kes mida näeb

Milliseid andmeid rakendus säilitab, kust need tulevad ja iga rolli kohta, mida see saab lugeda ja muuta. See on rakenduse turvalisuse alus ja see võimaldab kliendiportaali, kus igaüks näeb ainult oma toimikuid.

4. Ühendatavad programmid

CRM, ERP, arveldustööriist: igaühe kohta, mis liigub millises suunas ja kas sellel on dokumenteeritud programmeerimisliides. See on sageli hinnapakkumise kõige ebakindlam rida; hea lähteülesanne võimaldab teenusepakkujal seda välja öelda.

5. Kasutuspiirangud

Tegelikud tingimused: ettevõtte või isiklikud telefonid, võrgu puudumine mõnes kohas (vt võrguühenduseta rakendus), keeled, oodatavad teavitused (vt tõuketeavitused), maksed (vt tellimus), tehisintellekti funktsioonid (vt tehisintellekt rakenduses). Ja levituskanal: brauser, rakenduste poed või privaatne levitamine, mida võrdleb PWA või natiivne rakendus.

6. Omand

Kood, andmebaas, arendajakontod, majutus ja domeen Teie nimel ning kirjalik õiguste üleandmine. See hoiab ära olukorra, kus peate ühel päeval üle võtma teenusepakkuja poolt hüljatud rakenduse, ja seda selgitab avaldamine oma arendajakonto all.

7. Käitamine pärast käivitamist

Kes jälgib, kes parandab, millise tähtaja jooksul, ja igakuine kulu rea kaupa: majutus, andmebaas, e-kirjad, rakenduste poodide kontod, kohustuslikud uuendused. Üksikasjad on rakenduse hooldustöö eelarves.

Kohustused, mis tuleb kirja panna algusest peale

Mõned nõuded maksavad alguses vähe ja hiljem tagantjärele palju. Neil on koht lähteülesandes.

  • Lõimitud andmekaitse. Isikuandmete kaitse üldmääruse artikkel 25 nõuab andmekaitse rakendamist töötlemise kavandamise ajal ja vaikimisi ainult iga eesmärgi jaoks vajalike andmete töötlemist, CNIL-i avaldatud teksti järgi. Andmeid, mida ei koguta, ei pea kaitsma.
  • Konto kustutamine. Apple’i ülevaatusjuhised on selged: rakendus, mis võimaldab konto luua, peab võimaldama ka selle rakenduses kustutada, reegli 5.1.1 järgi.
  • Ligipääsetavus. Alates 28. juunist 2025 kehtib Euroopa ligipääsetavuse direktiiv teatud eraisikutele osutatavate teenuste suhtes, sealhulgas e-kaubandus ja pangandus. Isegi kui see Teid ei puuduta, teenib kõigile loetav rakendus ka Teie kiirustavaid kasutajaid, eredas päikesevalguses või ühe käega.

Meelespidamiseks

Lähteülesandesse kirjutatuna saab neid kohustusi hinnata ja testida nagu kõike muud. Avaldamise hetkel avastatuna lükkavad need väljalaske edasi.

Mis ei kuulu lähteülesandesse

Mis aitab projekti

  • Ühe lausega kirjeldatud teekonnad koos kasutajaga

  • Lühike esimene päev ja loend sellest, mis ootab

  • Kontrollitavad vastuvõtukriteeriumid

Mis seda koormab

  • Soovide loend ilma prioriteetideta

  • Ärilise põhjuseta pealesurutud tehnilised valikud

  • Mallist kopeeritud leheküljed, mis ei räägi Teie tegevusest

Tehnoloogia ette kirjutamine ei ole keelatud, kui selleks on põhjus: Teie meeskonnad hooldavad juba seda keelt, Teie IT-osakond nõuab teatud majutust. Ilma põhjuseta on parem kirjeldada oodatavat tulemust, lasta teenusepakkujal pakkuda ja seejärel pakkumisi võrrelda. Kui piisata võib ilma arendajata tööriistast, näitab lähteülesanne ka seda: sellest räägib low-code või kood.

Kust alustada

Kirjutage kõigepealt ühele leheküljele kasutajad ja nende toimingud, seejärel esimene päev. Laske neid toiminguid testida klikitaval prototüübil enne ülejäänu täiendamist: prototüüp kõrvaldab ebavajalikud funktsioonid ja toob välja teised. Kui kõhklete veel arendamise ja ostmise vahel, täidetakse eritellimuse või turul oleva tööriista tabel sama teabega. Välitööde rakenduse puhul lähtuge sellest, mida see Teie meeskondade jaoks muudab; taustasüsteemi puhul artiklist Supabase, Firebase või oma server. Ja kui idee on kõik tehisintellektiga genereerida, ütleb vibe coding, mida jääb inimestel otsustada.

Meie rakenduste arendus algab sellest dokumendist: kirjalik piiritlus sellest, mida rakendus teeb esimesel päeval ja mis ootab.

Korduma kippuvad küsimused

Kui pikk peaks rakenduse lähteülesanne olema?

Õiget pikkust ei ole. Esimese versiooni jaoks piisab sageli mõnest leheküljest, kui need kirjeldavad kasutajaid, nende toiminguid, esimest päeva, andmeid ja õigusi, integratsioone ja omandit. Pikk dokument, mis loetleb funktsioone ilma prioriteetideta, aitab vähem kui lühike dokument, mis otsustab.

Kes peaks lähteülesande kirjutama?

Rakenduse tellinud ettevõte tunneb vajadust, kasutajaid ja piiranguid: tema kannab sisu. Teenusepakkuja võib aidata seda struktureerida ja täiendada, sageli raamistamisetapi käigus. Oluline on, et lõpliku versiooni kinnitaksid need, kes rakendust kasutama hakkavad.

Kas väikese rakenduse jaoks on lähteülesannet vaja?

Jah, isegi kui see on ühe lehekülje pikkune. Ilma selleta ei saa võrrelda kahte hinnapakkumist ega teada, millal rakendus on valmis. Väikese rakenduse puhul piirdub see kasutajate, esimese päeva toimingute, andmete ning koodi ja kontode omandiga.

Kas lähteülesanne võib projekti käigus muutuda?

Jah, ja see on normaalne: kasutajate esimene tagasiside muudab prioriteete. Oluline on, et iga muudatus kirjutataks üles, hinnataks ja aktsepteeritaks enne arendamist. Esimene päev jääb lühikeseks ja see, mis lisandub, läheb järgmisse versiooni.

Allikad

  1. CNIL, isikuandmete kaitse üldmäärus, 4. peatükk (uus vahekaart)cnil.fr
  2. App Store’i ülevaatusjuhised, Apple (uus vahekaart)developer.apple.com
  3. Direktiiv (EL) 2019/882, EUR-Lex (uus vahekaart)eur-lex.europa.eu
Allikas 1

CNIL, isikuandmete kaitse üldmäärus, 4. peatükk

Loe saidil cnil.fr(uus vahekaart)
Allikas 2

App Store’i ülevaatusjuhised, Apple

Loe saidil developer.apple.com(uus vahekaart)
Allikas 3

Direktiiv (EL) 2019/882, EUR-Lex

Loe saidil eur-lex.europa.eu(uus vahekaart)

Jim · Brain Plus AI asutaja

Loe veel teemal veebi- ja mobiilirakendused

  • Vali ja arvuta5 min Teema juhend

    Kui palju maksab rakendus: mis hinda mõjutab

    Hinnavahemik ei ütle teie projekti kohta midagi: rakenduse pakkumist mõjutavad mõned täpsed otsused ja lisaks igakuine tegevuskulu, mis tuleb eraldi arvutada. Siin need on.

  • Vali ja arvuta5 min

    Ärirakendus: eritellimusel või valmislahendus?

    Turul olev tarkvara on odavam seni, kuni Teie tööviis mahub selle lahtritesse. Siin on märgid, mis kallutavad eritellimuse poole, ja kesktee, mis sageli ununeb.

  • Mõista6 min

    Küberkerksuse määrus: turvanõrkusest teatamine 24 tunni jooksul

    Alates 11. septembrist 2026 peab Euroopas müüdava tarkvara või nutiseadme tootja teatama ärakasutatud turvanõrkustest ja rasketest intsidentidest 24 tunni jooksul. Keda see puudutab, millest tuleb teatada ja mida see kohustus annab ettevõttele, kes laseb rakendusi arendada või neid ostab.

WhatsApp