#Tuotteen etiketissä.
ohjelmiston vaatimusmäärittely (SRS-dokumentti) kuvaa, kuinka ohjelmisto tulisi kehittää. Yksinkertaisesti sanottuna, SRS tarjoaa kaikille mukana oleville etenemissuunnitelman kyseiselle hankkeelle.
Se tarjoaa korkea-luokan määritelmät, toiminnalliset ja ei-toiminnalliset vaatimukset ja ohjelmiston, ja voi myös käyttää tapauksissa, jotka osoittavat, miten käyttäjä on vuorovaikutuksessa järjestelmän valmistuttua.,
Huomautus: anna meidän auttaa sinua kirjoittamaan ohjelmiston vaatimukset erittely. Pyydä puhelu CTO: lta täyttämällä tämä lomake.
Sisällysluettelo
Miksi SRS-Dokumentti Tärkeää?
Oletetaan, että haluat luoda chat-sovelluksen, jossa erityisten ulkonäkö ja toiminnallisuus, ja haluaisin sen olevan suunnattu nimenomaan yrityksille. Sinusta tuntuu, että voit leikata pois lisäominaisuuksia, joita kaupalliset chat-sovellukset käyttävät vedotakseen yleisöön ja keskittyäkseen ominaisuuksiin, joita yritykset tarvitsevat. Mutta et ole Kehittäjä.,
joten sinun täytyy ulkoistaa sovelluksen kehittäminen. Mutta sinun on myös varmistettava, että kuka tahansa palkkaat muuttamaan ideasi todellisuudeksi, tietää tarkalleen, mitä yrität saavuttaa. Ilman kaikkia yksityiskohtia loppuun sovellus, aika ja kustannukset voivat nopeasti päästä käsistä. Kehittäjät voivat viedä väärään suuntaan ja on refactor koodi, jos valmis tuote ei vastaa kuvaa, että sinulla oli päässäsi.
SRS-dokumentti pakottaa laittamaan idean paperille, jotta se kattaisi kaikki nämä yksityiskohdat. Tämä idea on käännettävä kielelle, jota kehittäjät ymmärtävät., SRS-dokumentissa kuvataan, mitä asiakas haluaa ja mitä kehittäjät tarjoavat. Se on kirjallinen sopimus jokaisesta yksityiskohdasta sovelluksen.
selkeillä vaatimuksilla varmistetaan, että kehitystiimi luo ohjelmistoja, jotka vastaavat asiakkaiden tarpeita. Strategia auttaa arvioimaan työn kustannuksia ja kattamaan hankkeen laajuuden. Se myös antaa kooderit käsityksen tech pino he tarvitsevat ja auttaa heitä suunnitella työnsä, mutta se ei ole kaikki:
- Suunnittelijat saada hankkeen oivalluksia läpi SRS asiakirjat, jotta he voivat ottelu suunnittelu käyttötapaus.,
- testaajat saavat ohjeet yrityksen tarpeisiin sopivien testitapausten luomiseen.
- loppukäyttäjät käyttävät SRS: ää ohjelmiston ymmärtämiseen.
- se antaa sijoittajille yleiskuvan järjestelmän ominaisuuksista, jotta he voivat tehdä sijoituspäätöksiä.
SRS on tärkeää, koska se on ainoa lähde, tiedot ja odotukset, joka estää väärinkäsityksiä välillä, projektipäälliköt, kehittäjät, suunnittelijat ja testaajat.
Mitä SRS Kuuluu?,
SRS: ssä pitäisi olla tarpeeksi tietoa kehittäjille kuvatun ohjelmiston täydentämiseksi. Se ei vain esitetään kuvaus ohjelmisto on kehitteillä, mutta myös tarkoitusta se palvelee: mitä ohjelmistolla on tarkoitus tehdä ja miten se pitäisi tehdä.,ohjelmiston tai mitä sen pitäisi tehdä
Ero Toiminnalliset ja Ei-toiminnalliset Vaatimukset
Toiminnalliset vaatimukset ovat tavoitteita uuden järjestelmän suunnittelussa., Ne kuvaavat järjestelmää ja sitä, miten se toimii auttaakseen käyttäjän tehtävissä. Ne määrittelevät, miten järjestelmä reagoi käyttäjän syötteeseen, ja niillä on yksityiskohtaiset tiedot laskelmista, tietojen syöttämisestä ja liiketoimintaprosesseista. Voit tarkastella toiminnallisia vaatimuksia yksityiskohtaisena kuvauksena sovelluksen ominaisuuksista ja käyttäjän tarpeista. Ilman toiminnallisten vaatimusten täyttämistä järjestelmä ei toimi.
Kun toiminnalliset vaatimukset määritetään, mitä järjestelmä ei, ei-toiminnalliset vaatimukset kuvaavat, miten järjestelmä tekee sen. Toiminnattomat vaatimukset eivät vaikuta sovelluksen toimivuuteen., Vaikka järjestelmä ei täyttäisi toiminnallisia vaatimuksia, se suorittaa halutut tehtävät.
ei-toiminnalliset vaatimukset ovat tärkeitä myös siksi, että niissä määritellään käyttäjäkokemukseen vaikuttavat yleiset ominaisuudet. Sen sijaan, että ne keskittyisivät käyttäjien vaatimuksiin, ne keskittyvät käyttäjien odotuksiin ja käsittelevät muun muassa suorituskykyä, turvallisuutta, luotettavuutta, käytettävyyttä ja käytettävyyttä.,
Miten Kirjoittaa Ohjelmiston vaatimusmäärittely-Dokumentti
Se on parasta järjestää parhaillaan käytät kirjoittaa SRS-dokumentti alkaa luuranko ja yleisiä tietoja ohjelmiston olet kehittämässä, ja viimeistely lisäämällä yksityiskohtia täsmentää teidän luonnos. Tässä on kuusi vaiheet mukana luomassa SRS-dokumentti:
Hae Ohjelmiston vaatimusmäärittelyn Dokumentti
– Meillä auttoi 200+ yritykset rakentaa niiden ohjelmisto tuotteita. Palkkaa yritysanalyytikkomme 6 vuoden asiantuntemuksella kirjoittamaan sinulle SRS.,
Pyydä SRS
Luo Ääriviivat
ensimmäinen askel on luoda hahmotelma oman SRS. Voit luoda tämän itse tai käyttää olemassa olevaa SRS-mallia lähtökohtana. Täällä on perus esimerkki SRS ääriviivat:
Lataa ebook
- Käyttöönotto
- Käyttötarkoitus
- kohdeyleisö
- käyttötarkoitus
- Laajuus
- Määritelmiä
- Yleinen Kuvaus
- Käyttäjien Tarpeet
- Oletukset ja Riippuvuudet
- Järjestelmän Ominaisuudet ja Vaatimukset
- Toiminnalliset Vaatimukset
- Ulkoinen Liitäntä Vaatimukset
- Järjestelmän Ominaisuudet
- Ei-toiminnalliset Vaatimukset
Määritä Varten
Kun olet ääriviivat, sinun täytyy lihassa sitä ulos., Aloita tuotteen käyttötarkoituksen määrittelystä SRS: n käyttöönotossa. Tässä kuvataan tarkoitettu yleisö ja miten he käyttävät tuotetta. Tässä on, miten sinun pitäisi rakennetta varten:
- Määrittää tuotteen laajuus
- Kuvaile arvoa se tuottaa
- Näyttää kuka käyttää ohjelmisto
- Yksityiskohtaisesti, miten se auttaa tarkoitettu käyttäjien työtä
Yleiskuva
Jälkeen määritellään tuotteen käyttötarkoitus, yhteenveto miten se toimii., Tässä annetaan yleinen kuvaus ohjelmiston ominaisuuksista ja siitä, miten ne sopivat käyttäjän tarpeisiin.
Voit myös kuvata oletukset teet tuotteesta toiminnallisuus ja mitä se riippuu nykyisen teknologian ekosysteemi.
Kuvaavat Toiminnalliset ja Ei-toiminnalliset Vaatimukset
Nyt kun olet kirjoittanut yleistä tietoa, se on aika saada tarkempia. Täyttämällä yhteenveto ennen työn toiminnalliset ja ei-toiminnalliset vaatimukset, antaa sinulle viittaus varmista, että olet täyttää käyttäjän perustarpeet, kun täytät tiedot.,
Tämä yksityiskohtainen kuvaus järjestelmän vaatimuksista on kaikkein olennainen osa SRS-dokumentti. Kuvataan toiminnalliset vaatimukset riittävän yksityiskohtaisesti, jotta kehittäjät voivat saada töitä ja ei-toiminnalliset vaatimukset, kuten turvallisuus tekniset tiedot ja suorituskyky.
tähän lisätään käyttötapauksia, joissa kuvataan elävästi, miten käyttäjä on vuorovaikutuksessa järjestelmäsi kanssa. Siinä projektisi tavoitteet ovat yksityiskohtaisia ja mitataan, miten hanke etenee kehityksen aikana.,
Lisää Täydentäviä Tietoja
viimeinen vaihe luoda luonnos SRS-dokumentti on lisäämällä yksityiskohtia että voisi auttaa kehittäjiä loppuun työ muodossa liitteet, sanastojen termejä ja viittauksia.
Hanki Hyväksyntä
Kun olet lisännyt tarpeeksi yksityiskohtia SRS kuvata mitä järjestelmän pitäisi tehdä, se on aika saada sidosryhmät hyväksyä asiakirjan.
todennäköisesti joudut tekemään esittelyn kehitysprosessiin osallistuville ihmisille., Ne voivat pyytää muutoksia, ja sinun on päivitettävä SRS-asiakirja sidosryhmien palautteen perusteella ennen lopullista hyväksyntää.
Tämä on hyvä merkki. Se tarkoittaa, että sekä kehittäjät ja sidosryhmät tekevät asiakirjan tarkempi, joten hanke on vähemmän kuin mene pois radan.
Miten Kirjoittaa Ohjelmisto Käyttää Tapauksissa SRS
käyttötapaus kuvaa, kuinka käyttäjä on vuorovaikutuksessa järjestelmän kanssa. Se kuvaa tuotetta loppukäyttäjän näkökulmasta yksinkertaisessa tarinamuodossa. Writing out use cases pakottaa sinut ajattelemaan läpi, mitä käyttäjät tekevät ohjelmiston ja miten se vastaa., Se on funktionaalisten vaatimusten tosielämän visualisointi.
tässä ovat vaiheet, joita voit seurata kirjoittaaksesi käyttötapauksen:
- kuvaile tuotteesi loppukäyttäjiä.
- keskity yhteen näistä käyttäjistä.
- hajota tämän käyttäjän yhteisvaikutukset käyttötapauksiin. Jokainen vuorovaikutus on käyttötapaus.
- kuvaile tapahtumien kulku kunkin käyttötapauksen osalta.
- Kirjoita yksityiskohtainen kuvaus käyttäjän toimista ja siitä, miten järjestelmän tulisi reagoida.
- Laajenna kutakin käyttötapausta vaihtoehtoisilla käyttäjätoimilla ja järjestelmävastauksilla.
- Toista 1-6 kullekin loppukäyttäjälle.,
Mitä ominaisuuksia hyvä SRS?
on olemassa erityisiä ominaisuuksia, jotka jokaisella SRS: llä tulisi olla. Tarkastelemalla tätä luetteloa ja vertaamalla sitä oman SRS, voit varmistaa, että se on hyödyllinen asiakirja kaikille sidosryhmille.
Selkeä
SRS asiakirjan pitäisi olla helppo ymmärtää. Minkään ei pitäisi olla epämääräistä, joten sidosryhmien välillä ei ole väärinkäsityksiä.,
Mitattavissa
vaatimukset SRS-asiakirja täytyy olla mitattavissa, joten valmis tuote voidaan validoida ja todentaa vastaan tekniset tiedot.
Täydellinen
SRS-asiakirjan pitäisi olla tarpeeksi tietoa oman kehityksen tiimi valmis tuote ja testaajille vahvistaa, että tuote täyttää käyttäjän pitää ilman vikoja.
toteuttamiskelpoinen
vaatimusten pitäisi sopia nykyisen ympäristön todellisuuteen, mukaan lukien budjetti, Aikajana ja teknologia. Niiden ei pitäisi riippua tulevista teknologisista läpimurroista.,
Joustava
Koska asiat voivat muuttua työympäristössä, SRS-asiakirjan tulisi olla tarpeeksi joustava, jotta päivitykset. Älä lisää tarpeettomia tietoja useisiin osioihin, jotka on päivitettävä jokaisen muutoksen yhteydessä.
Todennettavissa
Jokainen kehitystiimi olisi pitänyt tutustua asiakirjaan, jotta he voivat viitata sen niin usein kuin on tarpeen. Vaatimusten on oltava tarkkoja, jotta tiimin jäsenten ei tarvitse pyytää lisätietoja. Niiden kaikkien pitäisi olla saatavilla SRS-asiakirjassa.,
yhdenmukaiset
vaatimusten tulisi sopia keskenään. Yksi osa vaatimuksesi asiakirjasta ei saa olla ristiriidassa toisen kanssa. Asiakirja tulee muotoilla johdonmukaisesti ja käyttää samaa terminologiaa koko ajan.
Ei Toteutuksen Rajoitteet
SRS-asiakirjan tulee olla riittävän yksityiskohtainen, jotta sen homman, mutta ei pitäisi olla liian täsmällinen, koska se voi rajoittaa kehitystä. Paljon kehitystä riippuu kolmannen osapuolen palveluista, joita kehittäjät eivät voi hallita.,
tarkat
vaatimukset-asiakirjassa olevat tavoitteet on täsmennettävä sekaannusten välttämiseksi. Vältä seuraavia:
- porsaanreiät: ”sovelluksen pitäisi latautua 3 sekunnissa, jos se voidaan tehdä.”
- epäselvyys: ”MVP-tuote tulisi julkaista mahdollisimman nopeasti.”
- subjektiivisuus: ”käyttöliittymän pitäisi olla käyttäjäystävällinen.”
- superlatiivit: ”tämän pitäisi olla luokkansa paras sovellus.”
- vertaileva: ”tämän sovelluksen pitäisi olla parempi kuin Slack.,”
Ohjelmiston vaatimusmäärittely (SRS) Esimerkki
Tässä on leikattu alas esimerkki SRS-dokumentti yritys chat app nimeltään eChat:
Johdanto
Tämän dokumentin tiedot hankkeen suunnitelma kehittämiseen ”eChat.”
Se on tarkoitettu kehittäjille, suunnittelijat ja testaajat työskentelevät ”eChat” sekä hanke sijoittajille., Tämä suunnitelma sisältää yhteenvedon:
- miten järjestelmä toimii
- laajuus hankkeen kehittämisen näkökulma
- tekniikka, jota käytetään kehittää hankkeen, ja
- mittareita käytetään määrittämään hankkeen etenemisestä
- Yleinen Kuvaus
Yritykset tarvitsevat kauko viestintävälineitä, erityisesti nyt, että yhä useammat ihmiset ovat työskentelevät kotoa. Ongelmana on, että useimmat yritykset päätyvät käyttämään useita sovelluksia tämän saavuttamiseksi: yksi tekstikeskusteluun, yksi videochattiin ja yksi konferensseihin ja kokouksiin., ”eChat” ratkaisee tämän ongelman yhdistämällä nämä ominaisuudet yhteen sovellukseen.
Lataa raportti
Asiakkaat
asiakas on yritys yritykset. Se ei kohdistu suureen yleisöön.
toiminnallisuus
- käyttäjien pitäisi pystyä kirjautumaan enterprise LDAP-tileille.,
- käyttäjien tulisi voida luoda tilapäisiä keskusteluryhmiä, jotka koostuvat käyttäjäryhmistä ja lähettää yksityisviestejä yksittäisille käyttäjille.
- käyttäjien pitäisi voida keskustella tekstiviestillä, jonka avulla he voivat murtautua viestiketjuihin.
- sovelluksen pitäisi pystyä käsittelemään enintään 100 käyttäjän ryhmävideokeskustelua kerrallaan.
Platform
sovellus kehitetään React Native-muodossa mahdollistamaan verkkopohjaisen sovelluksen, iOS-mobiilisovelluksen ja Android-mobiilisovelluksen luomisen.
nämä sovellukset liitetään REST API rakennettu.,NET Core tallentaa ja hakea tietoja MySQL-tietokannasta.
tunnistautuminen tapahtuu olemassa olevien LDAP-laitteistojen kautta.
Kehitystä Vastuuta
kehittäjille ”eChat” joukkue on vastuussa kirjallisesti kaikki koodi sovellus, kehittää tietokanta, ja hallinta tiedotteet.,
Käyttäjä-Luokka ja Ominaisuudet
Siellä on luokan käyttäjät kutsutaan admin, jolla on oikeudet käyttää kaikkia toimintoja app, mukaan lukien:
- Luoda kanavia, jossa useat käyttäjät voivat olla vuorovaikutuksessa
- Joten nämä kanavat yleisölle koko yritys tai yksityinen ryhmä ihmisiä
- Poistamalla nämä kanavat
- Arkistointi nämä kanavat
Standard käyttäjät voivat käyttää kaikkia toimintoja app, paitsi kaikki edellä mainitut.,
Ominaisuudet
Toiminnalliset Vaatimukset
- Käyttäjien tulisi pystyä luomaan ad hoc chat-ryhmät, joissa sarjaa käyttäjien ja lähettää yksityisiä viestejä muille käyttäjille.
- käyttäjien pitäisi voida keskustella tekstiviestillä, jonka avulla he voivat murtautua viestiketjuihin.
- chatit pitäisi voida arkistoida toistaiseksi, joten käyttäjät voivat viitata menneisiin keskusteluihin.
- käyttäjien pitäisi pystyä lataamaan tiedostoja keskusteluihin viitteeksi.
- Ulkoinen Liitäntä Vaatimukset
käyttöliittymä
- Front-end ohjelmistoja: React Native
- Back-end ohjelmistoja: .,s-käyttöjärjestelmissä kautta heidän oletusselaimeksi
- iPhone
- Android
- Ei-Toiminnalliset Vaatimukset
Suorituskyky Vaatimukset
- hakemus pitäisi ladata, ja voidaan käyttää 3 sekunnin kuluessa
- sovelluksen pitäisi päivittää käyttöliittymä, – vuorovaikutus 2 sekunnin kuluessa
- Tietokanta on normalisoitu estää tarpeettomia tietoja, ja parantaa suorituskykyä
- tietokanta olisi jaettava estää seisokkien
Turvallisuus Vaatimukset
- Tietokannat pitäisi käyttää sharding on tarpeeton, estää tietojen menetyksen.,
- tietokantojen varmuuskopiot tulee tehdä tunneittain ja säilyttää viikon ajan.
turvallisuusvaatimukset
- kaikki REST API: ssa käytetyt avaimet tulee säilyttää turvallisesti.
- vain REST API: n pitäisi pystyä yhdistämään tietokantoihin.
- tietokantojen pitäisi olla palomuurin takana.
Ohjelmistojen Laatu Ominaisuudet
- Saatavuus: Koska tämä sovellus on kriittinen liiketoiminnan viestintä, meillä on tavoite neljä ysiä(99.99%) saatavuus.,
- oikeellisuus: sovelluksen ei pitäisi koskaan sallia kenenkään lukea viestejä tai keskusteluja, joita ei ole tarkoitettu kyseiselle henkilölle.
- ylläpidettävyys: sovelluksen tulisi käyttää jatkuvaa integrointia, jotta ominaisuudet ja virheenkorjaukset voidaan ottaa käyttöön nopeasti ilman seisokkeja.
- käytettävyys: käyttöliittymän pitäisi olla helppo oppia ilman opetussuunnitelmaa ja antaa käyttäjien saavuttaa tavoitteensa virheettömästi.
Yhteenveto
SRS-asiakirja on välttämätön osa ohjelmistokehitysprojektia., Tiekartta antaa suuntaa kaikille hankkeeseen osallistuville, joten lopputuote vastaa käyttäjän tarpeita.
ilman täydellistä SRS-asiakirjaa ennen projektin aloittamista on vaikea sanoa, milloin projekti on valmis ja se voi siirtää kehityksen tahattomien ominaisuuksien luomiseen. SRS-dokumentilla voit arvioida projektin tarkasti ja määrittää tehtävät tehokkaasti.
SRS-dokumentin luominen voi olla aikaa vievä, pikkutarkka prosessi., Onneksi relevantin tiimi on auttanut yli 200 yritystä luomaan SRS-dokumentteja ja lanseeraamaan uusia tuotteita. Olemme valmiita auttamaan seuraava ohjelmistoprojekti, vain pudota meille linja.