#etichetă produs

o specificație cerințe software (document SRS) descrie modul în care ar trebui dezvoltat un sistem software. Mai simplu spus, un SRS oferă tuturor celor implicați o foaie de parcurs pentru acel proiect.Acesta oferă definiții de înaltă calitate pentru specificațiile funcționale și nefuncționale ale software-ului și poate include, de asemenea, cazuri de utilizare care ilustrează modul în care un utilizator ar interacționa cu sistemul la finalizare.,notă: permiteți-ne să vă ajutăm să scrieți o specificație a cerințelor Software. Solicitați un apel la CTO-ul nostru completând acest formular.

cuprins

de ce este important un document SRS? să presupunem că doriți să creați o aplicație de chat cu un aspect și o funcționalitate specifică și doriți ca aceasta să fie orientată în mod special către întreprinderi. Simțiți că puteți elimina funcțiile suplimentare pe care aplicațiile de chat comerciale le folosesc pentru a face apel la public și pentru a vă concentra pe funcțiile de care întreprinderile au nevoie. Dar nu ești Dezvoltator.,deci, trebuie să externalizați dezvoltarea aplicației. Dar, de asemenea, trebuie să vă asigurați că oricine angajați să vă transforme ideea în realitate știe exact ce încercați să realizați. Fără toate detaliile pentru a termina aplicația, timpul și costul pot ieși rapid din mână. Dezvoltatorii pot face o întoarcere greșită și trebuie să refactoreze Codul dacă produsul finit nu se potrivește cu imaginea pe care ați avut-o în cap.

un document SRS vă obligă să puneți ideea pe hârtie pentru a acoperi toate aceste detalii. Trebuie să traduceți această idee într-o limbă pe care dezvoltatorii o înțeleg., Un document SRS descrie ce dorește un client și ce vor oferi dezvoltatorii. Este acordul scris cu privire la fiecare detaliu al aplicației.

