6 vaihetta SRS-dokumentin kirjoittamiseen, joka toimii + Template
Software specification-dokumentteja pidetään joskus artefakteina, jotka ovat järkeviä vain kehittäjille. SRS-Dokumentti voi kuitenkin mennä pidemmälle ja toimia oppaana markkinoinnin asiantuntijoille, sidosryhmille, suunnittelutiimeille ja jopa käyttäjille.
tässä artikkelissa selitetään, miksi ohjelmistodokumentoinnilla on merkitystä ja miten SRS-dokumentti kirjoitetaan, jotta se olisi käytännön opas kaikille tiimin asiantuntijoille.
mikä on SRS-dokumentti ja miksi sillä on väliä?
SRS (software requirement specification) – dokumentti on artefakti, joka sisältää tulevan tuotteen vaatimukset, odotukset ja standardit. Se voi kattaa tekstidokumentit, laskentataulukot, järjestelmät, ennakkotapaukset ja muut osat, jotka selventävät tuotteen visiota. Toisin sanoen SRS-dokumentissa on yksityiskohtainen kuvaus siitä, miten tuotteen tulisi toimia ja miten tuotekehitystiimin tulisi toteuttaa se.
kuvittele se kuin rakentaisi laivaa. Sinulla on visio mastosta tai purjeesta, ja voit jopa kuvitella, miten se kulkee aaltojen läpi. Tarvitaan kuitenkin tiukempia yksityiskohtia, jotta alus saadaan vesille.
sama koskee tuotekehitystä. Sinulla on selkeä näkemys sovelluksesta, jonka haluat rakentaa kaikkine ominaisuuksineen, sisustuselementteineen ja painikkeineen. Sanallinen ominaisuuksien kuvaus ei kuitenkaan riitä kehittäjille idean toteuttamiseen.
jotta tulos vastaa päässäsi olevaa kuvaa, sinun on selitettävä paperille tarkasti, miten jonkin ominaisuuden pitäisi toimia. SRS-dokumentti on erinomainen väline tällaisten teknisten yksityiskohtien kuvaamiseen.
.jpg)
kuka kirjoittaa SRS-dokumentin?
SRS-asiakirjan kirjoittaminen tarkoittaa ominaisuuksien, tehtävien ja tavoitteiden yleisten kuvausten siirtämistä niiden teknisen toteutuksen yksityiskohtaiseen suunnitelmaan.
SRS-dokumentit ovat yleensä tuote-ja projektipäälliköiden tai yritysanalyytikkojen kirjoittamia, jotka ovat suoraan yhteydessä asiakkaisiin tai jotka tekevät käyttäjätutkimusta (joka työskentelee myös lankakehyksissä ja tietää, miten tuotteen tulisi käyttäytyä) ja keräävät tulevien tuotteiden vaatimukset.
sillä välin tämä asiakirja. Hyvä SRS-dokumentti ei ole pelkästään tekninen, sillä se kattaa myös liiketoiminnan tavoitteet, mittarit, käyttäjien ongelmat, käyttäjäpersoonat jne.
3 Miksi SRS-dokumentti on tärkeä
niin, SRS-asiakirjan kokonaisarvo on selvä. Tässä ovat syyt, miksi ohjelmiston vaatimukset erittely asiakirjat ovat välttämättömiä:
SRS on Viestintäpiste
elävänä dokumenttina SRS-dokumentti toimii viestintäalustana kaikkien asiantuntijoiden välillä: Kehittäjät, markkinoinnin asiantuntijat ja perustajat.
selittämällä yksityiskohtia SRS-dokumentissa, virallisesti tai epävirallisesti, johtajat sopivat asiakkaiden kanssa tulosodotuksista. Sillä välin, jos muutokset tehdään vaatimuksiin, asiakas ja/tai tuotteen omistaja voi tarkistaa ja vahvistaa ne asiakirjassa. Ja kehittäjät ovat vastuussa näiden odotusten täyttämisestä.
ominaisuuksien lopullinen kuvaus
SRS dokumentoi ohjelmiston lopulliset versiot, jotka ovat peräisin asiakkaiden kanssa aiemmin keskustelluista oletuksista. Palavereissa ja puheluissa, käyttäjätesteissä ja haastatteluissa tuoteversiot voivat muuttua hyvinkin usein. Joskus jopa tuotepäälliköt voivat hukkua olemassa oleviin tuote-iteraatioihin. SRS-tiedosto auttaa yhdistämään kaikki nämä vaatimukset yhdeksi standardiksi ja poistamaan sekaannukset tuotteen vaatimuksista.
SRS on standardi opas tuotekehittäjille
sen lisäksi, että siinä kuvataan tuotteen vaatimukset, SRS-dokumentti opastaa kehitystiimiä siitä, mitä vaiheita heidän tulisi noudattaa rakentaakseen asiakkaan haluaman tuotteen.
projektin organisaatiosta riippuen kehittäjät voivat tai eivät voi olla mukana projektin analyyttisessä osassa. Kummassakin tapauksessa heidän on tehtävä johtopäätös siitä, miten järjestelmän tulisi toimia, määriteltävä sille sopivat vaatimukset ja koodiparametrit.
samoin laadunvarmistuksen ammattilaisten on ymmärrettävä kaikki tuotteen konseptin taustalla olevat tekniset näkökohdat. Näin SRS-dokumentaatio toimii standardina LAADUNVARMISTUSTESTIEN suunnittelussa ja suorittamisessa.
lopuksi suunnittelijat saavat SRS-dokumenttien avulla projekti-oivalluksia, jotka sovittavat suunnittelun käyttötapaukseen.
6 vaiheet kirjoittaminen hyvä SRS asiakirja
toiminnalliset ja ei-toiminnalliset vaatimukset ottavat suuren osan kaikista SRS-asiakirjoista. Tuotepäälliköt eivät ota näitä vaatimuksia tyhjästä. Ne ovat tulosta tarkasta viestinnästä asiakkaiden kanssa sekä syvällisestä käyttäjä-ja teknisestä tutkimuksesta. Tässä ovat tärkeimmät vaiheet kirjallisesti erinomainen SRS dokumentaatio:
Vaihe 1. Viestintä sidosryhmän kanssa
poistamme ensimmäisen epävarmuustason kysymällä sidosryhmiltä heidän odotuksiaan tuotteesta. Toki tällainen haastattelu antaa vain vähän ymmärrystä vaatimuksista. Tämä on kuitenkin edelleen hyvä lähtökohta tutkimukselle.
Uptechillä puhumme ensin asiakkaan kanssa ennakkomyynti-ja Aloituspuhelussa, kun yritämme selvittää, sopimmeko toisillemme. Yritämme kiteyttää pienetkin yksityiskohdat asiakkaasta ymmärtääksemme hänen ideansa.
pelkkä viestintä ei kuitenkaan anna riittävästi tietoa tuotteen kohdeyleisöstä ja heidän haluistaan ja tarpeistaan. Joten jatkamme discovery vaiheessa tehdä selväksi.
Vaihe 2. Discovery Stage
Discovery stage on kriittinen SRS-dokumentaation kirjoittamisessa. Tässä vaiheessa meillä on mahdollisuus tutkia ongelmaa, joka tuotteen pitäisi ratkaista, etuja ja tarpeita. Tavoitteenamme on tunnistaa käyttäjien ongelmat ja määritellä hypoteeseja mahdollisista ratkaisuista niiden ratkaisemiseksi. Tällaisella lähestymistavalla voimme tehdä sovelluksesta käyttäjälle arvokkaan.
Use Cases vs User Stories
kaikki käyttäjätiedot tulevat osaksi SRS-dokumenttia Käyttötapauksina ja käyttäjien tarinoina. Näiden kahden kategorian erosta keskustellaan laajasti tuotekehitysyhteisössä.
Yksinkertaisesti sanottuna käyttäjien tarinat keskittyvät enemmän lopputulokseen ja hyötyihin, joita Käyttäjä saa ominaisuutta käyttäessään. Kun taas käyttää tapauksissa enemmän granulaarisesti kuvata funktio itse.
esimerkiksi Yaza-projektin useiden käyttäjähaastattelujen jälkeen päädyimme siihen, että sovelluksessa pitäisi olla chat. Joten käyttäjän tarina tällaiseen tapaukseen kuulostaisi: ”käyttäjänä haluan keskustella mahdollisen talon omistajan kanssa.”
samaan aikaan, käyttötapaus tämän tarinan kuvaisi jokaisen vaiheen käyttäjän tämän tavoitteen saavuttamiseksi- ” käyttäjänä, minun täytyy lisätä kontakti minun chat-lista ja lähettää hänelle / hänelle viestin, niin että…”.
Vaihe 3. Rakenna rakenne
löydön valmistuttua siirrymme kirjoittamaan SRS-dokumentaatiota. Ensinnäkin tarvitsemme asiakirjan lyhyen rakenteen. SRS-dokumentin sisältö voi vaihdella merkittävästi, mutta tyypillinen SRS-dokumentaatiorakenne näyttäisi tältä:
1. Johdanto
johdanto sisältää tiivistelmän asiakirjan sisällöstä. Sen on tarkoitus vastata seuraaviin kysymyksiin:
- Lyhyt kuvaus asiakirjan sisällöstä;
- tämän asiakirjan aiotut lukijat;
- kehitteillä olevan ohjelmiston idea;
- aiotut lukijat.
1.1 liiketoimintatavoitteet
Aseta lista tavoitteista, jotka haluat saavuttaa projektissa, kuten MVP: n luominen, monitasoisen mobiilisovelluksen luominen tai verkkosivuston avaaminen.
lisäksi tämän osion tulisi kuvastaa yrityksesi tavoitteita ja menestysmittareita. Vaikka jotkut saattavatkin jättää tämän osan pois asiakirjasta, on tärkeää osoittaa nämä asiat, koska ne vaikuttavat suoraan tutkimukseen ja kehitykseen.
1.3 Käyttötarkoitus
miten kuvittelet henkilön käyttävän tuotettasi? Mitä toimintoja tarjoatte tämäntyyppiseen käyttöön? Kuvaile kaikki mahdolliset tavat, joilla henkilö voi käyttää tuotetta missä tahansa käyttäjän roolissa hän toimii.
1.4 Scope
tässä osassa kuvataan työn laajuus, joka sinun on suoritettava saadaksesi ideasi eloon.
1.5 määritelmät ja lyhenteet
tässä asiakirjassa esitetään käyttämiesi termien määritelmät, jotta käyttäjät ymmärtäisivät ne täydellisesti.
2. Yleiskuvaus
tässä kohdassa kerrotaan sovelluksen idea, mistä se on peräisin ja miksi se voi olla käyttäjille kiinnostava.
2.1 käyttäjä tarvitsee
jokaiselle rakennettua ohjelmistoa, joka ei palvele ketään. Mutta jos tiedät tarkalleen, kuka kohdeyleisösi on, missä he työskentelevät, ja heidän tuskansa, sinulla on paremmat mahdollisuudet toimittaa sovellus, joka on laajalti hyväksytty käyttäjien.
3. Järjestelmän ominaisuudet ja vaatimukset
nyt on aika hahmotella tulevan ohjelmiston tekniset vaatimukset. Kuvaile ominaisuuksia, jotka tuotteesi sisältää, sekä standardeja, jotka määrittävät näiden tuotteiden laatua.
3.1 toiminnalliset vaatimukset
toiminnalliset vaatimukset ovat järjestelmän eritelmiä, joita ilman ohjelmisto ei toimi kunnolla. Määritelmä annat ohjelmiston ominaisuuksia määrittää, miten ne toteutetaan edelleen.
3.2 Nonfunktional Requirements
siinä missä funktionaaliset vaatimukset määrittelevät, mikä järjestelmän funktio tulee olemaan, ei-funktionaaliset vaatimukset määrittelevät, miten järjestelmä toteuttaa nämä ominaisuudet, esimerkiksi valmistumisnopeuden.
3.3 Tekniikkapino
tekniikkapino on teknisten ratkaisujen joukko, jota käytetään ohjelmiston tai projektin luomiseen ja suorittamiseen. On tärkeää ilmoittaa se SRS-asiakirjassa, koska se määrittelee kaikki muut tekniset yksityiskohdat.
.jpg)
Vaihe 4. Tee yleiskuvaus
ennen kuin uppoudut tuotteen tietoihin, anna yleiskuva sovelluksen tärkeimmistä ominaisuuksista. Yksinkertaisesti selittää sovelluksen tarkoitus, sen ominaisuudet, ja miten ne ratkaisevat käyttäjän ongelma.
Vaihe 5. Määrittele toiminnalliset ja ei-toiminnalliset vaatimukset
SRS-asiakirjan ydin koostuu yleensä tuotteen toiminnallisista ja ei-toiminnallisista vaatimuksista. Tällaisten määritysten avulla voit lisätä tarkempia tietoja yleiskatsaukseen ja siten ohjata tiimiä sovelluksesi teknisten yksityiskohtien läpi.
toiminnallisten ja ei-toiminnallisten vaatimusten ero on toinen kiista tuotekehitysyhteisössä. Olemme jakaneet asiantuntemustamme aiheesta tässä artikkelissa.
Vaihe 6. Varmista, että asiakas on samalla sivulla
hyväksyntä on paljon odotettu osa kehitystä. Asiakkaan muokkaukset voivat kuitenkin joskus tehdä tyhjäksi koko työmäärän, joka valmistuu tietyssä vaiheessa projektia.
paineen välttämiseksi suosittelemme, että hyväksymme pieniä osia valmiista SRS-dokumentaatiosta sen sijaan, että toimittaisimme koko asiakirjapaketin kerralla. Tämä auttaa korjaamaan tiettyjä asioita nopeasti ja on vähemmän hankala.
asiantuntijan vinkit Great SRS-dokumentaation kirjoittamiseen
vie aikaa hioa taitoa kirjoittaa erinomaista SRS-dokumentaatiota. Olemme vetäneet listan asiantuntijoiden vinkkejä SRS-dokumentaation kirjoittamiseen kokemuksestamme. Joten tässä on muutamia oivalluksia, jotka tekevät SRS-dokumentaation tehokkaaksi:
Make It Simple
tämä tuskin on salaisuus, mutta yksinkertaiset asiat hallitsevat maailmaa. Tämä pätee varmasti kaikenlaisiin asiakirjoihin, joiden parissa työskentelet. SRS on yhtenäinen kuvaus tulevasta tuotteesta koko tiimillesi. Tämä tarkoittaa, että SRS-asiakirjan kielen, rakenteen ja muotoilujen tulisi olla mahdollisimman lakonisia.
Include Business Goals
joskin SRS-dokumentti keskittyy ensisijaisesti teknisiin ominaisuuksiin, mukaan lukien liiketoiminnan tavoitteet, on hyvä käytäntö. SRS-dokumentti on ohje kehitystiimille ja tuoteyhteenveto tuotteeseen liittyville ei-teknisille asiantuntijoille. Lisäksi, mukaan lukien liiketoiminnan vaatimukset, kuten mittarit ja tarkoitukset, tekee SRS yhtenäinen väline koko joukkue.
lisää käyttäjätiedot
löytövaihe paljastaa yleensä arvokkaimman tiedon käyttäjästä. Näiden tietojen lisääminen SRS-asiakirjaan tekee siitä hyödyllisen paperin suunnittelu-ja kehitystiimille.
käsittele SRS-asiakirjaasi elävänä asiakirjana
SRS-asiakirjan ei pitäisi olla staattinen, vaikka olet koonnut kaikki projektia varten tarvittavat paketit. Ketterissä ekosysteemeissä projektit kiertävät hankkimassa uusia ominaisuuksia jokaisen iteraation myötä. Kaikki tällaiset muutokset ja muutokset tulee välittää SRS-dokumentissa ja sopia asiakkaan kanssa.
johtopäätös
SRS-dokumenttien kirjoittaminen vaatii syvällistä tutkimusta, analysointia ja vaivannäköä. Kuitenkin, kattava SRS-asiakirja, joka kattaa liiketoiminnan ominaisuudet, tekniset tiedot, ja käyttäjätiedot maksaa pois upea tuote, joka täyttää sekä asiakkaan ja käyttäjien odotukset.
Uptechilla on viiden vuoden kokemus tuotteiden rakentamisesta kukoistaville startupeille. Osaamme tutkia käyttäjän tarpeita ja tehdä SRS documentista tehokkaan projektinhallinnan välineen pölypaperipinon sijaan.
F. A. Q.
mikä on SRS?
SRS on asiakirja, joka sisältää yksityiskohtaisen kuvauksen sovelluksen tai ohjelmiston teknisistä eritelmistä ja vaatimuksista. SRS myös ohjeistaa kehittäjiä siitä, miten toteuttaa tuotteen idea vastaamaan asiakkaan odotuksia.
mikä on SRS-asiakirjan tarkoitus?
SRS-asiakirjan tarkoituksena on antaa tekninen kuvaus tuotteen ominaisuuksista, antaa teknisiä ja ei-teknisiä vaatimuksia ja opastaa kehitystiimiä toteutuksessa.
kuka kirjoittaa SRS-asiakirjoja?
joukkueen kokoonpanosta riippuen SRS-asiakirjat ovat yleensä:
- Product Manager;
- Project Manager;
- Business Analyst;
- Technical Engineer.