Cerințe software - un set de solicitări / declarații privind atributele, proprietățile sau calitățile unui sistem software care urmează să fie implementat. Sarcini pentru dezvoltarea/modernizarea software-ului (SW) sunt create în procesul de elaborare (analiza și sinteza).
Cerințele pot fi exprimate sub formă de enunțuri text și modele grafice .
În abordarea tehnică clasică, un set de cerințe este utilizat în etapa de proiectare a software-ului. Cerințele sunt, de asemenea, utilizate în procesul de verificare a software-ului, deoarece testele se bazează pe cerințe.
Faza de dezvoltare a cerințelor poate fi precedată de un studiu de fezabilitate sau de o fază de analiză a proiectării conceptuale. Faza de dezvoltare a cerințelor poate fi împărțită în identificarea cerințelor (strângerea, înțelegerea, luarea în considerare și constatarea nevoilor părților interesate), analiză (verificarea integrității și completității), specificarea (documentarea cerințelor - sinteza modelelor text și grafice) și validare.
Caracteristicile calității cerințelor sunt definite diferit de diferite surse. Cu toate acestea, următoarele caracteristici sunt în general recunoscute :
| Caracteristică | Explicaţie |
|---|---|
| Singularitate | O cerință descrie un singur lucru. |
| completitudine | Cerința este complet definită într-un singur loc și toate informațiile necesare sunt prezente. |
| Urmare | Cerința nu intră în conflict cu alte cerințe și este pe deplin în concordanță cu documentația externă. |
| Atomicitatea | Cerința este „atomică”. Adică, nu poate fi defalcat într-o serie de cerințe mai detaliate fără pierderea completității. |
| Trasabilitate | Cerința îndeplinește integral sau parțial nevoile de afaceri, așa cum sunt declarate de părțile interesate și documentate. |
| Relevanţă | Cerința nu a devenit învechită în timp. |
| Fezabilitate | Cerința poate fi implementată în cadrul proiectului. |
| neambiguitate | Cerința este definită succint, fără a se recurge la jargon tehnic, acronime sau alt limbaj ascuns. Exprimă fapte obiective, nu opinii subiective. Este posibilă o singură interpretare. Definiția nu conține fraze neclare. Utilizarea aserțiunilor negative și a aserțiilor compuse este interzisă. |
| obligatoriu | O cerință reprezintă o caracteristică definită de un stakeholder, a cărei absență va duce la o inferioritate a soluției, care nu poate fi ignorată. O cerință opțională este o contradicție în însuși conceptul de cerință. |
| Verificabilitate | Fezabilitatea unei cerințe poate fi determinată prin una dintre cele patru metode posibile: inspecție, demonstrație, testare sau analiză. |
Toate revendicările trebuie să fie verificabile. Cea mai comună tehnică de verificare sunt testele. Dacă verificarea prin teste nu este posibilă, atunci ar trebui utilizată o altă metodă de verificare (analiza, demonstrație, inspecție sau revizuire a proiectului).
Anumite cerințe sunt în mod inerent neverificabile. Acestea includ cerințe care spun că sistemul nu trebuie să afișeze niciodată sau întotdeauna o anumită proprietate. Testarea corectă a acestor cerințe ar necesita un ciclu de testare nesfârșit. Astfel de cerințe ar trebui redefinite astfel încât să fie verificabile. După cum sa menționat mai sus, toate cerințele trebuie să fie verificabile.
Cerințele nefuncționale care nu sunt verificabile programatic ar trebui păstrate în continuare ca documentație a intenției clientului. Astfel de cerințe de produs pot fi traduse în cerințe de proces. De exemplu, o cerință nefuncțională conform căreia software-ul nu conține „pasaje secrete” poate fi satisfăcută prin înlocuirea acesteia cu o cerință de a utiliza programarea în pereche. Cerințele complexe de securitate pentru software de aviație pot fi îndeplinite urmând procesul de dezvoltare DO-178B .
La elaborarea cerințelor, apar adesea probleme de ambiguitate, incompletitudine și inconsecvență ale cerințelor individuale. Eliminarea acestor probleme în etapa de dezvoltare a cerințelor costă câteva ordine de mărime mai puțin decât rezolvarea acelorași probleme în etapele ulterioare de dezvoltare. Pentru a rezolva și elimina aceste probleme, există un proces de dezvoltare a cerințelor.
În dezvoltarea cerințelor, există un compromis tehnic între cerințele prea vagi și cerințele atât de detaliate încât:
Cerințele sunt de obicei folosite ca mijloc de comunicare între diferiți factori interesați. Aceasta înseamnă că cerințele ar trebui să fie simple și ușor de înțeles pentru utilizatorii și dezvoltatorii obișnuiți.
O specificație software este adesea denumită specificație tehnică .
Cel mai adesea, în practica rusă, un analist de sistem este responsabil pentru crearea unei specificații software , uneori un analist de afaceri .
Pentru modelele de cerințe grafice din punct de vedere istoric s-au folosit diagrame sau metodologii de modelare grafică: ER (IDEF1FX), IDEF0 , IDEF3 , DFD , UML , OCL , SysML , ARIS ( eEPC , VAD ).
În general, cerințele se modifică în timp. Odată ce cerințele sunt definite și aprobate, modificările ar trebui să facă obiectul controlului modificărilor. Pentru multe proiecte, cerințele se modifică înainte ca sistemul să fie finalizat. Acest lucru se datorează parțial complexității software-ului și faptului că utilizatorii nu știu de ce au nevoie cu adevărat. Această caracteristică a cerințelor a dat naștere procesului de management al cerințelor .
| Dezvoltare de software | |
|---|---|
| Proces | |
Concepte de nivel înalt | |
| Directii |
|
| Metodologii de dezvoltare | |
| Modele |
|
Cifre notabile |
|