având un set clar de cerințe asigură că o echipă de dezvoltare creează software care să răspundă nevoilor clienților. Un SRS va ajuta la estimarea costului muncii și la acoperirea domeniului de aplicare al proiectului. De asemenea, oferă programatorilor o idee despre stiva tehnică de care vor avea nevoie și îi ajută să își planifice activitatea, dar asta nu este totul: designerii obțin informații despre proiect prin documente SRS, astfel încât să poată potrivi designul cu cazul de utilizare.,

  • testerii primesc liniile directoare pentru crearea cazurilor de testare care să corespundă nevoilor afacerii.
  • utilizatorii finali folosesc SRS pentru a înțelege software-ul.Acesta oferă investitorilor o imagine de ansamblu a caracteristicilor sistemului, astfel încât să poată lua decizii de investiții.un SRS este important deoarece este o singură sursă de informații și așteptări, care împiedică neînțelegerile dintre managerii de proiect, dezvoltatori, designeri și testeri.

    ce include un SRS?,

    un SRS ar trebui să aibă suficiente informații pentru ca dezvoltatorii să completeze software-ul descris. Nu numai că stabilește descrierea software-ului în curs de dezvoltare, ci și scopul pe care îl va servi: ce ar trebui să facă software-ul și cum ar trebui să funcționeze.,de software-ul sau ce ar trebui să facă

  • Performanța software-ului într-o situație de producție
  • cerințe Non-funcționale
  • interfețelor Externe sau cum software-ul interacționează cu hardware-ul sau alte software-ul trebuie să se conecteze la
  • Design constrângeri sau limitări de mediu care software-ul va rula în
  • Diferența Între Funcționale și Non-funcționale Cerințele

    cerințe Funcționale sunt obiectivele noului sistem sunteți de proiectare., Acestea descriu sistemul și modul în care acesta va funcționa pentru a ajuta la sarcinile unui utilizator. Acestea definesc modul în care sistemul va răspunde la introducerea utilizatorului și va avea detalii despre calcule, introducerea datelor și procesele de afaceri. Puteți lua în considerare cerințele funcționale o descriere detaliată a caracteristicilor aplicației și a nevoilor utilizatorului. Fără a îndeplini cerințele funcționale, sistemul nu va funcționa.

    în timp ce cerințele funcționale specifică ce face un sistem, cerințele nefuncționale descriu modul în care sistemul o va face. Cerințele nefuncționale nu afectează funcționalitatea aplicației., Chiar și fără a îndeplini cerințele nefuncționale, sistemul va îndeplini sarcinile dorite.

    cerințele nefuncționale sunt, de asemenea, importante deoarece definesc caracteristicile generale care afectează experiența utilizatorului. În loc să se concentreze pe cerințele utilizatorilor, aceștia se concentrează pe așteptările utilizatorilor și acoperă subiecte precum performanța, securitatea, fiabilitatea, disponibilitatea și gradul de utilizare.,cel mai bine este să organizați procesul pe care îl utilizați pentru a scrie un document SRS începând cu un schelet și informații generale despre software-ul pe care îl dezvoltați și terminând prin adăugarea de detalii pentru a vă dezvolta proiectul. Iată șase pași implicați în crearea unui document SRS:

    obțineți documentul de specificație a cerințelor Software

    am ajutat peste 200 de companii să își construiască produsele software. Angajați analistul nostru de afaceri cu 6 ani de experiență pentru a scrie un SRS pentru dvs.,

    cerere SRS

    crearea unui contur

    primul pas în acest proces este crearea unui contur pentru SRS. Puteți crea acest lucru singur sau puteți utiliza un șablon SRS existent ca punct de plecare. Aici este un exemplu de bază de SRS schiță:

    ×

    Cum să Atingeți În Global de Talente pentru a Umple Tech Poziții mai Repede
    În această carte electronică, veți învăța cum să rezolve tech deficit talent atingând în global de talente.,

    Descărcați ebook

    1. Introducere
    2. Scop
    3. Publicul țintă
    4. Utilizarea Preconizată
    5. Aplicare
    6. Definiții
    7. Descriere Generală
    8. Utilizatorul are Nevoie
    9. Ipoteze și Dependențele
    10. Sistem de Caracteristici și Cerințe
      1. Cerințe Funcționale
      2. Cerințele interfețelor Externe
      3. Sistem de Caracteristici
      4. Cerințe Non-funcționale

    Defini Scopul

    Odată ce aveți o schiță, trebuie să-l scrii., Începeți cu definirea scopului produsului în introducerea SRS. Aici veți descrie publicul vizat și modul în care vor folosi produsul. Iată cum ar trebui să structurii scopul:

    • Definirea produsului domeniul de aplicare
    • Descrie valoarea pe care o va livra
    • Spectacol care va utiliza software-ul
    • Detaliu modul în care aceasta va ajuta cu destinat utilizatorilor de locuri de muncă

    Da o imagine de Ansamblu

    După definirea produsului scop, rezuma modul în care va lucra., Aici veți oferi o descriere generală a caracteristicilor software-ului și a modului în care acestea se potrivesc nevoilor utilizatorului.de asemenea, veți descrie ipotezele pe care le faceți cu privire la funcționalitatea produsului și la orice depinde de acesta în ecosistemul tehnologic actual.

    descrieți cerințele funcționale și nefuncționale

    acum că ați scris informațiile generale, este timpul să obțineți mai specific. Completarea prezentării dvs. de ansamblu înainte de a lucra la cerințele funcționale și nefuncționale vă oferă o referință pentru a vă asigura că îndepliniți nevoile de bază ale utilizatorului în timp ce completați detaliile.,această descriere detaliată a cerințelor sistemului este componenta cea mai esențială a unui document SRS. Descrieți cerințele funcționale suficient de detaliat, astfel încât dezvoltatorii să poată ajunge la lucru și cerințele nefuncționale, cum ar fi specificațiile de securitate și performanța.

    aici adăugați cazuri de utilizare pentru a descrie în mod viu modul în care un utilizator va interacționa cu sistemul dvs. Este locul în care obiectivele proiectului dvs. sunt detaliate și vor măsura modul în care proiectul progresează în timpul dezvoltării.,ultimul pas în crearea proiectului documentului SRS este adăugarea oricăror detalii care ar putea ajuta dezvoltatorii să termine lucrarea sub formă de anexe, glosare de termeni și referințe.după ce ați adăugat suficiente detalii la SRS pentru a descrie ce ar trebui să facă sistemul, este timpul ca părțile interesate să aprobe documentul.cel mai probabil va trebui să faceți o prezentare persoanelor implicate în procesul de dezvoltare., Aceștia pot solicita modificări și va trebui să actualizați documentul SRS pe baza feedback-ului părților interesate înainte de aprobarea finală.acesta este un semn bun. Aceasta înseamnă că atât dezvoltatorii, cât și părțile interesate fac documentul mai precis, astfel încât proiectul este mai puțin ca să meargă pe pistă.

    cum se scrie cazuri de utilizare a Software-ului într-un SRS

    un caz de utilizare descrie modul în care un utilizator va interacționa cu sistemul. Acesta va descrie produsul din punctul de vedere al utilizatorului final într-un format simplu de poveste. Scrierea cazurilor de utilizare vă obligă să vă gândiți la ce vor face utilizatorii cu software-ul și cum va răspunde., Este vizualizarea reală a cerințelor funcționale.

    iată pașii pe care îi puteți urma pentru a scrie un caz de utilizare:

    1. descrieți utilizatorii finali ai produsului.
    2. concentrați – vă pe unul dintre acești utilizatori.
    3. împărțiți interacțiunile acestui utilizator în cazuri de utilizare. Fiecare interacțiune este un caz de utilizare.
    4. descrieți succesiunea evenimentelor pentru fiecare caz de utilizare.
    5. scrieți o descriere detaliată a acțiunilor utilizatorului și a modului în care sistemul ar trebui să răspundă.
    6. extindeți fiecare caz de utilizare cu acțiuni alternative ale utilizatorilor și răspunsuri de sistem.
    7. repetați 1-6 pentru fiecare tip de utilizator final.,

    care sunt caracteristicile unui mare SRS?

    există caracteristici specifice pe care fiecare SRS ar trebui să le aibă. Examinând această listă și comparând-o cu SRS, vă puteți asigura că va fi un document util pentru toate părțile interesate.

    Explicit

    un document SRS ar trebui să fie ușor de înțeles. Nimic nu trebuie să fie vag, deci nu există neînțelegeri între părțile interesate.,cerințele din documentul SRS trebuie să fie măsurabile, astfel încât produsul finit să poată fi validat și verificat conform specificațiilor.un document SRS ar trebui să aibă suficiente informații pentru ca echipa dvs. de dezvoltare să termine produsul și pentru testeri să valideze că produsul satisface nevoia utilizatorului fără erori.

    viabil

    cerințele ar trebui să se potrivească realității mediului actual, inclusiv bugetul, calendarul și tehnologia. Nu ar trebui să depindă de viitoarele descoperiri tehnologice.,deoarece lucrurile s-ar putea schimba în mediul de lucru, documentul SRS ar trebui să fie suficient de flexibil pentru a permite actualizări. Nu adăugați informații redundante la mai multe secțiuni care trebuie actualizate cu fiecare modificare.

    verificabil

    toți cei din echipa de dezvoltare ar trebui să aibă acces la document, astfel încât să îl poată consulta cât de des este necesar. Cerințele trebuie să fie precise, astfel încât membrii echipei să nu fie nevoiți să ceară mai multe detalii. Toate acestea ar trebui să fie disponibile în documentul SRS.,

    consecvent

    cerințele ar trebui să se potrivească reciproc. O secțiune a documentului dvs. de cerințe nu trebuie să intre în conflict cu alta. Documentul ar trebui să fie formatat în mod consecvent și să utilizeze aceeași terminologie pe tot parcursul.

    Fără Aplicarea Constrângerilor

    Un SRS document ar trebui să fie suficient de detaliate pentru a termina treaba, dar nu trebuie să fie prea specifice, pentru că s-ar putea limita dezvoltarea. O mulțime de dezvoltare depinde de serviciile terților pe care dezvoltatorii nu le au control.,obiectivele dintr-un document de cerințe trebuie să fie precise pentru a evita confuzia. Evitați următoarele:

    • lacune: „aplicația ar trebui să se încarce în 3 secunde dacă se poate face.”
    • ambiguitate: „produsul MVP trebuie lansat cât mai repede posibil.”
    • subiectivitate: „UI ar trebui să fie ușor de utilizat.”
    • superlative: „aceasta ar trebui să fie cea mai bună aplicație din clasa sa.”
    • comparativ: „această aplicație ar trebui să fie mai bună decât Slack.,”

    O Cerință Software-ul caietul de sarcini (SRS), de Exemplu,

    Aici este o împodobite jos exemplu de SRS document pentru o întreprindere de chat app numit eChat:

    Introducere

    Acest document detaliile planului proiectului pentru dezvoltarea de „eChat.”

    este destinat dezvoltatorilor, designerilor și testerilor care lucrează la „eChat”, precum și investitorilor de proiecte., Acest plan va include un rezumat al:

    • modul în care sistemul va funcționa
    • domeniul de aplicare a proiectului de dezvoltare punct de vedere
    • tehnologia utilizată pentru a dezvolta proiectul, și
    • valorile utilizate pentru a determina progresul proiectului
    • Descriere Generală

    Companiile au nevoie de instrumente de comunicare la distanță, mai ales acum că mai multe persoane sunt de lucru de la domiciliu. Problema este că majoritatea companiilor ajung să folosească mai multe aplicații pentru a realiza acest lucru: una pentru chat text, una pentru chat video și una pentru conferințe și întâlniri., „eChat” va rezolva această problemă prin combinarea acestor caracteristici într-o singură aplicație.

    ×

    de Ce aceste 200 de companii de tehnologie & startup externaliza Ucraina

    Descărca documentație

    Clienții

    clienții vor fi companii de tip enterprise. Nu va viza publicul larg.

    funcționalitate

    • utilizatorii ar trebui să se poată înscrie cu conturile LDAP enterprise.,
    • utilizatorii ar trebui să poată crea grupuri de chat ad-hoc care să cuprindă seturi de utilizatori și să trimită mesaje private utilizatorilor individuali.
    • utilizatorii ar trebui să poată avea chat-uri text pe care le pot rupe în fire.aplicația ar trebui să poată gestiona chat-ul video de grup de până la 100 de utilizatori simultan.

    platformă

    aplicația va fi dezvoltată în React Native pentru a permite crearea unei aplicații bazate pe web, a unei aplicații mobile iOS și a unei aplicații mobile Android.aceste aplicații se vor conecta la un API REST construit cu .,Net Core pentru a stoca și de a prelua date dintr-o bază de date MySQL.

    autentificarea se va face prin instalări LDAP existente.

    Responsabilități de Dezvoltare

    dezvoltatorii de pe „eChat” echipa va fi responsabil pentru scris tot codul pentru aplicarea, dezvoltarea de baze de date, și gestionarea de presă.,va exista o clasă de utilizatori numită admin care va avea permisiuni pentru a accesa toate funcționalitățile aplicației, inclusiv:

    • crearea de canale în care mai mulți utilizatori pot interacționa
    • făcând aceste canale publice pentru întreaga companie sau private pentru un grup de persoane
    • ștergerea acestor canale
    • arhivarea acestor canale

    utilizatorii Standard vor avea acces la toate funcționalitățile aplicației, cu cele enumerate mai sus.,

    caracteristicile sistemului

    cerințe funcționale

    • utilizatorii ar trebui să poată crea grupuri de chat ad-hoc care să cuprindă seturi de utilizatori și să trimită mesaje private altor utilizatori.
    • utilizatorii ar trebui să poată avea chat-uri text pe care le pot rupe în fire.
    • chaturile ar trebui să poată fi arhivate la nesfârșit, astfel încât utilizatorii să poată face referire la chaturile din trecut.
    • utilizatorii ar trebui să poată încărca fișiere în chat-uri pentru referință.
    • cerințe de interfață externă

    interfețe utilizator

    • software Front-end: React nativ
    • software Back-end:.,s sisteme de operare prin browserul lor web implicit
    • iPhone
    • Android
    • cerințe nefuncționale

    cerințe de performanță

    • aplicația ar trebui să se încarce și să fie utilizabilă în 3 secunde
    • aplicația ar trebui să actualizeze interfața de interacțiune în 2 secunde
    • baza de date ar trebui să fie normalizată pentru a preveni datele redundante și>

    cerințe de siguranță

    • bazele de date ar trebui să utilizeze sharding pentru a fi redundante pentru a preveni pierderea datelor.,
    • backup-urile bazelor de date trebuie făcute pe oră și păstrate timp de o săptămână.

    cerințe de securitate

    • orice chei utilizate pentru API-ul REST trebuie stocate în siguranță.
    • numai API-ul REST ar trebui să se poată conecta la bazele de date.
    • bazele de date ar trebui să fie în spatele unui firewall.

    atribute de calitate Software

    • disponibilitate: deoarece această aplicație este esențială pentru comunicarea de afaceri, vom avea un obiectiv de patru nouari(99,99%) disponibilitate.,
    • corectitudine: aplicația nu ar trebui să permită nimănui să citească mesaje sau discuții care nu sunt destinate acelei persoane.
    • mentenabilitate: aplicația ar trebui să utilizeze integrarea continuă, astfel încât caracteristicile și remedierile de erori să poată fi implementate rapid fără întreruperi.
    • uzabilitate: interfața ar trebui să fie ușor de învățat fără un tutorial și să permită utilizatorilor să își atingă obiectivele fără erori.

    rezumat

    un document SRS este o parte necesară a finalizării unui proiect de dezvoltare software., Foaia de parcurs este cea care dă direcție tuturor celor implicați în proiect, astfel încât produsul final să răspundă nevoilor utilizatorului.

    fără un document SRS complet în loc înainte de a începe un proiect, va fi greu de spus atunci când un proiect este terminat și ar putea sidetrack de dezvoltare în crearea de caracteristici neintenționate. Un document SRS vă oferă posibilitatea de a estima un proiect cu precizie și de a atribui sarcini în mod eficient.

    crearea unui document SRS poate fi un proces consumator de timp, meticulos., Din fericire, echipa de la Relevant a ajutat peste 200 de companii să creeze documente SRS și să lanseze noi produse. Suntem gata să vă ajutăm cu următorul proiect software, trebuie doar să ne lăsați o linie.

    tag-uri: documentsoftware de dezvoltare