De ce sunt cerințele importante în ingineria software?

În acest articol, analizăm importanța cerințelor în dezvoltarea de software și motivele pentru care neglijarea etapei cerințelor nu este o idee înțeleaptă atunci când construiți o aplicație.

„ Software de lucru peste documentație cuprinzătoare. ” Aceasta face parte din Manifestul Agile.

La suprafață, această afirmație poate părea să implice faptul că cerințele sunt lipsite de consecință și nu sunt demne de timpul respectiv. Unii dezvoltatori și clienții lor renunță la documentația adecvată. Dar asta este o greșeală.

Să începem cu o mică explicație a cerințelor în ceea ce privește dezvoltarea software-ului.

Care sunt cerințele în dezvoltarea aplicațiilor?

Nu este ca și cum definiția cerințelor se schimbă semnificativ atunci când este aplicată dezvoltării de software. Cerințele specifică pur și simplu ce caracteristici ar trebui să includă un produs și cum ar trebui să funcționeze aceste caracteristici. Ceea ce este important este abordarea lor.

Adunarea și analizarea cerințelor este una dintre etapele inițiale ale procesului de dezvoltare software atât în ​​metodologiile Agile, cât și în cele ale cascadei. În faza cerințelor etapei de validare a ideii, trebuie să se ajungă la un acord între client și dezvoltator cu privire la ce anume ar trebui să facă produsul final și cum. Cerințele în dezvoltarea aplicațiilor sunt de obicei destul de detaliate.

Cum se definesc cerințele software

Pot exista mai multe tipuri de cerințe în dezvoltarea de software.

Cerințe de afaceri

De ce are nevoie clientul de aplicație? Dintr-o privire, aceste informații pot părea inutile sau chiar redundante. La urma urmei, aveți un client care dorește să vă plătească pentru a crea o aplicație. De ce ar trebui să-ți pese de motivele lor?

Ei bine, dacă te mândrești cu ceea ce faci și te străduiești să construiești produse de calitate, ar trebui să-ți pese de ce la fel de mult ca și ce ești și cum e.

Importanța cerințelor afacerii este că acestea oferă o viziune asupra obiectivului final. Având în vedere obiectivul, dezvoltatorii pot stabili priorități. De asemenea, își pot aplica expertiza pentru a oferi soluții mai bune pentru a atinge aceste obiective. Există un motiv pentru care analiza afacerii este inclusă în procesul de dezvoltare la majoritatea companiilor.

Fără cerințe comerciale clare, pot fi luate decizii slabe. Deciziile care vor încetini dezvoltarea, vor perturba termenele limită și vor duce la etape de dezvoltare suplimentare.

Cerințe software

Există două tipuri de cerințe: funcționale și nefuncționale. În termeni simpli, distincția este următoarea:

Cerințele funcționale sunt ce cerințe - Ce este proiectat să facă acest sistem? După cum sugerează și numele, acestea descriu funcționalitatea software-ului.

Cerințele nefuncționale sunt cum sunt cerințele - Cum va face acest sistem ceea ce este conceput să facă? Aceste cerințe descriu modul în care fiecare caracteristică ar trebui să se comporte în ce condiții, ce limitări ar trebui să existe și așa mai departe.

Cei doi merg mână în mână. Cerințele nefuncționale completează și definesc cerințele funcționale. De exemplu, să ne imaginăm că realizăm o aplicație de mesagerie.

Principalele cerințe funcționale, în acest caz, ar fi:

1. Aplicația trebuie să poată trimite mesaje.
2. Aplicația trebuie să accepte transferul de fișiere și conținut media.
3. Etc.

Acestea sunt destul de simple și este ușor de înțeles de ce sunt importante cerințele funcționale: descriu funcționalitatea. În acest exemplu, cerințele nefuncționale ar putea fi după cum urmează :

1. Serviciul trebuie să ofere funcționalitate completă în toate browserele majore: Microsoft Edge, Google Chrome (cele mai recente două versiuni), Mozilla Firefox (cele mai recente două versiuni), Opera, Safari (ultima versiune).
2. Aspectele mobile trebuie să fie acceptate.
3. Etc.

După cum puteți vedea, cerințele funcționale sunt practic o listă de funcționalități care trebuie incluse în sistem . Pe de altă parte, cerințele nefuncționale sunt specifice. Sunt necesare pentru a defini condițiile de dezvoltare și testare.

Este adevărat că procesul ager iterativ implică posibilitatea de a introduce modificări în orice stadiu al dezvoltării , dar asta nu implică cu totul cerințele anterioare. Trebuie doar să le faceți flexibile.

Fără parametrii precizați specificați, este imposibil să înțelegem dacă o caracteristică este proiectată exact așa cum ar trebui să fie.

Cerințele trebuie analizate și documentate cu atenție. De ce? Pentru că atât de multe lucruri se pot strică dacă nu sunt.

Sabia lui Damocles a cerințelor nedocumentate

Importanța cerințelor software este înțeleasă cel mai bine de specialiștii în asigurarea calității. Atunci când cerințele proiectului nu sunt prezentate în mod corespunzător, QA-urile primesc cea mai mare lovitură. Imaginați-vă că încercați să determinați dacă software-ul este implementat corect fără linii directoare clare cu privire la ce ar trebui să facă și cum ar trebui să o facă. E o nebunie totală.

Cu toate acestea, această problemă nu afectează numai testerii. A nu avea specificații oficiale înseamnă următoarele:

• Nu există o înțelegere clară a ceea ce constituie un produs finit sau chiar o caracteristică.
• Clientul nu știe la ce să se aștepte până la sfârșitul dezvoltării și la ce plătește.
• Dezvoltatorii sunt lăsați agățați, trebuind să descopere specificul caracteristicilor pe baza a ceea ce s-a spus și a modului în care au înțeles-o ei înșiși.
• Gandaci. Sunt peste tot.

Cerințele nedocumentate duc la comunicări greșite din toate părțile. Nu este deloc rar ca un client și un dezvoltator să înțeleagă aceiași termeni diferit. Mai ales dacă vorbim despre o companie de dezvoltare de externalizare care nu cunoaște intim afacerea clientului.

La rândul său, comunicarea necorespunzătoare stabilește o cale directă către relucrarea constantă, modificările și remedierea erorilor. Există șansa ca totul să meargă conform planificării, fără cerințe documentate, dar este subțire. De obicei, acest lanț se termină cu termene și costuri perturbate care trec prin acoperiș.

Pentru a asigura o dezvoltare lină a proiectului, toate părțile produsului și procesul de dezvoltare al acestuia trebuie înțelese de fiecare membru al echipei în același mod. Pentru a se asigura că dezvoltatorii văd fiecare caracteristică a produsului exact așa cum o face clientul, se face o specificație de cerințe software (SRS).

Diavolul este în detalii: Ce face o bună specificație a cerințelor software?

Acum, specificațiile cerințelor software reale pot fi excepțional de detaliate sau pot fi doar o schiță de caracteristici. Nivelul de detaliu depinde de o serie de factori.

Cerințele de înaltă calitate sunt ușor de înțeles de către toți cei implicați în proiect. Aceasta include clientul, care poate sau nu să fie bine versat în aspectele tehnice. Unele companii solicită o listă de cerințe extrem de tehnică și foarte detaliată, în timp ce altele preferă cerințele în termeni simpli.

Indiferent de cât de tehnică va fi documentația dvs., există reguli generale pentru gestionarea cerințelor software. Există chiar și un standard oficial: IEEE Std 830-1998, „Practică recomandată pentru specificațiile cerințelor software”. Iată ce ar trebui să fie un SRS bun, conform standardului:

• Corect . Acesta este ușor. Corectitudinea SRS este verificată de către client și dezvoltator pe baza acordului pe care îl au. SRS trebuie să fie în conformitate cu specificațiile tehnice și cu toate celelalte documentații de proiect care guvernează.

• Neambigu . Unul dintre principalele scopuri ale unui SRS este de a elimina comunicarea greșită. De aceea, fiecare specificație de cerință trebuie scrisă pentru a avea o singură interpretare posibilă. Nu este neobișnuit ca un SRS să includă un glosar.

• Complet . Cu cât aplicația este mai complexă, cu atât SRS trebuie să fie mai detaliat. Un SRS complet acoperă fiecare parte, de la cerințele de performanță la funcționalitate. De asemenea, stabilește anumite limite pentru proiectare. Cu toate acestea, nu specifică niciodată un design exact. Oferă doar parametri.

• Coerente . Coerența internă înseamnă că nicio afirmație dintr-un SRS nu contrazice alte afirmații din același SRS. Acesta este un alt motiv pentru a include un glosar - astfel încât orice obiect, proces și specificație din document să fie desemnat cu un termen precis.

• Clasificat pentru importanță și / sau stabilitate . În majoritatea cazurilor, există cerințe obligatorii și cerințe dorite. Este important ca specificațiile cerințelor software să eticheteze în mod clar ambele tipuri. Acest lucru îi va ajuta pe dezvoltatori și pe managerii de proiect atunci când vor crea un plan pas cu pas pentru proiect.

• Verificabil . Trebuie să existe o modalitate de a testa fiecare cerință pe care o includeți în SRS. Pentru a fi considerate verificabile, cerințele trebuie să conțină concepte măsurabile și concrete.

• Modificabil . Aceasta se referă la structura SRS. Pentru a nu perturba fluxul de lucru al proiectului atunci când trebuie să implementați modificări, SRS trebuie să fie clar și ușor de schimbat, iar cerințele nu trebuie repetate.

• Trasabil . Ar trebui să fie ușor să se identifice sursa fiecărei cerințe prevăzute în SRS.

Acestea sunt recomandări . În realitate, companiile pot renunța la unele dintre aceste puncte în funcție de proiect, client și echipă. Dar este întotdeauna bine să ai niște îndrumări.

Cerințele sunt la îndemână, indiferent dacă vă specializați în dezvoltarea de aplicații iOS sau Android sau dezvoltare web. Sunt documente de uz general. Și aspectul acestora depinde în general de dezvoltatori și de clienții lor.

Deoarece un SRS ar trebui să fie ușor de înțeles pentru toate părțile implicate, cel mai bun mod de a le concepe este, de asemenea, discutabil. Unii preferă tabele, unii preferă liste. Există dezvoltatori care preferă specificațiile lor sub formă vizuală ca diagrame și diagrame ale fluxului de date. Nu există o singură modalitate corectă de a crea un document de specificare a cerințelor.

Concluzie

Iată cele mai frecvente puncte atunci când cerințele software sunt utile:

• Înțelegerea obiectivului
• Estimarea costurilor de dezvoltare
• Crearea unui program cuprinzător
• Stabilirea priorităților

Faptul că documentează cerințele este ceva ce fiecare dezvoltator decide de la sine. Iar valoarea cerințelor variază în funcție de amploarea proiectului. La Mind Studios, preferăm să avem lucrurile în ordine, așa că documentăm toate cerințele . Dacă sunteți interesat de modul în care o facem sau aveți întrebări cu privire la valoarea cerințelor în general, contactați-ne prin formularul nostru de contact .